Caso · Reglas de negocio
Revisión de pedidos, comisiones y abonos
Un panel que aplica reglas explícitas a lo que exporta el ERP y deja a atención al cliente una lista de trabajo: qué revisar, por qué ha saltado cada caso y quién lo ha validado ya. Lo diseñé y lo mantengo, y el equipo lo usa a diario.
El problema
En atención al cliente algunos errores se detectaban tarde y a mano, repasando listados:
- El mismo pedido introducido dos veces.
- Portes cobrados a clientes que los tienen incluidos.
- Pedidos retenidos para agrupar un envío que se quedaban parados cuando el siguiente ya existía.
- Envíos asignados a una agencia que no reparte en esa provincia.
- Comisiones de agentes que no se ajustaban al aplicar un descuento, o que quedaban a cero.
- Devoluciones que cobraban la gestión y, a la vez, devolvían los portes.
Cada error cuesta dinero, una reclamación o un envío repetido. Casi todos se pueden describir con una regla.
Qué hace
El panel carga los datos exportados y ejecuta las reglas. Cada sección (pedidos, comisiones, abonos) tiene una ficha por regla con los casos pendientes y lo que suponen en euros. Al abrirla aparecen la regla, por qué importa y una tabla donde cada fila explica su causa. Las filas se marcan como «Revisando» o «Validado», se filtran y se exportan a CSV.
Por qué salta una regla
«Bajada insuficiente: comisión del 10 % → 8 % con un descuento del 30 %; el máximo permitido es el 5 %».
- Reglas como funciones puras con motivo legible. El motivo es parte del resultado, no un adorno. Reduce el tiempo de revisión y deja ver los falsos positivos.
- Excepciones explícitas. Clientes que recogen, abonos ya corregidos o comisiones rebajadas lo suficiente no saltan. En la demo hay casi-casos plantados para demostrarlo.
- Datos en bruto; lógica en el panel. Añadir o ajustar un aviso es una función y una línea de configuración, sin tocar el servidor del ERP.
- El estado de revisión va ligado al caso. Un pedido retenido validado vuelve a salir si aparece otro pedido nuevo del mismo cliente.
Qué es real y qué es demo
| Parte | En la demo | Detalle |
|---|---|---|
| Datos: pedidos, facturas, abonos | Sintético | Generados desde cero con semilla fija. Empresa sin nombrar. |
| Reglas | Sintético | El original tiene 13 reglas. La demo muestra 7 genéricas, con umbrales, zonas y agencias inventados. |
| Motor en el navegador y motivo por fila | Real | Misma arquitectura que el original, recreada desde cero. |
| Validaciones compartidas por el equipo | No incluido | En la demo se guardan solo en tu navegador. |
| Auditoría de facturas de transporte y reglas por cliente | No incluido | Existen en el original. |
Resultados
Sistema original: en uso diario por atención al cliente y administración. No publico importes ni datos de la empresa.
Un ejemplo real: cada día el motor compara los pedidos entre sí: mismo cliente, mismo importe total y misma dirección de envío. Si coinciden, salta un aviso; lo compruebo y, cuando es un duplicado real (más de 7 a la semana), se anula antes de enviarlo y facturarlo dos veces.
Transporte: la auditoría de facturas de transporte compara cada factura de las agencias con la tarifa pactada y señala lo que no cuadra para reclamarlo.
Las cifras de la demo salen de datos sintéticos. Miden que el motor funciona, no el impacto en la empresa.
Limitaciones y siguientes pasos
- Las reglas son deterministas: no priorizan por probabilidad ni aprenden de las validaciones.
- Siguiente paso: guardar el histórico de validaciones para medir la tasa de falsos positivos de cada regla. Es el punto de partida natural para un modelo que priorice.
- Avisos por correo cuando aparece un caso rojo.
Capturas de la demo
Todas con datos sintéticos.
