PhenixTweet

5 h.

a répondu au Message de yoyo64 - 5 h.

Ok, effectivement il manque le contexte du shop car la fonction $currency->update s'effectue dans le shop en cours.
Il faut donc bien rajouter ces lignes au début du foreach:

CODE
        Shop::setContext(
            Shop::CONTEXT_SHOP,
            (int)$shop['id_shop']
        );

5 h.

a répondu au Message de Eolia - 5 h.

apres j'ai ca aussi dans la base SELECT
id_shop id_currency iso_code conversion_rate
1 6 ARS 118.8609680000
1 7 BRL 5.7891780000
1 2 CNY 7.2846980000
1 4 DZD 151.8010410000
1 1 EUR 1.0000000000
1 5 RUB 87.4944280000
1 3 USD 1.1570420000
9 6 ARS 1.0000000000
9 7 BRL 1.0000000000
9 2 CNY 1.0000000000
9 4 DZD 1.0000000000
9 1 EUR 1.0000000000
9 5 RUB 1.0000000000
9 3 USD 1.1600000000
11 6 ARS 118.8609680000
11 7 BRL 1.0000000000
11 2 CNY 7.2846980000
11 4 DZD 151.8010410000
11 1 EUR 1.0000000000
11 5 RUB 87.4944280000

5 h.

a répondu au Message de Eolia - 5 h.

oui a rien mais la mise ajour des produit doit ce faire en mode multiboutique ou bien sur la boutique concernée

22 h.

a répondu au Message de yoyo64 - 22 h.

A quoi sert le Shop:setContext() ???

23 h.

a répondu au Message de Eolia - 23 h.

le probleme viendrais pas de cron_currency_rates.php
je me suis aider de codex il ma dit foreach(Shop::getShops() as $shop) {

if(!empty($id_shops[0]) && !in_array($shop['id_shop'], $id_shops)) {
continue;
}

Shop::setContext(
Shop::CONTEXT_SHOP,
(int)$shop['id_shop']
$last_update = Db::getInstance()->getValue('
SELECT `value`
FROM `'._DB_PREFIX_.'configuration`
WHERE `name` = "CURRENCIES_RATE_LAST_UPDATE"
AND `id_shop_group` = '.(int)$shop['id_shop_group'].'
AND `id_shop` = '.(int)$shop['id_shop'

1 jour

a répondu au Message de yoyo64 - 1 jour

Non, les prix sont toujours dan la monnaie par défaut en base de données, ensuite, en front office c'est la fonction displayprice qui effectue la conversion suivant la monnaie demandée.
Ce qui n'est pas normal c'est que vos taux de devises ne soient pas mis à jour.
Fonction Currency::refreshCurrencies();

2 jours

a répondu au Message de yoyo64 - 2 jours

exemple

SELECT
ps.id_shop,
ps.id_product,
p.reference,
ps.price
FROM ps_product_shop ps
INNER JOIN ps_product p
ON p.id_product = ps.id_product
WHERE p.reference = 'BR09280'
AND ps.id_shop IN (1, 9)

id_shop id_product reference price
1 16251 BR09280 129.000000
9 16251 BR09280 129.000000

le 9 devrais avoir le prix converti en usd soit 148,65
donc pohnix ne le fait pas automatique ?

2 jours

a répondu au Message de Eolia - 2 jours

non rien il en faite il ne mais pas a jour la table .cest bien ca ?
ps_product_shop.price
ps_product_attribute_shop.price

2 jours

a répondu au Message de yoyo64 - 2 jours

En mode debug, aucune erreur lors de la mise à jour des taux ?

2 jours

a répondu au Message de Eolia - 2 jours

ah ok mais alors pourquoi les prix ne change pas dans la base jai de pas de override pourtant

2 jours

a répondu au Message de yoyo64 - 2 jours

Oui mais je ne pige pas l'intérêt car si tu changes les prix de base en bdd la fonction fidplayPrice() va les remultiplier par le taux de la devise demandée en Front ?

3 jours

a répondu au Message de Atchworks - 3 jours

c'est des solopards ils veulent que des gros
sans compte les +3€ sur tout les colis
et la les taxe pour dhl ec..
âpres comment vont t'il vérifier ?

3 jours

a répondu au Message de Eolia - 3 jours

j'ai fait un petit module de sycro peux tu me dire si ca peux le faire . jai fait une syncro ca a fonctionné

dmmpricesync-compatible.zip

Atchworks @atchworks

3 jours

Salut,

Purée je viens de découvrir que je devais adhérer à la REP ( Recyclage des emballages) En gros payer une contribution tous les ans... et depuis le 12/08 si je vends dans les autres pays de l'union, devoir payer un mandataire dans chacun de ces pays pour la même chose... Tout cela parce que j'ajoute du scocth sur mes cartons standards fabriqués et acheté en France :)

Purée ça devient chaud d’être un petit artisan, sans parler de la facture électronique qui arrive lol

3 jours

Effectivement ça devrait être ça. Pas d'override de Currency.php ?
En mode debug, aucune erreur lors de la mise à jour des taux ?

3 jours

a répondu au Message de yoyo64 - 3 jours

Donc les taux de change des 3 shops1,9 et 11 ont été mis à jour.
Quels sont les taux (conversion_rate) dans la table ps_currency ?
Si tout est ok regardez dans vos overrides ou js/tpl de votre thème.

4 jours

a répondu au Message de Eolia - 4 jours

Currency rate updated for shop 1 Currency rate updated for shop 9 Currency rate updated for shop 11

4 jours

a répondu au Message de yoyo64 - 4 jours

Si vous lancez la tâche cron manuellement quel est le résultat ?

5 jours

bonjour ou peux ce trouve le probleme du taux de change euro usd
car 109euro me font 109 usd au lieu de 124.48usd
pourtant tout et bien renseigné la tache cron aussi

11 jours

a répondu au Message de Eolia - 11 jours

Merci. Le bon e-mail va maintenant être envoyé.

11 jours

a répondu au Message de BigM - 11 jours

Ok, elle sera désormais cochée par défaut.

11 jours

a répondu au Message de BigM - 11 jours

Ok, trouvé.
Remplacez les lignes 782 à 791 de /classses/order/OrderHistory.php.

Par:

CODE
                    if($order->id_carrier && $order->shipping_number) {
                        // Don't remove these comments: they are used for translations
                        $topic = /* Mail::sendCore(1, 'in_transit',*/Mail::l('Package in transit', (int)$order->id_lang)/*)*/; 
                        $result['template'] = $result['template'] ?: 'in_transit';
                    }
                    else {
                        // Don't remove these comments: they are used for translations
                        $topic = /* Mail::sendCore(1, 'shipped',*/Mail::l('Your order has been shipped', (int)$order->id_lang)/*)*/; 
                        $result['template'] = $result['template'] ?: 'shipped';
                    }

11 jours

a répondu au Message de BigM - 11 jours

Si le problème persiste, je peux me contenter d'un contournement : copier le contenu de l'e-mail custom_shipped dans in_transit. Cela éviterait d'envoyer un message supplémentaire au client (ce qui serait un avantage).

Cependant, je ne souhaite pas que l'e-mail in_transit soit envoyé lors de la saisie du numéro de suivi. Tu as déjà intégré une case à cocher pour supprimer cet envoi à ce moment-là ; j'aimerais qu'elle soit activée par défaut en permanence.

EDIT: J'avais oublié de mentionner le correctif (workaround) appliqué : dans le fichier _shipping.tpl à la ligne 81, j'ai activé la case à

12 jours

a répondu au Message de BigM - 12 jours

J’ai maintenant remplacé à titre d’essai le modèle d’e‑mail utilisé pour le statut d’expédition, en passant de custom_shipped au modèle standard shipped. Pourtant, même ainsi, l’e‑mail in_transit est envoyé une nouvelle fois par erreur.

12 jours

a répondu au Message de Eolia - 12 jours

Oui, le statut "shipped" est lié à custom_shipped dans toutes les langues. De plus, j'ai le même problème dans la deuxième boutique qui n'utilise qu'une seule langue (l'anglais).

12 jours

a répondu au Message de BigM - 12 jours

Le statut "Expédié" est bien associé au template custom_shipped dans TOUTES les langues ?

13 jours

J'ai remarqué un doublon d'envoi d'e-mails.

Quand j'ajoute un numéro de suivi, le système envoie l'e-mail in_transit. Mais lorsque je passe la commande à "Expédié", les réglages prévoient l'envoi de custom_shipped, mais le système renvoie l'e-mail in_transit à la place.

Après vérification, ne vient pas de la dernière mise à jour, il est présent depuis plus longtemps.

Pour résumer :
Ajout du numéro de suivi: envoi de in_transit (ok)
Statut "Expédié": devrait envoyer custom_shipped, mais renvoie in_transit (probleme).

Merci d'avance pour ton aide !

18 jours

a répondu au Message de Eolia - 18 jours

J’ai trouvé la solution. Avant, je désactivais les pays et leurs zones associées. Après la mise à jour, il faut laisser la zone active tout en gardant les pays désactivés. Dans cette configuration, le workaround fonctionne de nouveau comme avant.

18 jours

a répondu au Message de BigM - 18 jours

il faudrait voir votre code car beaucoup de choses ont changé. Ca peut concerner une requête sql plus stricte ou une fonction ayant des contrôles supplémentaires.
Et vous avez fait un bond de 7 versions donc je n'ai plus toutes les modifications en tête.

18 jours

a répondu au Message de Eolia - 18 jours

Je comprends que le workaround doit être adapté, mais comme je n’ai rien modifié et que le problème est apparu uniquement après la mise à jour, pourriez-vous m’indiquer ce qui a changé et comment je peux l’adapter pour le rendre à nouveau fonctionnel ?