Magento 1.9 mauvais symbole de devise dans le panier de confirmation de commande email-lors du paiement avec PayPal-formatPrice()

J'ai Magento 1.9.0.1 fonctionnant avec GBP (£) comme devise de base et d'affichage par défaut, et Euros (€) comme devise autorisée.

si l'utilisateur choisit de payer en Euros, le site tous les travaux sauf, s'ils paient par PayPal dans leur propre monnaie, alors l'email de confirmation de commande a une erreur. Sur mon test ci-dessous, j'ai vérifié en Euros (€) mais mon compte PayPal utilisait livres (£).

le prix de l'article de la charrette et le total Partiel montrent en Euros, mais avec un symbole de£. Le Le sous-Total, la livraison et le Total apparaissent tous en Euros, avec le symbole correct€.

L'exemple ci-dessous montre une représentation de base avec les prix approximatifs:

Items       Quantity    Item Price    Sub Total
---         ---         ---           ---
Product     1           £150.00       £150.00  <<-- These £'s should be €'s
-----------------------------------------------
Sub Total:                  €150.00 
Delivery:                   €0.00 
Total:                      €150.00 
Grand Total to be Charged:  £100.00

j'ai essayé de le retrouver, mais je ne suis pas sûr où ça va mal, et c'est un cauchemar à tester. L'e-mail des appels:

(Mage_Checkout_Helper_Data) $this->helper('checkout')->formatPrice(...);

Qui appelle

(Mage_Core_Model_Store) $this->getQuote()->getStore()->formatPrice($price);

qui finit par trouver son chemin pour Zendre les méthodes de monnaie, mais je ne sais pas où le symbole de monnaie se perd.

ce problème se produit uniquement lors de la vérification Avec PayPal, pas lors du paiement par CC directement via le site.

quelqu'un peut-il m'indiquer la bonne direction? Merci

29
demandé sur Jamie G 2015-09-14 15:03:27

3 réponses

dans le courriel de confirmation, il ne devrait pas y avoir d'appel à $this->helper('checkout')->formatPrice(...) n'importe où. Si tel est le cas, l'email de commande utilise les templates d'items de checkout au lieu des siens, ce qui est probablement causé par un type de produit Personnalisé non entièrement implémenté ou un bogue dans votre thème.

les totaux d'ordre montrent la bonne devise parce que le totaux bloc utilise formatPrice() méthode de l'ordre, qui prend la devise de l'ordre:

$this->getOrder()->formatPrice($total->getValue());

le des modèles pour les utiliser $_order->formatPrice(...). Mais selon le type de produit, différents modèles sont utilisés. C'est le modèle par défaut.

les blocs et gabarits pour chaque type de produit sont définis dans sales.xmladdItemRender action:

<sales_email_order_items>

    <block type="sales/order_email_items" name="items" template="email/order/items.phtml">
        <action method="addItemRender"><type>default</type><block>sales/order_email_items_order_default</block><template>email/order/items/order/default.phtml</template></action>
        <action method="addItemRender"><type>grouped</type><block>sales/order_email_items_order_grouped</block><template>email/order/items/order/default.phtml</template></action>
        <block type="sales/order_totals" name="order_totals" template="sales/order/totals.phtml">
            <action method="setLabelProperties"><value>colspan="3" align="right" style="padding:3px 9px"</value></action>
            <action method="setValueProperties"><value>align="right" style="padding:3px 9px"</value></action>
            <block type="tax/sales_order_tax" name="tax" template="tax/order/tax.phtml">
                <action method="setIsPlaneMode"><value>1</value></action>
            </block>
        </block>
    </block>
    <block type="core/text_list" name="additional.product.info" />
</sales_email_order_items>

les Modules qui ajoutent des types de produits doivent y enregistrer leurs propres rendus, comme on peut le voir dans bundle.xml:

<sales_email_order_items>
    <reference name="items">
        <action method="addItemRender"><type>bundle</type><block>bundle/sales_order_items_renderer</block><template>bundle/email/order/items/order/default.phtml</template></action>
    </reference>
</sales_email_order_items>

Si ce n'était pas défini, le renderer par défaut est celui de la caisse, où le modèle d'ordre lui-même n'est pas utilisé, juste les éléments simples (qui n'ont aucune information de devise jointe). Là le formatage de prix est fait par le Helper checkout qui n'a aucune information sur la commande, de sorte qu'il utilise la devise de magasin actuellement sélectionnée.

Pourquoi est-ce seulement un problème avec les paiements en ligne comme PayPal? Parce qu'avec d'autres méthodes, où le courrier de confirmation de commande est créé immédiatement avec le bouton "commander", la devise du magasin actuellement sélectionnée est toujours la même que la devise de la commande. Mais dans la requête de rappel de PayPal ce contexte est perdu et la devise par défaut sera utilisée à la place.

Que devez-vous faire?

  1. Recherche <sales_email_order_items> gérer la mise en page dans vos fichiers XML pour voir si les rendus par défaut sont enregistrés correctement
  2. assurez - vous que tout type de produit personnalisé enregistre également leur convertisseurs
  3. vérifiez les gabarits qui sont utilisés par les locataires d'item. C'est peut-être un bug dans votre thème et vous avez juste à remplacer $this->_helper('checkout')->formatPrice()$_order->formatPrice().
3
répondu Fabian Schmengler 2015-12-16 09:22:37

cela semble être l'erreur de monnaie du jeu de caractères. Vous avez besoin d'appliquer charset utf-8 en recherchant ce code particulier pour le modèle de courriel.

-2
répondu Gaurav 2015-11-30 11:33:03

vous pouvez changer les symboles de devise du système - > gérer la devise - > symboles

-4
répondu Y.Q 2015-11-12 02:02:48