Tracking de packages
Tracking a nivel de paquete dentro de un stop de entrega. Un stop lleva varios identificadores de package, cada uno avanzando pending → picked → delivered. Empujas los identificadores al crear el stop y luego reconcilias el estado por paquete — incluyendo entregas parciales — de vuelta en tu WMS o ERP.
Para quién es
Entregas más de un paquete trackeado a una misma dirección y tu sistema de registro necesita saber el destino de cada paquete, no solo si el stop se completó. Casos típicos:
- Una operación 3PL / paquetería donde una dirección recibe varios bultos, cada uno con su barcode, y el cliente o shipper espera visibilidad de scan por paquete.
- Un distribuidor B2B multi-bulto (farma, suministro industrial, food service) con pedidos paletizados o multi-caja donde la aceptación parcial es normal — el receptor firma por 8 de 10 cajas y rechaza 2.
- Un consolidador e-commerce que envía varias líneas repartidas en cajas que llegan a la misma puerta, donde el OMS trackea el fulfillment a nivel de paquete/SSCC.
- Cualquiera que hoy codifique "3 cajas" en el label del stop o en un custom field y quiera una lista de primera clase con estado en su lugar.
El modelo de datos completo (packages vs tasks vs capacidad), el lifecycle pending → picked → delivered, el código TS/Python/cURL, el production hardening (delivery-only, entregas parciales, reconciliación sin webhook de package) y los common errors viven en inglés.
Distribución capacitada
Cuando peso, volumen, cadena de frío o equipamiento especialista son innegociables. El optimizador respeta cada restricción declarada; el coste de no declararla es un camión que se queda sin sitio en la tercera parada y tiene que volver al depósito.
Última milla e-commerce
Entrega de paquetes B2C — los pedidos fluyen de tu OMS o WMS a Routal a lo largo del día, el optimizador los agrupa en rutas densas por barrio, los conductores ejecutan con tasks de scan de barcode, y los clientes reciben tracking links automáticamente.