Why punchout needs a mapping layer

On paper, a basket is simple: some items, quantities and prices. In practice, every buyer’s procurement system describes it a little differently, and that is where punchout projects get slow.

What typically differs

• Units of measure. Your shop says “box”; the buyer expects a coded unit such as BX or PCE.
• Classification. Many buyers require a commodity code on each line, often UNSPSC.
• Item identifiers. Your article number, the buyer’s material number and the manufacturer’s part number are three different fields.
• Currency and tax. Prices in AED, a tax rate per line, or net versus gross.
• Text fields. Maximum lengths, forbidden characters, language.
• Format. cXML for one buyer, OCI for another.

Two ways to handle it

In the shop. You add buyer-specific code to your shop for each buyer. It works for the first buyer. By the third, the shop contains if buyer == ... branches, and every shop update risks breaking a punchout connection.

In a mapping layer. Your shop produces one clean internal basket. A separate layer holds the rules per buyer: this field goes there, this unit becomes that code, this format is cXML. Adding a buyer means adding a mapping, not changing the shop.

What a good mapping layer gives you

1. One place to look when a buyer reports a wrong unit or a missing field.
2. A test mode. You can replay a basket and see the exact cXML or OCI that would be returned.
3. Independence. You can replace or upgrade your shop without redoing every buyer integration.

This is the idea behind our punchout middleware: you keep the shop you have, and the differences between buyers live in one maintained place.