Open SoniaViciana opened 5 months ago
*** Editado punto 4 y añadido punto 5.
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
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,
Lo suyo sería que se discutiera esto en los Spanish OCA Days. Sonia, convence a tu jefe para que vayáis para allá...
Contexto:
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![image](https://github.com/OCA/l10n-spain/assets/46522913/661e4034-17af-4e16-a2f3-6c16a9bbf239)
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. Lospos.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:
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
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: https://github.com/OCA/l10n-spain/issues/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