Este es un recorrido de producto, no el caso de ningún cliente real: describe cómo se conectan las pantallas de VendeWare, sin cifras inventadas ni un comercio en particular. La pregunta que resuelve es en qué momento exacto del camino entre el cobro de un pedido y su entrega física queda decidido -sin que nadie lo note- si ese pedido se va a quedar pagado y sin surtir indefinidamente (según lo visto en el pedido pagado de VendeWare puede quedarse sin surtir, sin aviso y sin reembolso).
1. El cliente paga en el storefront y el pedido se crea sin reservar inventario
El recorrido empieza en el checkout del storefront: el cliente confirma su compra, el pago se procesa y orders.service.ts::create() registra el pedido con estatus paid (o pending_payment, según el método de cobro). El propio código documenta que este paso "NO descuenta stock (sin reserva)": en este momento nadie ha confirmado todavía que exista mercancía suficiente para entregar lo que se acaba de cobrar.
2. El pedido llega a la sucursal para surtirse
El pedido pagado aparece del lado del personal como pendiente de surtir. Cuando alguien intenta prepararlo, entra en juego admin.service.ts::confirmPayment(), que es el punto donde VendeWare por fin verifica la existencia real contra el almacén y, si hay mercancía suficiente, genera la remisión y descuenta el inventario. Éste es el primer momento del flujo completo en que el pedido y el inventario real se cruzan.
3. Si falta existencia, el intento de surtido falla en silencio
Cuando no hay existencia suficiente, la generación de la remisión falla y el catch del mismo método revierte el pedido a su estatus previo -sólo eso: this.repo.setStatus()-. No hay una tercera rama para este caso: el pedido no pasa a un estado distinto de "recién pagado" ni "ya surtido", simplemente regresa al punto en el que ya estaba antes de que alguien intentara surtirlo.
4. Nada avisa, nada reembolsa: el pedido queda indistinguible de uno sano
El mismo catch que revierte el estatus no dispara ningún correo, notificación ni reembolso. Y aunque el modelo de datos sí contempla un estado 'cancelled' para StoreOrderStatus, ese valor nunca se usa para un pedido que falló por falta de stock. El resultado: un pedido que ya chocó una vez con la falta de existencia queda exactamente igual, en el sistema, que uno que simplemente todavía no se ha intentado surtir.
5. El cliente ve la misma pantalla, se haya intentado surtir su pedido o no
Del lado del cliente, el detalle de su pedido muestra "Pago confirmado. Estamos preparando tu pedido para envío." mientras el estatus siga siendo paid -sin distinguir si el personal ya intentó surtirlo y no pudo-. El cliente no tiene ninguna señal de que algo salió distinto a lo esperado: el mensaje es el mismo el primer día que el día quince.
Qué guarda el sistema en cada etapa
| Etapa | Qué guarda VendeWare | Aviso al cliente / reembolso |
|---|---|---|
| 1. Pago en el storefront | Pedido creado, estatus paid/pending_payment, sin reserva de stock | Confirmación de compra (no aplica todavía) |
| 2. Intento de surtido | Verificación de existencia real contra almacén | Nada visible para el cliente |
| 3. Falla por falta de stock | Estatus revertido al previo (setStatus) | Ninguno: no hay correo, notificación ni reembolso |
| 4. Después de la falla | Pedido idéntico a uno "recién pagado" (no existe estado de falla) | El cliente sigue viendo "pago confirmado" |
En ninguna de las cuatro etapas existe un campo, un estatus o una alerta que diga "este pedido ya falló al intentar surtirse". Puedes estimar cuánto representa eso, con tus propios números, en la calculadora de exposición por pedidos pagados sin surtir.
Preguntas frecuentes
¿En qué paso exacto se pierde el rastro de un pedido que no se pudo surtir?
En el catch de admin.service.ts::confirmPayment(): el pedido revierte a su estatus previo sin marcarse de ninguna otra forma, así que queda indistinguible de un pedido que simplemente no se ha intentado surtir todavía.
¿VendeWare reintenta solo el surtido más tarde?
No de forma automática. El pedido queda disponible para que el personal lo vuelva a intentar manualmente cuando haya existencia, pero nada en el sistema se lo recuerda ni lo prioriza sobre uno sano.
¿Este recorrido aplica a todos los métodos de pago del storefront?
El punto de falta de stock ocurre en confirmPayment(), después de que el pedido ya está creado; aplica por igual sin importar el método de pago usado para llegar a ese estatus.
Ve el recorrido completo en tu propia demo
Te mostramos en vivo cómo VendeWare mueve un pedido del cobro al intento de surtido, y qué pasa exactamente cuando falta existencia.
Agenda una demo gratis