Je ne sais vraiment pas si cela va aider de quelque façon que ce soit, mais quelque chose à examiner.
Il est possible que votre collecttotalsmodèle de commande soit différent et que la taxe soit commandée / appliquée après grand_total
Vous pouvez tester si c'est le problème comme suit. (notez que cela implique d'ajuster un fichier core pour obtenir des informations de débogage, veuillez ne pas essayer ceci sur un site en direct!)
Modifiez la méthode située dans:
Mage_Sales_Model_Quote_Address::collecttotals
et ajoutez une ligne à la méthode, ce qui vous permettra de sortir les modèles au fur et à mesure de leur traitement.
public function collectTotals()
{
Mage::dispatchEvent($this->_eventPrefix . '_collect_totals_before', array($this->_eventObject => $this));
foreach ($this->getTotalCollector()->getCollectors() as $model) {
mage::log($model->getCode()); // <===== ADD THIS LINE
$model->collect($this);
}
Mage::dispatchEvent($this->_eventPrefix . '_collect_totals_after', array($this->_eventObject => $this));
return $this;
}
assurez-vous que la journalisation est activée.
suivre le fichier journal via la console: tail -f system.log
Reproduisez le problème via le frontend.
Vous obtiendrez les entrées comme suit dans votre journal (ceci à partir d'une vanilla 1.9.2.2 - vous pouvez avoir d'autres entrées)
2015-12-21T05:54:12+00:00 DEBUG (7): nominal
2015-12-21T05:54:12+00:00 DEBUG (7): subtotal
2015-12-21T05:54:12+00:00 DEBUG (7): msrp
2015-12-21T05:54:12+00:00 DEBUG (7): freeshipping
2015-12-21T05:54:12+00:00 DEBUG (7): tax_subtotal
2015-12-21T05:54:12+00:00 DEBUG (7): weee
2015-12-21T05:54:12+00:00 DEBUG (7): shipping
2015-12-21T05:54:12+00:00 DEBUG (7): tax_shipping
2015-12-21T05:54:12+00:00 DEBUG (7): discount
2015-12-21T05:54:12+00:00 DEBUG (7): tax
2015-12-21T05:54:12+00:00 DEBUG (7): grand_total
Vous le verrez se répéter, alors voyez simplement où il commence et se termine, il devrait être facile de voir le motif
Notez les deux dernières entrées ci-dessus: la taxe précède le grand_total. Il est possible que cette commande soit hors de contrôle et que la taxe apparaisse après grand_total, donc grand_total n'aura pas de taxe appliquée.
ÉDITER:
D'accord, je n'ai donc pas vu que la question renvoyée indique en fait que le tri des documents collectifs était en cause. Je soupçonne que cela peut être le problème, mais je ne l'ai pas testé moi-même en PHP7
Il y a une solution, mais ce n'est pas très agréable. Toute nouvelle extension placée dans le magasin, qui insère des modèles dans le collecteur, devrait être notée et ajoutée au tri, sinon les choses pourraient aller encore plus mal. Peut être un peu un problème de maintenance à l'avenir.
Forcez simplement l'ordre de tri en plaçant un spécifique <sort_order>dans la configuration des totaux. Vous pouvez le faire via votre propre extension, qui n'aurait qu'un config.xml, où vous spécifiez l'ordre pour chaque collecteur.
dans le config.xml, ont la directive en tant que telle:
<sales>
<quote>
<totals>
<nominal>
<sort_order>100</sort_order>
</nominal>
<subtotal>
<sort_order>200</sort_order>
</subtotal>
<msrp>
<sort_order>300</sort_order>
</msrp>
<freeshipping>
<sort_order>400</sort_order>
</freeshipping>
......
insert each collector model with a sort directive
......
</totals>
</quote>
Utilisez de grands espaces entre chaque directive de tri, pour permettre à l'espace d'insérer davantage à l'avenir.
Comme mentionné, pas très élégant, mais peut résoudre votre problème immédiat.
Notez également qu'il existe d'autres directives de collecteur dans le système, elles peuvent donc également être erronées / nécessiter un ajustement
Vérifiez l'extension de vente principale config.xml et recherchez <totals>
Vous y trouverez:
<order_invoice>
<order_creditmemo>
<pdf>
Il peut y en avoir d'autres dans d'autres extensions, que ce soit le noyau / tiers
J'espère que cela pourra aider.
PS: Je n'ai testé rien de tout cela en PHP7. Je sais que le placement de la directive sort_order fonctionne sous php5.x
