En este artículo
Exportación de Odoo a BMD: concilia el lote antes de la entrega mensual
Un lote ficticio suma 300,00 EUR. Dos documentos siguen teniendo importes incorrectos. El ejemplo muestra por qué disponer del archivo y de un total correcto no demuestra que la entrega esté bien.
Concilia la entrega de Odoo a BMD con los documentos de origen aprobados, el perfil exacto de exportación y la evidencia de aceptación del destino. Compara identidades e importes individuales antes de confiar en los totales. Mantén visibles los abonos, las sociedades y las revisiones. Confirma qué registros aceptó el receptor antes de cerrar la entrega.
Investigación comprobada: 5 de noviembre de 2026. Consultamos documentación oficial de Odoo, el programa público de BMD sobre interfaces estándar y material de un proveedor para una versión concreta. Ejecutamos trece casos sintéticos de comparación en Python. No probamos una exportación de Odoo, una importación de BMD, datos contables de clientes ni una aprobación financiera. El modelo usa datos normalizados; no implementa un formato de archivo de BMD.
¿Qué debe demostrar una entrega de Odoo a BMD?
La entrega debe demostrar tres cosas distintas: que se seleccionó la población de origen correcta, que la exportación conserva el significado aprobado y que el destino aceptó los documentos previstos. Identifica cada etapa y conserva sus pruebas. Una descarga terminada demuestra que existe un archivo. Los registros de destino muestran qué ocurrió después de recibirlo.
Pide al equipo receptor que defina qué significa aceptar un lote. ¿Son documentos preparados para revisión o asientos importados en un espacio de trabajo concreto? Registra el resultado acordado. Un estado compartido de «importado» es ambiguo si los equipos lo interpretan de manera diferente.
| Límite | Evidencia que conservar | Pregunta que responde |
|---|---|---|
| Origen aprobado | Instantánea, sociedad, período, estados documentales y exclusiones. | ¿Qué documentos deben transferirse? |
| Lote generado | Revisión del conector y del perfil, identidad exacta del archivo y comparación por documento. | ¿Qué significado llevaba esta exportación? |
| Resultado en destino | Informe de importación, referencias aceptadas o rechazadas y casos pendientes. | ¿Qué registros previstos aceptó el receptor? |
El lote puede superar la comparación de exportación mientras su aceptación en destino sigue sin conocerse. Mantén visible ese estado, con pruebas que ambos equipos puedan consultar.
¿Qué conector y perfil de importación estás validando?
Valida la combinación exacta de versión y edición de Odoo, revisión instalada del conector y perfil receptor de BMD. Pide que se demuestre un documento representativo con esa combinación. El nombre del producto por sí solo no establece cómo interpretará el destino tus registros. Conserva la configuración concreta que produjo el resultado.
Por ejemplo, MPI describe su módulo BMD para Odoo 19, con contabilidad Enterprise, localización austríaca y columnas de exportación configurables. Esa descripción pertenece a una versión específica. Confirma por separado la compatibilidad con Odoo 20 si es tu destino.
La documentación de localización austríaca de Odoo 20.0 contempla módulos contables, informes y exportación SAF-T en XML. Eso no determina el formato exigido por tu perfil de importación de BMD.
El programa de BMD sobre interfaces estándar distingue importaciones de datos maestros, saldos y archivos de asientos, y trata errores y avisos. No es una especificación completa de campos. Obtén del responsable receptor el perfil y las correspondencias aplicables antes de implementar el archivo.
Incluye abonos y correcciones en la demostración, con sus adjuntos cuando hagan falta. Una factura ordinaria no recorre esos caminos. Registra cualquier preparación manual en destino necesaria para que funcione el ejemplo.
Si el alojamiento o el acceso a la API condicionan la integración, consulta la guía de arquitectura de integración con Odoo. El contrato de aceptación de este artículo sirve tanto para una entrega manual del archivo aprobado como para un transporte automatizado.
¿Qué debe contener el acuerdo de exportación mensual?
El acuerdo debe fijar la población documental prevista, las transformaciones aprobadas y la evidencia requerida en destino. Nombra a quienes pueden cambiar esas decisiones. Vincula la aprobación a la instantánea de origen y a la revisión del lote. Un cambio posterior del origen o de las correspondencias necesita revisión para conservar una aprobación válida.
| Decisión | Definir antes de exportar | Evidencia que revisar |
|---|---|---|
| Población | Sociedad, período contable, estados permitidos y exclusiones expresas. | Referencias de origen aprobadas y parámetros de extracción. |
| Identidad | Identificador estable de origen, revisión y referencia de destino. | Cada documento puede seguirse a través de toda la entrega. |
| Importes | Moneda, base de neto/impuestos/bruto y precisión acordada. | Valores individuales y totales agrupados por sociedad y moneda. |
| Correspondencias | Interpretación aprobada de cuentas, terceros e impuestos para el perfil elegido. | Revisión identificada y responsable de revisión financiera. |
| Abonos y correcciones | Relaciones documentales y tratamiento aprobado del perfil receptor. | Una corrección representativa produce el resultado previsto. |
| Documentación de respaldo | Archivos requeridos, identidad y acceso del destinatario autorizado. | El documento correcto se recupera desde el registro correcto. |
| Finalización | Significado de aceptación y resolución de resultados parciales o desconocidos. | Evidencia del destino vinculada a este lote y sus documentos. |
Separa la fecha del documento del período utilizado para la entrega. Decide cómo entran los documentos tardíos y las correcciones en otro lote, y quién aprueba su tratamiento. El comparador comprueba la regla acordada. Finanzas debe aprobar su interpretación contable.
Conserva una referencia de origen que pueda revisarse de forma independiente. Si la misma transformación errónea produce la exportación y los valores esperados, ambas partes pueden coincidir con el error. Comprueba documentos originales seleccionados contra las correspondencias aprobadas antes de confiar en el control agregado.
El flujo de excepciones de facturas trata las decisiones pendientes durante la entrada. La exportación no debe ocultar una duda de origen convirtiéndola en un valor de destino aparentemente razonable.
¿Por qué un total correcto puede ocultar documentos incorrectos?
Un total correcto puede ocultar documentos incorrectos porque los errores de signo opuesto se compensan al sumarlos. El recuento también pierde la identidad. Compara cada documento de origen aprobado con su equivalente exportado y añade después los totales agrupados. Nuestro ejemplo conserva tres documentos y todos los totales, pero dos documentos tienen netos y brutos incorrectos.
| Documento | Neto | Impuestos | Bruto |
|---|---|---|---|
| INV-001 | 100,00 | 20,00 | 120,00 |
| INV-002 | 200,00 | 40,00 | 240,00 |
| CR-001 | -50,00 | -10,00 | -60,00 |
| Total | 250,00 | 50,00 | 300,00 |
El abono negativo es una convención del ejemplo. Los importes no prescriben el signo requerido por BMD ni establecen un tratamiento fiscal válido. La etiqueta ficticia DEMO-MAP-1 no tiene autoridad contable.
Cambia ahora la primera factura a un neto de 101,00 EUR y un bruto de 121,00 EUR. Cambia la segunda a un neto de 199,00 EUR y un bruto de 239,00 EUR. Mantén los impuestos y el abono. El neto sigue en 250,00 EUR, los impuestos en 50,00 EUR y el bruto en 300,00 EUR. En cada línea sigue cumpliéndose la operación de neto más impuestos.
La comparación documental encuentra cuatro diferencias: neto y bruto en dos facturas. Esas diferencias bloquean el lote aunque los totales coincidan. La comparación por identificador tampoco valida por sí misma los valores de referencia ni demuestra una exportación contable real.
¿Qué demostraron los trece casos ejecutados?
Los trece casos muestran cómo una comparación normalizada distingue diferencias de origen, un candidato correcto sin acuse de importación y una confirmación incompleta del destino. El script utiliza documentos JSON inventados y la biblioteca estándar de Python. Solo comprueba esas reglas del modelo, sin interpretar un archivo de BMD ni ejecutar las aplicaciones de negocio.
| Caso | Decisión observada | Significado dentro del modelo |
|---|---|---|
| Lote sin cambios y acuse completo | ACKNOWLEDGED_IN_MODEL | Referencia, candidato y acuse inventado coinciden. |
| Sin acuse del destino | READY_FOR_IMPORT_REHEARSAL | El candidato concilia; la aceptación en destino no está demostrada. |
| Abono ausente | BLOCKED | Falta un documento esperado. |
| Documento duplicado | BLOCKED | Una identidad compuesta de origen aparece dos veces. |
| Importes que se compensan | BLOCKED | Recuento y totales coinciden, pero difieren cuatro campos de importe. |
| Sociedad incorrecta | BLOCKED | Un documento queda fuera de las identidades aprobadas. |
| Período contable incorrecto | BLOCKED | El período de un documento difiere del valor de origen aprobado. |
| Moneda incorrecta | BLOCKED | La moneda difiere de la referencia. |
| Correspondencia ausente | BLOCKED | La referencia ficticia de correspondencia está vacía. |
| Referencia documental ausente | BLOCKED | Falta la etiqueta de documentación de respaldo requerida. |
| Perfil de importación modificado | BLOCKED | El candidato ya no identifica el perfil revisado. |
| Acuse parcial del destino | RECONCILIATION_REQUIRED | No todos los documentos tienen una referencia aceptada en destino. |
| Acuse de otro contenido | RECONCILIATION_REQUIRED | El acuse no identifica este contenido candidato. |
Descarga el modelo de comparación ejecutable y los resultados registrados. Guarda el archivo Python y ejecútalo con:
python3 reconcile-export.pyLas trece decisiones esperadas coincidieron con la ejecución local. Los importes usan aritmética decimal y la política de comparación exacta del ejemplo. El hash identifica JSON normalizado, no un archivo exportado para BMD. En producción, identifica los bytes reales y el perfil del archivo, y conserva la evidencia documental auténtica del destino.
Una etiqueta de adjunto no vacía no prueba que el receptor pueda recuperar el PDF correcto. Revisa el archivo real y su asociación con el registro durante la aceptación del sistema.
¿Cómo se recupera una importación parcial?
Para recuperar una importación parcial, establece qué documentos fueron aceptados, rechazados o quedaron sin resultado conocido antes de decidir qué repetir. Utiliza el informe y las referencias del destino, y acuerda la corrección con el receptor. Un error del lote no demuestra que todos sus documentos fallaran. Un nuevo nombre de archivo tampoco crea nuevos hechos de negocio.
| Situación observada | Siguiente acción | Evidencia antes de cerrar |
|---|---|---|
| Todavía no hay evidencia del receptor | Solicitar el resultado del destino y mantener pendiente la aceptación. | Identificar si se procesó algún documento. |
| Algunos aceptados y otros rechazados | Conciliar cada estado y acordar la corrección o el reenvío de los rechazados. | Los aceptados están identificados y la recuperación no crea duplicados sin aprobar. |
| Resultado desconocido tras una interrupción | Inspeccionar los registros receptores antes de repetir. | La acción sigue el resultado comprobado, no una suposición sobre el fallo. |
| Origen o correspondencias cambiaron tras la aprobación | Crear una revisión identificada y repetir las comparaciones afectadas. | El lote actual tiene aprobación vigente y trazabilidad al intento anterior. |
No presupongas que el destino admite una corrección, reversión o repetición selectiva determinada. Demuestra el procedimiento acordado con el perfil real y el equipo receptor. Conserva la evidencia del intento original cuando lo sustituya un lote corregido.
Si n8n programa o transporta el archivo, su historial aporta evidencia útil de transporte. La guía de reintentos y recuperación con n8n explica la identidad estable de negocio y la necesidad de conocer el resultado del destino. Aquí, la evidencia decisiva es el estado de cada documento receptor.
¿Qué deben aceptar finanzas e ingeniería?
Ingeniería debe demostrar una selección, transformación, transferencia y recuperación trazables. La persona autorizada de finanzas debe aprobar las correspondencias y la interpretación contable resultante. Registra las decisiones por separado. Una comparación sin diferencias no aporta aprobación financiera. Una plantilla aprobada todavía necesita que sus comprobaciones se ejecuten sobre el sistema real antes de demostrar su comportamiento.
La hoja propuesta de trece controles de aceptación empieza con ejecución NOT_RUN y aprobación financiera PENDING. La evidencia observada y el aprobador están vacíos. Cubre población de origen, abonos, duplicados, importes, sociedades, períodos, monedas, correspondencias, documentos, revisiones, importaciones parciales y confirmación final.
Ejecuta un lote ordinario y un caso receptor deliberadamente incompleto en un entorno protegido. Incluye un abono aprobado y un documento que deba mantenerse bloqueado. Pide a ambos equipos que sigan un documento por el lote hasta su resultado de destino a partir de las pruebas conservadas.
Para una migración puntual, usa el marco de aceptación de migraciones de Odoo. En la operación recurrente, conserva la evidencia de cada mes con su lote y sus pendientes. Un cambio de conector o perfil receptor debe activar las comprobaciones afectadas antes de la siguiente entrega.
La lista de QA antes de la puesta en producción sitúa estos controles dentro de la decisión de entrega. Define quién investiga una confirmación ausente y quién puede aprobar un lote corregido para que el procedimiento funcione cuando falte su operador habitual.
¿Qué implementaríamos primero?
Empezaríamos con una población de origen aprobada, un perfil exacto de exportación y una confirmación del receptor que identifique los documentos resultantes. Demuestra un lote ordinario y un fallo parcial antes de automatizar el calendario. Amplía el alcance cuando finanzas y técnica puedan explicar el resultado y resolver la excepción usando la evidencia conservada.
Para el servicio de integración de API de Wavect, aporta una exportación de muestra autorizada, sus documentos de origen aprobados, el perfil receptor y un caso de corrección difícil. La primera entrega tendrá una pregunta concreta de aceptación: ¿pueden ambos equipos justificar el resultado de cada documento previsto?