Qual é o status dos problemas de arredondamento em 1.7?

27

Estamos usando o Magento CE 1.7 e temos vários problemas de arredondamento. Em vários cálculos, há uma diferença de 0,01 EUR.

A questão básica pode ser que os preços dos artigos sejam incl. imposto.

Os co-programadores substituíram o Mage_Core_Model_Store::roundPrice()método para calcular com precisão de 4 dígitos. Mas isso parece causar problemas nos pagamentos do PayPal.

Existe uma solução para esses problemas?

EDITAR:

Nós realmente tentei um patch de núcleo oficial que basicamente acrescenta 4 dígitos arredondamento para \Mage_Tax_Model_Sales_Total_Quote_Shipping::_round, \Mage_Tax_Model_Sales_Total_Quote_Subtotal::_deltaRounde \Mage_Tax_Model_Sales_Total_Quote_Tax::_deltaRoundque corrige um problema de arredondamento cupom, mas não o problema PayPal.

Alex
fonte
Tanto quanto me lembro, o Magento armazena preços com 4 pontos decimais. Portanto, se os preços forem introduzidos com 4 casas decimais, o cálculo está correto. Mas eu posso estar errado.
user487772
11
O que você quer dizer com "entrada com 4 pontos dec."? Mas o arredondamento Magento funciona com 2 de dezembro. pontos. Também acho que a interface do PayPal funciona com 2 de dezembro. pontos - isto parece onde o problema começa.
19413 Alex
Se bem me lembro, se você inserir preços em admin com 4 pontos decimais, ele será salvo em db com 4 pontos decimais. Em seguida, será arredondado para 2 pontos durante a saída, mas o arredondamento estará correto, pois o preço com 4 casas decimais será arredondado.
user487772
Claro - mas temos principalmente problemas com o cálculo total, principalmente se houver códigos de cupom baseados em porcentagem.
19413 Alex
Ah, entendi sua pergunta errada. Desculpe.
user487772

Respostas:

10

Estamos cientes de vários problemas de arredondamento no módulo tributário principal do Magento que cobrem os cenários que foram descritos. Atualmente, estamos trabalhando nessas questões para uma próxima versão 1.13. Esses problemas de arredondamento estão acionando uma verificação simples do Paypal, que determina se os itens de linha no carrinho são adicionados corretamente. Parece que o patch de Fabian cuida do cheque Paypal a curto prazo.

Se você tiver alguma dúvida, comentário ou sugestão sobre como podemos melhorar o módulo Magento Tax, não hesite em entrar em contato comigo, pois sou o gerente de produto responsável pelos impostos.

Atenciosamente, Chuck

Mandril
fonte
Ótimo! Existe algum tipo de suíte de testes disponível para mostrar quais problemas serão resolvidos?
21413 Alex
11
Chuck, você se importaria de configurar suas informações de usuário para confirmar?
benmarks
Os testes são apenas internos. Quanto mais detalhes sobre questões de arredondamento conhecidas, isso é um pouco interessante. Um cliente os consideraria associados a determinadas configurações de impostos usando combinações específicas de preço, alíquota, descontos etc. Nossa abordagem para a versão 1.13 foi identificar configurações comuns de impostos e garantir que as # combinações não produzam matematicamente erros de arredondamento e etiquetem certos itens. configurações (caixas de canto pequeno) como configurações perigosas que devem ser evitadas.
Chuck
Um pouco fora de tópico, mas isso significa que também haveria a edição CE 1.8?
Sergei Guk
Sim - os lançamentos da CE atrasam os lançamentos do EE em cerca de um mês. 1.13 é o próximo lançamento do EE.
Chuck
7

Graças a Andreas Vogt, construo um módulo para corrigir o bug redondo do Paypal. Andreas me deu alguns arquivos principais hackeados e eu fiz o módulo. Ele verifica se as somas estão corretas e, se não, está corrigido.

Afaik, o núcleo hack é testado na natureza. Muitas pessoas pediram o módulo, mas nenhuma onw me deu um retorno sobre o funcionamento. Mas é testado em unidade! (apenas se as reescritas funcionam, porque eu não tinha idéia, qual é o problema do paypal ;-))

https://github.com/magento-hackathon/PaypalRoundBugfix

Fabian Blechschmidt
fonte
11
Hum .. qual bug corrige exatamente? Parece o bug de transferência de itens de linha do carrinho. Na verdade, desativamos a transferência do carrinho. E deve ser aplicado com o adesivo de 4 dígitos?
19413 Alex
Existe mais de um problema? Como eu disse, eu não tenho idéia, o que exatamente ele corrige - se houver mais do que um problema :(
Fabian Blechschmidt
5

Estamos enfrentando tanto o bug de arredondamento do paypal quanto a questão dos códigos de cupom com 100% de desconto. Temos apenas problemas nos preços (como Eur 3,99, incluindo impostos), onde o preço líquido tem no terceiro dígito um 5 (3.325). Assim também o imposto (aqui com 20%) tem no terceiro dígito um 5 (0,665). Portanto, se você arredondar e adicionar os dois preços (o que o paypal e o magento fazem), o total será de 0,01 euro a mais do que o preço base (4,00 a euro).

A caclulação correta deve ser de EUR 3,32 líquido + EUR 0,67 de imposto = EUR 3,99

Como também estamos tentando encontrar uma solução geral, tentamos corrigir o arredondamento paypal!

Walter Huber
fonte
ótimo, me diga se você tiver problemas, estou ansioso para ajudar e ver o Bugfix em estado selvagem e depurá-lo, se necessário!
Fabian Blechschmidt
11
Para sua informação, o problema que você descreveu foi corrigido em nossa próxima versão (1.8 CE / 1.13 EE).
21313 Chuck #
@Chuck Acabei de testar esse cenário com o Mage_Tax_Model_Sales_Total_Quote_Tax da versão 1.13.0.1 e parece ter resolvido o problema como uma substituição imediata em um projeto 1.12. Muito obrigado. Já existe um ETA para 1.8CE?
Jonathan dia
4

existe uma relação geral entre preços, quantidade, desconto, imposto e suas precisões.

Assume:
x is the price
y is the percentage
s is the rounded sub-total

2 Directions
A) incl. Tax => excl. Tax => incl. Tax
B) excl. => incl. => excl.

A questão importante é o subtotal arredondado que estou calculando com o máx. Erro. 2 dígitos fracionários significa 5 * 10 ^ -3

Dê sua nota! Dê sua nota! 2Comentários (2)

B) x * (y + 10 ^ 2) / 10 ^ 2 // s * 10 ^ 2 / (10 ^ 2 + y)

A)
Subtotal precision 2 fractional digits:
5*10^-3*(y+10^2)/10^2 => (y+10^2)/10^2<1 => no y
3 fractional digits:
5*10^-4*(y+10^2)/10^2 => (y+10^2)/10^2<10 => y<900
4 fractional digits:
5*10^-5*(y+10^2)/10^2 => (y+10^2)/10^2<10^2 => y<90900
(must be a very bad country)

......

B)
Subtotal precision 2 fractional digits:
(5*10^-3)*10^2/(10^2+y) => 10^2/(10^2+y)&lt;1 => every y

Se você deseja calcular com descontos ou impostos e deseja recalcular o preço, a próxima explicação pode ser interessante para você. Esteja ciente de que, como não conheço nenhum caso no front-end, é possível que haja um cálculo interno. A) Total => Imposto / Desconto => Total B) Imposto / Desconto => Total => Imposto / Desconto

A) x * y / 10 ^ 2 // s * 10 ^ 2 / y

B) x * 10 ^ 2 / a // s * a / 10 ^ 2

A) Subtotal precision 2 fractional digits:
(5*10^-3)*10^2/y => 10^2/y < 1 => y>10^2
Subtotal precision 3 fractional digits:
(5*10^-4)*10^2/y => 10^2/y < 10 => y>10
Subtotal precision 4 fractional digits:
... 10^2/y < 10^2 => y>1

Com uma precisão de 2 dígitos, você deve ter uma taxa sem NENHUM DÍGITO FRACIONAL. Exemplo: Total: 15,15 alíquota: 0,3% => imposto 0,04545 => arredondado 0,0455 imposto: 0,0455 => total: 15,17

B) Subtotal precision 2 fractional digits:
(5*10^-3)*y/10^2 => y/10^2 &lt; 1 => y < 10^2

se a é a precisão, deve ser y menor que a + 2.

Observe se você lida com quantidades. O erro será multiplicado. Portanto, se você tem um máximo de 10 ^ 5, precisa ter uma precisão de 7. Isso é preocupante, se você está calculando com deslocamento!

ALÉM (2013/10/09 Magento Versão 1.7.0.2) Brutto <=> Netto e Impostos // América <=> antigos conjuntos Europa são inteiros (centavos) e o mapeamento
f (x) = round (a * x) a> 1 é não é bijetivo. Nas minhas palavras: nem por todos os preços, incl. existe um preço excl. ou Às vezes há 2 preços incl. por um preço excl. ou Você pode obter 2 resultados diferentes, dependendo de como calcular

Exemplo do mundo real da Alemanha:

Você tenta inserir um preço incl. impostos: 19,95 Você recebe 16,76 (2 dígitos) conforme seus preços excl. os impostos (19%). Se você calcular os 19% de impostos, obtém (16,76 * 0,19) 3,18. (Esteja ciente: 19,95 * 019 / 1,19 ~ 3,19)

Portanto, há uma diferença de 1 centavo. 16,76 => 19,94 16,77 => 19,96

Não há preço de 19,95 na América - terra de netto.

Portanto, calcule com os preços originais o máximo possível. Para incluir preços, use o preço inserido e os impostos (número quebrado).

O PayPal tem essa verificação de fraude - agora não tenho certeza - mas o PayPal apenas adiciona o número que o magento fornece. veja http://fabiankrueger.de/blog/magento-und-paypayl-rundungsfehler/ Se isso não for verdade e o PayPal recalcular imposto ou total, esse problema não é solucionável, caso contrário, os preços - errados ou corretos - são mostrados anteriormente no Magento . Resolva-o lá. Para mim, parece funcionar.

Andreas Dyballa
fonte