[12.0][l10n_es_aeat_mod303] - Casilla 14 no recoge movimientos contables

[JuanjoA]

Hola, estoy observando que tengo facturas rectificativas que no se reflejan en el modelo 303, casillas 14 y 15.

Creo que los tiros vienen en la forma que el modelo selecciona los valores para las casillas 14 y 15. Se busca por el _movetype del asiento contable, que es un campo calculado y este campo, comprueba entre otras cosas el tipo interno de las cuentas contables de los apuntes contables de la factura. La historia es que si tienes un modo de pago, que usa cuenta puente (por ejemplo para dar por pagadas las facturas pagadas con tarjeta de crédito), el apunte contable de la 430 ya no sale en el movimiento contable de la factura. Esto hace que ese movimiento contable tenga un tipo other y no _receivablerefund por lo que la factura no se tiene en cuenta en el cálculo del 303.

Realmente no se si este es el efecto deseado, o bien se me escapa algo, pero como resultado, el 303 sale incorrecto.

Paso una captura de ejemplo, en la que se ven 2 facturas de abono, una sin configurar en el modo de pago el apartado asiento contable y otro configurado. La fila en azul de la 430xx determina el tipo de movimiento. En el abono con el apartado asiento contable configurado, no tengo esa entrada, luego el movimiento tiene otro tipo.

Cálculo del tipo de movimiento:

oca/account-financial-reporting/account_tax_balance/models/account_move.py:30

Cálculo del 303

oca/l10n-spain/l10n_es_aeat/models/l10n_es_aeat_report_tax_mapping.py:76

Si se os ocurre algo, genial, por mi lado, sigo revisando.

Gracias

[pedrobaeza]

Juanjo, estoy viendo ahí muchas barbaridades para Odoo, como la manía de separar cada impuesto o cada cliente por cuenta contable, pero fuera de eso, las reglas son claras: las facturas deben ir bien hechas, lo que significa que debe haber una cuenta contable a cobrar/pagar y luego las de ingresos/gastos e impuestos. Si no hay esa estructura, el tipo no es correcto, y no saldrá.

[JuanjoA]

Jeje, gracias Pedro, como siempre. De todas formas son medias barbaridades, y el sistema se está comportando realmente bien, hasta nos hemos cargado un Sage por el camino. Entrar exclusivamente con la contabilidad en una empresa con Odoo, es algo que a veces requiere ciertas licencias. A cambio, pues tienes estas historias, o parecidas, y tema actualizaciones, pues más complejo. Voy a ver esa cuenta que se escapa, gracias de nuevo.

[pedrobaeza]

Esas licencias son las que luego te duele la cabeza. Cada sistema, tiene sus reglas, y no puedes querer cambiarlas por hacer la "transición más suave". Hacerlo serán futuros quebraderos de cabeza. Por ejemplo, en v13 no te funcionará el 303.

[HaraldPanten]

Eso iba a comentar... En versiones posteriores, con subcuentas de impuestos no te funcionará el modelo 303 de OCA. Ahí tendrás algún quebradero de cabeza si no se normalizan los datos con el funcionamiento que requiere el módulo.

O bien podrás utilizar el de versión Enterprise, claro, con todo lo que conlleve para bien y para mal.

Saludos.

[JuanjoA]

Gracias a los 2, es interesante saber que en v13 no se soporta. Aún tenemos lejos una posible migración, pero por lo que veo tendremos que ajustar varios puntos, pero bueno, para eso estamos.

[JuanjoA]

Voy a cerrar este tema, pero por aportar algo de info (lo tengo solucionado y pendiente de mejorar el proceso), decir que si, esto tiene que ver por el cómo se calcula el campo tipo de movimiento, y que hace que ciertos apuntes contables no aparezcan en el 303, bueno, y no tener esos asientos de acuerdo a lo que necesita odoo. El parche temporal ha sido añadir esos apuntes en el __get_move_linedomain Gracias a todos.