When a pallet network depot code cannot be resolved confidently, some systems use “fallback defaults.” These defaults can show the wrong depot on labels or route consignments to the wrong depot after dispatch. This guide helps you identify, fix, and prevent issues caused by fallback defaults.
🔔 Common symptoms
Label shows one depot before dispatch, then changes after export to the network
Consignment is sent to the wrong depot or uses the wrong leg type
Errors like “No delivery depot found” or silent defaulting to a depot
Multi‑network or multi‑stage orders pick the wrong depot set or credentials
1️⃣ First Steps
1. Did the network return depot codes?
Yes: Use the network’s returned depot codes as the source of truth. Do not overwrite with internal defaults.
No: Continue to step 2.
2. Is the consignment type correct for this job?
If third‑party vs network is wrong, depot resolution will be wrong too. Fix the consignment type for the specific stage or integration.
3. Is this a multi‑network or multi‑stage scenario?
If different networks handle collection and delivery, a single set of “global defaults” will be wrong. Separate logic per stage or integration
4. Is your internal gazetteer or “global list” in sync?
If not, pre‑dispatch labels may show a default that flips after export (when the network gazetteers the job). Sync your lists or rely on network codes post‑export for accuracy.
🛠️ How to fix it
If network depot codes are available
Treat network-returned codes as the source of truth for planning and labels.
Do not re-evaluate or override with internal defaults unless the network data is missing.
If depot resolution failed
Prefer an explicit error and guided correction over a silent default.
Use the “fix data” flow to correct mapping or create a one-time alias so future imports auto-match.
If labels “flip” after export
This often means a pre‑dispatch default was replaced by the network’s gazetteered depot at dispatch.
Verify the export event and compare the stored network depot codes. If your internal list is stale, update it or rely on network codes post‑export for accuracy.
If the consignment type is wrong
Validate consignment type per stage or per integration, especially when more than one stage is subcontracted. Avoid order-level defaults that apply to all stages indiscriminately.
For multi‑network or multi‑stage orders
Ensure the correct network is allocated to each leg or stage.
Check that surcharges are mapped correctly to the selected network options.
？FAQ
Why do depot codes change after dispatch?
The network finalizes depot codes during export. If your pre-dispatch view used a default, it may “flip” once the network assigns the actual depot.
Can we force a specific depot code?
In some integrations, yes, but best practice is to let the network’s gazetteer decide unless you have a clear contractual override. Always ensure overrides match network capabilities.
We use multiple networks or subcontract multiple stages — what should we do?
Define consignment type and depot rules per integration or stage rather than applying one rule to the whole order.
Why was the order sent to the wrong depot on import?
Internal defaults may have overwritten network-assigned depots. Use network-returned codes as source of truth on import.
📚 When network depot codes are present, treat them as the source of truth. Avoid overwriting with internal defaults. If a depot cannot be resolved, prefer an explicit error and guided correction over a silent fallback.