Qué resuelve
Un negocio de producción y venta de hielo con paneles solares, un crédito que pagar y clientes a los que se les revende energía. El problema real no es registrar ventas: es que al final del día la plata del cajón cuadre con lo que el negocio dice tener, y que la cuota del crédito exista cuando llegue el vencimiento.
Reparto automático
Cada ingreso se divide entre bolsillos por reglas ordenadas, antes de que nadie pueda gastarlo.
Crédito con amortización
Tabla completa, abonos parciales, y una regla que aparta la cuota sin volver a apartarla entera cada día.
Arqueo contra la realidad
El efectivo esperado se calcula descontando lo fiado ya repartido pero todavía no cobrado.
Sub-medición
Liquidación de medidores de cliente replicando la tarifa del operador, subsidio incluido.
El motor de reparto
Un ingreso no entra a una bolsa común: se reparte entre fondos —bolsillos con nombre— según reglas ordenadas por prioridad. La utilidad no es lo primero que se toma, sino lo último que queda.
El dinero no se pierde en silencio
El reparto devuelve, además del monto por fondo, un valor sinAsignar: lo que quedó sin dueño porque no hay ningún fondo «resto» activo. Debe ser cero, y si no lo es quien llama tiene que avisar.
Antes ese sobrante simplemente desaparecía dentro de la función. Un motor de reparto que descarta plata sin decirlo es peor que uno que falla, porque el error se descubre semanas después cuando el arqueo no cuadra y ya no se sabe de qué día viene.
Una función pura, un solo resultado posible
El motor no toca base de datos ni interfaz: recibe el ingreso y las reglas, devuelve el reparto. Eso permite que el cierre real y la vista previa del cierre usen exactamente el mismo código. Si fueran dos caminos distintos, la pantalla podría prometer un reparto y el cierre ejecutar otro — y el usuario solo lo notaría después de confirmar.
Bolsillos que son efectivo y bolsillos que no
Cada fondo lleva una marca de si su saldo es efectivo en el cajón. Los que se guardan en el banco se desmarcan, y así dejan de contar para el arqueo físico sin dejar de existir en la contabilidad. Es la diferencia entre «cuánto tengo» y «cuánto debería poder tocar ahora mismo».
Crédito y amortización
El crédito se guarda con su monto, su tasa mensual y su número de cuotas, y de ahí sale la tabla de amortización completa: por cada cuota, el capital, el interés y el saldo que queda.
Abonos parciales
Cada cuota guarda cuánto se le ha abonado. Mientras el abonado sea menor que la cuota, el estado es parcial; cuando la alcanza, pasa a pagada. Un negocio que factura a diario no siempre puede pagar una cuota completa de una vez, y forzar el modelo a «pagada o pendiente» obligaría a mentir en uno de los dos sentidos.
El fondo del crédito tiene una regla de monto fijo: la cuota. Pero si cada cierre apartara la cuota entera, en cinco días habría cinco cuotas apartadas y el resto del negocio se quedaría sin operación.
Por eso la regla se ajusta antes de repartir: su aporte se limita a lo que le falta para llegar al objetivo — el objetivo menos lo ya apartado. El primer cierre del período aporta casi toda la cuota, los siguientes solo completan, y cuando el fondo llega al objetivo deja de recibir. El ajuste se aplica igual en el cierre real y en la vista previa, por la misma razón que el motor de reparto es puro.
El arqueo de caja
Contar el cajón y compararlo con lo que el sistema dice es la prueba de fuego. La sutileza está en calcular bien lo que el sistema dice.
Cuando el fiado se cobra, no se mueve ningún fondo: el reparto ya ocurrió, y lo único que cambia es que el efectivo por fin llega. Por eso el arqueo se hace después de cerrar caja — en ese momento el fiado pendiente ya está repartido y las ventas de contado también.
Hay un segundo desfase, de signo contrario: una venta de contado que aún no ha pasado por el cierre tiene su efectivo en el cajón pero no en los fondos. El cálculo la contempla; si no, el arqueo saldría sobrado justo por el dinero que sí está.
De qué bolsillo sale cada gasto
Un gasto no se descuenta de un total: sale de un bolsillo concreto. La regla es que sale del fondo homónimo de su categoría si existe, y del bolsillo general de operación si no.
| Situación | Bolsillo que se debita |
|---|---|
| Existe un fondo con el nombre de la categoría | Ese fondo |
| Categoría sin fondo propio, o desconocida | Operación |
| La categoría apunta a un bolsillo automático | Operación — el automático nunca se debita |
| No existe siquiera el fondo de operación | No se debita, en vez de inventar un destino |
Por qué hay un mapa explícito y no una conversión
Las categorías se guardan en minúscula y sin tilde; los fondos, con mayúscula y tilde. Capitalizar la categoría a ciegas fallaría en cuanto la palabra lleve acento, y fallaría en silencio: el gasto caería en el bolsillo de operación sin que nadie note que debía ir a otro. El mapa explícito convierte un error silencioso en una entrada que se puede leer y corregir.
Algunos fondos tienen un significado propio — la reserva de la cuota del crédito, el ingreso de energía — y nunca se debitan por un gasto. Su saldo responde a otra pregunta, y dejar que un gasto los toque haría que dejaran de responderla.
El débito queda atado a su gasto en la base de datos, con borrado en cascada: editar o eliminar el gasto revierte su movimiento automáticamente, en vez de dejar un descuento huérfano que nadie sabe de dónde salió.
Sub-medición de energía
El negocio tiene medidores propios instalados a clientes, y les cobra la energía. Cobrar «consumo × tarifa» sería sencillo y estaría mal: el recibo del operador de red trae subsidio, alumbrado público y aseo, y cada uno se comporta distinto.
El subsidio es del recibo, no del medidor
El tope de consumo de subsistencia se aplica al recibo completo, no a cada medidor por separado. Si tres medidores comparten un recibo, hay un solo subsidio y hay que repartirlo.
El cálculo obtiene el subsidio del recibo entero y lo asigna a cada medidor en proporción a su consumo. Si el medidor es el único del recibo, el consumo total es el suyo y el subsidio le queda completo. Tratar cada medidor como si tuviera su propio tope de subsistencia multiplicaría el subsidio por el número de medidores, y el negocio cobraría de menos sin enterarse.
El tope de subsistencia no es universal: depende del piso térmico del municipio, por eso es un parámetro y no una constante.
Guardas contra el error humano
| Riesgo | Qué hace el cálculo |
|---|---|
| Lectura anterior mayor que la actual | El consumo nunca baja de cero |
| Porcentaje fuera de rango, o no numérico | Se acota entre 0 y 100, y un valor inválido cuenta como cero |
| Subsidio mayor que el consumo | El total nunca baja de cero: no se genera un cobro negativo |
| Cambio posterior de tarifa o de factor | La liquidación copia el factor del medidor: queda congelada con lo que se usó |
Producción, inventario y ventas
La producción consume insumos según una receta, y esa es la vía por la que el inventario baja solo.
El resto de la operación
| Módulo | Qué cubre |
|---|---|
| Ventas y clientes | Venta con ítems, contado o fiado, y el cobro posterior del fiado |
| Inversión y crédito | Aportes iniciales, crédito, tabla de amortización y pagos |
| Energía | Generación diaria de los paneles —manual o por integración— y recibos de servicios |
| Personal | Empleados, asistencia y pagos de nómina |
| Activos | Equipos del negocio y su mantenimiento |
| Compras y gastos | Con lectura asistida del documento y débito al bolsillo que corresponde |
| Reportes | Resumen del negocio, alertas y respaldo de la información |
El dinero como número entero
Todo el dinero del sistema son centavos en enteros. Nunca coma flotante.
En coma flotante, sumar cantidades de dinero acumula error: valores que deberían dar exacto dan una fracción de menos, y el arqueo no cuadra por unos pesos que nadie puede rastrear. Con enteros el problema no existe, porque no hay nada que redondear después.
El redondeo ocurre una sola vez, al convertir lo que el usuario escribe en pesos a centavos, y de ahí en adelante todas las operaciones son exactas. La conversión de vuelta es solo para mostrar.
Los importes se presentan con formato local, y la entrada acepta separadores de miles: quien escribe 1.500.000 ve el separador mientras teclea, y el sistema guarda el entero. La interfaz se adapta a cómo se escriben las cifras, no al revés.
Arquitectura y ejecución
Aplicación web instalable, con la lógica de negocio separada de la interfaz.
lib/finance como funciones puras, sin base de datos ni interfaz. Es lo que permite probarlo sin levantar nada y lo que garantiza que la vista previa y la ejecución no puedan divergir.Pruebas
120 pruebas en 17 suites, concentradas donde importa: reparto entre fondos, amortización, abonos, cuotas, gastos, liquidación de energía, inventario, fechas y cifrado. Corren en cada cambio como puerta de calidad antes de desplegar.
| Capa | Tecnología |
|---|---|
| Interfaz | Next.js · React · Tailwind |
| Datos | PostgreSQL · Prisma |
| Ejecución | Despliegue continuo, con lint, tipos y pruebas antes de publicar |
| Cliente | Aplicación instalable, con notificaciones y modo sin conexión |