El vendedor de campo trabaja en el peor entorno posible para el software: de pie en el mostrador de su cliente, con el celular en una mano, con señal intermitente y con alguien esperando una respuesta.
El vendedor necesita saber si hay producto, a qué precio para ese cliente concreto y con qué descuento negociado, y necesita cerrar antes de que la conversación se enfríe.
Y necesita que el pedido llegue bien puesto al ERP. Porque si un toque de más en una pantalla que no responde genera dos pedidos idénticos, alguien va a recibir mercancía duplicada y alguien va a pasar la tarde arreglándolo.
Una aplicación instalable que funciona como el frente móvil del ERP del grupo. El ERP es la fuente de verdad; la aplicación es la capa de captura y consulta, con su propia base local sincronizada continuamente.
Del primer día de trabajo a un ciclo comercial funcionando de punta a punta —cliente, cotización, pedido en el ERP, factura y tablero de metas— pasó menos de una semana. No es un prototipo: es el sistema que la fuerza de ventas usa.
Recibe un enlace, ve su cotización, el estatus de su pedido, sus referencias bancarias, y descarga su comprobante fiscal. Sin cuenta, sin contraseña, y sin que ese enlace permita asomarse a los pedidos de nadie más.
Para lanzamientos se construyó un inventario virtual de preventa, repartido en cuotas por vendedor. Cada quien vende contra la suya y el sistema descuenta lo que ya comprometió, así que no hay sobreventa antes de que el producto llegue.
Cada uno es un problema de negocio real que solo se resuelve con decisiones de ingeniería correctas.
El corazón técnico del proyecto. Un doble toque, un tiempo de espera agotado o un reintento no pueden generar dos pedidos en el ERP. Y un fallo a mitad del proceso no puede dejar la cotización inutilizable, porque el vendedor sigue frente al cliente.
Si el pedido ya tiene folio y está en un estado terminal, la operación responde correctamente y sale sin hacer nada.
Si el pedido se está procesando, el segundo toque no compite: recibe una respuesta de espera.
En cuanto el ERP devuelve el identificador del pedido, se guarda antes de intentar confirmarlo. Un fallo posterior ya no puede duplicar.
Cualquier excepción devuelve la cotización a estado editable guardando el error, pero conserva deliberadamente la referencia al ERP.
Si el folio local ya no existe en el ERP porque alguien lo borró a mano, se limpia la referencia y se permite recrear.
El vendedor puede tocar dos veces, perder la señal y volver: el pedido acaba existiendo exactamente una vez.
Entre que el vendedor cotiza y autoriza pueden pasar días. Autorizar contra stock inexistente genera pedidos imposibles de surtir.
No en el momento de cotizar.
Cada línea se ajusta al múltiplo inferior surtible: no se puede enviar media caja.
Se convierte en faltante y el ajuste se documenta en el pedido, para que el almacén y el cliente sepan qué pasó.
Decisión de negocio explícita: incluye la mercancía en tránsito, no solo la existencia física.
El pedido que llega al almacén es un pedido que el almacén puede surtir.
En lanzamientos el stock aún no existe físicamente, pero hay que permitir levantar pedidos sin sobrevender.
El disponible no viene del ERP sino de la cuota asignada menos lo que ese mismo vendedor ya comprometió.
Un pedido con líneas de preventa no viaja al ERP hasta la autorización selectiva por lotes.
Con varias iteraciones y una reversión explícita en producción cuando una versión no se comportó como debía.
El lanzamiento se puede vender con anticipación sin comprometer lo que no existe.
El cliente debe ver su cotización por un enlace, sin cuenta. Un identificador secuencial en la dirección permitiría enumerar todas las cotizaciones del grupo cambiando un número.
Con una clave que solo vive en el servidor.
La comprobación no filtra información por el tiempo que tarda en responder.
Un enlace manipulado se rechaza, no se comporta de forma ambigua.
El cliente accede a lo suyo y solo a lo suyo, sin fricción de registro.
Vale la pena ser preciso, porque es el matiz que distingue a quien conoce el terreno: la aplicación no timbra. El ERP timbra. Lo que resolvimos es conseguir el comprobante y entregarlo bien.
Se usa la existencia del archivo fiscal como evidencia de que la factura está realmente timbrada antes de servirla. No basta con que el documento exista en el ERP.
Cuando el ERP niega la generación del documento por permisos, el sistema cae a una segunda vía y valida que lo recibido sea realmente el archivo esperado antes de entregarlo.
Cuando un pedido genera facturas parciales, se empaquetan juntas para el cliente.
El cliente recibe su comprobante sin que nadie del equipo tenga que buscarlo a mano.
El ERP modela el surtido como una cadena de movimientos de almacén encadenados. El vendedor necesita ver dónde va su pedido en una sola línea, en un celular.
Los pasos del surtido se consolidan con sus fechas y estados.
No a la terminología interna del ERP.
La pregunta «¿dónde va mi pedido?» se responde sin llamar a nadie.
Todo lo de esta lista existe hoy en producción, en un negocio que factura todos los días.
Ver todos nuestros serviciosForma parte de un ecosistema de seis sistemas que comparten un mismo corazón de datos. Recórrelos, o vuelve a la visión de conjunto.
Si algo de lo que acabas de leer se parece a lo que vives todos los días, hablemos. La primera conversación es de diagnóstico, no de venta.