Un desarrollo de Odoo nunca es una operación puramente técnica cuando afecta a la facturación, el IVA, los salarios o la contabilidad. Compromete a la empresa a largo plazo, con obligaciones legales suizas que no se negocian con un pliego de condiciones. En el mercado de Suiza francófona, esta realidad enfrenta a menudo a dos perfiles: los integradores que dominan el código de Odoo sin conocer el plan contable suizo, la factura QR o las normas Swissdec; y las fiduciarias que dominan la contabilidad pero no desarrollan nada por sí mismas, remitiendo cada solicitud de personalización a un tercero. AX-Fiduciaire, partner oficial de Odoo, reúne las dos competencias en el mismo equipo: el desarrollo (módulos, campos, workflows, informes, conectores) y la experiencia fiduciaria (contabilidad, IVA, salarios, cumplimiento suizo). Esta página presenta nuestro desarrollo Odoo a medida: qué cubre, el método seguido, y los límites que nosotros mismos establecemos.
Cuándo se justifica un desarrollo a medida
Odoo estándar cubre una parte amplia de las necesidades de gestión de una pyme: contabilidad, facturación, compras, existencias, ventas, recursos humanos. Una parte de estas necesidades se resuelve sin escribir una línea de código, mediante la configuración o mediante Odoo Studio. Un desarrollo a medida solo se justifica cuando estas opciones están agotadas: un proceso de negocio realmente específico de la empresa, una regla de gestión que el estándar no prevé, un conector hacia un sistema externo que no existe bajo ninguna forma de módulo, o un documento cuya estructura no corresponde a ningún modelo suministrado.
A la inversa, un desarrollo no se justifica cuando:
- la necesidad ya está cubierta por la configuración estándar (campos adicionales, reglas de facturación, secuencias, derechos de acceso);
- Odoo Studio permite añadir el campo, la vista o la automatización sin tocar el código fuente;
- un módulo OCA (Odoo Community Association) existente responde a la necesidad, con la ventaja de estar mantenido por una comunidad en lugar de por un único proveedor;
- la necesidad real es un cambio de hábito de trabajo, no una limitación del software.
Esta disciplina condiciona la supervivencia del desarrollo en el tiempo. Un módulo añadido para reproducir un hábito en lugar de responder a una restricción real se convierte, en la primera actualización de versión mayor, en un trabajo adicional sin justificación clara. El criterio determinante no es el número de funciones que un desarrollo puede añadir, sino su capacidad de atravesar las futuras versiones de Odoo. Odoo 19 es la versión estable actual; Odoo 20 se presenta el 24 de septiembre de 2026. Todo desarrollo a medida debe pensarse para esa continuidad, no solo para responder a la necesidad del momento.
Esta cuestión se plantea con especial agudeza en cuanto un módulo toca la contabilidad, el IVA o la nómina. Un campo añadido a una factura, una regla de cálculo insertada en un workflow de validación, o una automatización que modifica un asiento contable nunca son desarrollos inocuos: se ejecutan en cada transacción, a menudo sin supervisión humana directa. La pregunta a hacerse antes de cualquier desarrollo no es solo «¿es posible?», sino «¿este desarrollo seguirá siendo correcto dentro de dos años, con un equipo diferente, en una versión de Odoo diferente?». Es esta pregunta, más que la viabilidad técnica, la que distingue un desarrollo pertinente de un desarrollo que se convertirá en un problema.
Qué es posible desarrollar en Odoo
El desarrollo a medida en Odoo abarca varios niveles, del más simple al más estructurante. A menudo se combinan en un mismo proyecto: un conector casi siempre se acompaña de un nuevo modelo de datos para almacenar lo que recibe, un workflow generalmente modifica una vista para seguir siendo legible.
Módulos
Un módulo de Odoo agrupa un conjunto coherente de funcionalidades: modelos de datos, vistas, reglas de negocio, derechos de acceso. Un módulo a medida se instala junto a los módulos estándar sin modificarlos, lo que limita el impacto en las futuras actualizaciones de versión. Es el nivel que priorizamos por defecto, en lugar de intervenir directamente en el código de los módulos suministrados por Odoo.
Campos y modelos
Añadir un campo a un formulario existente, crear un nuevo modelo de datos para seguir una información propia de la empresa (un número de expediente, una categoría interna, un estado específico), y vincular esta información a los modelos existentes — clientes, facturas, pedidos, empleados. A menudo es el punto de partida de un desarrollo más amplio: una vez almacenada la información, debe mostrarse, filtrarse y a veces trasladarse a un documento.
Vistas
Adaptar la visualización de un formulario, una lista o un cuadro de mando para que corresponda al flujo de trabajo real del equipo, sin sobrecargar la interfaz estándar con opciones inútiles para los demás usuarios. Una vista mal pensada, añadida para un único puesto de trabajo, a menudo acaba estorbando a todos los demás.
Workflows y automatizaciones
Automatizar un encadenamiento de etapas — validación, notificación, cambio de estado — según reglas propias de la empresa, dentro de los límites en los que la automatización sigue siendo comprensible y corregible por una persona. Una automatización opaca, que nadie sabe explicar ni corregir, supone un riesgo superior al tiempo ganado.
Informes y documentos
Diseñar documentos impresos o PDF (facturas, nóminas, albaranes, informes de análisis) que respeten una identidad gráfica o una estructura de información particular, generándose siempre a partir de los datos reales de Odoo, nunca de una fuente paralela que pudiera divergir.
Conectores y API
Conectar Odoo con un sistema externo — banco, caja registradora, plataforma de comercio electrónico, herramienta sectorial de terceros — a través de la API de Odoo (XML-RPC, JSON-RPC o REST según los casos) o mediante conectores dedicados a los estándares suizos de pago, ISO 20022 y factura QR. Un conector mal aislado puede hacer fallar toda una sincronización por un error menor del lado del sistema externo; el análisis de impacto, descrito más abajo, sirve precisamente para limitar este riesgo.
Portales
Abrir un acceso limitado y seguro a terceros — clientes, proveedores, empleados — para consultar o depositar documentos, sin darles acceso a la interfaz completa de gestión. Los derechos de acceso del portal deben definirse con el mismo rigor que los de un usuario interno.
El método seguido en cada desarrollo
Un desarrollo de Odoo que afecta a datos de gestión sigue una secuencia de trabajo fija, sea cual sea su tamaño.
| Etapa | Objetivo |
|---|---|
| Cadraje de la necesidad | Comprender el proceso real, distinguir lo que corresponde a la configuración estándar de lo que justifica un desarrollo. |
| Análisis de impacto | Identificar los módulos estándar afectados, los riesgos sobre las futuras actualizaciones de versión, y las alternativas existentes (Studio, módulo OCA). |
| Especificación | Describir con precisión los campos, reglas, vistas y documentos afectados, validados antes de cualquier desarrollo. |
| Desarrollo | Escritura del código en un módulo dedicado, sin modificación de los módulos estándar. |
| Pruebas | Verificación funcional y pruebas de no regresión sobre los procesos existentes. |
| Recepción | Validación por los usuarios de negocio en un entorno de prueba, antes de la puesta en producción. |
| Puesta en producción | Despliegue planificado, con un punto de retorno posible en caso de anomalía. |
| Mantenimiento | Seguimiento del desarrollo en el tiempo, incluido durante las actualizaciones de versión. |
Dos etapas de este método suelen ser descuidadas por los integradores que no conocen la contabilidad suiza: el análisis de impacto, que debe incluir una lectura de las consecuencias contables y fiscales del desarrollo, y la recepción, que debe ser validada por una persona capaz de juzgar si el resultado producido es correcto en el sentido contable, no solo en el sentido funcional.
La restricción suiza: lo que cambia la doble competencia
Un desarrollo que afecta a la contabilidad, el IVA o la nómina nunca es un desarrollo neutro. Debe respetar el plan contable adoptado por la empresa, las posiciones fiscales aplicadas a cada tipo de operación, la estructura de la factura QR, el estándar de pago ISO 20022, y los requisitos Swissdec para la gestión de los salarios. Un campo añadido sin tener en cuenta estas restricciones puede producir un asiento contable erróneo, una posición de IVA incorrecta, o una factura QR no conforme.
Odoo instala automáticamente la localización suiza (módulo l10n_ch) cuando la sociedad se configura en Suiza, lo que sienta una base correcta para el plan contable y las tasas de IVA — 8.1 %, 2.6 % y 3.8 % desde el 1 de enero de 2024. Esta base estándar no exime de verificar, en cada desarrollo, que la personalización se mantiene alineada con ella en lugar de eludirla.
En cuanto a la nómina, Odoo figura en el registro Swissdec en el nivel « swissdec certified basic » (certificado n.º 1203.25, para ELM 5.3, verificado el 22.09.2026). Un desarrollo que afecte al cálculo o la transmisión de los salarios debe respetar este marco de certificación: no es un ámbito en el que se pueda permitir una adaptación que se aparte del estándar certificado. Es precisamente en esta intersección donde cuenta la doble competencia de AX-Fiduciaire: comprender a la vez lo que el código debe hacer y lo que la ley suiza exige de ese resultado. Nuestros desarrollos que afectan a la contabilidad se articulan con nuestra oferta contabilidad Odoo; los que afectan a los salarios, con nuestra oferta nómina y RR. HH. Odoo.
Mantener un desarrollo en el tiempo
Un desarrollo entregado no es un desarrollo terminado. Convive con el resto del sistema y debe seguir siendo compatible con sus evoluciones. Es un punto que los proyectos pilotados únicamente por la puesta en producción inicial descuidan a menudo: el coste de un desarrollo no se mide solo por su entrega, sino por lo que cuesta mantenerlo a lo largo de varias versiones sucesivas.
- Actualizaciones de versión: cada nueva versión mayor de Odoo puede modificar API, modelos o vistas en los que se apoya un módulo a medida. Un módulo bien concebido, sin modificación de los módulos estándar, limita este riesgo sin eliminarlo. Vea nuestra oferta migración Odoo.
- Deuda técnica: cada desarrollo añadido aumenta la superficie a mantener. Un desarrollo no documentado, no probado o redundante con el estándar se convierte en una carga que se acumula.
- Pruebas de no regresión: verificar, en cada actualización, que los desarrollos existentes siguen funcionando como se espera.
- Documentación: dejar constancia de lo que se ha desarrollado, por qué, y según qué reglas de negocio, para que otro desarrollador pueda retomar el trabajo sin adivinar las intenciones originales.
- Reversibilidad: un desarrollo debe poder desactivarse o retirarse sin romper el resto del sistema, si desaparece la necesidad que lo motivó.
Este seguimiento en el tiempo se incluye en nuestra oferta de soporte Odoo, que cubre tanto los módulos estándar como los desarrollos realizados por AX-Fiduciaire.
Retomar un desarrollo existente hecho por otro proveedor
También intervenimos en desarrollos de Odoo realizados por un proveedor anterior, ya sea para corregir una anomalía, preparar una actualización de versión, o retomar el mantenimiento de un sistema cuyo proveedor de origen ya no está disponible. Esta retoma siempre empieza con un análisis del código existente: qué hace realmente, cómo se construyó, si modifica módulos estándar o si vive en módulos separados, y qué riesgos presenta para las futuras actualizaciones de versión.
Este análisis puede mostrar que un desarrollo existente es sólido y merece conservarse tal cual, que debe documentarse antes de cualquier intervención adicional, o que debe revisarse parcialmente porque modifica directamente módulos estándar o elude una regla contable. En todos los casos, la retoma se hace sobre la base de lo que existe, no de una reescritura sistemática.
Este tipo de intervención es frecuente después de una actualización de versión que revela desarrollos que se han vuelto incompatibles, o cuando un desarrollo que afecta a la contabilidad o la nómina fue realizado por un proveedor sin experiencia fiduciaria y debe verificarse en el fondo, no solo en la forma del código.
Lo que AX-Fiduciaire no hará
Estos límites se establecen desde el cadraje de la necesidad, no se descubren en pleno proyecto.
- Desarrollar lo que el estándar ya cubre. Si una configuración, una opción nativa o un módulo OCA existente responde a la necesidad, no proponemos un desarrollo a medida en su lugar.
- Eludir una regla contable, fiscal o de nómina mediante código. Un desarrollo nunca sirve para producir un resultado que se aparte del plan contable, de las posiciones de IVA o de los requisitos Swissdec aplicables.
- Entregar sin pruebas. Un desarrollo que afecta a datos de gestión pasa por pruebas funcionales y pruebas de no regresión antes de su puesta en producción, sin excepción.