PunchOut Procurement

How PunchOut Works

PunchOut lets a buyer shop a supplier's own catalogue from inside a purchasing document, and have the basket come back as lines on that document.

You are the buyer here. Nothing in PunchOut hosts a catalogue for anybody else and nothing here touches the storefront — this is about buying from suppliers, not selling.

Where to find it

Architect Panel → ERP - Setup:

• PunchOut Suppliers — the console — suppliers, sessions and returned baskets
• Documents — the requisition or order the basket returns into
• Document Types — the document type a session defaults to

The problem it solves

Supplier catalogues are large, change constantly, and are priced under a contract. Importing one into your own system means maintaining a copy that is out of date the day after it lands, and pricing that quietly diverges from what you have agreed.

PunchOut inverts it. You keep no catalogue. The buyer shops the supplier's live site, which already knows the contract prices, and only the chosen items come back.

What a buyer sees

1. They open a requisition and choose a PunchOut supplier.
2. The supplier's catalogue opens, already logged in and showing your negotiated prices.
3. They add items to a basket in the supplier's own interface.
4. They check out — which does not place an order, but returns the basket.
5. The items appear as lines on the requisition, ready for the normal approval route.

The point that surprises people: checking out on the supplier's site orders nothing. It hands the basket back for approval on your side.

What comes back on a line

Each returned line carries the supplier's part number and auxiliary ID, the manufacturer's part number and name, description, quantity, unit price, currency, unit of measure, a classification code, lead time, and any contract or quote reference.

Those part numbers matter. An order quoting the supplier's own part number is one their system can process without interpretation — which removes the commonest source of wrong deliveries.

Lines are mapped to your items

A returned line can be matched to your own item record, so a purchase feeds stock and reporting normally rather than being a free-text line. Mapping accumulates: map a part once and subsequent baskets recognise it.

Two dialects

Suppliers use one of two conventions — cXML, the more common, and SAP OCI. Both are supported and the difference is handled per supplier. You need to know which one your supplier uses; they will tell you, and it is in their integration guide.

Sessions

Each punch-out creates a session with its own state, recording who opened it, which document it belongs to, when it was opened, what came back, and when it was applied. A session expires, so an abandoned basket does not stay open indefinitely.

Worked example

An engineer raising a requisition for consumables punches out to the stationery supplier, adds nine items, and checks out. Nine lines appear on the requisition with the supplier's part numbers, contract prices and lead times. Their manager approves it, and the approved order goes back to the supplier electronically — with no rekeying and no catalogue to maintain.

Recommendations

• Confirm the dialect with the supplier before configuring.
• Map returned lines to your items so purchases reach stock and reporting.
• Explain that checkout returns a basket — buyers expect it to place the order.
• Start with one supplier and prove the round trip before adding more.

Configuring a PunchOut Supplier

Each supplier you punch out to needs a configuration row. The supplier provides most of the values in their integration guide.

Where to find it

Architect Panel → ERP - Setup:

• PunchOut Suppliers — the console — configure, test, monitor sessions

Architect Panel → Automation:

• Tasks — PunchOut Order Transmission every 15 minutes; PunchOut Session Expiry hourly

What to configure

• Supplier code and the counterparty record it binds to.
• Dialect — cXML or SAP OCI.
• Setup URL — where a session is opened.
• Order URL — where the approved order is sent.
• OCI method — for OCI suppliers, how the return is posted.
• Default document type — what a punch-out creates.
• Currency.
• Price tolerance — how much the returned price may differ from the reference before it is flagged.
• Session lifetime in minutes.
• Enabled and test mode.

Price tolerance

Returned prices are compared against your reference price and flagged when they differ by more than the tolerance.

This is the control that catches a supplier quietly moving off contract pricing. Set it tight enough to be meaningful — a percent or two covers rounding and small legitimate variation — and actually review what it flags. A tolerance set at 20% to stop the alerts is a tolerance that catches nothing.

Session lifetime

Sessions expire so an abandoned basket cannot be returned into a document hours later, when the requisition has moved on or the prices have changed.

Set it long enough for a real shopping trip — 60 to 120 minutes suits most — and short enough that stale returns are not possible. Too short and buyers lose baskets mid-order, which they will mention.

Test mode first

Suppliers provide a test endpoint. Configure in test mode, run a full round trip — open a session, build a basket, return it, apply it, approve the document and transmit the order — and confirm each step before enabling for real.

Test the whole loop, not just the punch-out. The return leg and the order transmission are where configuration errors surface, and they are the legs a buyer cannot work around.

The two background tasks

Both ship disabled and both are needed:

• PunchOut Order Transmission, every 15 minutes, sends approved orders to the supplier's order URL.
• PunchOut Session Expiry, hourly, closes sessions past their lifetime.

Without the first, approved orders sit unsent — which looks exactly like a working system right up until somebody asks where the delivery is. Enable both under Automation → Tasks when you go live.

Monitoring

Sessions move through opened, sent to supplier, cart returned, applied, and end as cancelled, expired or errored. Messages carry their own status — queued, sent, acknowledged, received, rejected by supplier, or failed.

Watch for rejected by supplier: it means the order reached them and they refused it, which is a different problem from a transmission failure and needs a person rather than a retry.

Worked example

A first supplier is configured in test mode with a 90-minute lifetime and a 2% price tolerance. The full loop is run twice, including a deliberately stale session to confirm expiry. Test mode is then turned off, both tasks are enabled, and the buying team is shown the round trip. A second supplier is added the following month using the same pattern.

Recommendations

• Enable both tasks — unsent orders are silent failures.
• Keep the price tolerance tight and review what it flags.
• Test the whole round trip, including order transmission.
• Investigate supplier rejections individually rather than retrying.