[16.0] l10n_es_vat_book no refleja correctamente las operaciones de facturas simplificada del pos

[IJOL]

Hola a todos:

Como todos sabeis, he visto las discusiones al respecto en 15.0, y no me queda claro si había una solucion prevista o algún tipo de workaround, ya he visto que una posible "solucion" sería no necesitar el libro de IVA usando l10n_es_pos_sii, pero en el caso de mi cliente, usar el SII es algo que por ahora no quieren hacer, así que esto me deja con la cuestión, es un bug solucionable, o no en el estado actual del asunto en 16?

En caso de que sea solucionable, puedo poner el trabajo de pruebas y programación, pero me fallan conocimientos de base sobre el asunto, en una aproximación naive, seria poco mas que poner el numero de factura simplificado en el libro de IVA, os es algo mucho mas complicado? no busco tanto reportar un bug ( no hay muchas opciones la verdad) como iniciar una discusión sobre como se podria solucionar el asunto, y no tengo problemas en hacerlo yo mismo, pero necesito claridad..

[pedrobaeza]

La forma adecuada de resolverlo sería crear un módulo l10n_es_vat_book_pos, que detecta qué apuntes provienen del PoS, y que no los marque como incorrectos por no tener NIF, y además tenga en cuenta las posibles casuísticas de constar como simplificadas, o también resumirlos como agrupados.

[IJOL]

además tenga en cuenta las posibles casuísticas de constar como simplificadas,

Que casuísticas se pueden producir?

o también resumirlos como agrupados.

esto a simple vista parece mucho mas complicado, no iria por esta ruta si no es obligatorio

[IJOL]

En cuanto a lo de no dar errores por no tener nif, según deduzco de anteriores conversaciones una manera de solucionar este asunto sería por la ruta de pos_default_partner, y marcar este partner como no Aeat, esto sigue siendo válido como solución?

[IJOL]

l10n-spain/l10n_es_vat_book/models/l10n_es_vat_book_line.py

Lines 39 to 41 in d1aaa8a

	move_id = fields.Many2one(comodel_name="account.move", string="Invoice")
	move_id = fields.Many2one(comodel_name="account.move", string="Journal Entry")

He visto esto en la revision del asunto, no es dañino, pero tampoco bonito

[pedrobaeza]

Que casuísticas se pueden producir?

Creo que básicamente que venga indicado que es simplificada, pero no he entrado en detalles.

esto a simple vista parece mucho mas complicado, no iria por esta ruta si no es obligatorio

Sí, pero sería lo más útil en cuanto a volumen.

He visto esto en la revision del asunto, no es dañino, pero tampoco bonito

Sí, estaría bien limpiarlo.

En cuanto a lo de no dar errores por no tener nif, según deduzco de anteriores conversaciones una manera de solucionar este asunto sería por la ruta de pos_default_partner, y marcar este partner como no Aeat, esto sigue siendo válido como solución?

Esto es un workaround, pero lo suyo es tratarlo adecuadamente.