Saltar al contenido principal

0003 — Facturación electrónica como módulo propio

Estado: aceptada · Fecha: 2026-09-14

Contexto​

La primera versión de la facturación electrónica se sembró como un menú más de la vertical médica (health.invoices, en /dashboard/health/invoices), abierto con health.records.manage. Tres problemas salieron de ahí:

  • Acoplamiento falso. Facturar lo hace cualquier negocio. Para emitir una factura había que activar Salud, y Salud arrastra Agendamiento.
  • Permisos prestados. "Gestionar historias clínicas" no dice nada sobre quién puede firmar facturas en nombre de la clínica. Y en el backend bastaba con pertenecer al tenant: recepción podía subir un certificado .p12.
  • El menú se pintaba con el código crudo, porque la sección de Salud no tenía la clave en navbar.json: síntoma de una pantalla que no seguía el camino de un módulo.

Decisión​

La facturación es el módulo invoicing (el account_edi de Odoo): manifiesto propio, sin dependsOn, sección de menú propia, rutas /dashboard/invoicing/*, API /api/invoicing/* y permisos por operación (invoicing.invoices.read, invoicing.invoices.issue, invoicing.issuers.manage).

Se abre con dos llaves independientes: el tenant activa la aplicación, y el plan contratado incluye el extra (plans.invoicing_ec, fail-closed). Una dice qué quiere usar el cliente; la otra, qué pagó.

El país es un proveedor detrás de la API, no un módulo: hoy FacturacionEcClient (SRI). Si llega otro país, entra como otro cliente del mismo servicio.

Consecuencias​

  • La correlación con paciente, cita o consulta (edi_invoices.patient_id, appointment_id, encounter_id) sigue existiendo, pero es opcional. Si Salud quiere un botón "facturar esta consulta", lo pone Salud llamando a este módulo, no al revés.
  • La migración de salida conserva lo que cada rol ya hacía, salvo registrar emisores, que pasa a ser solo de administradores: era el agujero, no un derecho.