Field-level descartes data mapping for Descartes Shipments → Fusion Order Management, BOLs → Fusion Inbound Logistics, Customs entries → Fusion GTM, EDI 850/810/856/214 → Fusion B2B Messaging. Pre-built crosswalk library covers 80%+ of typical translations; only the customer-specific 20% needs configuration.
Descartes is an acquisition-assembled platform: GLN, MacroPoint, Aljex, Customs Info, ShipRush, Datamyne, OneView. Each product has its own data model, its own field naming conventions, its own master-data structure. Mapping every field by hand is what eats 4–6 months of a consultant-led project.
Descartes' data model is shipment-centric: a single shipment record carries header, lines, BOL reference, tracking events, freight charges, customs context and document attachments. Oracle Fusion's SCM/TMS/GTM model is normalized: Shipment Header, Shipment Lines, Distribution lines, Carrier master, Lane master, Rate-Card master, Trade Transaction (GTM), Receiving Transaction (Inbound Logistics) and Attachments are all separate entities with referential integrity. Translating one model to the other isn't a JSON rename — it's a structural decomposition with master-data crosswalks at every join.
Syntra ETL's descartes data mapping engine ships with a governed crosswalk library: carrier code mapping, lane definition translation, HTS classification routing, customer master deduplication, accessorial-charge rule mapping, fuel-surcharge formula conversion, EDI qualifier/ID preservation. The library is refined across every Syntra ETL Descartes-to-Fusion migration, so 80%+ of typical translations are pre-built. The customer-specific 20% — customer master overrides, custom accessorial codes, niche EDI partner qualifiers — is configured by the team in weeks 2–4 of the mapping phase.
The output of the descartes data mapping phase is a signed crosswalk specification reviewed by logistics ops, customs broker, finance and IT integration leads. That spec is the input to the transform-and-validate phase, and the source of truth for every Fusion validation error message in the load phase. Without the spec, debugging a load failure in week 8 of the migration becomes a multi-day archaeology project.
Every mapping ships pre-built. Configure only the customer-specific overrides; trust the rest.
Descartes shipment_id, origin, destination, carrier, lane, ship-date, ETA → Fusion OM Shipment fields with carrier code remapped through crosswalk, lane resolved against Fusion TMS lane master, original Descartes shipment_id preserved as DESCARTES_REF attribute.
Descartes shipment line_id, item, quantity, weight, dimensions, declared value, HTS classification → Fusion OM Shipment Line with item resolved against Fusion Item Master, HTS classification routed through Fusion HS classification master.
Descartes BOL number, origin, destination, accessorial charges, BOL image attachment → Fusion Inbound Logistics Receiving Transaction linked to PO/transfer order, with BOL document bound via FBDI attachment metadata.
Descartes ACE entry number, ISF transaction ID, HTS classification, declared value, country-of-origin, bond reference → Fusion GTM Trade Transaction with full CBP audit chain preserved.
EDI message body archived with full envelope context (sender/receiver IDs, qualifiers, ISA/GS control numbers); trading-partner registry re-pointed to Fusion B2B Messaging with matching qualifier/ID metadata.
Descartes carrier rate card (base rate, accessorial, fuel-surcharge formula, tier breakpoints) → Fusion TMS Rate Master with carrier code remapped, accessorial rule names translated, full version history preserved.
3–4 weeks from pre-built crosswalk activation to signed-off mapping specification. Compare to 4–6 months on a hand-built project.
Syntra ETL's governed crosswalk library activated against the customer Descartes tenant: carrier code crosswalk, lane definition master, HTS classification routing, accessorial-charge rule mapping, fuel-surcharge formula conversion, EDI qualifier preservation. 80%+ of translations covered immediately.
Logistics ops team walks the pre-built crosswalk, flags customer-specific overrides (carrier code mismatches, accessorial codes unique to the business, lane definitions not in the standard master). Overrides applied to the descartes data mapping spec with sign-off trail.
Customer and shipper master deduplicated across GLN, Aljex, Customs Info and ShipRush. Fuzzy matching on name, address normalization, tax-ID matching, human-in-the-loop review for ambiguous cases. Deduplicated master prepared for FBDI Trading Community Import.
Final descartes data mapping spec reviewed by logistics ops, customs broker, finance/AP and IT integration leads. Test loads run against Fusion sandbox to validate mapping correctness. Signed spec becomes input to the transform-and-validate phase.
Mapping is structural translation, not deletion. Every Descartes identifier survives the migration as a cross-reference attribute on the Fusion record.
Every Fusion OM Shipment carries the original Descartes shipment_id as DESCARTES_REF — so a freight claim that references the 2023 Descartes shipment ID still finds the record in Fusion in 2026.
Every Fusion Receiving Transaction carries the original Descartes BOL number — so a carrier-side freight audit that references the 2024 BOL number still resolves to the correct Fusion record.
Every Fusion GTM Trade Transaction carries the original CBP entry number, ISF transaction ID and bond reference — preserving the full audit chain for CBP 5-year post-entry retention.
Every archived EDI message preserves sender/receiver IDs, qualifiers and ISA/GS control numbers — so a trading-partner dispute over a 2023 EDI 850 PO can be resolved with full envelope evidence.
Every Fusion TMS rate-master carries effective/expiration dates and version sequence — so a 2023 freight charge can be defended against the exact 2023 contract rate active at the time of shipment.
Every document image preserves the original Descartes document-id as cross-reference — so a CBP audit retrieval that references the 2022 document-id still resolves to the correct image.
Descartes data mapping is the field-level translation layer between Descartes' shipment-centric, acquisition-assembled data model (Global Logistics Network shipments, MacroPoint visibility events, Aljex freight broker bookings, Customs Info filings, ShipRush small-parcel manifests) and Oracle Fusion's unified SCM/TMS/GTM model (Shipments, Lines, Tracking Events, Carriers, Customs Entries, Trading Community). Syntra ETL ships pre-built descartes data mapping rules: Descartes Shipment Header → Fusion Order Management Shipment, Descartes BOL → Fusion Inbound Logistics, Descartes Customs Entry → Fusion GTM record, EDI 850/810/856/214 → Fusion B2B Messaging equivalents. These mappings get refined across every Syntra ETL descartes migration and ship as a governed crosswalk library — not a 4-month bespoke development engagement.
Descartes shipments carry a denormalized record structure: header, lines, BOL reference, tracking events, freight charges, customs context — all attached to a single shipment ID. Fusion Order Management splits this into Shipment Header, Shipment Lines, Distribution lines and Attachments, with separate references to Carrier, Lane and Rate-Card master. Syntra ETL's descartes data mapping walks each Descartes shipment, decomposes the structure into Fusion-compliant components, maps carrier codes through the carrier crosswalk, resolves lane definitions against Fusion TMS lane master, links freight charges to AP invoice attachments, and emits FBDI Shipment Import payloads. The mapping preserves the original Descartes shipment ID as a cross-reference field for audit traceability.
Bills of Lading in Descartes are first-class objects with their own BOL number, origin/destination, carrier, accessorial-charge breakdown and document image attachment. Fusion Inbound Logistics models BOLs as Receiving Transactions linked to Purchase Orders or Transfer Orders, with carrier and freight charge context on the Shipment record. Syntra ETL's descartes data mapping walks every BOL, resolves the associated Descartes shipment, links to the corresponding Fusion PO or transfer order via shipment-line cross-reference, maps the BOL document image through FBDI attachment metadata, and emits the Receiving Transaction record. The BOL number itself is preserved as an attribute on the receiving transaction for audit and freight-claim defense.
Descartes Customs Info houses ACE entries, ISF filings, ACI declarations and HTS classifications as discrete records with CBP entry numbers, ISF transaction IDs, port-of-entry codes and bond references. Oracle Fusion Global Trade Management (GTM) models customs records as Trade Transactions with HS classification, country-of-origin, declared value and customs duty context. Syntra ETL's descartes data mapping walks every Customs Info record, maps HTS classifications to the Fusion HS classification master, preserves CBP entry numbers and ISF transaction IDs as cross-reference attributes, links to the corresponding Fusion Shipment record, and emits GTM Customs Entry Import payloads. The original Customs Info document images (commercial invoice, packing list, certificate of origin) are bound via FBDI attachment metadata.
EDI message mapping is structurally different from shipment data mapping because the messages aren't migrated as historical records into Fusion — they're either archived for audit (descartes data archive) or the trading-partner connection itself is re-pointed (Fusion B2B Messaging). Syntra ETL's descartes data mapping for EDI does two things: (1) for historical message archive, it preserves the raw EDI 850 PO / 810 invoice / 856 ASN / 214 shipment status / 944 warehouse receipt message body with full envelope context (sender/receiver IDs, qualifiers, ISA/GS control numbers) in the descartes data archive for 7-year audit retention, and (2) for live trading-partner re-pointing, it generates Fusion B2B Messaging endpoint configuration with matching qualifier/ID metadata so the trading partner sees no difference.
Yes. Carrier rate cards in Descartes (GLN parcel tariffs, Aljex freight broker rates, ShipRush FedEx/UPS/DHL rate cards) carry a complex structure: base rate per lane, accessorial charges (residential, lift-gate, hazmat, inside delivery), fuel-surcharge formulas, tier-pricing breakpoints by volume or weight, contract-effective and expiration dates. Fusion TMS rate-management has equivalent constructs with different field names and structure. Syntra ETL's descartes data mapping walks every rate card with its full version history, maps carrier codes through the carrier crosswalk, translates accessorial-charge rule names to Fusion TMS accessorial codes, converts fuel-surcharge formula syntax, and emits Fusion TMS Rate Import payloads. Version history is preserved so a 2023 freight charge can be defended against the 2023 contract rate in a 2026 dispute.
Customer and shipper master is one of the most fragmented data domains in any Descartes tenant because the same customer may exist as multiple records across GLN, Aljex, Customs Info and ShipRush — each with its own customer ID, address variations and contact preferences. Syntra ETL's descartes data mapping runs a master-data deduplication pass: fuzzy matching on customer name, address normalization through a postal-address service, tax-ID matching where available, and human-in-the-loop review for ambiguous cases. The deduplicated customer master is then emitted as FBDI Trading Community Import payloads with original Descartes customer IDs preserved as cross-reference attributes across every source product.
Pre-built crosswalk activation runs in week 1 of the migration. Customer-specific overrides — carrier code remapping, lane-master alignment, HTS classification cleanup, customer master deduplication review — typically consume weeks 2–4. The full descartes data mapping phase including stakeholder sign-off is 3–4 weeks on a Syntra ETL project versus 4–6 months on a consultant-led project where every mapping rule gets developed from scratch. The acceleration comes from the pre-built crosswalk library that already covers 80%+ of typical Descartes-to-Fusion translation rules — the team only configures the 20% that's customer-specific.
Book a 30-minute discovery call. We'll walk you through the pre-built crosswalk library, identify your likely customer-specific overrides, and give you a concrete mapping-phase timeline before the call ends.