EDI

Este módulo tiene como objetivo proporcionar una infraestructura para simplificar el intercambio de documentos entre sistemas que proporcionan una plataforma de configuración. Será heredado por otros módulos con el fin de definir las implementaciones adecuadas de los componentes.

Para definir un nuevo Exchange Record, necesitamos configurar:

• Backend Type
• Exchange Type
• Backend
• Components

Jobs

• Internal User: podría ser un usuario EDI sin siquiera saberlo, desencadenando flujos EDI mediante algunas de sus acciones sobre registros de negocio; no necesita acceso a los trabajos de cola relacionados.
• EDI User: usuario EDI más consciente que a veces podría necesitar depurar cosas un poco más y, por lo tanto, necesita acceso a los trabajos de cola relacionados.
• EDI Manager: acceso completo a la configuración.

Código a ejecutar

Por defecto, EDI Framework utiliza campos en edi.backend para obtener la función correcta a ejecutar. Cada función está relacionada con un modelo donde se define la función específica. Este modelo necesita heredar el handler específico de cada caso.

• receive: modelo edi.oca.handler.receive con la función receive.
• process: modelo edi.oca.handler.process con la función process.
• generate: modelo edi.oca.handler.generate con la función generate.
• send: modelo edi.oca.handler.send con la función send.
• check: modelo edi.oca.handler.check con la función check.
• validate on inputs: modelo edi.oca.handler.input.validate con la función input_validate.
• validate on outputs: modelo edi.oca.handler.output.validate con la función input_validate.

Puedes ver un ejemplo en los tests fake_models.

Para un comportamiento más complejo, puedes usar el módulo edi_component_oca para usar componentes.

Generación de EDI por el usuario

En el exchange type, podría ser posible definir un conjunto de modelos, un dominio y un fragmento de código. Después de definir estos campos, veremos automáticamente botones en la vista para generar los exchange records. Esta configuración es útil para definir una forma de generación gestionada por el usuario.

Configuración de reglas de exchange type

Los exchange types se pueden configurar aún más con reglas. Puedes usar reglas para:

• hacer que los botones aparezcan automáticamente en los formularios
• definir tu propia lógica personalizada

Ve a un exchange type y ve a la pestaña "Model rules". Ahí puedes añadir una o más reglas, una por modelo. En cada regla puedes definir un dominio o un fragmento para activarla. En el caso del tipo "Form button", si el dominio y/o el fragmento se cumplen, aparecerá un botón de formulario en la parte superior del formulario. Este botón puede ser usado por el usuario final para generar manualmente un exchange. Si hay más de un backend y el exchange type no tiene un backend establecido, aparecerá un asistente pidiendo seleccionar un backend a usar para el exchange.

En el caso del tipo "Custom", tendrás que definir tu propia lógica para hacer algo.

Manejadores de eventos personalizados mediante edi.configuration

El framework puede despachar eventos del ciclo de vida EDI a configuraciones definidas por el usuario, proporcionando una alternativa declarativa a los eventos de componentes. Cada registro edi.configuration vincula un trigger (un código edi.configuration.trigger) a un fragmento (snippet_do) que se ejecuta cada vez que el evento coincidente se dispara en un exchange record.

Los eventos integrados disparados por EDIExchangeRecord incluyen:

• on_edi_exchange_done — exchange procesado correctamente
• on_edi_exchange_error — exchange finalizado con error
• on_edi_exchange_done_ack_received — archivo ACK recibido
• on_edi_exchange_done_ack_missing — ACK esperado no recibido
• on_edi_exchange_done_ack_received_error — ACK recibido con errores
• on_edi_exchange_<action>_complete — finalización de acción genérica (p. ej. generate_complete, send_complete), disparado una vez en el exchange record y una vez en su registro relacionado cuando existe

El fragmento recibe al menos dos variables en su contexto de evaluación:

• conf — el registro edi.configuration actual
• record — el objetivo del evento (ya sea el propio edi.exchange.record o su registro de negocio relacionado)

Además de los extras estándar de edi_exec_snippet_do (operation, edi_action, old_value, vals, ...).

Los triggers también pueden ser disparados por una acción programada en lugar de por un exchange. Añade un edi.configuration.trigger con un código propio, luego una acción programada sobre edi.configuration ejecutando model._cron_run_by_trigger("your_code") en el periodo que necesites. Ningún trigger de este tipo se incluye como datos, ya que los periodos que necesita una base de datos son propios; los datos de demostración tienen uno horario y otro diario para copiar.

Un trigger programado no tiene registro de origen, por lo que sus configuraciones se ejecutan sobre los registros vinculados a ellas, o una vez cuando son globales.

Hay disponibles dos modos de búsqueda complementarios, y se pueden combinar libremente en el mismo flujo.

Configuraciones de eventos globales

Usa este modo cuando quieras que una configuración reaccione a eventos en cualquier registro de negocio que viaje a través de EDI, sin configuración por partner.

Marca Global Configuration (is_global) en el edi.configuration. Cuando se dispara un evento, el framework llama a edi.configuration.edi_get_conf_global(exchange_record, trigger), que selecciona todas las configuraciones globales activas cuyo trigger coincide con el código del evento, filtradas por el exchange record de origen:

• Exchange type (type_id): debe coincidir con el tipo del exchange record, o dejarse vacío para aplicarse a todos los tipos
• Backend (backend_id): debe coincidir con el backend del exchange record, o dejarse vacío para aplicarse a todos los backends
• Model (model_id / model_name): debe coincidir con el modelo del registro relacionado (p. ej. sale.order, account.move), o dejarse vacío para aplicarse a todos los modelos

Los valores vacíos significan "se aplica a todos". Las configuraciones inactivas y las configuraciones no globales se ignoran. Todas las configuraciones coincidentes se ejecutan en secuencia.

Casos de uso típicos:

• Publicar un mensaje genérico de chatter en cada exchange que finaliza con error
• Enviar una notificación a un sistema externo cada vez que se recibe un ACK para un backend dado
• Registrar información de auditoría adicional para cada exchange de un tipo dado

Configuraciones de eventos específicas de partner (basadas en relación)

Usa este modo cuando la reacción deba depender del partner (o cualquier otro registro relacionado) involucrado en el exchange.

En este caso las configuraciones no se marcan como globales. En su lugar, el registro de negocio expone una relación edi_config_ids (mediante edi.exchange.consumer.mixin._edi_config_field_relation, que por defecto devuelve self.env["edi.configuration"] y se puede sobrescribir, por ejemplo para apuntar a self.partner_id.edi_config_ids). Cuando se dispara un evento sobre el registro de negocio (p. ej. al crear, al escribir, al enviar por email/EDI), el framework llama a edi_confs.edi_get_conf(trigger) sobre esa relación y ejecuta los fragmentos coincidentes.

Comparado con las configuraciones globales:

• El descubrimiento proviene de la propia relación del registro, no de una búsqueda en toda la base de datos; este es el lugar adecuado para modelar reglas del tipo "este partner quiere este comportamiento"
• El filtrado se reduce a trigger y (opcionalmente) backend_id, ya que el recordset ya está acotado por la relación
• Se aplica la misma API de snippet_do, por lo que un fragmento se puede reutilizar tal cual entre configuraciones globales y específicas de partner

Casos de uso típicos:

• Enviar un flujo EDI específico solo para un subconjunto de partners
• Personalizar la generación de documentos por cliente (p. ej. distinta plantilla de email, distinto transporte)
• Alternar entre entrega por EDI y por email según las preferencias del partner

Tras ciertas operaciones o ejecución manual, se generarán registros de Exchange. Estos registros de Exchange pueden ser registros de entrada o registros de salida.

El cambio de estado puede ser ejecutado manualmente por el sistema o ser gestionado mediante ir.cron.

Registros de Exchange de salida

Un registro de salida está destinado a ser utilizado para el intercambio de información desde Odoo hacia otro sistema.

El flujo de un registro de salida debería ser:

• Creación
• Generación de datos
• Validación de datos
• Envío de datos
• Validación de datos procesados correctamente por la otra parte

Registros de Exchange de entrada

Un registro de entrada está destinado a ser utilizado para el intercambio de información desde otro sistema hacia odoo.

El flujo de un registro de entrada debería ser:

• Creación
• Recepción de datos
• Verificación de datos
• Procesamiento de datos