3PL & External WMS Connector

Once fulfilment moves to a third-party logistics provider, F&O stops being the system that knows where the stock physically is. Reality lives in somebody else's warehouse management system, and the only thing keeping your inventory accurate, your customers informed and your month-end defensible is the quality of the message traffic between the two. Most teams start with a spreadsheet and an SFTP folder. That holds up until the 3PL short-ships an order, adjusts a cycle count, or sends the same shipment confirmation twice — and nobody can prove what was sent, when it was sent, or why F&O and the warehouse disagree by forty units on a fast-moving item.

This connector is built to order. There is no pre-built package to download and no instant activation. ECOSIRE builds it against the specification your actual 3PL publishes, on the transport they actually support, mapped to the way your F&O implementation is actually configured — then installs it in your sandbox first and production second.

What ECOSIRE builds

### A message spine, not a pile of point-to-point scripts Every exchange in both directions passes through one message log built as an X++ table with its own maintenance form: correlation ID, trading partner, direction, message type, timestamp, full request and response payload, processing status, retry count, error text, and a link to the F&O record the message created or updated. From that form an operator can open the source document, read the raw payload, and reprocess a failed message without a developer. Idempotency keys are stored per inbound message so a repeated shipment confirmation cannot post a second packing slip against the same sales order line — the single most expensive failure mode in outsourced fulfilment.

### Outbound to the warehouse Outbound shipment instructions are generated from WHSShipmentTable and WHSLoadTable where you run advanced warehouse management, or directly from SalesTable and SalesLine where the items are not WHS-enabled — both patterns are supported because most catalogues are mixed. Inbound expectations are pushed as ASNs from purchase orders and from InventTransferTable transfer orders so the 3PL knows what is arriving, from whom, and against which reference. Item master synchronisation covers released products, product dimensions, unit of measure conversions, barcode setup, gross weight and any handling or hazard attributes the warehouse needs to store and pick correctly. Return authorisations are pushed with the RMA reference so an unexpected carton at the receiving dock can be matched instead of quarantined.

### Inbound from the warehouse Receipt confirmations post the purchase order product receipt through the item arrival journal, or through the ASN receipt path where advanced warehouse management is enabled. Shipment confirmations post the packing slip with the carrier, tracking number, package count and actual shipped quantities written back to the sales order line, so short shipments become visible in F&O immediately rather than at invoicing. Inventory adjustments and cycle count results create counting and adjustment journals in InventJournalTable with a reason code, ready for review and posting under your existing approval rules — the connector never silently changes your inventory value. Return receipts post against the RMA with a disposition code so restock, scrap and repair paths diverge correctly. Transfer order receipts close the loop on inter-warehouse movement.

### Whatever transport your 3PL actually offers We build for the integration the provider genuinely supports rather than the one we would prefer. That means REST and JSON against a custom X++ service class exposed through the F&O service endpoints and OData surface; Data management framework recurring integrations using the enqueue and dequeue endpoints for file-based exchange; or flat-file EDI over SFTP or AS2 covering the usual logistics set — X12 856 advance ship notice, 846 inventory advice, 940 warehouse shipping order, 943 and 944 stock transfer, 945 shipping advice and 947 inventory adjustment, or the EDIFACT equivalents such as DESADV and INVRPT. Where the provider offers more than one, we choose with you and document why.

### Mapping as configuration Field mapping between the provider's payload and F&O lives in configuration records against a trading partner profile, not in compiled logic. When the 3PL adds a field, changes a code list or renames an element, that is a change to a mapping record made by your team, not a code change, a rebuild and a deployment window. Each partner profile carries its own transport settings, credentials reference, warehouse-to-facility mapping and message enablement flags.

### Scheduling, failure handling and alerting All polling and dispatch runs under the batch framework using SysOperation service classes with configurable recurrence, concurrency limits and API throttling. Failed messages retry with backoff and then land in a dead-letter state that is visible, searchable and reprocessable rather than lost. Alerts fire by email or through workflow when a message fails repeatedly, when a message type stops arriving inside its expected window, or when an inventory variance crosses a threshold you set.

### Reconciliation you can run every morning A scheduled comparison takes the provider's inventory snapshot and compares it against InventSum in F&O by item, site, warehouse and tracking dimension. The output is a variance report with quantity and value impact, and approved lines can be turned into an adjustment journal for posting. This is the control that turns outsourced fulfilment from an act of faith into a managed process.

### Multiple providers, multiple legal entities Several 3PLs can run side by side, each with its own profile, transport and message set, each mapped to its own F&O warehouses, and everything scoped by legal entity so a shared instance does not cross-contaminate.

## Who it is for Distributors and manufacturers who have outsourced all or part of fulfilment and are reconciling by spreadsheet. E-commerce and wholesale operations running several fulfilment centres and needing one consistent integration pattern instead of one bespoke script per provider. Finance teams whose inventory valuation is being audited and who need a payload-level audit trail behind every adjustment.

## How delivery works 1. Scoping call. We collect the provider's integration specification, the message types you need in each direction, your WHS and non-WHS item split, the warehouses involved, volumes and the legal entities in scope. 2. Fixed quote. You get a written scope naming every message type, the transport, the mapping work and the reconciliation report. The price is fixed against that scope. 3. Build. Typical lead time is two to four weeks depending on message count and how many providers are in scope, with a checkpoint demo of the message log and one working round trip. 4. Install in test. The deployable package goes into your sandbox through your LCS pipeline, connected to the provider's test endpoint for end-to-end testing with real documents. 5. Production. Installed into production, profiles switched to live endpoints, batch schedule enabled, alerts routed to named owners. 6. Support window. An agreed post-go-live period covering defects and one mapping revision, because the first weeks of live traffic always surface a field somebody forgot to mention.

## Scope notes Everything is delivered as extensions — no overlayering, nothing that blocks a platform update. ECOSIRE does not operate your EDI VAN, does not own the provider's specification, and cannot commit the provider to a delivery date. Where the provider changes their contract after go-live, mapping-level changes are configuration; a genuine change to the API contract is quoted as a change request.