Connect your systems

Set up a punchout

Create the channel, the assortment and the credentials for one customer's OCI or cXML connection, and test it against their real system.

This is the setup for one punchout customer. Punchout is set up per contract rather than once per platform: a second customer means a second channel, a second assortment and a second set of credentials.

Before you begin. Read Punchout explained if you have not. From the customer you need: which standard (OCI 4, OCI 5 or cXML), the name of their procurement system, a technical contact who can trigger a test call, and their test environment. From your side you need the agreed assortment and the agreed prices, both settled before you start.

1. Create the channel

  1. Go to Configuration › Channels.
  2. Select New channel.
  3. Set a code you will recognise in a log a year from now: punchout-acme rather than channel3. The code is what everything else scopes on.
  4. Set the type to PunchOut.
  5. Assign the market. The market carries the currency, the locales and the tax classes this buyer will see. A customer ordering in CHF needs a Swiss market, not a discount on a EUR price.
  6. Set Unassigned rows in this channel to Hidden until assigned. This is the important one: it means the channel shows only what you explicitly put in it.
If you leave that setting at Inherit while the tenant default is open, this punchout shows your entire catalog — every article and every price, including ones never negotiated with this customer. Close the channel before you hand over credentials.

2. Assign the assortment

Assign the agreed products to the channel. For a negotiated range this is normally a filtered selection from the product grid rather than a per-article click: a product group, a manufacturer, or the articles on the contract list.

Then check it from the other end: filter the product grid by this channel and count. If the contract says roughly 2,400 articles and you see 18,000, something is assigned that should not be.

3. Make the data procurement-ready

Procurement systems reject lines that a web page would happily render. Before going live, confirm for every article in this channel:

FieldRequirement
Unit of measurePresent, and a code their system accepts rather than free text
Order quantity step / packaging unitPresent, so 1 does not mean a pallet
Manufacturer part numberPresent and distinct from your own article number
Tax classSet, and correct for the market
Short descriptionPlain text, within their length limit

Use completeness filtered on this channel to produce the work list. This step is where punchout projects lose their weeks, so do it before the connection rather than during the test round.

4. Set the prices

The buyer must see the price their contract says. Confirm that the customer's conditions (contract prices, scale prices and currency) resolve for this channel before anyone external tests it. A punchout that shows list prices to a contract customer is the fastest way to lose the project. See How pricing works.

5. Create the connection and credentials

There is no single "Punchout" screen. A punchout is assembled from three pieces: the channel from step 1, a credential, and a connector or workflow that handles the round trip.

  1. Go to Integrations › Credentials and create a credential for this customer. Name it after the channel (punchout-acme) so a run log is readable. Put the shared secret or password in Integrations › Secrets and reference it.
    • For OCI, the customer's system calls you with a username and password in the call URL.
    • For cXML, you exchange an identity, a domain and a shared secret. Those values come from the customer's setup sheet and must match exactly, including case.
  2. Install or configure the punchout connector from Extend and Develop › Marketplace, or build the round trip as a workflow. It needs to know three things: the standard (OCI 4, OCI 5 or cXML), the channel from step 1, and the customer organisation this contract belongs to. That last link is what makes an incoming session resolve to the right assortment and the right prices.
  3. Set the session timeout. Ninety minutes is a reasonable default: long enough for a buyer to be interrupted, short enough to expire.
  4. Configure the cart return: for OCI the HOOK_URL their system supplies at call time, for cXML the PunchOutOrderMessage target. Check the field mapping for the returned lines: which of your fields fills NEW_ITEM-MATNR, NEW_ITEM-VENDORMAT, NEW_ITEM-UNIT and the rest.
  5. Configure the order transmission separately: a connector, or a workflow triggered by the order.placed event. The punchout hands over a cart; the purchase order arrives afterwards as its own message.
  6. Send the customer their setup URL and credentials, through a channel that is not plain email.

6. Test against their real system

Your own test call proves your endpoint answers. It proves nothing about their installation, which is customised.

  1. Ask their technical contact to punch out from their test environment.
  2. Watch the session resolve: correct customer, correct assortment, correct prices.
  3. Have a buyer, rather than an administrator, build a cart of at least three lines, including one with an awkward unit of measure.
  4. Transfer the cart and let them confirm what arrived in the requisition, field by field.
  5. Take the requisition all the way through approval to a purchase order, and confirm the order reaches you in the agreed format. The punchout and the order transmission are two different messages, and this step is the one that gets skipped.

What to check

  • The buyer never sees a login screen.
  • The article count in the punchout matches the contract.
  • Prices match the contract, including scale prices.
  • Every transferred line carries a unit of measure and a manufacturer part number.
  • The purchase order arrives and can be processed without retyping.

Next