Carrier mappings

Carrier mappings

Carrier mappings

Each line links an Odoo delivery method to the 3PL's carrier and service codes (e.g. delivery method "ROYAL MAIL - 070 UK-48 RM TRK-PKT" -> carrier ROYAL MAIL, service 070 UK-48 RM TRK-PKT).

Used in both directions:

  • Outbound (order push). The order's delivery method is looked up here and the mapped service is requested from the 3PL. No mapping? The delivery method's name is sent as-is - fine for 3PLs that accept free-text service levels, risky otherwise, so map what you use.
  • Inbound (despatch confirmations). The carrier/service the 3PL actually shipped with is matched back to an Odoo delivery method and written onto the delivery. Matching is tolerant of formatting - ROYAL MAIL, RoyalMail and royal-mail all match; an exact carrier+service line wins, and a carrier-only line (service left empty) acts as the fallback for that carrier.
  • Returns. The Return Carrier offered when creating a return is restricted to services of the carrier the order originally shipped with, using these mappings.

Fetch Carriers (where the provider supports it) pre-fills the table from the 3PL's own service catalogue, then immediately tries to auto-map each entry (below) - so on a database that already has its delivery methods, one click usually completes the whole table. Where the 3PL publishes display names alongside its machine codes (ShipHero does: code usps_modern, name USPS), the name is stored in the Carrier Name column and used everywhere a person would read it.

ShipHero carrier source. ShipHero instances choose where the list comes from, on the instance form (one of the two, never both):

  • Use Experimental Functionality - queries ShipHero's experimental API for the account's carrier catalogue with display names. ShipHero only enables the experimental schema on some accounts; if Fetch Carriers fails with an HTTP error, use the other source.
  • Use Historical Orders (default) - sweeps the shipping labels of orders already despatched on the account and compiles the distinct carrier/service pairs actually used. Works on every account. Because this list reflects real shipments, any pair auto-mapping cannot match gets an Odoo delivery method created and linked automatically (named with the friendly-name rules above).

Auto-Map Carriers matches unmapped lines against your existing Odoo delivery methods by name: an exact name match wins, then a shared well-known carrier (the connector recognises Royal Mail, Parcelforce, DPD, Evri/Hermes, Yodel, DHL, UPS, FedEx, TNT and USPS under their common spellings), then plain name containment. If the machine code finds nothing, the fetched Carrier Name is tried the same way. Anything with no plausible match is left unmapped and listed in the instance chatter - auto-mapping never guesses wildly. Re-run it any time from the Carriers tab.

Tracking links. For every mapped delivery method, auto-mapping also checks Odoo's native Tracking Link field on the method: if it is empty and the carrier is well known, the canonical tracking URL is filled in (so the Track button on deliveries and the customer portal works immediately); if you have set your own link that differs from the known default, it is left untouched and flagged in the chatter for you to verify.

If the 3PL despatches with a service you have not mapped, behaviour follows the Auto-create Delivery Methods setting: fail with a clear retryable error, or create the method and mapping automatically (recognised carriers get their tracking link at creation).

Shipping Product. Every delivery method the connector creates carries a service product. Set the instance's Shipping Product to control which one - a single shipping product serves any number of delivery methods. If left empty the connector falls back to Odoo's shared default delivery product; note that shared product cannot be restricted to one company once it has been used in orders of another company, so multi-company databases should set a per-company Shipping Product on each instance.