De fotos por WhatsApp a una cartera de pedidos en vivo: un ERP y una app de campo offline para distribuidores

La mayoría de los distribuidores que conocemos funcionan con tres herramientas: Tally (el software contable más extendido en la India) para las facturas, Excel para el stock y los cobros pendientes, y WhatsApp para todo lo demás. Un comercial fotografía la hoja de pedido en una tienda, la envía a la oficina, alguien la introduce en Tally a la mañana siguiente y solo entonces se descubre que la tienda ya debe ₹50,000 y lleva dos meses sin pagar. El stock es «unas 20 cajas» hasta el día en que deja de serlo.

Construimos AIVCJ ERP para mostrar qué sustituye a ese círculo: una app de campo que funciona sin cobertura, una cartera de pedidos que comprueba el crédito antes de que salga nada, stock controlado por lote y caducidad, facturas GST con un clic y una forma de que el propietario haga preguntas en lenguaje natural. Funciona sobre un distribuidor ficticio de gran consumo: Northwind Distribution, con 3 almacenes (Nagpur, Indore, Hubli), 396 minoristas, 8 comerciales de campo, 123 SKU y 100 días de historial. Cada visitante recibe su propia copia.

El pedido, de la tienda a la factura

1. En la tienda: el comercial abre la ruta del día (el «beat», su recorrido diario de ventas) en la app Northwind Sales, ve la situación de crédito de la tienda, añade cajas y realiza el pedido. ¿Sin cobertura? El pedido se guarda en el teléfono y se marca como «esperando cobertura».
2. Sincronización: cuando el teléfono vuelve a tener conexión, la cola se sube sola. El ERP pone precio a cada línea según su propia tarifa y ejecuta el control de crédito en código.
3. Bloqueo por riesgo: si la tienda supera su límite o una factura ha vencido, el pedido queda bloqueado con el motivo exacto («Pendiente ₹49,917 + este pedido ₹12,147 = ₹62,064, por encima del límite de ₹50,000; la factura NW/26-27/000993 tiene 74 días»). El propietario lo libera indicando un motivo, o lo cancela. La app del comercial se actualiza sola.
4. Preparación y factura: el almacén prepara por lote según el criterio FEFO (primero en caducar, primero en salir), descartando todo lo que caduque en menos de 15 días, y se genera la factura fiscal GST con códigos HSN, números de lote, CGST + SGST o IGST y el importe en letras.
5. Reaprovisionamiento: el ritmo de venta × el plazo de entrega del proveedor señala lo que se va a agotar, agrupado por proveedor y almacén; con un clic se emite la orden de compra, y al registrar la recepción de mercancía se añaden los nuevos lotes al stock.

Primero offline, y nunca dos veces

La venta de campo en la India ocurre en godowns (almacenes locales), sótanos y pueblos pequeños. Una app que necesita cobertura para guardar un pedido pierde pedidos. Por eso la app Northwind Sales (hecha con Expo / React Native) escribe primero cada pedido y cada cobro en el teléfono —SQLite en Android— y los sube después.

Lo difícil del modo offline no es el almacenamiento, son los reintentos. Un comercial pulsa «realizar pedido», la petición llega al servidor, la respuesta se pierde en una zona sin cobertura y el teléfono lo vuelve a intentar. Sin cuidado, eso son dos pedidos. Cada elemento que la app pone en cola lleva su propio id, y el ERP devuelve el pedido existente cuando ve un id repetido. Los precios y el crédito que muestra el teléfono son solo una vista previa: el ERP vuelve a calcular precios y a comprobarlo todo al recibirlo, así que un teléfono desactualizado nunca puede vender a un precio antiguo ni por encima de un límite.

El stock se asigna cuando el almacén prepara el pedido, no cuando el comercial lo toma: dos comerciales pueden vender las últimas 20 cajas a la vez sin que ninguno tenga cobertura. La segunda preparación queda entonces bloqueada con una falta clara («faltan 850») y el propietario traslada stock o emite una orden de compra (PO). No se vende nada que no exista y ningún lote queda en negativo.

Control de crédito en código, no en el modelo

Las decisiones de crédito son decisiones de dinero, así que no interviene ninguna IA. Un pequeño módulo de reglas decide: el riesgo es la suma de las facturas pendientes más los pedidos abiertos aún no facturados más este pedido, comparada con el límite de la tienda; y cualquier factura impagada más antigua que el plazo de pago de la tienda bloquea el pedido. (Detectamos el hueco de los pedidos abiertos durante las pruebas: un segundo pedido de la misma tienda ignoraba el primero, que estaba bloqueado. Está corregido y ahora tiene su propia prueba unitaria.) Liberar un bloqueo siempre exige un motivo, y cada liberación, cambio de límite y ajuste de stock queda registrado en un log de auditoría.

Pregunta a tus datos, con salvaguardas

El único lugar donde usamos IA es cuando el propietario hace preguntas: «¿Qué minoristas de Nagpur tienen deudas de más de 60 días?», «Margen bruto por categoría este mes». Claude Haiku 4.5 escribe una consulta SQL; después, el ERP decide si puede ejecutarse:

• la consulta se ejecuta en una transacción de solo lectura, únicamente sobre 14 vistas de la copia del propio visitante (importes en rupias, sin números de teléfono);
• un filtro en código rechaza todo lo que no sea un único SELECT, o que toque tablas del sistema, configuración o cualquier cosa fuera de esas vistas; probado con 28 casos permitidos y de ataque;
• límite de 5 segundos, máximo de 200 filas, 15 preguntas por visitante y día;
• la consulta exacta se muestra con cada respuesta, como tabla y como gráfico cuando la forma de los datos lo permite.

Las preguntas que los datos no pueden responder —el precio de un competidor, las ventas del mes que viene, «borra todos los pedidos cancelados»— reciben una respuesta breve que indica qué puede responder en su lugar. Una pregunta cuesta unos $0.002.

Qué medimos

Dos notas sobre honestidad. Primera: las respuestas se evalúan en código, no con un juez de IA: la consulta del modelo y una consulta correcta escrita a mano se ejecutan sobre los mismos datos y se comparan los resultados (mismas filas, mismas cifras con un margen de ±1%). Segunda: los tres fallos del conjunto ciego fueron reales: una lista se cortó en 50 filas, una serie salió de la más reciente a la más antigua y una pregunta sobre el precio de un competidor se buscó en nuestro propio catálogo en lugar de rechazarse. Corregimos el primero y el tercero después de la ejecución; el 17/20 se mantiene tal como se midió. La primera ejecución guionizada también detectó cuatro errores en nuestras consultas de referencia —se fusionaban tiendas con el mismo nombre—, y por eso los datos de ejemplo tienen ahora nombres de tienda únicos.

Qué hace falta para conectar Tally

La mayoría de los distribuidores no sustituirán Tally el primer día, y no necesitan hacerlo. El camino práctico es una sincronización nocturna o cada hora: los maestros (cuentas, artículos de stock, godowns) y las facturas pendientes llegan desde la interfaz XML de Tally, los pedidos de venta vuelven como asientos (vouchers) una vez facturados, y el ERP guarda lo que Tally no tiene: rutas (beats), pedidos de campo, stock por lote, bloqueos y el registro de auditoría. La demo no llama a Tally ni al portal GST; los campos de factura electrónica (IRN) y de e-way bill (documento de transporte electrónico) están preparados para ese paso.

Pruébalo: abre erp.demos.aivcj.com, toma un pedido para Shree Ganesh Kirana en la app de ventas, observa cómo queda bloqueado por riesgo de crédito, libéralo, prepáralo y abre la factura. Después pon la app en «sin cobertura» y repítelo.