Connecting your WMS, TMS and ERP: one layer for EDI, API, files and email

Connecting your WMS, TMS and ERP means orders and transport bookings move between those systems on their own, without anyone retyping them, even when every party in the supply chain uses its own format. At a 3PL, a WMS integration is rarely one integration. One client sends orders over EDI, the next through an API from its web shop, a third emails an Excel file every morning. Connecting your systems then means getting all of those streams to land in one place, in one shape, without the next client turning into another project.

What is a WMS integration at a 3PL?

An integration is an agreement between two systems: which fields move across, in which format, how often, and what happens when something is wrong. A warehouse that works for a single company has a handful. At a 3PL, every new client adds one, and so does every carrier.

That is usually where it goes wrong. Each new client becomes a separate job: someone writes a translation from that client’s file into the WMS and switches it on after a few test orders. A few years later a whole stack of those translations is running side by side, each built slightly differently, and often only one person knows how they work. If one breaks while that person is on holiday, that client’s orders sit and wait.

What is the difference between EDI, API, files and email?

All four bring in the same order or transport booking. They differ in how tightly the format is fixed and in who starts the exchange.

EDI

EDI uses fixed messages in an agreed standard. The best known is EDIFACT, developed for the United Nations. Retail and logistics often use the EANCOM subset, for orders, delivery notes and invoices. Because the format is fixed, EDI is dependable. Even so, every partner fills in the standard a little differently, so each EDI client still has its own quirks.

API

An API is a door into a system through which another system can fetch or drop data whenever it needs to. Web shops and shipping software such as Shopify, WooCommerce, Picqer and Sendcloud all have one. The data is current. You do depend on what the vendor exposes, and on the access your client gives you.

Files

A CSV or Excel file dropped in a fixed location, often an SFTP server, once an hour or once a night. Simple, and still very common. The catch is that nobody guards the format. If a column shifts because someone at the client added one, the import goes wrong and nobody notices.

Email

An order typed into an email, or a PDF or Excel file attached to it. For a system this is the hardest, because there is no format at all, so someone in the office retypes it. This is the stream where AI does the most work. How reading such an email works is covered in orders from email into your WMS.

How does one layer stop a new client from being a new build?

By translating everything into one format of your own first, and only then sending it on to the WMS, TMS or ERP. The layer in between holds one translation per source. This client sends EDI with these quirks, that one leaves a CSV with these columns every night. What comes out is always the same order with the same fields.

When a new client arrives, the connection to the WMS already exists. You add a translation at the front and the rest of the chain stays as it is. If something goes wrong with that one source, the other clients are not affected.

The checks then live in one place too. An order with an unknown item number, a delivery address without a postcode or a quantity far outside the usual range does not slip into the WMS unseen. It goes to a queue, and someone on your team looks at it.

What does AI do in a WMS integration, and what does it not do?

Most of an integration is ordinary code: converting an EDI message, calling an API, reading a file. That has to happen exactly the same way every time. You do not need a language model for that, and you do not want one there, because a model does not give the same answer every time.

A model only comes in where there is no fixed format: the email that has an order in its text, the PDF every client lays out differently, or the Excel file a client changed on its own. The model reads it, pulls out the order lines and states for each field how sure it is. Anything below the threshold goes to a person. When you connect a new source, a model can propose how the columns of an unfamiliar file map onto your own format. Someone approves that proposal before it runs.

The system never changes an order or smooths over a discrepancy without anyone seeing it. Every change records where it came from.

Why build in the seam instead of replacing the WMS?

The WMS is usually not the problem. The manual work sits between the WMS and the individual client: retyping, converting files, chasing an order that never arrived. A new WMS changes none of that. Clients will still send their own files, in their own way.

Replacing a WMS means a migration, new processes on the floor and a team that has to relearn its job. We build into the WMS and the admin systems you already run. Your people work in the same screen as yesterday, except the orders are already in it.

When a package is the better choice is covered in bespoke or off the shelf software.

What access does a builder need?

As little as possible, and read only at first. For the first step, an account with read rights on the WMS is often enough, or an export. That shows us what your orders and items look like, without us being able to change anything.

Write rights come later, and only for what the system has to do. If it places orders in the WMS, it may create orders and nothing else. Each source needs its own access as well: the folder or service where EDI messages arrive, an API key per platform and a mailbox the order emails go to. You grant that access yourself, and you can revoke it yourself.

What is a read layer over an old system?

Some warehouses run on a system without an API, or on a version nobody dares to touch any more. In that case we build a read layer. At fixed times we fetch a copy of the data, from the database or from an export. It is only ever read from, never written to, so the old system stays exactly as it is.

On that copy you can check and compare without risk, for instance which work was carried out but never invoiced. How that check works is in work that never made it onto an invoice.

Which approach fits which source?

Run your clients and carriers through this test one by one. If a source sends EDI, you build a fixed translation with its own quirks in it, without a language model. If it has an API, you fetch the data with the access your client gives you. If it drops a file, you also check the shape on every delivery, so a shifted column stands out. If it emails text or a PDF, a model reads the order and anything below the threshold goes to a person.

Start with the stream that costs the most manual work right now. Often that means the orders arriving by email or as PDFs, because they are retyped by hand. We build that one stream first. Beforehand we write down what it has to do and measure how things run today. Only once it works does the next source come in.

That way the layer grows with your clients and nothing has to be designed up front. The steps are set out in how we work. Where else AI fits in a warehouse is covered in AI in the warehouse.

Line up your own sources that way and we will look at them together in an introductory call.