[18.0] Migration de Integración de FACe a v18

[etobella]

El envío de la factura electrónica a FACe ha cambiado mucho con los años:

en v11 y v12 usabamos un model dentro de l10n_es_facturae en el que permitiamos diferentes integraciones (Como FACe y e.Fact)

A partir de v13 empezamos a usar el framework de EDI de OCA que està basado parcialmente en los modelos comentados.

El problema que nos surge es que el Framework de EDI es bastante complejo y añade una capa de complejidad bastante importante (connector, queue job...).

Personalmente se me ocurren 3 opciones:

1. Usar el account_edi de Odoo, pero tiene 2 limitaciones:
   1. No contempla de forma correcta el envío una segunda vez (complica los reintentos)
   2. No contempla la recepción de información externa
2. Crear de nuevo unos modelos sencillos dentro de FACe. Al no tener e.Fact, la cosa es mucho más sencilla ahora, aunque implicará hacer algo "parecido" pero mucho más simplificado a lo hecho por el framework
3. Seguir con el framework de OCA

¿Cual es vuestra opinión?

[ValentinVinagre]

Hola,
No veo mal que haya un módulo para gestiona las comunicaciones, ya que da mucha más versatilidad a OCA. El problema que veo es que el framework EDI le ha pasado como al contract, ha evolucionado mucho y de tener una orientación sencilla de utilización ha pasado a ser un monstruito jaja.
¿Cabe la posibilidad de separación y adaptación del framework EDI?

Según estuve mirando en su día el punto 1 no lo veo viable. El punto 2, me gustaría no realizarlo ya que realizar módulos bases de comunicaciones es muy útil, a lo mejor ... añadir un apartado a los videos donde se explicase el funcionamiento de framework EDI ¿podría estar bien @etobella ?

Creo que como has comentado enric, el camino natural ha ido a la extracción de ese apartado, no veo del todo bien volver hacía atrás, si no, que se tendría que simplificar. ¿Creación de otro módulo de comunicaciones más sencillito? (pero eso se podría conseguir con el refactor y separación del framework edi ¿correcto?)

[pedrobaeza]

¿No podríamos hacer como con SII, que solo se necesitan unos cuantos campos de control? Realmente el resto de información se ha demostrado no demasiado útil, y más si hay una plataforma como FACe detrás, donde la misma ya registra la actividad. A efectos prácticos, solo necesitamos saber si se ha enviado o no, y error en caso de que no.

[etobella]

Seria otra opción, si, por eso eran las ideas que se me ocurrían por ahora. De todas formas, si simplificasemos el EDI Framework no lo vería mal yo

[pedrobaeza]

El tema es depender de la migración de ese framework en cada versión para tener esto operativo, y más si se da integración por lo de la ley "Crea y crece". En ese sentido deberíamos ser más autónomos. Por eso también se quiso quitar de en medio queue_job en el SII.

[etobella]

También depende de otros módulos, aunque el edi-framework acostumbra a ser el más complejo.

Además, la ley crea y crece no irá con facturae, así que si deberá ser con un módulo diferente (y sus respectivos campos y tal)

[pedrobaeza]

Cuantos menos módulos haya en la pila, mejor, y algunas dependencias son lógicas (como l10n_es_facturae), pero todo el framework EDI no.

[etobella]

En eso estoy de acuerdo @pedrobaeza De todas formas, el problema no es el edi-framework, es todo lo que lleva incorporado (queue job, connector....) que tiene una arquitectura demasiado compleja 😢

[pedrobaeza]

Pues entonces sí que estás de acuerdo, porque el tema es que esa pila es demasiado compleja, y en 18 o cortamos por lo sano, o esa supuesta refactorización del EDI no va a llegar, porque ya hay una parte de la pila fusionada y otros no van a querer cambiarla, y mientras, seguiremos sin tener este módulo disponible.

[ValentinVinagre]

A nivel de pilas de módulos obviamente sería mejor integrarlo en el propio y listo, pero veo mejor que exista uno base para que el máximo de módulos se pueda beneficiar de ello, como actualmente está el framework-EDI. Estoy de acuerdo en que la dependencia tecnológica de ese módulo es muy grande y hay puntos de los cuales se quiere "huir" (job_queue) como pasó con el SII (también se podría mirar de adaptar el módulo para el queue o triggers de odoo, según configuración o extensiones).
Según lo veo yo si integramos esta conexión directamente en el módulo, estamos "cerrando" y duplicando funcionalidades que actualmente están genéricas. Está bien que hayan módulos bases para circuitos de comunicaciones, ya que estamos viendo que cada vez es más común.

[pedrobaeza]

Yo no veo que tenga tanta base compartida, pero si acaso, esa base podría ir en l10n_es_aeat como hicimos con SII/VeriFactu.

[ValentinVinagre]

Pero entonces si otros módulos se quieren aprovechar de esas funcionalidades si no son del repo l10n-spain, no podrán.
Por otro lado, esta característica podría necesitarse o no ¿es necesario ponerlo en el l10n_es_aeat? Ya que en general no gusta ampliar ese módulo.

[pedrobaeza]

¿Pero qué funcionalidad se va a reaprovechar? A ver, dejemos de hablar en abstracto. Aquí no hay nada reaprovechable realmente. Lo dicho, al final tenemos unos campos de estado de envío/error, y el código que llama a la API de FACe. Por eso digo que no hay que complicarse. Teniendo librerías Python para esas comunicaciones, y que se inicializan con dos líneas y se envían datos con otras 2, dejemos de montar capas abstractas que si edi_webservice, y sustituyendo código por configuraciones raras que continuamente cualquier cambio hacía que ya no saliera un botón o que no se enviara.

Lo dicho, tenemos el antecedente del SII donde no hay complicación. Y lo de l10n_es_aeat era siguiendo vuestra línea de razonamiento, pero que efectivamente, aquí no hay código compartido con nada. Lo otro de SII/VeriFactu era porque las estructuras de datos que se envían son iguales en ambos, y sí es más cantidad de código.