Set up a punchout
This is the setup for one punchout customer. A second customer means a second channel, a second assortment and a second punchout account. The order below is deliberate: the data comes before the connection, because that is where punchout projects lose their weeks.
1. Create the channel
- Go to Configuration › Channels and select New channel.
- Set a code you will recognise in a log a year from now:
punchout-acmerather thanchannel3. - Set the type to PunchOut.
- Assign the market. It carries the currency, the locales and the tax classes this buyer sees. A customer ordering in CHF needs a Swiss market, not a discount on a EUR price.
- Set Unassigned rows to Hidden until assigned (closed), so the channel shows only what you explicitly put in it.
2. Assortment, data and prices
Assign the agreed products to the channel, then 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.
Then make every article in the channel procurement-ready: a unit of measure their system accepts as a code, a manufacturer part number distinct from your own article number, a tax class, and a plain short description within their length limit. Completeness, filtered on this channel, gives you the work list.
Last, confirm that the customer's conditions resolve on this channel: contract prices, scale prices, currency. A punchout that shows list prices to a contract customer loses the project. See How pricing works.
3. Prepare the organisation
The punchout account points at the customer's organisation in the CRM, and at one of its contacts as the technical contact. Create both first. See Organizations.
4. Create the punchout account
Go to Procurement › Punchout › Accounts and select New punchout account.
| Field | What to enter |
|---|---|
| Code | A stable code. It appears in the entry URL, and a cost centre can be restricted to it. For IDS, it is the user name the trade software sends (name_kunde). |
| Protocol / Protocol version | OCI, cXML or IDS 2.5, and the version the customer's system announces. |
| Channel | The channel code from step 1. Mandatory: without it a punchout buyer gets the public shop's catalog and prices. |
| Entry URL | The storefront address the customer's system calls and where its buyers land. |
| Organisation / Technical contact | The customer, and the contact the session runs as when their system names nobody. |
| Unknown user | What happens when their system names a person you do not know: fall back to the technical contact, refuse the session, or create the contact. |
| Session lifetime (minutes) | How long a visit stays open. The default is 60. |
| Enabled | Leave it off for now. |
The credentials depend on the protocol:
| Protocol | Fields |
|---|---|
| OCI | Authenticates with (user name and password, or login token), Identity (USERNAME), then Password or Login token. Tick Secured OCI only if the customer's SAP is configured for the secured variant. |
| cXML | Identity, Identity domain (for example NetworkID or DUNS) and Shared secret, exactly as on the customer's sheet, including case. |
| IDS 2.5 | Identity (name_kunde, the same value as the code), Password (pw_kunde) and, if the wholesaler identifies the craftsman by customer number, IDS customer number (kndnr). |
Passwords, tokens and shared secrets are write-only. After saving, nobody can read them back; you can only replace them, and the customer's calls fail until their system has the new value.
5. Check the field mapping
Procurement › Punchout › Field mappings decides what goes back in the cart:
which of your values fills NEW_ITEM-MATNR, NEW_ITEM-UNIT and the rest for
OCI, or which node of the cXML or IDS document. A standard set ships for all
three protocols, so most accounts need nothing here. Add a row for this account
only where the customer's system deviates; an account's own row overrides the
standard one.
To see the result, use Preview payload on the account in the account list. It runs the account's mappings over a cart you name and shows what would be handed back, without recording or sending anything.
6. Prove the account, then enable it
Two row actions on the account list do this without the customer:
- Probe entry URL calls the account's entry address from outside and records what it found. By default an account can only be enabled once the probe reads reachable. That catches the storefront that answers every unknown address with its own start page while the customer's system gets nothing useful.
- Test entry call sends one entry call with the account's own credentials and shows the answer the customer's system would get. The visit it opens is revoked again; no cart and no transfer are created.
Then switch Enabled on.
7. Test against their real system
- Ask their technical contact to punch out from their test environment.
- Watch Sessions: the right account, the right contact, the right channel. If nothing appears, look in Refused entries. The customer's system only sees a neutral refusal; the reason (wrong credentials, account disabled, unknown account) is kept there.
- Have a buyer build a cart of at least three lines, including one with an awkward unit of measure, and transfer it.
- Open the transfer under Transfers and compare it with what arrived in their requisition, field by field.
Agree separately how the purchase order reaches you. The punchout ends with the hand-back; the order the customer's system creates afterwards does not come back through it.
What to check
- The buyer never sees a login screen.
- The article count in the punchout matches the contract, and prices match it, scale prices included.
- Every transferred line carries a unit of measure and a manufacturer part number.
- Refused entries stays empty once the customer is live. A row there means somebody's system is calling with the wrong credentials.
Next
- Field mapping: mapping in general.
- Connect customer procurement: the whole programme, beyond one account.