Nómina CLT brasileña en Odoo - validada en producción, ahora open source.
El cálculo CLT (INSS, IRRF, FGTS, 13º, vacaciones, rescisión) corrió años en producción en órgano público brasileño. Ahora migrado a Odoo 16 y donado a la OCA, sin licencia por colaborador y sin MDR sobre nómina.
Cuando el leiaute eSocial cambia, el fix entra al GitHub OCA en días. Ustedes no esperan el roadmap cerrado de un vendor.
AGPL-3 · validada por años en producción · 232 pruebas · en curso en la OCA
De dónde viene el código
KMEE construyó el módulo de nómina CLT para ABGF (Agência Brasileira Gestora de Fundos), órgano público federal cliente de KMEE. El sistema corrió en Odoo 8.0 en producción emitiendo holerites mensuales por años: cálculo de INSS progresivo, IRRF, FGTS, salário-família, 13º (1ª y 2ª cuotas), vacaciones con art.130, rescisiones con rubros legales, 22 tipos de afastamento CLT, reembolso vía nómina, sindicatos.
Ahora estamos modernizando ese mismo código para Odoo 16 y donándolo a la OCA. El histórico de kmee-odoo-addons en GitHub incorpora 2.257 commits de esa historia vía git merge --strategy=ours, preservando la trazabilidad. Todo el código fue reescrito para la API de Odoo 16, con 232 pruebas automatizadas y specs BDD en archivos .feature. El destino final es el repositorio OCA/l10n-brazil.
Resultado: cálculo CLT de autoría KMEE, validado por años de producción real en órgano público, ahora en código abierto, sin cobro por colaborador. Toda la comunidad Odoo brasileña gana.
Qué viene adentro
Nómina CLT completa, eSocial transmitiendo, código auditable.
Cálculo CLT validado en producción
INSS progresivo, IRRF progresivo, FGTS, salário-família, DSR, faltas, 13º (1ª y 2ª cuotas), vacaciones CLT art.130, rescisión por rubros configurables. Años de holerite real emitido en ABGF.
Decimal ROUND_HALF_UP documentado
414 líneas de pruebas garantizando redondeo correcto. Corrige el bug clásico de banker's rounding del `round()` de Python. Diferenciación técnica rarísima de ver explicitada.
Specs BDD en archivos .feature
Cálculos auditables en lenguaje natural (Gherkin). Su contador puede leerlos. Cada escenario (admisión, vacaciones, rescisión, 13º) tiene caso de prueba reproducible.
eSocial transmitiendo vía certificado A1
Generación de XML vía librería `esociallib`, firma ICP-Brasil A1 (PFX), transmisión directa al ambiente nacional. Lote <= 50 eventos (regla del gobierno), clasificación automática por grupo.
Recursos del trabajador completos
22 tipos de afastamento CLT, reembolso vía nómina (`hr.expense -> payslip`), substitución CLT art.450, sindicatos (CCT/ACT), tablas oficiales pobladas (CID 14k líneas, proceso FAP 7k líneas).
AGPL-3 - sin licencia por colaborador
Sin cobro por contracheque emitido. Sin MDR sobre nómina. Ustedes corren en su infra, auditan el cálculo, contribuyen de vuelta a la OCA. Senior/TOTVS/ADP/Domínio cobran por colaborador activo.
Cobertura eSocial - leiaute S-1.3
Eventos del eSocial cubiertos por el módulo, con evolución continua en la OCA.
-
S-1000Empleador -
S-1005Establecimientos -
S-1010Rúbrica -
S-1020Lotación Tributaria -
S-1070Tabla de procesos -
S-1200Remuneración RGPS (mensual) -
S-1210Pagos -
S-1299Cierre de competencia -
S-2200Admisión / Registro inicial -
S-2205Alteración de datos de registro
-
S-2206Alteración contractual -
S-2210CAT (Comunicación de Accidente) -
S-2220ASO (Atestado Salud Ocupacional) -
S-2230Afastamento -
S-2240Agentes nocivos -
S-2298Reintegración -
S-2299Desvinculación -
S-2300Trabajador sin vínculo -
S-3000Exclusión de evento -
S-5001/5002/5003/5011Totalizadores
La cobertura para su escenario se presenta en el diagnóstico gratuito.
Comparativo con nóminas propietarias
Senior HCM, TOTVS RM Folha, Domínio/Onvio - 10 criterios técnicos y comerciales.
| Criterio | Senior HCM | TOTVS RM Folha | Domínio/Onvio | Odoo + OCA (KMEE) |
|---|---|---|---|---|
| Modelo de licencia | Por colaborador | Licencia + mantenimiento | Por colaborador | Sin licencia, sin por colaborador |
| Acceso al código | Closed (SDK Senior X) | Closed ADVPL | Closed | AGPL-3 - fork, audit, modifique |
| Vendor lock-in | Alto | Alto | Medio | Cero |
| BDD .feature files | No | No | No | Sí |
| ROUND_HALF_UP testeado | No documentado | No documentado | No documentado | 414 líneas pruebas |
| Eventos eSocial cubiertos | Completo | Completo | Completo | Cubiertos por el módulo, evolución continua en la OCA |
| Portal del empleado | Kit listo | Kit listo | Kit listo | Vía portal Odoo, alcance definido en el proyecto |
| Integración nativa NF-e/SPED | Vía ETL | Nativa | Vía export | Misma base Odoo |
| Velocidad adaptación leiaute | Roadmap interno | Roadmap interno | Roadmap interno | Commit GitHub en días |
| Validación en producción real | Cientos de clientes | Miles de clientes | Miles de oficinas | ABGF (años en Odoo 8.0) |
No atacamos competidores. Presentamos la alternativa open source que faltaba en el mercado brasileño de nómina.
Preguntas frecuentes
Las dudas que más recibimos sobre nómina + eSocial en Odoo.
¿La nómina de Odoo+KMEE está en producción?
Sí. KMEE construyó el módulo de nómina CLT para ABGF (Agência Brasileira Gestora de Fundos), cliente de KMEE - el sistema corre en producción sobre Odoo 8.0 desde hace años emitiendo holerites mensuales. Ese mismo código de autoría KMEE es el módulo donado a la OCA, migrado a Odoo 16.
¿Qué eventos eSocial cubre el módulo?
Tablas (S-1000, S-1005, S-1010, S-1020, S-1070), eventos del trabajador (S-2200, S-2205, S-2206, S-2210, S-2220, S-2230, S-2240, S-2298, S-2299, S-2300), periódicos (S-1200, S-1210, S-1299) y estructurales/totalizadores (S-3000, S-5001/5002/5003/5011), con evolución continua en la OCA. La cobertura para su escenario se presenta en el diagnóstico.
¿Cubre Reinf?
No directamente en este stack. Reinf vive en otro stack OCA (`l10n_br_reinf`) en paralelo, complementario. Para empresas que necesitan R-2010, R-2030, R-2040 (Reinf-persona-jurídica), trabajamos la integración separada.
¿Cubre DCTFWeb?
La cobertura de DCTFWeb depende del cierre periódico (S-1299), de los totalizadores (S-5001/5002/5003/5011) y de la integración con Reinf; el alcance para su escenario se presenta en el diagnóstico.
¿Es AGPL-3 en serio?
Sí. El código está en github.com/kmee/kmee-odoo-addons (incubadora) y en github.com/OCA/l10n-brazil (destino final). Pueden correrlo, modificarlo, contribuir. Sin cobro por colaborador, sin MDR sobre nómina.
¿Quién lo usa hoy?
ABGF (órgano público federal) lo usa en producción sobre Odoo 8.0 desde hace años. Nuevos clientes empiezan a adoptarlo a medida que la versión 16.0 estabiliza. Si su empresa tiene una prioridad específica, KMEE puede priorizarla con alcance pago.
¿En qué versión de Odoo funciona?
La versión modernizada del PR actual es Odoo 16 + OCA l10n-brazil 16.0. ABGF corre Odoo 8.0 en producción. Las versiones 17 y 18 de la OCA aún no recibieron el stack completo de account/sale/purchase brasileños, así que la nómina en 17/18 queda para después.
¿Cómo firma los XMLs eSocial?
ICP-Brasil A1 (PFX), reusando el módulo `l10n_br_fiscal_certificate` de la OCA. El mismo certificado A1 que firma NF-e/CT-e/MDF-e firma los eventos eSocial. Vault externo opcional (HashiCorp, AWS, Azure, GCP).
¿Cómo transmite los eventos?
Directo al ambiente nacional del eSocial (homologación `tp_amb=2` o producción `tp_amb=1`). La librería `esociallib` hace parsing, validación XSD y SOAP. Lote <= 50 eventos (regla del gobierno), clasificación automática por grupo (1=tablas, 2=no-periódicos, 3=periódicos).
¿Y si la transmisión falla?
El modelo `l10n_br.esocial.ocorrencia` registra errores por evento. La máquina de estados permite reenvío: `draft -> validated -> pending -> sent -> success | error | rectified`. En caso de retorno de error del gobierno, el evento vuelve para corrección sin bloquear el lote entero.
¿Tiene portal del empleado?
Vía portal Odoo, con alcance definido en el proyecto. Si su empresa necesita portal/holerite digital con QR Code, conversamos sobre el desarrollo en el diagnóstico.
¿Tiene control de asistencia integrado?
Solo `hr.attendance` core de Odoo. Integraciones con reloj de asistencia físico o app tienen alcance definido en el proyecto.
¿Quién revisó los cálculos?
Años de uso real en ABGF + 232 pruebas automatizadas + specs BDD en `.feature` + revisión de la comunidad OCA cuando el PR mergeé. Es cálculo que pagó contracheque real por años.
¿Cuánto cuesta?
Sin licencia por colaborador. Ustedes pagan implementación (alcance definido tras diagnóstico de adopción) y soporte mensual continuo. Si un evento tiene prioridad específica para su operación, podemos priorizarlo con alcance pago - ese trabajo beneficia a toda la comunidad OCA.
¿Puedo patrocinar la evolución de un evento o feature?
Sí. El sponsorship es camino común en proyectos OCA. Si su empresa tiene una prioridad específica, conversamos sobre alcance, plazo y la contribución que vuelve a la comunidad. El código vuelve a la OCA - todo el ecosistema brasileño gana.
Diagnóstico de adopción gratuito
En 30 minutos mapeamos su escenario (volumen, eventos eSocial necesarios, ERP actual, equipo de RH) y salimos con un plan realista de adopción o recomendación de mantener el sistema actual.
Cuéntenos sobre su nómina
Cuántos colaboradores, sistema actual de nómina, eventos eSocial críticos, plazo. Respondemos en hasta 1 día hábil.
Sin spam, sin venta de listas. LGPD-compliant. Política de Privacidad.