cifraHQ Enterprise
Multi-entidad

Para el grupo que tiene tres empresas y un solo CFO.

Jerarquía de partes con <code>ParentPartyId</code>, settings en cascada desde la organización padre, cross-subscription vía servidor de licencias e intercompany con mirroring automático. Para firmas contables, franquicias y holdings reales.

Solicitar demo Ver cluster Operaciones
La jerarquía

Party hierarchy con tipo de relación

El modelo base es ParentPartyId con un enum RelationshipType explícito. Los hijos son financieramente independientes en v1 — cada uno tiene su propio tenant y su propio libro mayor. La jerarquía documenta la relación; no mezcla la contabilidad.

  • Subsidiary. Empresa filial con estados financieros propios. Reporta al padre para consolidación, pero opera con libro, cuenta bancaria y reportes fiscales separados.
  • Branch. Sucursal del mismo ente legal. El tipo existe para grupos que operan con sucursales contables separadas (común en LATAM).
  • Franchise. Franquiciado con contrato con el padre. Usualmente paga royalty — la relación está documentada aun cuando la operación es independiente.
  • Department. División interna de una misma empresa que se administra con un tenant distinto por escala. Menos común; existe para operaciones con volumen que justifica aislamiento técnico.
  • Other. El catch-all para relaciones atípicas — joint ventures, alianzas, estructuras que no caen en las cuatro anteriores.

El esquema es forward-compatible con consolidación AR/AP multi-nivel y estados consolidados — funcionalidad diferida a v1.5/v2. La estructura existe hoy; la agregación financiera viene después.

Settings en cascada

Un solo lugar para configurar el grupo

  • Organización como nodo de settings. Una organización agrupa tenants. Los settings configurados en la organización propagan por default a los tenants hijos — plantillas de documento, políticas de aprobación, templates de COA, configuraciones de reporte.
  • Override por tenant. Cualquier setting puede sobrescribirse en el tenant hijo. La cascada es default, no obligatoria. Los auditores ven qué se heredó y qué se modificó localmente.
  • Branding white-label heredable. Logo, CSS variables y dominio custom (erp.acmecorp.com) se configuran en la organización y heredan — o se overrridean por subsidiaria cuando la marca difiere.
  • Plantilla de documento versionada. Si la organización cambia su layout de factura, los tenants heredan la nueva versión. Los que sobrescribieron localmente mantienen su versión — sin regresiones silenciosas.
Cross-subscription

El servidor de licencias amarra el grupo

  • Una suscripción, varios tenants. El servidor de licencias (P4S_Licenses) permite que una sola suscripción Stripe cubra múltiples tenants. Facturación agregada al grupo, no per-tenant.
  • Entitlements por edición. Feature flags y límites de usuarios concurrentes viajan desde la licencia al tenant en login time. El admin de la organización ve uso agregado y límites disponibles.
  • Identidad cross-tenant (v1.5). Un usuario con acceso a tres tenants del grupo — un solo login, picker de tenant al entrar. Resuelto en la capa de licencias en v1.5; en v1 requiere una cuenta por tenant.
  • Weighted feature voting. Suscripciones Enterprise tienen 3× el peso en el feature request board — el grupo multi-entidad acumula voz proporcional al tamaño del negocio.
Intercompany

Transacciones entre tenants del mismo grupo

Cuando la subsidiaria A vende a la subsidiaria B, el manual del contador dice "registrar en ambos libros". En la práctica, el 60% de las disputas mensuales vienen de que uno registró y el otro no.

  • IntercompanyPartner por tenant. Cada tenant declara cuáles de los otros tenants del grupo son partners oficiales. Mapeo explícito — no se postea intercompany con cualquier tenant, solo con los autorizados.
  • Mirroring automático. Al postear un documento intercompany en el tenant A, el sistema genera automáticamente un documento Draft en el tenant partner B. El contador de B revisa, ajusta si necesita, y postea.
  • Draft preserva autonomía. El mirror no se postea automáticamente — B sigue siendo dueño de su libro. Pero ya no hay "¿lo registró o no lo registró?" — el draft está ahí esperando.
  • Reconciliación intercompany. Reporte IntercompanyReconciliation compara los balances intercompany entre tenants del grupo. Discrepancias salen en rojo; parte del checklist de cierre mensual.
  • Eliminación consolidada (v1.5). Los asientos de eliminación para estados consolidados están diferidos a v1.5. En v1 el grupo genera la vista; la eliminación formal se hace fuera del sistema o en el próximo release.
Qué esperar en v1 y qué llega en v1.5

Claridad sobre el roadmap

v1 (hoy)

Jerarquía + cascada + intercompany manual

ParentPartyId con relaciones tipificadas, settings en cascada, white-label heredable, intercompany con mirror draft automático, reporte de reconciliación.

v1.5

Identidad cross-tenant + eliminación

Un login para varios tenants del grupo y asientos de eliminación consolidados. Diseño empieza cuando los módulos core cierran.

v1.5/v2

AR/AP consolidado

Consolidación multi-nivel de AR y AP. El esquema ya es forward-compatible; la agregación financiera ship después.

Demo multi-entidad con su estructura real

Traiga su organigrama legal; le mostramos cómo se modela en jerarquía, settings y intercompany en una sesión.

Agendar demo