Skip to content

CASOS DE USO

Software empresarial sobre una base financiera

Aurora no es un ERP. Es la plataforma sobre la que se construyen ERPs, CRM, nómina, inventario, ventas y analítica. Todo módulo orbita el libro mayor, postea por las costuras del SDK y evoluciona sin romper dependencias. Aquí se distingue lo que ya corre hoy de lo que es construible.

sistemas sobre el GL orbitando
Quorum · control de finanzas en producción
Ventas · facturación en producción
Inventario · costeo en producción
CRM · front-office en producción
Diferidos · periodificación en producción
nómina · analítica construible
todo módulo orbita el libro mayor, ninguno escribe directo

El kernel de Aurora es el GL (libro mayor). Esa decisión —la regla de gravedad: todo módulo orbita el GL y ninguno escribe en journal_lines directo— define qué clase de software se construye bien sobre la plataforma. No es un app-builder horizontal para cualquier formulario; es una plataforma vertical para sistemas empresariales donde la consistencia operacional y la integridad financiera no son opcionales. Un módulo nace de un manifiesto declarativo procesado por Aurora Make, depende de los contratos del Platform SDK en lugar de las implementaciones del kernel, y reusa la infraestructura compartida de Aurora Runtime: multiempresa con aislamiento por esquema, panel, scope por empresa, numeración y entitlements. Los tipos de sistema descritos a continuación comparten esa cimentación; algunos ya corren ya construido sobre Aurora, otros son construibles con las mismas piezas.

ERP y control de finanzas

Quorum

El núcleo: gestión financiera completa sobre el GL kernel. Plan de cuentas, pólizas con doble partida validada en BCMath, periodos fiscales con cierre y reapertura, cierre anual, libros (Diario, Mayor, Balance de Comprobación), estados financieros (Balance General, Estado de Resultados) y multimoneda. Las cuentas se resuelven por determinación —nombre canónico, nunca por código— de modo que el mismo concepto funciona en plantillas de cuentas distintas. Sobre esa base se encienden las áreas financieras: CxC y CxP con manejo de partidas abiertas y aging, bancos con conciliación de extractos, e import fiscal FEL/SAT.

ya construido sobre Aurora (módulo Quorum + financiero)

Ventas y facturación

Ventas

Motor de comprobantes dirigido por tipo: maestros de producto y servicio, listas de precios y comprobantes fiscales que postean al GL por las costuras del SDK. Al postear se encienden solas las consecuencias financieras —CxC, aging y Libro de Ventas— sin que el módulo conozca al módulo del libro mayor. Es el primer módulo front-office cuyo usuario es el operador de la PyME, no el contador. El endurecimiento cambiario, de crédito y de retenciones se resuelve por contratos del SDK, no por reglas quemadas.

ya construido sobre Aurora

Inventario y costeo

Inventario

Valuación perpetua con costeo promedio ponderado: stock y kardex valuado que postea al GL por las costuras del SDK. El COGS al vender se dispara por evento del SDK entre Ventas e Inventario —Ventas solicita consumo de stock, Inventario responde— a través de contratos como ChecksStockAvailability y ResolvesDefaultWarehouse, sin que ninguno de los dos importe al otro ni al kernel financiero. La consistencia entre lo físico y lo financiero es un invariante, no una rutina de conciliación nocturna.

ya construido sobre Aurora

CRM y front-office

CRM

Gestión de relaciones y pipeline comercial: prospectos, oportunidades, etapas y conversión a cliente. Fue el primer módulo nacido del generador aurora:make-module y vive como paquete Aurora con frontera limpia. Cuando una operación comercial debe tener efecto financiero, lo hace por las mismas costuras de posteo del SDK. El módulo company-scoped reusa multiempresa, numeración y entitlements del Runtime sin reimplementarlos.

ya construido sobre Aurora

Periodificación, nómina y módulos de cálculo

Deferrals

Diferidos es el motor de periodificación —diferidos y provisiones auto-reversibles— y fue el primer paquete que postea al GL directamente por los contratos CreatesJournalEntries / PostsJournalEntries: el satélite arma el asiento y el kernel lo ejecuta. Ese mismo patrón es la plantilla para cualquier módulo de cálculo recurrente con efecto financiero, como nómina: devengos, retenciones y provisiones que se vuelven asientos por las costuras del SDK, con las reglas del país inyectadas por strategy en lugar de quemadas en el código.

Diferidos ya construido sobre Aurora · nómina construible con el mismo patrón

Capacitación y analítica

Academy

Academia ya corre como paquete Aurora; ilustra la segunda forma válida de integrarse: emite eventos de dominio y un módulo-kernel postea, sin posteo propio. Toda actividad de los módulos termina en el GL como hechos financieros sobre un esquema único por tenant, lo que vuelve a la analítica un consumidor natural: reportes y tableros que leen un libro mayor consistente en vez de reconciliar fuentes dispersas. Reportería sobre saldos materializados y exportadores son construibles con los mismos cimientos.

Academia ya construido sobre Aurora · analítica construible sobre el GL

Por qué Aurora

Por qué Aurora es la base adecuada

  • Integridad financiera por construcción: todo módulo orbita el GL y ninguno escribe en journal_lines directo. El dinero es BCMath sobre columnas numeric(15,2), nunca float, y las cuentas se resuelven por determinación canónica, no por código. El asiento siempre lo ejecuta el kernel.
  • Consistencia operacional: los módulos no se acoplan entre sí. Ventas solicita consumo de stock por evento y Inventario responde; ninguno importa al otro ni al módulo del libro mayor. Las consecuencias —CxC, COGS, Libro de Ventas— se encienden solas por las costuras del SDK.
  • Evolución sostenible: los módulos dependen de contratos estables del Platform SDK, no de implementaciones del kernel. PlatformContractsFreezeTest congela la superficie del SDK; un cambio de firma falla ruidoso en CI en vez de romper N módulos en silencio.
  • Gobernanza verificada: la arquitectura se gobierna con ADRs e invariantes transversales validados en cada build por fitness functions —un paquete nunca importa App\Modules, el wiring real coincide con el manifiesto, el núcleo financiero no depende de ningún otro.
  • Infraestructura compartida que no se reescribe: multiempresa con aislamiento por esquema por tenant, CompanyContext como fuente de verdad fuera de HTTP, panel, scope por empresa, numeración y entitlements vienen del Runtime. Un módulo nuevo nace cableado.
  • Costo marginal interno bajo: un módulo nace de un manifiesto module.yaml procesado por un generador determinístico que emite un paquete Aurora ya cableado. El manifiesto es scaffold y contrato; la lógica de dominio se escribe a mano sobre el esqueleto verde.

Evalúa qué sistema construir sobre Aurora

Si necesitas un sistema empresarial con consistencia operacional, integridad financiera y capacidad de evolucionar sin acumular deuda, conversemos sobre cómo se modela sobre Aurora —lo que ya corre hoy y lo que es construible.