De hojas de cálculo a una aplicación dedicada para una operación de servicios

Qué construimos y por qué conservamos la interfaz

Implementamos una aplicación con base de datos embebida y una instancia independiente por cliente. Al 10 de agosto de 2026, el modelo reúne 18 colecciones para representar la operación, incluidas propiedades, servicios, técnicos y pagos. Los usuarios tienen roles de administración, operación, finanzas y técnico. Conservamos la interfaz existente y añadimos un adaptador que traduce sus operaciones hacia el nuevo sistema. Descartamos reescribir todas las pantallas junto con el almacenamiento: mantener su estructura concentra la transformación en los datos y en la ejecución de las reglas. La modernización tiene un alcance verificable, sin sumar un rediseño completo a la misma entrega. También separamos las reglas del negocio de la tecnología que guarda los registros. El cálculo de pagos trabaja con contratos de acceso a datos; la implementación de almacenamiento vive en otra capa. Esta decisión hace que las reglas se prueben de forma independiente y que cambiar su soporte no obligue a reconstruirlas. El importador recibe archivos exportados de las hojas y relaciona los identificadores anteriores con los nuevos. La importación es idempotente: actualiza el registro correspondiente cuando ya existe y lo crea cuando hace falta. Repetir una carga conserva la identidad de los datos. Elegimos una aplicación compacta con almacenamiento propio, coherente con el alcance de este negocio. La hoja conserva su función de exportación y custodia; deja de ser el lugar donde la aplicación mantiene su estado operativo.

Cómo opera hoy el motor de pagos

El motor resuelve la regla aplicable siguiendo seis niveles de prioridad. Primero evalúa la regla explícita de la orden; después, la predeterminada del técnico. Si ninguna corresponde, revisa la combinación de servicio y propiedad, luego solo el servicio, después solo la propiedad y finalmente la regla global. En cada paso exige una regla activa. Este orden vuelve ejecutables los acuerdos particulares. Una condición específica de una orden prevalece sobre el valor general; una condición del técnico tiene prioridad sobre las reglas por servicio o propiedad. La jerarquía queda en el sistema y se aplica en el mismo orden cada vez que se calcula un pago. El recálculo selecciona las órdenes elegibles dentro del periodo indicado y actualiza sus pagos asociados. Los pagos aprobados o pagados quedan protegidos frente al recálculo automático. Esa frontera conserva la decisión financiera ya tomada mientras el sistema procesa el resto de órdenes. Las validaciones generan excepciones con deduplicación. Si una situación ya tiene una excepción abierta, repetir la validación conserva esa referencia en lugar de multiplicar avisos equivalentes. La atención se concentra en situaciones que requieren revisión. Los permisos se aplican desde el servidor. El perfil técnico recibe información sin el precio cobrado al cliente, y los registros de auditoría quedan en una colección protegida de la edición directa. Los controles acompañan al dato y a la operación, además de la presentación en pantalla.

Resultados: una aplicación ejecutable y comprobada

Al 10 de agosto de 2026, construimos un MVP funcional con 18 colecciones, un motor de pagos de seis niveles y una prueba de extremo a extremo de 18 pasos completada satisfactoriamente. La entrega incluye datos de demostración para recorrer la aplicación y un importador de archivos de la operación. La comprobación combina pruebas de las reglas con ejecución contra la base de datos real del sistema. Los 18 pasos verifican valores esperados, además de respuestas de la aplicación. Una revisión independiente confirmó la ejecución satisfactoria de la suite y del recorrido completo. El resultado técnico reúne responsabilidades antes apoyadas en hojas y scripts: almacenamiento estructurado, cálculo de pagos, validaciones, permisos y auditoría del lado del servidor. Conservamos la lógica original y la interfaz, e incorporamos una ruta de carga repetible. Cada una de estas capacidades tiene una función concreta en el control de la operación.

Qué aprendimos al trasladar las reglas

La parte más valiosa de esta modernización estaba en las decisiones acumuladas del negocio. Hicimos explícitas las prioridades de pago, los estados que bloquean un recálculo y la información visible para cada rol. Después trasladamos esas decisiones a una aplicación con límites claros entre interfaz, reglas y datos. También fijamos la verificación en dos planos: comprobar el cálculo por separado y recorrerlo conectado al almacenamiento. Ambos forman parte de la entrega. Para modernizar tu operación, el diagnóstico empieza por identificar esas reglas y los puntos donde una decisión humana debe conservar autoridad. Agenda un diagnóstico operativo con Khipura.

¿Se reemplazó toda la interfaz? Conservamos la interfaz y añadimos un adaptador hacia el nuevo sistema. El cambio se concentra en almacenamiento, reglas y controles de acceso.

¿Cómo decide el sistema qué regla de pago aplicar? Sigue seis niveles: orden, técnico, servicio y propiedad, servicio, propiedad y regla global. Aplica la primera regla activa que corresponde.

¿Qué ocurre al recalcular un pago aprobado? El recálculo automático respeta los pagos aprobados o pagados. Esos estados protegen la decisión financiera frente a una nueva ejecución del cálculo.

¿Cómo se cargan las hojas existentes? El importador lee archivos tabulares, relaciona identificadores y crea o actualiza registros de forma idempotente. Repetir la carga conserva su identidad.

¿Qué validación recibió la aplicación? Al 10 de agosto de 2026, las pruebas del código y el recorrido de extremo a extremo de 18 pasos finalizaron satisfactoriamente, con revisión independiente.