Tax with Counterparty about l10n_co_point_of_sale

[hivam]

@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]

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]

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]

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... 😸