When a shipment goes wrong the blame almost always ends up on the warehouse or the courier. In most cases the problem lies further upstream: two systems both convinced they decide the same thing, or neither of the two deciding it. An ecommerce integration project is therefore set up starting from who decides what.
What follows is intended for those who have to define the architecture before an ERP, OMS or WMS project, or before a replatforming. It is not the description of a solution but a list of decisions, put in the order in which they arise. It also applies when part of the chain is external: those who have entrusted the warehouse to an e-commerce fulfillment provider have the WMS outside their own perimeter, and the boundaries must be defined with more precision.
The map of the systems and the responsibilities
In the shipping cycle of a structured ecommerce at least five systems are involved, and for each it is worth writing what it decides and what it merely transports.
The webshop, or the marketplace, collects the order and shows the customer the delivery options with their promise, but it is not there that the carrier is chosen. The ERP oversees master data, prices, fiscal documents and accounting: however much it is the most stable system in the company, the shipping routing logic does not belong to it. The OMS orchestrates the order, so it checks availability, decides from which node to fulfill, manages splits and priorities and maintains the commercial status.
Un software WMS governa il magazzino fisico, e quindi ubicazioni, picking, imballaggio, peso e dimensioni reali del collo. La piattaforma di spedizione, per ultima, applica le regole di assegnazione del vettore, crea la spedizione, genera l’etichetta e riporta gli stati di tracking a un formato comune.
The criterion for checking the map is easy to state and hard to respect: every piece of data has a single owning system, the others read it. Where two systems can write the same field, a discrepancy is created that goes unnoticed as long as volumes stay low.
The main data flows of the shipping cycle
Once the responsibilities are defined you move on to the flows. There are five, and it is worth putting them on paper before opening an editor. Those who work with an ecommerce logistics partner should draw them together with the provider, because two of the five flows cross the boundary between the two companies.
Proposal of the delivery services at checkout
The webshop must show only the options actually available for that cart, that destination and that moment of the day. Into play come the availability of the goods, the node from which the order will leave, the cut-off and the services active in the destination country. It is the most delicate flow, because a promise displayed at checkout and not supported by the downstream systems does not generate a delay but a complaint.
Carrier assignment and ecommerce courier integration
The choice of carrier must be made on definitive data, that is after the warehouse has confirmed real weight and dimensions. Assigning the courier on the theoretical catalogue weight generates rate differences and shipments rejected at creation, with manual recovery downstream. In an ecommerce courier integration project the assignment rule must sit in a single point: duplicating it between OMS and shipping platform leaves two truths and no way of knowing which of the two decided.
Creazione della spedizione
Alla creazione il sistema riceve dal vettore l’identificativo e i dati di ritiro. Nella pratica capitano tutte e tre le situazioni che di solito vengono considerate marginali: la chiamata che non torna, la spedizione creata due volte per un doppio invio, la chiusura quando nella stessa giornata sono previsti più ritiri. Se non le gestisce il sistema le gestisce una persona, a mano, quando ha meno tempo per farlo.
Label generation
Without a label the parcel does not leave, and this makes the printing flow the most rigid constraint of the whole chain. The format accepted by each carrier must be decided, the point of the line where printing happens, how you reprint after an error without duplicating the shipment, what the system does when the courier's service does not respond. A test on a few orders measures only the best case.
Tracking and exception management
The states must be translated into a single internal vocabulary, otherwise no report is comparable across carriers and every analysis goes back to being manual work. It must then be decided who speaks to the customer, on which channel and at which moments: when webshop, shipping platform and customer service send independent messages, the customer receives information that contradicts itself and calls. A Centralised shipment tracking serves first of all to avoid this.
Direct integration with the couriers or a shipping layer?
On this choice, what weighs most is who takes on the maintenance of the interface over time. With direct integration it is the internal team: every time a courier modifies a format or an endpoint, the fix enters the development queue and competes with commercial priorities. With a shipping layer that work passes to the provider, and the internal team maintains only one.
The point to clarify at the contractual stage concerns the data: which shipping and tracking information stays extractable, in which format and with what frequency. It is the element that determines how reversible the choice is and how far it is possible to build independent reporting.
On the operational level the layer also becomes the point where the management system and logistics exchange the information on the order status, without each courier having to be reached separately by both.
The role of OMS software in ecommerce management-system integration
In ecommerce management-system integration projects the OMS software is underestimated with a certain regularity, because its functions end up distributed between ERP and webshop without an explicit decision. From there two consequences arise: the choice of the fulfillment node is taken by a system that does not see all the stock, and the splitting of orders rests on makeshift solutions that hold as long as volumes allow.
The OMS should remain the owner of the commercial status of the order and of the fulfillment decisions. To the WMS belong the physical ones, to the shipping platform those about the carrier. The advantage of this separation is seen the day something does not add up, because the perimeter in which to search is already defined.
Requirements of the shipping API, security and test environments
On the technical level the shipping API should guarantee some things regardless of the provider. Idempotency on the creation calls, so as not to generate duplicate shipments when a request is repeated. Explicit handling of timeouts and retries. Error messages that distinguish a problem in the data from a problem of service availability, because the operational reaction is different. Declared versioning, with reasonable notice on non-backward-compatible changes.
On security you need separate credentials per environment, key rotation, traceability of who generated each shipment and attention to personal data in the addresses. A test environment separate from production is the condition for trying a change without generating real shipments, and it must be required also of the party providing the shipping service, not only of the internal departments.
The UAT and cut-over checklist before the peak
Il collaudo si costruisce sui casi che si rompono. Vale la pena provare un ordine multi-riga che si divide su nodi diversi e produce due spedizioni, un peso rilevato in magazzino diverso da quello di catalogo, un corriere non raggiungibile nel momento della creazione, un’etichetta da ristampare senza duplicare la spedizione, un indirizzo che il vettore non valida, un annullamento arrivato dopo la creazione ma prima del ritiro, un reso avviato su una spedizione già tracciata, una chiusura con due ritiri nella stessa giornata.
On the cut-over you need a freeze window agreed with all the departments, a rollback plan written and tested at least once, and a go-live date far enough from the peak to have a few weeks of real operation before the high volumes. Those who go into production in November on a new shipping flow find themselves doing debugging and the season together.
When the architecture turns out more complex than the team can oversee, the conversation shifts to which components to keep inside. Among the logistics solutions there are different degrees of delegation, and the variable that guides the choice is how many people can be dedicated to maintaining the integrations over the course of the year, not only during the project.