El ERP se cayó el sábado: qué pasa con las ventas que entraron mientras tanto

En 1 minuto

Un ERP que se cae un rato no es raro: hay mantenimientos, actualizaciones y fallas. Lo caro es lo que pasa con las ventas que entraron mientras tanto. Si cada venta se guarda antes de prometerla, se reintenta con paciencia, no se duplica al repetirse y lo que no pasa queda apartado con su motivo, la caída se vuelve un trámite. Si no, se vuelve días de capturas a mano, pedidos dobles y un cierre que no cuadra.

Imagine una empresa que vende en línea y en mostrador. Es ficticia, pero se parece a muchas. Un sábado, su ERP deja de contestar. Puede ser una actualización que se alargó, un servidor que se reinició o un enlace que se cortó; para lo que sigue, da igual. La tienda en línea sigue abierta. Los clientes siguen comprando. Y cada venta tiene que llegar al ERP para descontar el inventario, registrar el ingreso y, después, facturarse.

Alguien en operaciones se da cuenta tarde, porque un cliente pregunta por su factura. En ese momento la empresa tiene tres caminos, aunque rara vez se toman a propósito:

1. Cerrar la tienda hasta que el ERP regrese. Es seguro y es caro: se pierde la venta y, a veces, el cliente.
2. Seguir vendiendo y «capturar después». Alguien exporta los pedidos a una hoja y después los mete a mano. Es barato durante la caída y caro al día siguiente.
3. Seguir vendiendo con cada venta guardada en una espera ordenada, que se pone al día cuando el ERP regresa, diseñada para no duplicar y con la lista de lo que no pudo pasar.

Este artículo es para quien dirige operación, finanzas o tecnología en una empresa cuyos sistemas dependen unos de otros. Sostiene una idea: la caída no es el problema; el problema es no saber qué quedó pendiente. Y explica, en lenguaje de negocio, las cinco piezas que convierten el tercer camino en lo normal.

No es un artículo sobre cómo elegir entre una llamada en línea, una cola o un evento; eso está en ¿En línea o asíncrono?. Tampoco sobre reconstruir la historia de una orden; para eso está La orden no se pierde, se pierde el rastro. Aquí el foco es otro: conservar, dosificar y reconciliar lo pendiente durante una caída y al regreso.

Todo lo que sigue es genérico a propósito. Vale para un ERP, un sistema de facturación, una paquetería o el sistema de un socio: cualquier destino que un día no conteste.

La caída no es el problema: no saber qué quedó pendiente

Ningún sistema contesta todo el tiempo. Los fabricantes publican ventanas de mantenimiento, las redes se cortan y los servidores se reinician. El propio estándar de la web reserva un código para eso: el 503 indica que el servidor no puede atender por una sobrecarga temporal o un mantenimiento programado, que probablemente se resolverá después de un tiempo (traducción libre) [7]. Es decir, la industria da por hecho que el destino a veces no estará.

Lo que cambia de una empresa a otra es qué pasa con lo que llegó mientras el destino no estaba. Y ahí aparecen tres preguntas que, al día siguiente, alguien va a hacer en voz alta:

• ¿Cuántas ventas entraron mientras el ERP estaba caído?
• ¿Cuántas ya llegaron, cuántas siguen esperando y cuántas no van a pasar solas?
• ¿Alguna llegó dos veces?

Si la respuesta a cualquiera es «hay que revisar», una caída corta se convierte en días de trabajo manual y conciliación. Y lo peor no es el tiempo: es que nadie puede afirmar con certeza que la lista está completa.

Lo que pasa en cada momento de una caída

Conviene separar la caída en tres momentos, porque en cada uno se rompe algo distinto.

Las cinco piezas que siguen protegen lo que entra durante la caída; la sección siguiente cubre el regreso y el cierre.

Cinco piezas para que una caída sea un trámite

1. Guardar la venta antes de prometerla

La primera regla es sencilla de decir: la venta se guarda en la empresa antes de mandarla a ningún lado. No en la memoria del programa que la manda, que se pierde si ese programa se reinicia, sino en un lugar que sobreviva a una falla.

La forma más conocida de hacerlo tiene nombre en la industria: la bandeja de salida (en inglés, transactional outbox). Al registrar la venta, en el mismo paso se anota también «hay que avisarle al ERP». Un proceso aparte lee esa bandeja y hace el envío. Así, la venta no queda registrada sin su pendiente [3]. Ojo: esto protege lo que pasa dentro de la empresa; no confirma que el ERP lo recibió. Esa confirmación llega después, cuando el ERP contesta.

Si entre los dos sistemas hay mensajería, existe una idea complementaria, la entrega asegurada (en inglés, Guaranteed Delivery): una vez que el sistema de mensajería acepta un mensaje, lo guarda en su almacén y no lo borra hasta que el siguiente paso lo recibió [6].

En el lenguaje del comité: si el ERP no contesta, la venta espera registrada, en lugar de perderse.

2. Reintentar con paciencia y con espacio

Cuando el envío falla, lo natural es reintentar. Y está bien, con dos cuidados.

Paciencia: cada reintento espera un poco más que el anterior, hasta un tope, para no reintentar de más [1]. Si el ERP va a tardar en regresar, no sirve preguntarle cada segundo. Y esto vale para fallas pasajeras: si el ERP rechaza una venta por un dato mal capturado, reintentarla no la arregla (eso va en la pieza 5).

Espacio: los reintentos de muchas ventas no deben caer en el mismo instante. La guía de reintentos de Amazon lo explica así: si todas las llamadas que fallaron esperan lo mismo, al reintentar vuelven a llegar juntas y vuelven a saturar al destino; la solución es agregar algo de azar a la espera para repartirlas en el tiempo [1]. La misma guía lo resume en una frase que conviene llevar al comité: los reintentos son egoístas (traducción libre); cada reintento le exige al destino gastar más recursos en atenderlo, y si el destino ya está saturado, reintentar empeora la sobrecarga en lugar de aliviarla [1].

Si el destino contesta con una sugerencia de cuánto esperar —el estándar de la web prevé un aviso técnico para eso, llamado Retry-After [7]—, se toma en cuenta junto con la regla de reintentos acordada.

3. Dejar de tocar la puerta

Hay un punto en el que reintentar ya no ayuda. Si el ERP lleva un buen rato sin contestar, mandarle cada venta para que falle una por una solo gasta recursos de los dos lados y genera fallas repetidas que no ayudan a operar.

Para eso existe el cortacircuitos (circuit breaker). Martin Fowler lo describe así: la llamada al otro sistema se envuelve en un objeto que cuenta las fallas; cuando llegan a cierto límite, el cortacircuitos «se dispara» y las llamadas siguientes regresan con error sin intentar siquiera la llamada; y conviene que, cuando se dispare, avise a alguien [2]. No cualquier error debe dispararlo, solo las fallas que se definieron para eso [2]. Cada cierto tiempo deja pasar una prueba controlada; si el destino ya contesta, el flujo sigue.

En el lenguaje del comité: la empresa se da cuenta de la caída por un aviso, no por un cliente que pregunta por su factura.

4. Que repetir no duplique

Ésta es la pieza que más dinero cuida. Un reintento puede llegar dos veces: el envío salió, el ERP lo registró, pero la respuesta se perdió en el camino; quien mandó no sabe si llegó y lo manda otra vez. La guía de Amazon lo dice sin rodeos: que una llamada falle o se agote el tiempo no significa que su efecto no haya ocurrido, y una operación que tiene efectos no es segura de reintentar a menos que esté diseñada para eso [1]. La bandeja de salida tiene la misma advertencia: el proceso que envía puede mandar un mensaje más de una vez —por ejemplo, si se cae justo después de enviarlo y antes de anotarlo—, así que quien lo recibe tiene que reconocer lo que ya procesó [3].

La forma de lograrlo es que cada venta viaje con un folio único que el destino reconozca y guarde: si llega dos veces, la segunda no crea un pedido nuevo, sino que contesta lo mismo que la primera. El folio solo funciona si el destino lo compara de verdad, y se prueba con cada sistema que participa, incluido el de cobro. Los procesadores de pago lo hacen así; Stripe, por ejemplo, guarda la respuesta de la primera solicitud con una llave y, si llega otra con la misma llave, devuelve la respuesta guardada en lugar de repetir la operación; además compara los datos con los de la primera y conserva la llave por un tiempo, no indefinidamente [5]. A esta propiedad se le llama idempotencia: repetir no cambia el resultado.

En el lenguaje del comité: el reintento está diseñado para que el cliente tenga un solo pedido y un solo cobro, y la conciliación del final lo comprueba.

5. Apartar lo que no pasa, con su motivo

No todo lo que falla es por la caída. Algunas ventas no van a pasar aunque el ERP esté perfecto: un producto que no existe en el catálogo del ERP, un dato fiscal mal capturado, un precio que no coincide. Si esas ventas se reintentan sin límite, tapan a las demás y nadie se entera.

La práctica habitual es poner un límite de intentos y, al llegar a él, apartar la venta en una fila aparte (en inglés, dead-letter queue). La fila no guarda el motivo sola: junto con la venta se anota el error, el intento y quién decide el siguiente paso. La documentación de colas de Amazon lo describe así: se fija cuántas veces se intenta un mensaje antes de moverlo a esa fila, y apartarlos sirve para aislar lo que no se procesó y averiguar por qué [4].

Lo importante no es la fila: es que tenga dueño. Una venta apartada sin responsable es una venta perdida con mejor nombre.

Cuando el ERP regresa: el orden y el ritmo

El momento más delicado no es la caída: es el regreso. Hay dos errores frecuentes.

Mandar todo de golpe. Tras una caída larga, puede haber cientos de ventas esperando. Si se mandan todas al mismo tiempo, el ERP recién levantado recibe una avalancha y puede volver a caerse. Es la misma lección del punto 2, en grande: el pendiente se manda a un ritmo que el ERP aguante, y ese ritmo se decide y se prueba antes, no durante la emergencia.

Mandar en desorden. Si un cliente compró y después canceló, el ERP tiene que recibir primero la compra y después la cancelación. Al revés, la cancelación no encuentra qué cancelar y la compra se queda viva. Para cada venta se define el orden de lo que le pasa —por ejemplo, con su folio y un número de paso— y la regla para aplicarlo, de modo que la cancelación no se procese antes que la compra aunque haya reintentos. Ventas distintas sí pueden avanzar en paralelo. Y si una venta pasó por la fila de apartados, al regresarla se respeta ese orden; la documentación de colas de Amazon advierte que una fila de apartados puede romper el orden de los mensajes [4].

Y al final, una conciliación: lo que se mandó contra lo que el ERP confirmó, con la lista de lo que falta. No es desconfianza en el diseño; es la evidencia de que la caída terminó de verdad.

Qué ve el cliente mientras tanto

Durante la caída, lo ideal es que el cliente note solo lo que de verdad depende del ERP. La regla útil es que cada aviso al cliente salga cuando lo que anuncia ya ocurrió:

• «Recibimos su pedido» puede salir de inmediato, porque la venta ya quedó guardada en la empresa.
• «Su factura está lista» sale hasta que la factura exista, no antes.
• Si el inventario se lleva en el ERP, conviene que la tienda reserve lo vendido de su lado mientras tanto, para no vender dos veces la última pieza.

Un aviso que sale antes de tiempo dice algo que todavía no es cierto, y el cliente lo recuerda más que la demora.

Los riesgos, en lenguaje de negocio

Cinco preguntas para su próximo comité

1. La última vez que el ERP —o el sistema de facturación, o la paquetería— no contestó, ¿cuántas ventas entraron mientras tanto, y cuánto tardó su empresa en saberlo?
2. ¿Dónde quedan guardadas esas ventas mientras el destino no contesta? Si la respuesta es «en el programa que las manda», se pierden cuando ese programa se reinicia.
3. Si una venta se manda dos veces, ¿el ERP crea dos pedidos? Pídale a tecnología que lo demuestre en pruebas, no que lo afirme.
4. ¿Quién es dueño de las ventas que no pasaron solas, y cómo se entera?
5. Cuando el ERP regresa, ¿quién decide a qué ritmo se pone al día? Si nadie lo decidió antes, lo decide en plena emergencia quien esté de guardia.

Si varias respuestas son «no lo sé», tómelo como señal para medir el flujo antes de la próxima ventana de mantenimiento.

Por dónde empezar esta semana

Haga un simulacro. En un ambiente de pruebas, apague a propósito el destino —el ERP, la facturación o el que más le preocupe— durante un periodo y con un volumen de ventas de prueba que defina su equipo. Incluya tres casos difíciles: una venta cuya respuesta se pierde aunque el destino sí la registró, una venta que el destino rechaza por un dato mal capturado, y una venta que se compra y se cancela durante la caída. Después, responda por escrito:

• ¿Cuántas ventas entraron durante el simulacro, y cuántas llegaron al destino cuando volvió?
• ¿Alguna llegó dos veces?
• ¿Cuáles no pasaron, y alguien se enteró sin buscarlas?
• ¿Cuánto tardó el destino en ponerse al día, y aguantó el ritmo?
• ¿Alguien recibió el aviso de la caída, y la conciliación final identifica cada folio como confirmado o pendiente?

La hoja que resulte es una especificación muy concreta de lo que su operación necesita.

Qué hace Hábil

En Hábil construimos a la medida el espacio entre sus sistemas: la tienda, el ERP, la facturación, las paqueterías y los socios. Es justo donde se decide qué pasa con una venta cuando el destino no contesta.

Si su diagnóstico confirma que una caída se vuelve días de capturas, la propuesta está en Hábil MDW: la capa que se pone entre los sistemas que ya tiene, sin reemplazarlos. Cada envío queda con su respuesta o con su motivo de falla, y los reintentos están diseñados para no repetir el efecto. De cada operación queda qué se mandó, qué contestó cada sistema, a qué hora y, si falló, por qué. El alcance, los sistemas que se conectan y el ritmo de recuperación se revisan con su caso.

La conversación puede empezar con la última caída que recuerde: cuánto duró, qué se hizo con las ventas y cuánto costó ponerse al día. Con eso revisamos juntos dónde está el riesgo en su operación. Escríbanos por WhatsApp; para proteger a sus clientes, no comparta por ese medio números de pedido ni datos personales: acordaremos en la conversación el canal para el caso.

Pida su primera conversación, sin costo.

Consultadas el 12 de noviembre de 2026. Cada referencia lleva su confianza: alta (fuente primaria leída).