--- title: "Odoo BMD: concilia la exportación mensual" canonical: https://wavect.io/es/blog/odoo-bmd-export-reconciliation/ language: es description: "Concilia la exportación de Odoo a BMD por documento, importe y acuse. Usa un modelo ejecutable y controles de aceptación antes de la entrega mensual." image: "https://wavect.io/img/blog/headers/header_odoo-bmd-export-reconciliation.png" author: ["Kevin Riedl"] published: "2026-11-05" updated: "2026-11-05" reviewed: "2026-11-05" --- # Exportación de Odoo a BMD: concilia el lote antes de la entrega mensual [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 minutos de lectura · 5 nov 2026 Última revisión 5 de noviembre de 2026 [**Siguiente**](/es/blog/odoo-migration-acceptance-reconciliation/) Resumen Concilia los documentos aprobados de Odoo con la exportación exacta y la evidencia del receptor. Compara identidades e importes individuales, conserva abonos y sociedades, y resuelve importaciones parciales antes de repetir un lote. El modelo ejecutable demuestra trece casos sintéticos; la hoja separada propone comprobaciones todavía no ejecutadas en el conector real. 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](https://www.mpi-erp.at/bmd), 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](https://github.com/odoo/documentation/blob/20.0/content/applications/finance/fiscal_localizations/austria.rst) 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](https://www.bmd.com/at/akademie/akademieshop/seminar/d/fibu-standardschnittstellen-10943/52) 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](/es/blog/odoo-erp-api-integration-limits-2026/). 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](/es/blog/odoo-invoice-ocr-ai-exception-workflow/) 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](/downloads/odoo-bmd-export-reconciliation/reconcile-export.py) y los [resultados registrados](/downloads/odoo-bmd-export-reconciliation/model-results.json). Guarda el archivo Python y ejecútalo con: ``` python3 reconcile-export.py ``` Las 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](/es/blog/odoo-n8n-idempotency-recovery/) 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](/downloads/odoo-bmd-export-reconciliation/handoff-acceptance.csv) 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](/es/blog/odoo-migration-acceptance-reconciliation/). 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](/es/software-development-guide/software-qa-checklist-before-launch/) 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](/es/services/api-integration/), 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? ## Preguntas sobre la conciliación de exportaciones Odoo-BMD ### ¿Un CSV genérico es compatible con BMD? CSV es un contenedor de valores. La compatibilidad depende del perfil receptor, campos requeridos, correspondencias, codificación e interpretación. Obtén esos requisitos y demuestra la importación real con documentos representativos. El JSON normalizado del artículo especifica el comportamiento de comparación; no es un diseño de archivo que puedas cargar en BMD. ### ¿Un conector para Odoo 19 demuestra compatibilidad con Odoo 20? No. Una descripción para una versión solo respalda el alcance que declara. Pide al mantenedor la versión, edición, dependencias y revisión exactas, y prueba el perfil receptor que utilizarás. Conserva la evidencia de esa combinación en vez de tratar un nombre de módulo conocido como confirmación para otra versión. ### ¿El abono negativo del ejemplo define el signo requerido por BMD? No. Los valores negativos son una convención de esta comparación sintética. El tipo documental, tratamiento de signos, relación con la corrección y resultado de destino deben seguir el perfil del conector y la regla financiera aprobados. Demuestra un abono representativo con el receptor antes de aceptar esa parte del alcance. ### ¿Puede el comparador aprobar una correspondencia fiscal? Puede comprobar que el candidato utiliza la referencia y los valores aprobados. No puede establecer que las reglas sean correctas para la transacción subyacente. El responsable financiero debe aprobar la interpretación y sus excepciones. Mantén esa autoridad separada del resultado técnico que indica que dos registros coinciden. ### ¿Basta una referencia documental para validar su PDF? La referencia solo demuestra que se proporcionó una etiqueta o enlace. La aceptación debe recuperar el archivo real, verificar que corresponde al registro previsto y confirmar el acceso del destinatario autorizado. Decide cómo comparar originales o documentos regenerados deliberadamente y conserva esa evidencia junto con la entrega. ### ¿Una transferencia correcta debe cerrar el período? Solo si la regla acordada termina en la entrega del archivo y asigna expresamente las responsabilidades posteriores. Si incluye aceptación de importación, conserva el resultado del destino y la lista de documentos pendientes antes de cerrarla. Un mensaje de transporte correcto no demuestra qué registros contables creó o aceptó el sistema receptor. ### ¿El script Python se conecta a Odoo o BMD? No. Ejecuta trece casos sobre documentos JSON inventados con la biblioteca estándar de Python. Demuestra comparaciones documentales y límites de confirmación sin credenciales ni acceso a la red. Usa los resultados para evaluar tus controles y después ejecuta la hoja separada de aceptación con el conector, los archivos y el entorno receptor reales. QA y preparación para producción ## Qué leer después Pruebas, auditorías, mantenimiento y hardening para software fiable. [Empieza aquí**QA para Código Generado por IA**](/es/blog/qa-for-ai-generated-code/) - [Malware en ZIP enlazado desde README: revisa qué instalas](/es/blog/readme-zip-malware-install-review/) - [Módulos Odoo generados por IA: audita las reglas de negocio](/es/blog/ai-generated-odoo-module-audit/) - [Aceptar una migración a Odoo: concilia registros y saldos](/es/blog/odoo-migration-acceptance-reconciliation/) - [Pruebas de agentes IA en Odoo: valida las actividades guardadas](/es/blog/odoo-ai-agent-business-state-tests/) - [Migrar permisos a Odoo 20: prueba el aislamiento entre empresas](/es/blog/odoo-20-company-access-migration-tests/) [Artículo anterior**Importación a Odoo con IA: valida el mapeo de precios**](/es/blog/odoo-ai-data-mapping-validation/) [Artículo siguiente**Datos expuestos en Lovable: cómo verificar la corrección**](/es/blog/lovable-supabase-data-exposure/) [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 minutos de lectura · 5 nov 2026 Última revisión 5 de noviembre de 2026 [**Siguiente**](/es/blog/odoo-migration-acceptance-reconciliation/)