Punchout explained

At some point a procurement lead at one of your large customers tells your Innendienst that from January, orders will come through Coupa, and asks whether you support punchout. The honest translation of that question is: can we keep buying from you without anyone having to leave our system? If the answer is no, the contract moves.

What punchout is

Punchout is a connection between your customer's procurement system and your shop. Look at it from the buyer's side, because that is the side that matters.

A buyer at a company with a few thousand employees does not open a browser and search for suppliers. They open SAP Ariba, Coupa, JAGGAER, Onventis or the purchasing module of their SAP ERP, because that is where their budget, their cost centres and their approval workflow live. There they see a list of approved suppliers, and they click yours.

At that moment the procurement system "punches out": it opens your shop, in a frame or a new window, and the buyer is already logged in. The identity came across in the call, so nobody types a password. They see the assortment their company negotiated, at their contract prices, with your live stock figures. They search, compare, and fill a cart the way they would in any shop.

Then, instead of checking out, they transfer the cart. It is handed back into the procurement system as a requisition, the BANF of the SAP world. Approval, cost-centre assignment, budget check and the purchase order all happen there. The purchase order reaches you afterwards, as a message of its own, on whatever path you and the customer agreed for orders.

The buyer never left their system. From their point of view, your catalog is a feature of Coupa.

Why large customers insist on it

Purchasing organisations above a certain size have one goal: see all spend in one place and steer it onto suppliers with negotiated contracts. They bought a procurement system to enforce that, and every order placed outside it is spend they cannot see, on terms they did not negotiate.

The consequence for you is hard. A supplier reachable from inside the system is on the standard path. A supplier who is not becomes an exception somebody handles by hand: a PDF quote, a manual requisition, an email to the Einkauf. Exceptions get cleaned up. Over one or two purchasing cycles a supplier without punchout is designed out, and it is rarely announced as a decision about you.

This is why most punchout projects are defensive ones, with a date attached.

The three standards

Three appear in practice. Your customer decides which one you need: it follows from the procurement system they already run.

OCI is deliberately simple. The catalog data comes back as ordinary HTML form fields: NEW_ITEM-DESCRIPTION[1], NEW_ITEM-MATNR[1], NEW_ITEM-QUANTITY[1], NEW_ITEM-UNIT[1], NEW_ITEM-PRICE[1], NEW_ITEM-CURRENCY[1], NEW_ITEM-VENDORMAT[1], NEW_ITEM-MANUFACTMAT[1]. That simplicity is why it spread, and also why nearly every SAP customer has their own small deviation from it.

cXML carries more: supplier part numbers with an auxiliary ID, classification codes, unit-of-measure codes from UN/CEFACT Recommendation 20 (C62 for piece, EA for each, MTR for metre), and a BuyerCookie that ties the session together.

IDS works differently from the other two because its users do. The trade software of a heating installer asks your shop by action code: WKE opens a shopping visit whose cart goes back into the software, WKS sends a cart into your shop (the installer drafted it in their software and wants your prices and availability on it), ADL jumps straight to one article and AS opens a search. Two more actions, LI and SV, let the software ask which credentials and which interface versions your shop expects before anybody has configured anything.

The round trip, step by step

1. Setup request. The procurement system calls your punchout endpoint with credentials: in OCI a URL with username and password parameters, in cXML a PunchOutSetupRequest carrying an identity and shared secret.
2. Session URL. You verify the credentials, resolve which customer this is, create a session and answer with a URL. In cXML that is a PunchOutSetupResponse containing a browserFormPost address; in OCI you redirect straight into the shop.
3. The buyer shops. Inside your storefront, in their session: their assortment, their prices, your live availability. This is the part that looks like a normal shop and is the reason punchout is worth having.
4. Cart transfer. The buyer transfers the cart. OCI posts the line items back as form fields; cXML posts a PunchOutOrderMessage. Either way, the cart crosses the boundary and your session ends.
5. Approval in their system. The lines become a requisition. Cost centres, budgets and approvers apply. Lines can be changed or deleted here, and often are.
6. Order transmission. The approved requisition becomes a purchase order and is sent to you as a cXML OrderRequest, an EDI message, a BME document or, more often than anyone admits, an email. This is a separate message from the punchout. Building steps 1–5 and forgetting step 6 leaves you with orders arriving as PDFs to be retyped, which was the problem you were solving.

Why punchout projects fail

Almost never on the protocol. The protocol is a week of work. These are the things that stop projects, roughly in order of how often they do it:

Prices. Customer-specific conditions live in the ERP, sometimes in a spreadsheet in the Vertrieb. If the shop cannot reach the same price the ERP would calculate, the punchout shows numbers that do not match the contract. Somebody notices on the first order, and it costs trust that took years to build. A punchout project starts at pricing, not at OCI.

Data quality. Procurement systems are stricter than a web page. Five fields cause most rejected lines:

These are catalog problems, not integration problems. Fix them in the catalog; see Measurements and units and Completeness and readiness.

Session and authentication handling. Credentials per customer, sessions that expire mid-basket, buyers who open two punchouts at once, a cart posted back to a system that has already timed out. Unglamorous and responsible for most of the support tickets in year one.

Testing against the real system. Your endpoint validating against your own test harness proves very little; every procurement installation is customised. Test against the customer's system, with their credentials and their buyer, before you call it live. That test needs a slot in their IT queue, which is a schedule risk you do not control. Do not promise a go-live date before the slot exists.

The assortment is customer-specific. A punchout is a contract, and the contract names a range. Showing your whole catalog to a punchout buyer breaks what was agreed, and it exposes articles and prices that were never negotiated for them.

What punchout replaces

The alternative is static catalog exchange: you export your range as a BMEcat file or an Excel sheet, the customer imports it into their system, and their buyers shop from that copy.

Static catalogs are still normal for small ranges and for customers whose system cannot punch out. But every cycle is manual work on both sides, and between cycles the data is wrong. Punchout removes the cycle.

How this works in the Revenue Cloud

Two parts work together: a channel decides what the buyer sees, and a punchout account decides who may come in and what goes back out.

The channel carries the assortment and the presentation:

• In Configuration › Channels you create a channel with type PunchOut and your own code — punchout-acme for one customer, punchout-konzern-x for the next. One channel per punchout customer is the normal setup, because the assortment and the presentation differ per contract.
• Each channel belongs to a market, which carries the currency, the locales and the tax classes that apply. See Languages and markets.
• Unassigned rows decides the visibility policy; in the channel detail the setting reads Products with no assignment to this channel are. Set it to Hidden until assigned (closed) on a punchout channel and only products explicitly assigned to it appear, which is what a punchout contract describes. Your storefront channel can stay open at the same time.
• Attributes that are scopable can hold a different value per channel, so the short, plain description a procurement system needs is not the marketing prose your shop shows. See Channels, locales and completeness.
• Completeness is calculated per channel, so you can ask the only question that matters before go-live: how many of the 2,400 articles in this punchout channel carry a unit of measure, a manufacturer part number and a tax class?

The punchout account lives under Procurement › Punchout, one per external system:

A transfer is not an order. It reserves no stock and books nothing. It is the record of what you handed over, which is what you need when the customer's purchasing department asks why line four arrived without a unit.

Next

• Set up a punchout — the connection, step by step.
• Field mapping — turning your fields into theirs.