El cierre del mes no es un permiso. Es una máquina de estados auditable.
Lo que el CFO pelea cada mes — cerrar a tiempo, saber quién tocó qué, explicar la varianza cambiaria — cifraHQ lo resuelve en el esquema, no en la política interna.
Los cuatro dolores del cierre corporativo
- El cierre se alarga porque AR y AP no cierran el mismo día. Los sistemas que exigen cerrar todo a la vez obligan a esperar la última factura de proveedor para poder cerrar las ventas. La máquina de estados de cifraHQ soporta locks asimétricos:
LockSalesel día 3,LockPurchasingel día 8,LockSalesAndPurchasingcon ajustes del contador permitidos,Lockedal final. El cierre fluye al ritmo del negocio, no al ritmo del software. - FOREX que nadie sabe explicar al auditor. El pago en USD de una factura en PAB generó una diferencia — ¿qué cuenta? ¿qué tipo de cambio? El módulo multi-moneda preserva la moneda original en cada línea; la revaluación de AR/AP abiertos corre a fin de mes con política configurable (promedio, spot, histórico);
FXGain/FXLossposten a cuentas determinadas sin ajuste manual. - "¿Quién cambió esto?" seis meses después. La pregunta llega en el peor momento — durante una auditoría externa. El dual audit trail combina temporal tables sobre cada entidad mutable con
AuditEventsappend-only para eventos de negocio.DENY UPDATE/DELETEa nivel SQL significa que ni un ingeniero puede reescribir la historia. - Reporting consolidado que siempre pide "un pequeño ajuste". Los estados se preparan en un sistema y se ajustan en otro. cifraHQ es API-first: el mismo
OpenAPI 3.0público que consume la UI sirve al motor de reporting; el exportador de estados toma la foto del período cerrado, no del período en movimiento.
Tres mecanismos específicos
Máquina de estados del periodo
Seis estados con locks asimétricos. <code>LockSales</code>, <code>LockPurchasing</code>, ajustes, <code>Locked</code>, cierre anual guiado. Transiciones logueadas; reversa con razón ≥ 20 caracteres.
Moneda original preservada
Cada línea en su moneda nativa; revaluación con política configurable; <code>FXGain</code>/<code>FXLoss</code> a cuentas determinadas sin ajuste manual.
Dual audit trail
Temporal tables + <code>AuditEvents</code> con <code>DENY UPDATE/DELETE</code>. La evidencia no depende de la aplicación — vive en el motor SQL.
Cómo se ve un close bien hecho
- Día 1–3: AR en sprint, AP todavía abierto. Ventas y notas de crédito se acumulan; el equipo de AP espera las últimas facturas.
LockSalescierra AR sin afectar AP. - Día 3–8: AP se completa. Las compras se posteen, las cuentas de gasto se revisan.
LockPurchasingcierra AP; el periodo entra enLockSalesAndPurchasingpara que solo los ajustes del contador sean posibles. - Día 8–10: revaluación de moneda. El job Hangfire corre la revalorización de AR/AP abiertos al tipo de cambio configurado;
FXGain/FXLossquedan posteados. El contador revisa los asientos antes de transicionar. - Día 10: Locked. El periodo entra en
Locked. El posting está bloqueado a nivel motor — ningún documento conPostingDatedentro del periodo se postea más. - Reversión disponible, pero costosa. Descubrir un error después del lock requiere
PostingPeriod.ReverseClose, razón ≥ 20 caracteres y queda enAuditEvents. La puerta existe, pero es visible.
Habla con ventas para CFO
Simulamos su cierre mensual con sus datos — locks asimétricos, revaluación de FOREX, cierre anual y evidencia de auditoría — en una sesión técnica.