Nómina CLT brasileña en Odoo —
validada en producción, ahora open source.

No. KMEE construyó el módulo de nómina CLT para ABGF (Agência Brasileira Gestora de Fundos), cliente de KMEE — el sistema corrió en producción sobre Odoo 8.0 por años emitiendo holerites mensuales. El PR actual trae ese mismo código de autoría KMEE migrado a Odoo 16 y donado a la OCA. El badge 'Beta' en el manifest refleja el ciclo de migración + revisión OCA, no inmadurez del método.

8 eventos: S-1000 (empleador), S-1010 (rúbrica), S-1020 (lotación tributaria), S-1200 (remuneración mensual), S-2200 (admisión), S-2206 (alteración contractual), S-2230 (afastamento), S-2299 (desvinculación). Los demás (S-1005, S-1070, S-1210, S-1299, S-2205, SST, S-3000, totalizadores) están en migración — el código legado de ABGF existe, es trabajo de port para 16.0.

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.

Hoy no automatiza. Depende del cierre periódico (S-1299) + totalizadores (S-5001/5002/5003/5011) + integración con Reinf. Esos componentes están en la cola de migración.

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.

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 necesita un evento aún en migración, KMEE puede priorizar el port con alcance pago.

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.

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).

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).

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.

Hoy no nativo. Roadmap. Si su empresa necesita portal/holerite digital con QR Code, podemos discutir desarrollo bajo alcance.

Solo `hr.attendance` core de Odoo. Integraciones con reloj de asistencia físico o app vía roadmap.

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.

Sin licencia por colaborador. Ustedes pagan implementación (alcance definido tras diagnóstico de adopción) y soporte mensual continuo. Si un evento aún en migración es crítico para su operación, podemos priorizar el port con alcance pago — ese trabajo beneficia a toda la comunidad OCA.

Sí. El sponsorship es camino común en proyectos OCA. ¿Su empresa necesita S-1299 cerrando competencia mañana? Podemos priorizar con ustedes. El código vuelve a la OCA — todo el ecosistema brasileño gana.