1. Why can’t I remove the Palletforce (export) resource from an already dispatched order?
You can’t remove it when:
A tracking code exists and the consignment is depot locked.
A tracking code exists and the manifest date has passed.
Why: Once an order is dispatched to Palletforce and locked in their system, edits are restricted. Changes to imported Palletforce orders must be made in the Palletforce portal.
Workaround in Qargo: Assign a driver and vehicle as an extra resource and dispatch to the driver to continue operationally without removing the Palletforce resource.
2. Why isn’t the SA surcharge added automatically via order import?
Summary: Saturday AM (SA) is a Palletforce surcharge that Qargo applies automatically when a delivery is scheduled on a Saturday. You do not need to add a time window for SA.
Other time windows: Options like AM or Booked Window are standard time windows. If they are included in your import or selected on the order, the related charges will be added.
What to do: For a specific non‑Saturday timed delivery, add the appropriate time window (for example, AM or Booked Window) to your order or include it in your import.
Status: Expected behaviour. We continue to work with Palletforce on mapping improvements.
3. Why is there a different depot assigned to my order instead of the one I expected?
Gazetteering per leg: The leg assigned to Palletforce is gazetteered by Palletforce. If PF is on collection only, PF will resolve the collection depot, not the delivery depot.
Leg and resource assignment matter: If users assign PF to a different leg than they expect, the resolved depot can differ accordingly.
In‑area vs out‑of‑area: When the delivery is outside a customer’s local area, PF may treat it as third‑party or choose a different depot than the user anticipated.
Defaults vs network truth: Any internal or transport‑service defaults can seed a pre‑dispatch depot or label that PF replaces after export. Treat PF‑returned depot codes as source of truth.
After dispatch: Depot changes observed after dispatch typically come from PF processes, not Qargo updating codes post‑export.
4.)Why did my dispatch fail with a duplicate tracking number error?
This typically occurs when an order has an Palletforce tracking number set and the same tracking number has already been used on a previously dispatched order
The most common cause is order copying. When an order is duplicated in Qargo, all fields are copied — including the Palletforce tracking number.
If the copied order is dispatched to Palletforce without removing or replacing the tracking number, Palletforce will reject the dispatch because the number is already registered.
What to do: Before dispatching a copied order, navigate to the order and clear or update the Palletforce tracking number field to a new, unique tracking number.
5. Why is there no barcode available on my order even though it was imported before dispatch?
Barcodes are registered in Qargo only after the dispatch task is completed and Palletforce returns the tracking information.
If an order was created and still has no barcode at import, confirm that:
The order is routed through a Palletforce transport service.
The delivery depot and service level are correctly set — these are required to generate the barcode.
The dispatch task has not been blocked or skipped in a way that prevented consignment creation.
6. Why does the barcode on the physical label not match what Palletforce shows?
After an order is exported (dispatched), Palletforce may assign a different tracking number or depot than the one initially generated; eg: when Palletforce re-routes the consignment based on its own network logic.
When this occurs, the barcode printed from the pre-dispatch label will differ from the one Palletforce holds.
Reprint the label after the dispatch task completes and Palletforce has returned the confirmed tracking data, to ensure the physical barcode matches the Palletforce system.