Recopilación de problemas encontrados con l10n_es_pos_sii

[SoniaViciana]

Contexto:

• https://github.com/OCA/l10n-spain/tree/16.0/l10n_es_pos_sii
• Envíos al SII automáticos desde el POS #3058

Los envíos al SII desde el pos.order se implementaron pensando en que Verifactu requeriría el envío individual de las facturas simplificadas, sin embargo, el Reglamento ya se aprobó y no aplica a las empresas adheridas al SII:

https://sede.agenciatributaria.gob.es/Sede/normativa-criterios-interpretativos/analisis/2023/diciembre/11/reglamento-verifactu.html

Objetivo:

Aparte, llevamos un tiempo usando este módulo en entornos de producción, y en esta tarea quiero plantear todos los prolemas que hemos encontrado (algunos ya se sabían de antes):

1. Diferencias entre los envíos al SII y la contabilidad

Si un restaurante abre sesión a las 10:00 horas y cierra a las 01:00 horas, los pedidos registrados desde las 10:00 hasta las 00:00 horas se enviarán al SII con fecha X. Sin embargo, el asiento contable estará con fecha X+1 dado que responde a la fecha de cierre de sesión.

2. Imposibilidad de corregir errores del SII

Cuando se nos presenta un error en el SII, por ejemplo, por un impuesto mal indicado en la ficha de producto, y en consecuencia, mal asignado a la pos.order.line no existe ninguna opción de corregirlo. Los pos.order no se pueden manipular una vez han sido publicados, ni siquiera con el método de importación / exportación. Este punto hace que el usuario sea muy dependiente del implantador / equipo técnico.

3. Complejidad en la revisión de los envios al SII
Cuando se acaba un periodo fiscal, lo ideal es que el usuario de contabilidad revise todos los envíos al SII antes de generar el 303 (por ejemplo). Actualmente, hay que revisar:

• Facturas de venta
• Rectificativas de venta
• Facturas de compra
• Rectificativas de compra
• Pedidos de TPV

Para los 4 primeros puntos, solemos hacer uso de https://github.com/OCA/account-invoicing/tree/16.0/account_menu_invoice_refund y así son 2 los menús a revisar y no 4. Sin embargo, imperativamente hay que revisar el menú de pedidos del TPV, con el agravante descrito en el punto 2.

4. Problemas de conexión y sesiones de rescate

• Entro en el TPV en un dispositivo A
• Registro pedidos, pero pierde la conexión y no se envían
• Entro en el mismo TPV desde otro dispositivo B y cierro la sesión
• Cuando A recupera la conexión al día siguiente, se crea sesión de rescate con pedidos del día anterior.

Mismo problema de fechas que lo comentado en el punto 1.

5. Diferencias pre-303 y 303 de Odoo

El pre-303 se completa conforme a los envíos al SII, y el modelo 303 de Odoo conforme a la contabilidad. Existe diferencias en estas casillas:

El pre-303 completara todas esas casillas, mientras que el modelo 303 sólo completa desde la 1 hasta la 9, ya que el asiento agrupado de simplificadas, no diferencia si hay rectificativas (devoluciones).

Propuesta de solución:

Implementar la opción 2 definida en: #3058

---

*** Abro esta tarea para dara conocer y recopilar todos los inconvenientes que hemos encontrado con el uso del módulo, seguramente aportemos la solución en un futuro.

Saludos,

@AlbertCabedo @pedrobaeza @zamberjo @omar7r

[SoniaViciana]

*** Editado punto 4 y añadido punto 5.

[anmarmo1]

Hola @SoniaViciana

Entiendo los problemas que indicas, sobre todo los que tienen que ver con las sesiones que cierran al dia siguiente. Donde los apuntes se van a quedar en una fecha distinta a la del envio del SII de algunas facturas simplificadas.
Lo que no tengo muy claro es la propuesta de solución usando el l10n_es_aeat_sii_invoice_summary por que hacer un apunte con el resumen de lo que hay que enviar al SII, ¿supone duplicar la información contable?
Como dices verifactu ha excluido a las empresas adscritas al SII pero no se hasta cuando van a permitir seguir enviando un asiento resumen a los del SII cuando a los demás les van a exigir enviar todas las facturas...

En cualquier caso, es cierto que hay algunos problemas con esta implementación que habría que revisar, tal vez podríamos esperar a ver la implementación del verifactu en el pos por que habrá que tocar también cosas para enviar cada una de las facturas simplificadas por separado.

Un saludo

[SoniaViciana]

Hola @anmarmo1

En la propuesta de solución, la idea sería no duplicar, si no dotar al asiento agrupado de facturas simplificadas que ya genera el TPV, de la información / lógica faltante para que sea una factura de venta a todos los efectos. Completando a su vez los campos de l10n_es_aeat_sii_invoice_summary (primer y último número de factura simplificada).
Sin embargo... esto se tiene que sopesar, porque haría el SII del TPV incompatible con l10n_es_pos_by_device (múltiples dispositivos por sesión en el punto de venta).

Entonces, lo cierto es que hay que pensarse bien qué conviene más, sabiendo los pros y los contras de cada opción (esto es lo que pretendo en este issue). En todo caso, iremos informando. La opción 2 no es algo que tengamos pensado abordar a corto plazo.

Saludos,

[pedrobaeza]

Lo suyo sería que se discutiera esto en los Spanish OCA Days. Sonia, convence a tu jefe para que vayáis para allá...

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.