Realmente não sei se isso vai ajudar de alguma forma, mas algo para investigar.
É possível que o collecttotals
pedido do seu modelo esteja sendo pedido de forma diferente e esse imposto esteja sendo solicitado / aplicado após grand_total
Você pode testar se esse é o problema da seguinte maneira. (observe que isso envolve ajustar um arquivo principal para obter algumas informações de depuração, não tente isso em um site ativo!)
Edite o método localizado em:
Mage_Sales_Model_Quote_Address::collecttotals
e adicione uma linha ao método, que permitirá a saída dos modelos à medida que são processados.
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;
}
verifique se o log está ativado.
Tail o arquivo de log através do console: tail -f system.log
Reproduza o problema pelo frontend.
Você obterá as entradas da seguinte maneira em seu log (isto é de um vanilla 1.9.2.2 - você pode ter outras entradas)
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
Você o verá se repetir; portanto, apenas veja onde começa e termina; deve ser fácil ver o padrão
Observe as duas últimas entradas acima: O imposto vem antes de grand_total. Ele pode ser possível esta ordenação é fora de louco, e imposto está aparecendo depois grand_total, então grand_total não terá impostos aplicados.
EDITAR:
Ok, então eu não vi a pergunta referida realmente aponta para a classificação dos colecionáveis como o problema. Suspeitei que esse seja o problema, mas ainda não testei isso no PHP7
Existe uma solução, mas não é muito agradável. Qualquer nova extensão colocada na loja, que insere modelos no coletor, precisaria ser notada e adicionada adicionalmente à classificação, caso contrário, as coisas poderiam dar ainda mais errado. Pode ser um problema de manutenção daqui para frente.
Simplesmente force a ordem de classificação colocando um específico <sort_order>
na configuração de totais. Você pode fazer isso através de sua própria extensão, que teria apenas um config.xml, onde você especifica a ordem para cada coletor.
no config.xml, tenha a diretiva como tal:
<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>
Use grandes lacunas entre cada diretiva de classificação, para permitir espaço para inserir mais adiante.
Como mencionado, não é muito elegante, mas pode resolver seu problema imediato.
Observe também que existem outras diretivas de coletor no sistema, portanto elas também podem estar erradas / precisando de ajuste
Verifique a extensão de vendas principal config.xml e procure por <totals>
Lá você encontrará:
<order_invoice>
<order_creditmemo>
<pdf>
Pode haver outros em outras extensões, seja ele principal / de terceiros
Espero que ajude.
PS: Eu não testei nada disso no PHP7. Eu sei que a colocação da diretiva sort_order funciona em php5.x