Chronos Ledger

Para una aplicación de planificación, hoy lo evidente es incorporar un modelo de lenguaje: una pregunta en palabras, una respuesta en palabras. Chronos Ledger no tiene ninguno, a propósito. Una previsión de liquidez se convierte en la base de decisiones sobre salarios, compras y reservas fiscales. Para eso, los mismos datos deben dar la misma cifra en cada ejecución, y cada cifra debe poder remontarse a los apuntes de los que salió. Se barajó un panel de preguntas y no se construyó; habría sido la primera llamada de API hacia fuera de esta aplicación.

La segunda decisión sostiene toda la aplicación. En cada petición, el horizonte de planificación se construye una sola vez como lista plana de filas con fecha: movimientos contabilizados, órdenes permanentes desplegadas, nóminas, los pagos derivados de IVA y de impuestos sobre beneficios, inversiones aprobadas y devoluciones esperadas del impuesto sobre la renta. Cada gráfico y cada tabla se calcula a partir de esa única lista. Dos vistas no deben discrepar nunca sobre el mismo día. Cuando la cabecera y la curva lo hicieron una vez, porque dos funciones recorrían por separado las mismas filas, el script de auditoría encontró la diferencia.

La tercera afecta a los impuestos. Qué es un apunte, qué ve de él la declaración de IVA y qué ve de él el cálculo del beneficio son tres columnas separadas. Un único tipo por apunte no puede expresar una transferencia entre cuentas propias, que mueve dinero en dos cuentas y no es ingreso en ninguna. Las categorías rellenan de antemano los tres valores, pero cada apunte conserva su propia copia.

Lo que a propósito no sale de aquí es una declaración de impuestos. La aplicación proyecta y prepara; no transmite nada a ELSTER, y cada vista fiscal lleva la advertencia de que se trata de una estimación.

Una previsión que no se puede recalcular es una opinión con decimales.

Una autoprueba asegura la aritmética: importes, plazos con sus traslados, IVA, impuestos sobre beneficios, los tramos de la tarifa del impuesto sobre la renta, series, filas de ajuste y la banda de incertidumbre. Quien cambia un tipo o una constante de la tarifa cambia en el mismo paso la comprobación correspondiente. Un cambio silencioso de constante es exactamente el fallo que esta aplicación no puede absorber.

Un script de auditoría recalcula por segunda vez los totales centrales directamente a partir de las tablas en bruto, con código propio: liquidez de hoy, punto más bajo, final del horizonte, IVA y base del beneficio. También señala apuntes que se contradicen a sí mismos, por ejemplo una salida clasificada como ingreso. Fue revelador de dónde venían las discrepancias: más de una vez el fallo estaba en el script de auditoría, porque todavía no conocía una regla que el motor ya tenía. Desde entonces, cada regla nueva lleva la pregunta de si el script de auditoría la conoce.

Y la aplicación registra sus propias previsiones: una vez al día, solo finales de mes, nunca sobrescritas. Más tarde se evalúan frente a lo que las cuentas tenían de verdad según los movimientos contabilizados, nunca frente a una previsión más reciente. El error se promedia en valor absoluto, para que una cifra demasiado alta y otra demasiado baja no se anulen entre sí.