Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tax with Counterparty #14

Closed
blaggacao opened this issue Oct 24, 2016 · 4 comments
Closed

Tax with Counterparty #14

blaggacao opened this issue Oct 24, 2016 · 4 comments

Comments

@blaggacao
Copy link

We have discussed this, I think, but I'm not 100% affirmative on congruency of the issues, yet.

I have noticed, that a tax with counterparty used in the POS, while generating a wrong receipt (image 1 & 2), the synched order is correct (image 3), resulting in a payment difference (image 4)

Image 1

image

Image 2

image

Image 3

image

Image 4

image

@dkrimmer84 It seems that counterparty is not employed in POS. Can you confirm that it was this issue that you solved on master?
/cc @xyklex

@hivam
Copy link

hivam commented Oct 24, 2016

@blaggacao No comprendo muy bien el issue, veo que el impuesto (10,20) no lo está mostrando en la imgen 3, pero no entiendo la imagen 4.

Nosotros no hemos tenido ese problema, es posible que tenga relación con la forma cómo gestionas el CREE.

Quita el CREE del producto y realiza de nuevo la prueba.

Si puedes hacer un screencast nos ayudaría a entender mejor el isuue.

@blaggacao
Copy link
Author

blaggacao commented Oct 24, 2016

Para replicar es suficiente crear un grupo de impuestos con dos hijos uno siendo la contrapartida del otro.

Para aclarar:
Imagen 1: Impuesto y valor = Falso
Imagen 2: Valor = Falso
Imagen 3: Valor e impuesto = Correcto
Imagen 4: Ejemplo pagado con 2000, donde después había que conciliar los 10,20 de diferencia manualmente.

Claramente esperaba que ustedes tambien hayan encontrado ese bug. 😄

Lo que pasa:
En el POS, la contrapartida no esta teniendose en cuenta (por las razones que fueran) y genera un pago con un valor alterado, mientras server side, las cosas se están recalculando(?) bien y por ende el pago equivocado no coincide con los valores correctos dejando abierto un balance.

@blaggacao
Copy link
Author

blaggacao commented Oct 24, 2016

The reason is that code taxes are not supported in the POS, while we make heavy use of those... Obviously this won't work....

More precisely, one of the children - the counterparty - is a code tax, which is simply ignored, while its predecessor child is applied, beeing a percentage tax.

@blaggacao
Copy link
Author

blaggacao commented Oct 24, 2016

You can use the reinstalled "division" type to get the correct counterparty amount:
First child: <field name="include_base_amount" eval="True"/>
eg.: base_amount=1000 > base_amount=1008 (CREE 8 x mil)
Second Child: <field name="amount_type">division</field>, <field name="include_base_amount" eval="True"/>

base_amount / (1 - tax.amount / 100) - base_amount
1008 / (1 - -0.8 / 100) - 1008 = -8
> base_amount
> 1000

Well you can also just do -0.8 +0.8 without any of the above... 😸

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants