Pedidos (0)
GetExpCli.
Usá ⟳ Sync para que lo lea ahora — o dejalo latente y que lo levante la rectificación.
Códigos GLS
| Código | Descripción | |
|---|---|---|
0 |
Manifestada | |
1 |
Pendiente autorización | Incidencia |
2 |
En tránsito a destino | |
3 |
En delegación destino | |
5 |
Anulada | Rechazado Final |
6 |
En reparto | |
7 |
Entregado | Final |
8 |
Entrega parcial | Final |
10 |
Devuelta | Rechazado Final |
11 |
Pendiente datos | Incidencia |
12 |
Devuelta al cliente | Rechazado Final |
13 |
Posible devolución | Incidencia |
14 |
Solicitud de devolución | Incidencia |
15 |
En devolución | Rechazado |
17 |
Destruido | Final |
18 |
Retenido | Incidencia |
20 |
Cerrado por siniestro | Final |
22 |
Entregado en ParcelShop | Final |
51 |
Entrega anulada (devuelta) | Rechazado Final |
90 |
Cerrado definitivo | Final |
91 |
Con incidencia | Incidencia |
-10 |
Grabado |
Configuración Webhook
Expediciones espurias (I3104)
—Las tres variantes de recanalización falsa de GLS ES. Todas son expediciones que nunca persistimos, por eso ningún guard basado en hermanos las ve.
GrabaServicios crea la expedición y recién después responde,
delay_ms más tarde. Con 65000 el corte de order-service (60s en
POST /shipping/create) ocurre de verdad: el packing reintenta, GLS ya tiene
la expedición y contesta -70 solo. Es la secuencia que duplica en producción,
sin sembrar nada.
Atajos para llegar al -70 sin esperar el timeout. Se arman antes de
crear el envío, sobre la Referencia tipo="C" (el order_number).
Ojo: fabrican el estado final, no reproducen la carrera.
La fantasma se cuelga de la MISMA referencia con codexp propio,
borrado=S, un único -10 y <fecha> posterior.
Lo que la distingue de la ida viva es el <servicio>, no el borrado.
El <borrado> no se configura: el simulador lo deriva del movimiento
(S mientras la expedición no se movió, N después), que es como
lo reporta GLS. No es un discriminador.
POST /shipping/{tracking}/sync-single en shipping-service.