Puesta en marcha de Belgium Peppol B2B E-Invoicing Compliance en Odoo: un caso de principio a fin

La empresa del caso y lo que quiere conseguir

Ejemplo Caso ilustrativo: la empresa y sus datos son inventados para explicar el flujo.

Distribuciones Kessel SRL es una empresa inventada que vende material de oficina a otras empresas en Bélgica y factura desde Odoo 18. Acaba de instalar Belgium Peppol B2B E-Invoicing Compliance y quiere enviar sus facturas por Peppol sin perder de vista qué ha salido, qué ha llegado y qué ha fallado. Su responsable de administración, Marta, dedica la primera semana a dejarlo todo en orden. Lo que sigue es lo que hace ella y lo que va viendo en cada lista.

Primer día: el perfil de cumplimiento de la compañía

Marta empieza por Compliance Profiles, dentro de Invoicing. En la animación de más abajo, con datos de demostración, se ve un perfil de la compañía Acme Belgium SPRL con su ID Peppol, el estado Completed, el modo Test / SMK y la casilla de salida marcada.

Entre los estados que define el módulo hay un campo state con los valores Draft, In Progress y Completed. El módulo tiene además campos de estado por paso, de step_1_state a step_7_state, y cada uno puede estar en Not Started, In Progress o Completed. Marta se apunta estos nombres para reconocerlos cuando aparezcan y no da la puesta en marcha por buena mientras vea pasos en Not Started o In Progress.

Segundo día: los IDs Peppol de los clientes

Antes de mandar nada, Marta revisa a quién va a enviar. El módulo guarda un peppol_id_status con estos valores: Not Yet Resolved, Resolved, Not Found, Non-Belgian Scheme y Lookup Failed. También existe un inbound_endpoint_status con Unknown, Resolvable y Not Resolvable.

Su criterio es sencillo: los clientes en Resolved pasan; los que aparecen en Not Found, Lookup Failed o Non-Belgian Scheme los revisa uno a uno antes de facturarles por Peppol, y los que siguen en Not Yet Resolved los deja pendientes. Las etiquetas son literales del módulo y conviene leerlas tal cual, sin traducirlas en la cabeza a otra cosa.

Tercer día: las reglas de validación antes de la primera factura

En Invoicing › Belgium Peppol › Validation Rules Marta encuentra la lista de reglas. Las columnas son Rule Name, Rule Code, Severity, FR Reference y Active. En la lista casi todas bloquean la transmisión y una es solo un aviso, así que sabe qué reglas pararán una factura y cuál solo le avisará.

No toca la columna Active sin saber qué hace cada regla. Si una factura no pasa, el texto exacto del aviso está explicado en los mensajes de error y avisos del módulo.

La primera semana: leer el Transmission Log

Con las primeras facturas enviadas, la lista que Marta abre cada mañana es Transmission Log. Ahí ve la referencia de factura, la dirección, el ID Peppol del destinatario, la fecha de transmisión y el estado.

El campo status puede tomar estos valores: Draft / Validation, Sent, Delivered, Acknowledged, Failed, Received y Manual. Hay además un transmission_status con Sent, Delivered y Failed. La rutina de Marta la primera semana:

• Filtra por Failed y no cierra el día con ninguno sin mirar.
• Revisa los que siguen en Draft / Validation.
• Abre los que están en Manual y comprueba cada uno.
• Comprueba que los documentos recibidos aparecen como Received.

Otros estados que Marta aprende a reconocer

El módulo usa dos juegos de estados más. Uno con New, Acknowledged, Resolved y Dismissed, y otro con Open, Resolved y Past Deadline. La norma que se pone Marta es no dejar nada en New al final de la semana y tratar cualquier Past Deadline como prioridad.

También encuentra un registro con los campos company_id (Company), field_name (Field Name), old_value (Old Value), new_value (New Value), user_id (User), timestamp (Timestamp) y notes (Notes). Marta se queda con los nombres de las columnas para leerlas cuando las necesite y usa Notes para dejar sus comentarios.

Archivo y paquetes de evidencias

En Archive Scans cada registro muestra la fecha de escaneo, el resultado Pass o Fail, el total de archivos y columnas de faltantes y alterados. Marta se fija en cualquier Fail y en esas dos últimas columnas.

En Invoicing › Evidence Packs está la lista de paquetes de evidencias, con el botón New y la columna Pack Name.

El módulo define estados Draft, Generating, Done y Error para un campo state, y Draft, Running, Done y Partial Success para otro. Marta no da por terminado nada que esté en Error o Partial Success.

La lista 2028 Readiness

Por último abre Invoicing › 2028 Readiness. Es una lista con código, título, estado de preparación, tipo y responsable. El estado de preparación toma los valores Ready, Partial y Gap.

Lo primero que hace es poner un responsable a cada elemento, porque en la lista aparecen vacíos.

Qué aprender del caso

• Revisa el perfil de cumplimiento antes que nada y aprende los estados por paso.
• Mira el peppol_id_status de los clientes antes de enviar, no después.
• Lee las reglas de validación para saber cuáles bloquean y cuál solo avisa.
• La primera semana, el Transmission Log filtrado por Failed es tu lista diaria.
• Asigna responsables en 2028 Readiness desde el primer día.

Si quieres ver cómo encajan menús y registros por dentro, tienes cómo funciona el módulo en Odoo.

Cómo te ayuda FlexigoTech

FlexigoTech implanta Odoo 17, 18, 19 y 20 y desarrolla conectores e integraciones a medida, así que podemos acompañarte en esta puesta en marcha o adaptar el flujo a tu empresa. En Odoo Apps, el módulo cuesta 9 € por versión de Odoo (17, 18, 19 y 20), pago único y sin IVA; cada versión de Odoo se compra allí por separado. El servicio local cuesta 29 €/mes o 290 €/año sin IVA (Pro: 58 €/mes o 580 €/año), y con la suscripción el módulo para las versiones nuevas de Odoo va incluido si lo compraste en flexigotech.com. Sin suscripción, o con el servicio suspendido, se para lo que da la suscripción, pero los datos se quedan en tu Odoo; tienes los detalles en la página del módulo y en la ficha de Odoo Apps.

Sigue leyendo