Cuando una pantalla de liquidaciones no se entiende, probablemente el modelo está mal

Hay una frase que aplica mucho al software de gestión:

Si la UI no se entiende, muchas veces el problema no está en la UI. Está en el modelo.

Cuando una pantalla necesita demasiadas aclaraciones, demasiados estados visuales, demasiados botones y demasiadas excepciones, puede ser una señal de que el sistema todavía no está representando bien el problema real.

Esto aparece con fuerza cuando se diseña una pantalla de liquidaciones para obra.

A primera vista, una liquidación parece una tabla:

• trabajador;
• horas;
• jornal;
• adelantos;
• banco;
• efectivo;
• total a pagar.

Pero en la práctica, una liquidación de obra no es solamente una tabla con montos.

Es el cierre de una quincena.

Y cerrar una quincena implica tomar datos de asistencia, aplicar jornales, descontar adelantos, considerar recibos, separar pagos por banco y efectivo, contemplar redondeos, generar exports y dejar una historia auditable.

Si todo eso se mezcla en una sola vista, la pantalla se vuelve difícil de entender.

Pero el problema no es solo visual.

El problema suele ser conceptual.

Una liquidación no es un cálculo en vivo

Una tentación común en software es pensar que una liquidación puede resolverse con una query o una fórmula que se recalcula cada vez que abrimos la pantalla.

Eso puede funcionar mientras la liquidación está en borrador.

Pero deja de funcionar cuando esa liquidación se confirma o se paga.

¿Por qué?

Porque en una quincena real hay valores que necesitan quedar congelados.

Por ejemplo:

• el jornal usado para calcular;
• las horas tomadas de la asistencia;
• los adelantos descontados;
• el importe declarado o importado desde recibos;
• la política de pago aplicada;
• la parte que fue a banco;
• la parte que fue a efectivo;
• el redondeo aplicado;
• el saldo que queda para la próxima liquidación;
• las advertencias que existían al momento de cerrar.

Si esos valores se recalculan siempre en vivo, cualquier cambio posterior puede modificar el pasado.

Cambia el jornal de un trabajador y parece que cambió una liquidación vieja.

Se actualiza una política de pago y cambia un export anterior.

Se corrige un adelanto y ya no se entiende por qué se pagó lo que se pagó.

Por eso, una liquidación necesita snapshots.

No todo dato histórico debería recalcularse.

Algunas cosas son fuente viva.

Otras son resultado congelado.

Y esa diferencia cambia completamente cómo se diseña la pantalla.

Borrador, confirmada y pagada no son solo etiquetas

Los estados de una liquidación no deberían existir solamente para mostrar un chip de color.

Tienen que representar reglas reales del negocio.

Una liquidación en borrador todavía puede cambiar.

Puede recalcularse.

Puede incorporar asistencias corregidas.

Puede tomar nuevos adelantos.

Puede actualizarse con recibos importados.

Puede marcarse como desactualizada si cambió algo importante.

En cambio, una liquidación confirmada ya debería comportarse distinto.

No necesariamente está pagada, pero ya representa una decisión tomada.

En ese punto, la pantalla debería ayudar más a auditar y operar que a recalcular libremente.

Y una liquidación pagada debería ser todavía más estable.

Ya no es solamente un cálculo.

Es historia.

Es un registro de lo que se pagó, cómo se pagó y con qué información se tomó esa decisión.

Por eso, cuando una UI muestra el mismo conjunto de acciones para todos los estados, algo empieza a hacer ruido.

No es lo mismo editar un borrador que tocar una liquidación ya pagada.

La interfaz debería reflejar esa diferencia.

Pero para que la interfaz pueda hacerlo bien, el modelo también tiene que estar bien separado.

La asistencia es input, la liquidación es resultado

En obra, la asistencia es una de las fuentes principales de la liquidación.

Pero no son lo mismo.

La asistencia responde preguntas como:

• qué trabajador fue;
• qué día trabajó;
• en qué obra;
• cuántas horas;
• si estuvo ausente;
• si fue medio día;
• si hubo alguna observación.

La liquidación responde otras:

• cuánto corresponde pagar;
• qué adelantos se descuentan;
• qué saldo queda;
• cuánto va por banco;
• cuánto va en efectivo;
• qué trabajador necesita revisión;
• qué export se genera para pagar.

Si la pantalla mezcla ambos niveles sin jerarquía, se vuelve pesada.

El usuario necesita ver el resumen para decidir.

Pero también necesita poder entrar al detalle si alguien reclama un día o si hay una diferencia.

Por eso conviene separar:

• resumen de liquidación;
• alertas antes de cerrar;
• detalle por trabajador;
• auditoría de asistencia;
• pagos por obra;
• exports.

No todo tiene que estar visible al mismo tiempo.

Pero todo tiene que estar disponible cuando hace falta.

Adelantos, banco y efectivo: donde aparece la complejidad real

En muchas empresas de construcción, el problema no termina en calcular cuánto cobra cada trabajador.

También hay que resolver cómo se paga.

Un trabajador puede haber recibido adelantos durante la quincena.

Algunos adelantos pueden haber sido por banco.

Otros en efectivo.

Después llega el momento de liquidar y hay que descontarlos correctamente.

Además, puede existir un importe declarado o recibido desde el estudio contable.

Ese importe puede definir cuánto corresponde transferir por banco.

El resto puede ir en efectivo.

Pero si el trabajador no tiene CBU, quizás todo debe ir por efectivo.

Y si se paga en efectivo, muchas veces no se paga al centavo.

Se redondea a una unidad práctica y la diferencia se arrastra como saldo para la próxima liquidación.

Entonces una pantalla que solo muestra:

Total a pagar

se queda corta.

Para operar bien, hace falta distinguir:

• total calculado;
• adelantos descontados;
• banco pendiente;
• efectivo calculado;
• efectivo redondeado;
• diferencia por redondeo;
• saldo que se arrastra;
• política de pago usada.

Pero mostrar todo eso sin orden también puede ser un problema.

La clave es que la pantalla no obligue al usuario a reconstruir mentalmente la fórmula.

Tiene que mostrar el resultado, explicar el origen y permitir auditar el detalle.

Los imports no deberían mezclarse con las reglas de pago

Otra fuente de complejidad aparece cuando se importan datos externos.

Por ejemplo:

• recibos del estudio contable;
• jornales base;
• cuentas bancarias;
• trabajadores;
• adelantos;
• asistencia.

Cada import tiene un propósito distinto.

Importar una cuenta bancaria no es lo mismo que importar un jornal.

Importar un recibo no es lo mismo que definir una política de pago.

Importar trabajadores no debería cambiar silenciosamente cómo se liquida una quincena.

Si todo eso se mezcla en un solo flujo, el sistema se vuelve difícil de explicar y peligroso de usar.

Por eso, en una herramienta como Traziq, el import tiene que ser una capa separada:

• ingesta datos;
• valida filas;
• matchea trabajadores;
• muestra preview;
• advierte conflictos;
• deja auditoría.

Pero no debería esconder decisiones de negocio importantes.

Si un archivo trae un nuevo jornal, hay que decidir desde cuándo aplica.

Si un recibo trae un importe declarado, hay que asociarlo a una liquidación concreta.

Si una cuenta bancaria cambia, hay que confirmar si se actualiza el trabajador.

El sistema puede ayudar.

Pero no debería tomar decisiones silenciosas que afecten pagos.

Los exports tampoco deberían recalcular

Un error común es tratar los exports como una segunda oportunidad para calcular.

Por ejemplo:

• exportar pago bancario;
• exportar efectivo;
• exportar resumen de quincena;
• exportar costo por obra;
• imprimir recibos.

Si cada export vuelve a correr fórmulas, el sistema puede generar inconsistencias.

La liquidación dice una cosa.

El archivo bancario dice otra.

El resumen impreso muestra otro número.

Y nadie sabe cuál es la verdad.

Por eso, una regla importante es:

Los exports deberían leer snapshots guardados, no recalcular la liquidación.

Si la liquidación ya definió cuánto va por banco, el export bancario debería leer ese valor.

Si la liquidación ya definió cuánto va en efectivo, el export de efectivo debería leer ese valor.

Si hubo redondeo y saldo a próxima quincena, también debería salir de lo guardado.

Esto permite que, aunque mañana cambie una política, una liquidación vieja siga explicándose igual.

La trazabilidad depende de eso.

La UI mejora cuando el dominio se ordena

Cuando el modelo está mezclado, la UI empieza a pedir parches.

Aparecen columnas que no se sabe dónde ubicar.

Botones que solo aplican en algunos casos.

Alertas que compiten entre sí.

Textos largos para explicar excepciones.

Modales que intentan resolver problemas que vienen de más abajo.

En cambio, cuando el dominio está mejor separado, la pantalla empieza a respirar.

Una liquidación puede tener una sección de resumen.

Otra de preparación antes de cerrar.

Otra de detalle operativo.

Otra de pagos por obra.

Otra de exports.

Y cada acción aparece donde tiene sentido.

Recalcular pertenece al borrador.

Confirmar pertenece al cierre.

Exportar pertenece a una liquidación ya confirmada o pagada.

Auditar asistencia pertenece al detalle.

Ver política usada pertenece a la trazabilidad.

La UI no se vuelve simple porque se escondió información.

Se vuelve simple porque cada cosa encontró su lugar.

Diseñar liquidaciones es diseñar confianza

En una liquidación de obra, un error no es menor.

Puede generar discusiones con trabajadores.

Puede hacer perder tiempo administrativo.

Puede duplicar adelantos.

Puede afectar el flujo de caja.

Puede distorsionar el costo real de una obra.

Por eso, una buena pantalla de liquidaciones no solo tiene que verse prolija.

Tiene que ayudar a cerrar una quincena con confianza.

Eso significa mostrar:

• qué datos se usaron;
• qué falta revisar;
• qué valores quedaron congelados;
• qué pagos se van a hacer;
• qué export corresponde generar;
• qué cambió desde el último cálculo;
• qué decisiones quedaron registradas.

Una liquidación no es solo un monto.

Es una decisión operativa que tiene que poder explicarse después.

Cómo lo estamos pensando en Traziq

En Traziq estamos construyendo la liquidación como parte de un flujo más grande:

asistencia → adelantos → liquidación → pago → exportación → control por obra.

La idea no es reemplazar una planilla por una pantalla igual de cargada.

La idea es ordenar el proceso.

Que la asistencia cargada durante la quincena alimente la liquidación.

Que los adelantos se descuenten de forma trazable.

Que la política banco/efectivo quede guardada.

Que los exports salgan de los valores confirmados.

Que el detalle esté disponible para auditar.

Y que el usuario pueda entender, antes de pagar, si está en condiciones de cerrar la quincena.

Porque digitalizar una liquidación no es solamente pasar Excel a una app.

Es convertir un proceso disperso en un flujo confiable.

Menos planillas sueltas.

Menos WhatsApp perdido.

Más trazabilidad para pagar y controlar la obra.

Sumate al waitlist

¿Trabajás con asistencia, adelantos o liquidaciones de personal de obra?

Estamos construyendo Traziq para ordenar ese flujo de punta a punta.

Sumate al waitlist para seguir el avance del producto y ayudarnos a construir una herramienta pensada para la operación real de obra.