Understanding the flow
From procurement to approved order
- 1
Buyer system
Launch shopping session
- 2
Supplier catalogue
Approved assortment
- 3
Cart return
OCI or cXML payload
- 4
Buyer approval
Order placed after review
Simplified teaching diagram. Steps and technical choices depend on the context; this is not a delivered client architecture.
The customer request looks simple
A large account wants to find its supplier's catalogue from its procurement tool or ERP. The buyer browses an authorised selection, builds a cart, then returns to the original system to follow approvals and place the order. That pattern is known as PunchOut.
For the supplier, this is not an ordinary e-commerce site. The information must respect an exchange contract, a purchasing context, catalogue rules and sometimes commercial conditions specific to each organisation.
Start with the business, then the protocol
In professional work on large-account B2B exchanges, the real subjects are not limited to displaying products. Who identifies the buyer, which catalogue they are allowed to see, how prices and stock are obtained, and what is returned to the procurement tool all have to be determined.
Depending on the ecosystem, OCI and cXML can take part in these exchanges. They do not by themselves resolve mappings of references, units of measure, pack sizes, classifications or supply constraints.
The journey that has to be made robust
The customer's purchasing system opens a contextualised PunchOut session. The supplier checks access and exposes authorised products, fed by its catalogue and management systems. On the way back, the cart is retransmitted in the agreed format, with the fields expected for the customer's internal approval.
A returned cart does not necessarily mean the supplier has received an order. Depending on the process, the order only exists after approval in the customer's ERP or procurement tool. Confusing those two steps creates serious operational errors.
Less visible cases also have to be planned: expired session, item that has become unavailable, pack-size change, non-matching price, missing data or an incomplete cart return.
Design a reusable core for several large accounts
Building an entirely different integration for each customer increases technical debt. A more durable architecture separates the catalogue and cart core from OCI or cXML adapters, visibility rules, mappings and the contractual specifics of each large account.
The model has to be validated on real flows. Tool names, mandatory fields and authentication mechanisms vary; no protocol guarantees interoperability without end-to-end tests.
What leadership has to decide
Who is responsible for incorrect information? What are the limits of price and stock synchronisation? Who actually triggers the order? Which evidence and logs make an incident understandable? Which interface contract allows a new customer to be onboarded without rewriting the platform?
Possible Mahthildis involvement
Paulo Castro can frame the purchasing and catalogue need, define APIs and mappings, challenge an integrator, lead delivery and take on agreed technical components. The objective is not only to open a catalogue. It is to make the B2B purchasing process between two organisations reliable.
PunchOut is neither a shop window nor a simple “order” button. It is an inter-company process to secure, from purchasing context through to cart return.
About these field situations
These situations combine lessons from Paulo Castro's professional experience. Organisations and operational details are not identified. They illustrate issues and possible approaches, not a claim that all suggested solutions were delivered together or that they are Mahthildis client references.
