Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Envíos al SII automáticos desde el POS #3058

Closed
SoniaViciana opened this issue Jun 5, 2023 · 16 comments
Closed

Envíos al SII automáticos desde el POS #3058

SoniaViciana opened this issue Jun 5, 2023 · 16 comments
Labels
enhancement stale PR/Issue without recent activity, it'll be soon closed automatically.

Comments

@SoniaViciana
Copy link

Buenos días,

Abro tarea para plantear 2 opciones a desarrollar para el envío automático al SII de las ventas de facturas simplificadas emitidas desde el TPV:

Opción 1 - Envio al SII de los ticket individuales

Esta opción replicaría lo que ya se hace con TicketBai. Es decir, cada pedido del TPV que sea de factura simplificada se enviaría al SII de foma individual añadiendo la pestaña del SII en los pos.order que tengan a TRUE is_l10n_es_simplified_invoice (este campo lo habilita l10n_es_pos, pendiente de mergear en v16 -> #2615)

A tener en cuenta:

  • Con este cambio, los usuarios tendrían que realizar la revisión de los envíos al SII desde el menú de pos.order, es decir, se añade complejidad, ya que no todos los envíos al SII se unificarían desde los menús de facturas

  • Desde la versión 14 ya deberían estar solucionados todos los errores conocidos respecto a la duplicidad de número de factura simplificada (l10n_es_unique_id, campo contenido en l10n_es_pos). Sin embargo, no he realizado las sucifientes pruebas para corrobarar esto al 100% pero soy consciente de que ha sido muy problemático.

Opción 2 - Envio al SII de asientos agrupados de simplificadas

Esta opción añadiría al asiento contable resumen de los elementos necesarios para realizar el envío al SII. Esta funcionalidad sería dependiente de l10n_es_aeat_sii_invoice_summary

A tener en cuenta:

  • Esta opción no conlleva los inconvenientes de la opción 1. Dado que al SII se enviaría el primer y último nº de factura simplificada de cada sesión, si existiera algún duplicado no saltaría error / se diluye entre la multitud de simplificadas.

  • Con esta opción el 100% de facturas remitidas al SII se podrían revisar desde el menú de facturas de "Contabilidad". Aunque quizá esto no sea relevante, a simple vista la facturación electrónica (Verifactu) nos obligará a remitir las facturas simplificadas de TPV de forma individual...


Agradecería si otros compañer@s pueden aportar sus impresiones.

Gracias,

@Gelo-fl
Copy link
Contributor

Gelo-fl commented Jun 5, 2023

Hola @SoniaViciana y a todos,

Desde mi punto de vista, considero como opción preferente la opción 1, una vez que se ha solucionado el asunto de la duplicidad de número de factura simplificada. Como comentas, la evolución va a ser hacia remitir las facturas simplificadas de TPV de forma individual. Por lo tanto creo que es coherente ya empezar esta mejora en ese sentido.

Respecto a

Con este cambio, los usuarios tendrían que realizar la revisión de los envíos al SII desde el menú de pos.order, es decir, se añade complejidad, ya que no todos los envíos al SII se unificarían desde los menús de facturas

Comprobar por un lado el envío de facturas y de facturas simplificadas no lo veo descabellado. Ahora mismo también se comprueban desde sitios distintos las de clientes y proveedores/acreedores. Tal vez se puede solucionar de forma sencilla añadiendo un submenú de acceso en el módulo de contabilidad directamente a los pos.order . Aunque no estarían en la misma vista, se podría pasar de un menú a otro sin necesidad de salir del módulo de contabilidad

@anmarmo1
Copy link

anmarmo1 commented Jun 5, 2023

La aeat permite enviar las facturas en lote indicando el primer numero y el último, en el módulo de acysos original se enviaba la sesión, pero si finalmente vamos a tener que enviar las facturas simplificadas individualmente tal vez no seria la mejor opción. Añadir un punto del menú para añadir los tiquets del pos no seria mucho problema yo creo.

Por que, ¿crear las facturas simplificadas directamente como facturas con el cliente anónimo para aeat y el check de simplificadas ?

@SoniaViciana
Copy link
Author

Añado otra variable al desarrollo propuesto:

FACTURAS DE CANJE

https://www.agenciatributaria.es/static_files/AEAT/Contenidos_Comunes/La_Agencia_Tributaria/Modelos_y_formularios/Suministro_inmediato_informacion/V_1_1/Faqs_General/FAQs15_12_2020.pdf?hsCtaTracking=106ae082-251b-40e9-8f9f-8d8f241a8572%7C290c86c1-b36e-4fd7-b394-a7203a636f12

image

Contexto

Las facturas simplificadas se pueden convertir en completas realizando un envío al SII de la misma que contenga los datos del cliente e identificándola como F3. Las facturas de canje no se contemplarán en el periodo fiscal presente (el IVA repercutido ya se declaró). Hay un plazo de 4 años desde que se expedió la factura simplificada para que el cliente solicite el canje a factura ordinaria.

EXTRA: Salvo error, si una simplificada tiene rectificativas relacionadas, por ejemplo:

  • Factura simplificada: 0000064 por 120,00€ emitida el 01/01/2020
  • Rectificativa simplificada: 0000078 por -25,00€ emitida el 05/02/2020

Si el cliente solicita hoy factura de canje de la simplificada 0000064, Odoo debería tener en cuenta la rectificativa asociada, de tal forma que la nueva factura de canje sería por 95,00€.

Opción 1 - Envio al SII de los ticket individuales

Habilitar asistente para envío al SII de facturas de canje desde pedidos de venta. El asistente deberá requerir que el res.partner contenga los datos suficientes para el envío al SII como F3.

La comunicación con el SII se almacenaría en el pos.order

Opción 2 - Envio al SII de asientos agrupados de simplificadas

Habilitar asistente para envío al SII de facturas de canje desde pedidos de venta. El asistente deberá requerir que el res.partner contenga los datos suficientes para el envío al SII como F3.

La comunicación con el SII se almacenaría en el account.move vinculado al pos.order


Dudas

Con ninguna de las 2 opciones quedaría registro contable ya que no hay intención de modificar la forma de contabilizar de Odoo. Actualmente los asientos resumen de simplificada no contienen res.partner:

image

El módulo pos_default_partner sólo aplica a los pos.order pero no al account.move, quizá es interesante mover el cliente por defecto al asiento contable en el 100% de los casos donde el pedido contenga is_l10n_es_simplified_invoice a TRUE

¿La emisión de una factura de canje debe dejar registro contable? Teorícamente sería un asiento que mueva el saldo de la 430 del cliente por defecto a la 430 del cliente B2B.

Saludos,

@FernandoRomera
Copy link
Contributor

Explico mi granito de arena, ya que parece que hay diferentes punto de vista.

Primero de todo, no tiene que ver nada con el SII (l10n_es_aeat_invoice_summary).

Siempre hay que generar una factura resumen (y no un asiento contable), independientemente si la empresa esta adscrita al SII o no. De esta manera, al declarar el impuesto, cuadrará con la lista de facturas expedidas.

Si utilizamos el módulo que genera series por cada dispositivo, tendremos que generar n facturas resumen por cada sesión, en la definición de la factura resumen, sólo hay una columna para la serie y 2 para la primera y la última factura simplificada.

El proceso sería así:

Al realizar un canje de una factura simplificada por una factura completa, generaríamos una nueva factura completa con fecha actual con una nueva serie de facturas de canje.

Además, de dicha factura completa generaríamos una nueva factura simplificada negativa con fecha actual, pero sin considerarla factura simplificada rectificativa, ya que este canje de factura simplificada por factura completa no está completado como causa de factura rectificativa.

La consulta vinculante para ello:

https://petete.tributos.hacienda.gob.es/consultas/?num_consulta=V2873-17

@SoniaViciana
Copy link
Author

Buenas tardes @FernandoRomera

El supuesto que nos planteas es este:

image

La factura de canje F3 pretende no tener que realizar una rectificativa, si no un PDF / ticket de factura completa y el envío al SII para comunicar a la AEAT del canje, de ahí la duda respecto al registro contable (cuenta 430, libro mayor del cliente..).

Añado mayor contexto: Las facturas de canje son útiles cuando ya se ha cerrado la sesión y el cliente solicita factura completa para poder deducírsela (por ejemplo). En este caso hay 2 opciones:

  • El cliente se lo pide al vendedor de la tienda. El vendedor debería rectificar el pedido original y emitir uno nuevo idéntico pero como factura completa. Esta es la mejor opción.

  • El cliente lo pide por mail a la oficina central. Desde el departamento de administración / contabilidad deberían expedir la factura completa. Esto es lo más complejo, hay 2 opciones:

    1. Convertir la simplificada original en canje: Envío al SII como F3 y PDF / ticket de factura completa. No se realizan asientos ni apuntes contables, y si se hacen deberían ser nulos. Esto no existe hoy día.
    2. Rectificar la simplificada original y emitir una nueva de tipo F1. Esto es lo que se hace habitualmente ya que no hay más opciones. Dado que tenemos un asiento resumen que contiene muchas ventas, es una labor compleja y muy manual para el usuario.

En todo caso, el objetivo del issue es decidir sí:

  • Enviamos al SII los sale.order de forma individual. No estarían relacionados con el asiento resumen de facturas simplificadas.
  • Enviamos al SII el asiento resumen de facturas simplificadas (account.move) haciendo uso de l10n_es_aeat_sii_invoice_summary. Lo único que añadiríamos es el envío automático (actualmente se debe hacer manualmente).

** Las facturas de canje se deberían tratar en un issue independiente llegado el momento, lo he añadido sólo para tener toda la visibilidad o incluso plantear alguna otra opción adicional que no haya contemplado.

Saludos,

@AlbertCabedo
Copy link

buenas tardes, bien explicado y resumida toda la información. Entiendo que la mejor opción es Enviamos al SII el asiento resumen de facturas simplificadas (account.move) haciendo uso de l10n_es_aeat_sii_invoice_summary. Lo único que añadiríamos es el envío automático (actualmente se debe hacer manualmente).

dado que en muchos casos el elevado número de operaciones realizaria muchos asientos, entiendo que si hay que priorizar una opción, mejor la de enviar el resumen.

posteriormente,

  1. revisar lo que comentaba de comunicación en el SII de la factura de canje,
  2. A nivel contable:
  3. A nivel de 347

a nivel contable:
Las facturas de canje no tienen ningún tipo de implicación en su contabilidad. Al tratarse de ejercicios fiscales ya cerrados, simplemente está reconociendo un servicio prestado en su momento a estos clientes.

Las razones son las siguientes:

No es necesario que modifique su contabilidad, ya que en su momento contabilizó ese servicio/venta.
No existe corrección del importe de la base o IVA por lo que no implica ningún tipo de ajuste contable.
Tampoco da lugar a ningún tipo de modificación por error en la factura. La factura emitida o ticket ya es una “factura” correcta. Simplemente reemplaza un documento original por uno nuevo, más completo y que refleja exactamente la misma operación.

Efectos contables para el emisor de facturas de canje
La primera interpretación posible desde el punto de vista del emisor de las facturas de canje a efectos contables es que no procede realizar ningún ajuste contable asociado con su emisión. Existen varias razones para no tocar la contabilidad a raíz de su emisión, que serían las siguientes:

a) El importe (base+IVA) de la factura simplificada/ticket por ventas y prestación de servicios fue contabilizado en el momento de la expedición del mismo. Puesto que no se produce ninguna variación en dicho importe al emitir la factura de canje no procedería un ajuste contable, al menos no por esta razón.
b) No procedería la aplicación de la NRV. 22 (Norma de Valoración del PGC -> Cambios en criterios contables, errores y estimaciones contables), ya que la emisión de la factura de canje no da lugar a ningún ajuste producido por un error. No hay error, simplemente remplazamos el documento original por uno nuevo, más completo, pero que refleja los mismos importes y representa la misma operación.
c) Tampoco afecta a las declaraciones de IVA del emisor, pues el IVA de estas facturas de canje ya fue declarado en el momento de la generación de la factura simplificada/ticket, según la Ley del Impuesto sobre el Valor Añadido.

(NO ME CONVENCE ESTE ENFOQUE) Existe un segundo enfoque igualmente válido y con un efecto contable final idéntico, que sí podría dar lugar a un apunte contable doble. Este apunte doble consistiría en realizar un contra-asiento por el apunte realizado en su día (en periodos anteriores) por la emisión de la factura simplificada y un nuevo asiento por la emisión de la factura de canje en el ejercicio actual.

La realización de estos asientos, al compensarse, no produciría ninguna variación final en el saldo de las cuentas a utilizar, por lo que el resultado del ejercicio no sufriría ningún cambio.

Caso distinto es el del receptor de las facturas, en este caso el principal interesado en la emisión de las facturas de canje, puesto que el IVA fue contabilizado como gasto en su día y no como IVA deducible.

El objetivo del receptor de las facturas de canje (el cliente) es precisamente deducirse ese IVA de las facturas originales simplificadas mediante su remplazo por facturas de canje, lo que sí le lleva a realizar obligatoriamente un ajuste contable.

Efectos fiscales para el emisor de facturas de canje
En la factura de canje, que se emite con fecha actual, tendrá que venir indicado el ticket o factura simplificada a la que se corresponde y su fecha original de expedición.

En relación al modelo 347, y siempre que el importe facturado supere los 3.005,06 €/cliente de total (Base+IVA), el emisor de las facturas de canje tendrá que incluir dicho importe en la declaración del año en el que se emiten, es decir, el de la fecha actual.

Según el RD 1065/2007, art. 35, las operaciones a relacionar son las realizadas en el año natural al que se refiere la declaración, las cuales se entenderán producidas el día en que se expida la factura o documento sustitutivo que sirva de justificante de las mismas. Puesto que las facturas de canje llevan fecha actual, procede incluirlas en el periodo actual.

Se entiende que existen motivos fundados para incluir las facturas procedentes del canje en el modelo 347 correspondiente al año de expedición de la factura en base a los siguientes argumentos:

a) No estamos ante un supuesto de factura rectificativa del art. 13 del RD de facturación, sino ante una figura distinta que es el «canje» de tickets por facturas. El supuesto es totalmente distinto pues aquí las operaciones no se declararon en el 347 nunca porque se documentaron mediante tickets, mientras que en una factura rectificativa sí hubo una factura inicial (declarada, en su caso, en el 347) y ahora habría otra.

b) Declarando las operaciones en el modelo 347 del año en que se efectúa el canje se estaría cumpliendo la literalidad del Reglamento de Gestión que indica que las operaciones han de declararse cuando se expide la factura.

Finalmente y como importante consejo práctico, sería muy conveniente «coordinar» en la medida de lo posible la información que incluyan en el modelo 347 tanto el proveedor del servicio como el destinatario de éste, para evitar que salten diferencias en los cruces de datos por parte de la AEAT, que podrían dar lugar a requerimientos y, por tanto, a un trabajo y un coste adicionales.

FAQ GENERALES FACTURAS DE CANJE
¿Cómo contabilizar una factura de canje?
Las facturas de canje son distintas a las facturas ordinarias y, al tratarse de una operación fiscal ya cerrada, no tienen efecto en la contabilidad de la empresa que la emite.

Como el ingreso ya se contabilizó, no es necesario incluirlas de nuevo en el registro de la contabilidad. De la misma forma, no hay que hacer ningún ajuste o modificación de la base imponible o del IVA.

Ejemplo de una factura de canje
Vamos a suponer un ejemplo básico para visualizar todo lo que hemos visto sobre las facturas de canje. Imagina que eres dueño de un restaurante de lujo donde en Julio del año pasado serviste una comida de empresa a 35 comensales por un valor de 1.575 euros. Pasados unos meses, un representante de esta empresa acude a tu restaurante y solicita una factura de canje para poder hacer la liquidación del IVA en su empresa.

En primer lugar, como responsable del restaurante tendrás que asegurar que el cliente ha traído la factura simplificada original. A partir de ahí, simplemente tendrás que emitir una nueva factura que esté numerada correctamente (indicando que se trata de una factura de canje y con una numeración propia) y, por otro lado, añadir las dos fechas de la factura. Una vez hecho esto, ya podrás terminar con el proceso entregando la nueva factura al cliente, que quedaría como algo así:

Otras preguntas frecuentes sobre las facturas de canje
Muchos profesionales tienen dudas sobre cómo proceder cuando un cliente solicita una factura de canje, principalmente por desconocimiento o por miedo de no estar haciendo las cosas correctamente y poder tener problemas con Hacienda.

Vamos a ver algunas preguntas frecuentes sobre las facturas de canje para que termines el artículo y no tengas ninguna duda de cómo funcionan este tipo de facturas.

¿Las facturas de canje son legales?

Sí, las facturas de canje son legales, de forma que los clientes profesionales tienen el derecho a solicitarlas y los profesionales a los que se les solicita pueden emitirlas sin ningún tipo de inconveniente legal.

El uso de las facturas de canje se recoge en el Reglamento de Facturación (art. 15.6) y es ahí mismo donde se establece que no se consideran facturas rectificativas.

¿Qué fecha deben de tener las facturas de canje?

Una factura de canje debe contar con una fecha de emisión correcta, es decir, que coincida con la fecha en la que se emitió esa misma factura. Sin embargo, como es una factura que alude a una factura simplificada anterior, también debe incluir en algún punto una referencia a esta factura original con su fecha.

¿Qué numeración deben de llevar las facturas de canje?

Las facturas de canje no son facturas que afecten a la contabilidad, es por eso que deben tener una numeración propia y con una serie de números correlativa que no se confunda con la numeración de otras facturas ordinarias.

¿Es obligatorio emitir facturas de canje?

Sí, todas las empresas y profesionales tienen la obligación de emitir una factura de canje siempre que la solicitud de la misma se haya realizado conforme a los requisitos que ya hemos comentado en este artículo.

¿Cuál es el plazo para solicitar las facturas de canje?

Las facturas de canje deben ser solicitadas en el plazo de 4 años después de la emisión de la factura simplificada o ticket original que se pretende sustituir o completar.

@anmarmo1
Copy link

anmarmo1 commented Jun 6, 2023

@AlbertCabedo Gracias por la explicación.
Estoy de acuerdo en que las facturas de canje quedarían fuera de esta issue. Solo decir que el módulo l10n_es_aeat_sii_invoice_summary esta basado en que has de crear manualmente la factura y eso duplicaría el asiento de venta del pos.

@SoniaViciana
Copy link
Author

Entonces, finalmente optamos por enviar el asiento resumen de facturas simplificadas al SII. Es decir, dentro de esta sesión tenemos pedidos con factura y pedidos con simplificadas:

image

Las facturas simplificadas se recogen contablemente en el asiento asociado a la sesión, esta:

image

El objetivo sería dotar al asiento contable de los elementos de factura:

image

  • Cliente: el definido conforme a pos_default_partner (ampliamos funcionalidad)

  • Posición fiscal: debería arrastrarse desde el pos.order al asiento. En nuestra experiencia, un TPV siempre aplica la misma posición fiscal a todos los pedidos que contiene. La opción de aplicar distintas posiciones fiscales en una tienda no es habitual y a los vendedores no se les da formación fiscal para que lo puedan usar.
    image

  • Añadir pestaña "SII":

image

Dentro de esta pestaña, los asientos resumen de simplificadas creados desde el TPV deberían tener a TRUE el campo is_invoice_summary y además, autocompletar "Primera factura" y "Última factura"

image

Esto del SII lo habilita l10n_es_aeat_sii_invoice_summary

Aparte, la lógica en los envíos al SII:

  • OUT_INVOICE: Factura agrupada de simplificadas con multitud de pedidos cuyo resultado es positivo -> F4
  • OUT_REFUND: Factura agrupada de simplificadas con multitud de pedidos cuyo resultado es negativo -> F4
  • OUT_INVOICE: Factura de sesión que sólo contiene una venta, el resultado es positivo -> F2
  • OUT_REFUND: Factura de sesión que sólo contiene una devolución, el resultado es negativo -> R5

Conclusiones

  • Con las mejoras anteriores se enviarían al SII de forma automática los asientos resumen de simplificadas
  • Interesante si estos asientos se muestran en el menú de facturas del apartado "Contabilidad", para que los usuarios puedan revisar desde aquí todos los envíos al SII.
  • La numeración del asiento no tendrá sentido de factura. Es decir, a efectos contables / fiscales, la numeración de facturas correcta serían las detalladas en color verde:

image

  • Con el desarrollo, la contabilidad cuadraría a la perfección con el SII como es habitual.

Saludos,

@SoniaViciana
Copy link
Author

Añadido PR respecto a las posiciones fiscales e impuestos dentro del POS -> OCA/pos#1009

@omar7r
Copy link
Contributor

omar7r commented Jun 12, 2023

Hola,

En mi opinión, esto debería de plantearse como envío individual de cada factura simplificada como comentaba más gente, pensad en TicketBAI o el futuro Verifactu, está obligando y va a obligar a tener un QR en cada factura simplificada, entonces ¿por qué no ir ya en este camino y evitar tener que retrabajarlo en el futuro? Además, permitiría una gestión de errores directa y concreta como las facturas actualmente y no contra un asiento de cierre que de tener que tocarlo por algún casual es poco claro y nada sencillo.

Un saludo

@SoniaViciana
Copy link
Author

Buenos días @omar7r

En el supuesto de que enviáramos al SII los ticket de forma individual, se nos puede presentar esta situación:

  • Fecha inicio sesión 31/05/2023 a las 17.00 horas
  • Fecha cierre sesión 01/06/2023 a las 10:00 horas

Se han remitido 10 ticket al SII con fecha 31/05 y 4 con fecha 01/06, sin embargo, sólo se genera un asiento resumen de simplificadas con fecha 01/06.

Llega el momento de presentar el modelo 303 de 05/2023 ante la AEAT, el usuario encuentra las diferencias en el PRE-303 respecto al 303 de Odoo consecuencia de lo anterior. Es decir, desvincular la contabilidad de los envíos al SII puede dar lugar a diferencias en los modelos legales. Actualmente los acogidos al SII pueden y suelen hacer uso del PRE-303, hasta el día de hoy Verifactu no permite lo anterior o por lo menos no se sabe.

¿Se debería si no cambiar el método de facturación del TPV para que cree facturas simplificadas individuales por cada pos.order? ¿Se sabe si Verifactu tendrá algún método de contraste / vínculo respecto al SII?

Para solventar lo anterior sin cambiar el método de facturación, se me ocurre establecer el periodo de liquidación dentro del SII conforme al asiento resumen de simplificadas:

image

Pero creo que no está permitido deducir una factura de venta a posteriori respecto a su fecha de expedición (no lo sé con seguridad).

En todo caso, el envío al SII del asiento resumen es un desarrollo más simple y está más avanzado al disponer ya de l10n_es_aeat_sii_invoice_summary.

Saludos,

@omar7r
Copy link
Contributor

omar7r commented Jun 12, 2023

@acysos está más al tanto, pero según me ha comentado, en el borrador actual del futuro Verifactu, se mantendría el diccionario de datos que actualmente se envía al SII, añadiendo un par de campos para la gestión del QR. Por lo que lo más probable es, que sí sea necesario el envío individual en el futuro.

Respecto a la diferencia con el PRE303, se podría indicar como periodo de liquidación la fecha del asiento de cierre como comentas y valdría aunque requeriría algunos controles extra según el retardo de envío al SII y la fecha de cierre. También se podría usar como fecha contable del asiento de cierre la fecha de apertura de la caja no la de salida y así ya no habría problema, en algún caso ya lo tengo cambiado por desarrollo, por ejemplo en restaurantes, que es donde suele suceder el cruce de días en los cierres de cajas, suelen contabilizar en la fecha de apertura, que es en al fecha que se ejecutan en su mayoría los servicios.

Usar l10n_es_aeat_sii_invoice_summary es más simple si las facturas simplificadas se contabilizan fuera de Odoo, sino, obliga a crera una factura para enviar al SII y luego cancelarla, para que no se duplique el ingreso, lo cual es bastante feo o requiere un desarrollo desde el cierre de sesión como el que planteais para suplantar su funcionalidad desde otro sitio. Y hay casuístcas que podrían ocurrir que no estarían bien cubiertas, por ejemplo, con la secuencia por dispositivo, podría darse el caso de que una misma sesión tenga varias series de factura simplificada.

@AlbertCabedo
Copy link

entiendo que llegado el verifactu, el módulo del SII desaparecerá o será "independiente" de verifactu. la idea de hacerlo masivamente es pensando en clientes grandes que usan odoo en centenares de tienda y para que no les generé miles de asientos, por eso veia más viable esa opción y así "seguimos" contablemente como hasta ahora, con un asiento por día de TPV.

@pedrobaeza
Copy link
Member

Aquí no habrá miles de asientos. Serán miles de envíos al SII únicamente.

@zamberjo
Copy link
Member

Buenos días, tras las OCA Days, hablarlo con todos y analizarlo llegamos a la misma conclusión que @omar7r por lo que hemos desarrollado lo siguiente (WIP):

  • Hemos modulado la parte genérica del SII del account.move a un modelo nuevo sii.mixin, dejando la misma funcionalidad en el account.move.
  • Hemos creado un nuevo módulo l10n_es_pos_sii de forma que añade el envío al SII de los pos.order de forma individual.
  • En cuanto a la fecha que se envía, se ha modulado de forma que es fácilmente heredable adaptándolo así a las necesidades de cada cliente.

Todavía nos faltan algúnas funcionalidades por definir para estar 100% funcional, pero el envío básico ya esta. En poder subimos el PR con los cambios.

Copy link

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.

@github-actions github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Dec 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement stale PR/Issue without recent activity, it'll be soon closed automatically.
Projects
None yet
Development

No branches or pull requests

8 participants