En este artículo
Módulos Odoo generados por IA: audita las reglas de negocio
Aprobar un descuento parece sencillo: marcar un campo y guardar quién aprobó. Nuestro ejemplo deliberadamente defectuoso aprueba un presupuesto cancelado, confía en un aprobador inventado por quien llama y deja cambios parciales tras un fallo provocado. La demostración habitual sigue funcionando.
Audita un módulo Odoo generado por IA contra unas reglas de negocio aprobadas y la versión exacta instalada. Reproduce fallos relevantes, inspecciona registros finales y verifica las correcciones independientemente. Un modelo local ayuda a definir pruebas; las evidencias nativas de instalación, autorización, transacciones y actualización siguen decidiendo si el módulo puede publicarse.
Investigación revisada: 5 de noviembre de 2026. Revisamos fuentes oficiales de Odoo 20 y ejecutamos trece casos ficticios de aprobación. Ambas implementaciones Python se escribieron para este artículo; no son código de clientes ni una evaluación de una herramienta de IA. No se instaló un addon ni se ejecutó una actualización nativa. Todas las comprobaciones nativas propuestas siguen en NOT_RUN.
¿Qué debe decidir la auditoría del módulo?
Debe decidir si una personalización concreta tiene evidencias suficientes para publicarse, necesita una reparación acotada o conviene reemplazarla por una implementación más sencilla aprobada. Empieza por los cambios permitidos al comando de negocio. Una puntuación de calidad del código no aporta una regla ausente ni decide quién tiene autoridad para aprobarla.
Pide al responsable que demuestre el requisito con la configuración actual antes de ampliar el código. Si un flujo mantenido ya lo satisface, compara esa opción con mantener una sustitución. Es una decisión que verificar en la versión instalada, no una suposición de que toda aprobación personalizada sea innecesaria.
Fija después el alcance: commit del módulo, versión y edición de Odoo, revisiones de dependencias, registros afectados e identidades de ejecución. Incluye los ajustes que modifican el comportamiento. Revisar una rama sin su configuración puede dejar fuera la ruta concreta que utilizará el negocio.
La guía general de QA para código generado por IA cubre la preparación para producción. Aquí revisamos una personalización determinista de Odoo. La guía de estados del negocio para agentes trata tareas completas y elección de herramientas.
¿Qué debe hacer el ejemplo de aprobación?
El ejemplo aprueba la versión actual de un presupuesto en borrador solo si el actor tiene autoridad para su empresa y el descuento está dentro de un límite ficticio de delegación. Registra una vez la identidad fiable. Debe rechazar decisiones desactualizadas o prohibidas sin aprobación parcial, incluso si falla un elemento posterior del lote.
El presupuesto ficticio Q-17 pertenece a A, está en la revisión 3 y empieza con un descuento del 5,00 %. El usuario 7 puede aprobar desde el 0 % hasta el 10,00 %, incluido. Una petición del 10,01 % exige otra decisión. Son reglas ilustrativas, no valores predeterminados de Odoo. Los campos approval y approved_revision pertenecen al modelo Python.
| Regla | Resultado permitido | Comportamiento exigido al fallar |
|---|---|---|
| Autoridad y empresa | El actor aprobado actual actúa dentro de A. | Sin rol o con empresa no autorizada, el registro no cambia. |
| Revisión y ciclo de vida | La versión revisada sigue vigente y el presupuesto continúa en borrador. | Se rechaza una revisión antigua o un presupuesto cancelado. |
| Límite delegado | El 10,00 % está incluido en el límite del ejemplo. | El 10,01 % no puede recibir esta aprobación. |
| Identidad acreditada | Se registra al usuario fiable 7. | Una etiqueta del solicitante no puede sustituirlo por el usuario 99. |
| Selección repetida | Una aprobación y una entrada de auditoría por revisión. | Repetir o duplicar la selección no añade otro efecto de aprobación. |
| Fallo del lote | El lote acordado termina con sus evidencias de auditoría. | Un rechazo o fallo de auditoría provocado no deja cambios parciales. |
La aprobación modifica aquí un campo de revisión. No confirma el presupuesto, crea una entrega ni contabiliza. Ese límite define qué significa «éxito». Si el módulo real realiza una acción posterior, añade su autorización y el estado final que debe producir.
Resuelve las reglas discutidas antes de generar resultados esperados. La guía de conflictos entre reglas de negocio explica cómo asignar esa decisión. Inspeccionar una función que acepta el 10,00 % no permite deducir que ese límite sea correcto.
¿Qué defectos descubre la revisión comentada?
Descubre requisitos previos ausentes, una identidad de aprobación no fiable y cambios que sobreviven a una acción incompleta. Las llamadas repetidas también añaden otro efecto de auditoría. Cada hallazgo vincula una instrucción concreta con un caso incumplido. Esto ayuda más a decidir una publicación que asignar riesgo genérico a la etiqueta «generado por IA».
La implementación defectuosa contiene esta secuencia, abreviada para mostrar el orden:
quote["approval"] = "approved"
quote["approved_revision"] = expected_revisions[key]
quote["approved_by"] = claimed_approver or actor["uid"]
if key == fail_audit_for:
raise InjectedAuditFailure(key)
store["audits"].append({
"quote": key,
"revision": expected_revisions[key],
"actor": quote["approved_by"],
})La secuencia no verifica si el actor puede aprobar el registro actual. Las indicaciones de Odoo sobre métodos públicos consideran no fiables los registros y parámetros suministrados; comprobar acceso CRUD no acredita todas las condiciones de negocio. Revisa el método receptor, no solo el botón visible.
| Hallazgo | Consecuencia en el ejemplo | Corrección que verificar |
|---|---|---|
| Sin controles actuales de autoridad y registro | Un actor o empresa no autorizados reciben aprobación. | Validar identidad fiable y registro destino antes de modificarlo. |
| Sin condiciones de revisión, estado o límite | Se aprueba una petición antigua, cancelada o fuera del límite. | Comparar el contrato aprobado con los valores actuales. |
| El solicitante elige al aprobador registrado | La auditoría atribuye el usuario 99 en lugar del 7. | Derivar la atribución de la identidad fiable de ejecución. |
| Cada selección añade un efecto | Una repetición o duplicado produce dos entradas de auditoría. | Reconocer una aprobación ya completada de esa revisión. |
| Mutación antes del fallo sin límite atómico | El fallo de auditoría deja un registro aprobado o un lote parcial. | Demostrar el resultado de todo o nada en la implementación real. |
La versión corregida valida la selección y aplica cambios sobre una copia antes de reemplazar el estado del modelo. Representa el resultado requerido; no implementa transacciones de Odoo. Las directrices oficiales de desarrollo explican la responsabilidad transaccional del framework y por qué revisar commits manuales sin justificar. Los cursores gestionados explícitamente como excepción necesitan un análisis aparte.
Descarga el registro comentado de hallazgos para relacionar defectos y reproducciones. Las pruebas de acceso entre empresas en Odoo 20 cubren la transición específica de permisos. Una lista antigua y genérica de ACL no basta para esa migración.
¿Qué cambió en las trece pruebas del contrato?
La versión defectuosa incumple once de las trece expectativas fijas. La corregida cumple las trece. Ambas superan la aprobación habitual y el límite exacto, lo que explica cómo una demostración satisfactoria puede ocultar los demás problemas. Estas cifras corresponden a ejemplos construidos deliberadamente, no a una tasa de defectos de código Odoo generado por IA.
| Caso | Versión defectuosa | Versión corregida |
|---|---|---|
| Aprobación habitual del 5,00 % | Aprobada; una entrada de auditoría | Aprobada; una entrada de auditoría |
| Límite exacto del 10,00 % | Aprobada; una entrada de auditoría | Aprobada; una entrada de auditoría |
| Solicitud del 10,01 % | Aprobada incorrectamente | Rechazada; sin cambios |
| Actor sin autoridad de aprobación | Aprobada incorrectamente | Rechazada; sin cambios |
| Registro de B no autorizada | Aprobada incorrectamente | Rechazada; sin cambios |
| La revisión cita versión 3; el registro está en 4 | Aprobada incorrectamente contra versión 3 | Rechazada; sin cambios |
| Presupuesto cancelado | Se marca la aprobación igualmente | Rechazada; sin cambios |
| Mismo presupuesto seleccionado dos veces en una petición | Dos entradas de auditoría | Una entrada de auditoría |
| Misma aprobación invocada dos veces | Dos entradas de auditoría | Una entrada de auditoría |
| El solicitante proporciona aprobador 99 | Atribuye usuario 99 | Atribuye usuario fiable 7 |
| Fallo de auditoría tras asignar aprobación | La marca permanece; ninguna entrada de auditoría | Sin cambios |
| Segundo registro del lote pertenece a B no autorizada | Ambos aprobados | Ningún registro cambia |
| Falla la segunda escritura de auditoría del lote | Ambos aprobados; una sola entrada | Ningún registro cambia |
Descarga el ejemplo ejecutable de revisión de aprobación y los estados completos esperados y observados. Guarda el archivo Python y ejecuta:
python3 approval-review-model.pyEl script utiliza la biblioteca estándar y comparación decimal para la regla porcentual ficticia. No importa Odoo ni accede a la red. Los estados esperados se definen desde el contrato, independientemente de ambas funciones. La salida incluye errores y campos finales; lanzar una excepción no puede hacer pasar por aceptable una escritura parcial.
El modelo no prueba solicitudes nativas simultáneas. El método real puede necesitar más protección si dos actores aprueban la misma revisión a la vez. El artículo de recuperación con n8n trata la creación externa de pedidos. El efecto de auditoría repetido aquí no acredita idempotencia de un conector.
¿Qué debe verificarse en el módulo Odoo real?
Verifica entradas y registros afectados en la versión real antes de trasladar las conclusiones del modelo. Inspecciona sustituciones y dependencias, y ejecuta los casos aprobados mediante los métodos receptores. Confirma qué identidad hace cada cambio. Una función aislada puede cumplir su contrato y seguir integrada incorrectamente en la aplicación.
| Área | Pregunta | Evidencia necesaria |
|---|---|---|
| Entradas | ¿Botón, API y automatización alcanzan el mismo comportamiento? | Identidad aprobada y estado final por cada ruta relevante. |
| Dependencias | ¿El manifiesto declara los módulos utilizados? | Instalación reproducible desde las dependencias declaradas. |
| Sustituciones | ¿Por qué se reemplaza o amplía cada comportamiento base? | Regresiones que demuestren los flujos estándar necesarios. |
| Empresa y campos | ¿El comando usa registro, empresa y valor previstos? | Evidencia nativa de rol/contexto y campos representativos. |
| Fallo y concurrencia | ¿Qué queda tras interrupción o aprobaciones simultáneas? | Registros y efectos de auditoría con fallos controlados. |
| Datos existentes | ¿Qué ocurre con presupuestos anteriores a esta revisión? | Expectativas de actualización aprobadas y registros observados tras ensayo. |
El paquete de aceptación nativa propuesto contiene estos controles y los casos del contrato. Empieza en NOT_RUN, con aprobación de política pendiente. Sustituye expectativas ilustrativas por reglas autorizadas, registra identidades y revisiones exactas, y adjunta evidencia real antes de aprobar una fila.
Revisa cada sustitución junto al comportamiento estándar. Una sustitución sin explicación obliga a descubrir qué se eliminó. Si solo falta una comprobación de decisión, pregunta si existe una extensión más acotada que reemplazar todo el proceso. Verifica esa elección con los casos estándar afectados.
¿Cómo se comprueban instalación y actualización?
Trata instalación, actualización y comportamiento en ejecución como controles separados. Una instalación limpia puede revelar dependencias ausentes; un ensayo con datos existentes aborda registros y configuración anteriores. Ninguno demuestra que se ejecutaron las pruebas de negocio correctas. Vincula el informe al commit, entorno objetivo y casos seleccionados exactos.
La documentación de pruebas de Odoo exige importar los módulos de prueba y explica cómo activación y selección determinan su ejecución. Pide una salida del ejecutor que identifique los casos previstos. Un comando verde sin esos casos deja su comportamiento sin verificar.
La guía de actualización de bases personalizadas distingue instalación en base vacía, instalación con datos actualizados y ensayo de funcionamiento. Nuestra ejecución Python no aporta ninguno de esos resultados nativos.
Para esta personalización, incluye un presupuesto antiguo sin nuevos campos de aprobación cumplimentados, uno aprobado cuyo contenido cambió y otro pendiente al comenzar la actualización. Decide su destino antes del ensayo. Un valor predeterminado que hace parecer aprobado un registro antiguo es una decisión comercial.
Mantén un plan controlado de recuperación para el ensayo. Revertir solo el código no demuestra que los datos se hayan revertido. La guía de conciliación de migraciones cubre la comparación más amplia entre esperado y observado.
¿Qué debe incluir la entrega de auditoría?
Cada decisión de publicación debe poder rastrearse hasta una regla aprobada y evidencia reproducible. Para cada bloqueo, registra revisión, reproducción y consecuencia comercial; añade corrección y repetición independiente de pruebas. Mantén visibles los controles no ejecutados. Una lista de mejoras de estilo no responde si un presupuesto puede aprobarse sin autoridad.
El registro del ejemplo distingue un incumplimiento local confirmado de una pregunta nativa aún pendiente. Conserva esa separación en la auditoría real. «El modelo rechaza una aprobación antigua» y «el método desplegado de Odoo la rechaza bajo estas identidades» son afirmaciones de evidencia diferentes.
Separa reparación de implementación y aprobación de política. El revisor puede demostrar que la función aplica el 10,00 %; el responsable decide si esa es la delegación prevista. Si cambia la regla, actualiza resultados esperados y repite los casos afectados.
La lista de QA previa al lanzamiento ofrece contexto general. La guía general de auditoría de software creado con IA describe un encargo más amplio. La revisión del módulo debe conservar su alcance acotado y comprobable.
¿Cuándo publicaríamos, repararíamos o retiraríamos la personalización?
Publica solo el alcance respaldado por evidencia nativa aprobada. Repara incumplimientos demostrados y vuelve a probar los flujos afectados. Considera retirar una personalización innecesaria si una alternativa mantenida y aprobada cumple el requisito, con un plan para sus datos. Una demostración pulida no debe decidir ninguna de estas opciones.
Empezaríamos por un comando relevante, su entrada real y un caso permitido y otro denegado. Añadiríamos fallos capaces de dejar registros incorrectos. Así la auditoría obtiene una primera decisión concreta antes de ampliarse a todos los archivos del repositorio.
Para el servicio de calidad de software de Wavect, prepara commit, detalles de versión y una regla que el responsable pueda aprobar. El resultado útil es un hallazgo reproducible y un control nativo de publicación claro, seguido de evidencia de que la corrección acordada funciona.