Automatización de cobranzas sin API del POS

Un fabricante de alimentos del sur de Florida vende wholesale a cuenta corriente a unos setenta y cinco clientes entre restaurantes y retail.

El reclamo de esas facturas era manual e inconsistente. Una persona mantenía la planilla de cobranzas, llamaba cuando se acordaba, y todos los días volvía a tipear en esa misma planilla las facturas wholesale del reporte de recibos del punto de venta.

Las cadenas lo complicaban más: varias sucursales, una sola casilla de cuentas a pagar, y ninguna forma de mandar un reclamo consolidado.

Dos etapas de aviso: uno entre el día veintiuno y el treinta, y el de mora desde el día treinta y uno.

Los recordatorios se agrupan por dirección de correo y no por cliente, porque las cadenas comparten una sola casilla de cuentas a pagar. Un cliente con doce facturas abiertas recibe un mail con una tabla de doce, no doce mails.

Cinco workflows en total: recordatorios, carga automática de facturas desde el reporte del POS, parte diario al operador, alta de clientes nuevos y conciliación de cobros.

El cliente decidió no licenciar la API del punto de venta. Para su volumen el costo no se justificaba, y esa decisión estaba tomada antes de que yo entrara a definir el alcance.

Así que el sistema no llama a ninguna API. Lee el reporte que el POS ya manda por mail de forma programada, lo parsea, y de ahí carga las facturas wholesale del día. Eso dejó el costo recurrente en cero y el proyecto dentro del presupuesto.

La segunda decisión importa igual: la lógica vive en la planilla del cliente, no en la plataforma de automatización. Una hoja se llena sola con exactamente las facturas a reclamar hoy, ya cruzadas con el email del contacto y el tipo de aviso. La persona que lo opera audita lo que el sistema va a hacer mirando su propia planilla, sin abrir la herramienta de automatización.

Tampoco hay almacén de estado externo. Lo enviado queda registrado en dos columnas de esa misma hoja, así que el estado del sistema no se puede desincronizar del estado real del negocio.

En una pyme eso es casi toda la arquitectura: no la mejor integración en abstracto, sino la mejor que el cliente va a pagar por mantener andando.

El sistema se probó contra noventa días de historia real — cuatrocientas doce facturas — contra lo que el operador había cargado efectivamente a mano.

Esa corrida detectó un defecto real. El primer filtro seleccionaba las facturas wholesale por perfil de cliente y perdía veintisiete en silencio: facturas wholesale legítimas cargadas bajo perfil retail, según qué botón apretó quien tomó el pedido.

El perfil de cliente nunca fue un discriminador confiable. La forma de pago sí. Filtrar por forma de pago reprodujo exactamente la carga manual del operador.

Después se validó un día completo de punta a punta: de cincuenta y cuatro recibos se extrajeron las cinco facturas wholesale, con los nombres normalizados y los vencimientos bien calculados.

En producción. Los cinco workflows corren todos los días y le devuelven al operador entre treinta y cuarenta y cinco minutos diarios: el tiempo que antes se le iba en tipear las facturas del día y en decidir a quién reclamar.

Entregado con runbook de salida a producción, guía de usuario escrita para la persona que lo opera todos los días, procedimiento semanal de conciliación, el análisis de calidad de datos detrás de la planilla, y un registro de incidentes.

Un set de validación no es un trámite. Correr el sistema contra lo que una persona hizo de verdad, y no contra lo que el proceso dice que hace, es lo que saca a la luz el discriminador que nadie escribió.