Inbound Orders and Pricing

Cart return and order creation are separate steps. Return to System sends the selected products back to the procurement platform. After its own approval process, that platform can submit a cXML OrderRequest to Magento.

Choose the processing mode

Configure the default under Stores > Configuration > MageB2B > Punchout > Inbound Orders. A buyer profile can override the Store-view value.

The inbound-order grid records the effective mode with the request. This matters when one buyer overrides a Store-view default.

Preserve the BuyerCookie

The procurement system chooses the opaque BuyerCookie during PunchOutSetupRequest. Magento returns the same value in PunchOutOrderMessage and stores a returned-cart snapshot against it.

For later snapshot-based pricing, the approved OrderRequest must return that value in OrderRequestHeader:

<Extrinsic name="BuyerCookie">buyer-provided-opaque-value</Extrinsic>

The snapshot is bound to the original buyer profile, Magento customer, Store view and currency. A BuyerCookie from another buyer or shopping context is rejected. Set Returned Cart Snapshot Retention longer than the customer's longest approval cycle.

Select the price authority

The hybrid option is the normal choice when approval may take days or weeks. It preserves the price Magento originally returned without trusting changed order content.

The four sources are not a merge of arbitrary values. The selected source defines the authoritative unit price for each line; the mismatch action then decides what to do when the submitted price differs. The hybrid source is the only source that branches on line identity: an unchanged SKU/quantity/configuration can use the immutable returned snapshot, while a changed quantity or new line goes through the current Magento quote calculation.

Compare the approved lines

With snapshot or hybrid pricing, Magento matches each ItemOut by auxiliary ID and then SKU by default. SKU Only is available when the procurement platform does not preserve stable auxiliary IDs.

The remaining policies answer four separate questions:

• What happens when an approved quantity differs from the returned cart?
• May the buyer add a product after cart return?
• May the approved order omit a returned line?
• What happens when the snapshot is missing or expired?

Each case can recalculate, allow, reject or enter manual review where that choice is applicable. Do not select a permissive fallback until the procurement team has supplied a real example of that change.

The policy is evaluated in this order:

1. Magento authenticates the sender and resolves the effective buyer and Store view configuration.
2. For snapshot or hybrid pricing, Magento loads the immutable snapshot by the BuyerCookie and matches each line by auxiliary ID and SKU, or by SKU when that strategy is selected.
3. The configured actions handle a changed quantity, a new item and a removed returned item independently.
4. A missing or expired snapshot follows Use Current Magento Price, Manual Review or Reject. Manual approval changes only the review gate; it does not bypass product, address, shipping, payment or total validation.
5. Magento applies the selected price source and mismatch tolerance, then runs the processing mode.

For Returned Quote Snapshot, a new item or a changed line is rejected because every submitted line must exist in the snapshot. For the hybrid policy, unchanged lines use the captured value and changed or new lines use current Magento pricing unless the configured action sends the request to review or rejects it. For Current Magento Pricing and Incoming Order Prices, snapshot matching is still available for line metadata, but it does not make the snapshot price authoritative.

Validate prices and totals

Magento compares the submitted unit price with the selected authoritative price. A difference is accepted when either the absolute or percentage tolerance allows it. The mismatch action can reject the order, send it to manual review, log and continue, or ignore the difference.

Quote creation still uses Magento's customer, product, address, shipping, payment, tax and inventory rules. Price tolerance does not bypass those checks.

The session tax_mode decides which completed Magento quote value is sent back. NET uses Magento's calculation price. GROSS uses Magento's price including tax. Magento still calculates taxes and totals from the Store view, customer, addresses, tax classes and installed pricing or tax extensions.

Preserve product options and line data

The returned-cart snapshot stores Magento's safe buy-request data for configurable products, custom options, bundles and downloadable links. Every returned line receives an opaque SupplierPartAuxiliaryID, so Magento can distinguish equal SKUs with different configurations when the approved OrderRequest arrives.

The OrderRequest quantity remains authoritative. Magento validates and stores each external line number and UnitOfMeasure on the quote and order item. Confirmation, shipment and invoice documents reuse those values. Configurable and bundle children are reconciled through their visible parent line; Magento rejects inconsistent partial quantities or invoice amounts instead of sending misleading document data.

Resolve the Magento context

• Customer Resolution follows the buyer profile: guest, fixed Magento customer, e-mail mapping, or an optional/required request customer ID. E-mail mapping can provision a missing account when JIT is enabled.
• Product Resolution treats SupplierPartID or SupplierPartAuxiliaryID as the Magento product reference.
• Address Source uses incoming ShipTo and BillTo values or the customer's default addresses.
• Shipping Method must be available for the resolved quote and destination.
• Payment Method defaults to the included PunchOut Purchase Order method.

When Create Magento Order is active, empty or unavailable shipping and payment choices stop order creation.

Updates, cancellations and manual review

OrderRequestHeader@type selects new, update or delete.

• Updates can enter manual review, be rejected, or cancel and recreate the Magento order.
• Cancellations can enter manual review, be rejected, or cancel the linked Magento order.
• A request held for review appears in Stores > Punchout > Inbound Orders. Authorized administrators can inspect the normalized payload and then process or reject it.

Use a new orderVersion for a genuine revision. An exact network retry keeps the same PO identity, request body and X-Punchout-Request-Key; Magento returns the existing result instead of creating a duplicate.

An update is a business revision, not a transport retry. The supported automatic update policy is Cancel and Recreate; it uses a recoverable replacement-order workflow so an interrupted update does not silently lose the original order or create an untracked duplicate. Manual Review and Reject keep the existing order untouched. A delete follows its separate cancellation policy and can be manually reviewed, rejected or cancel the linked Magento order.

The replacement workflow records the original order, the replacement attempt and the resulting inbound-order state. If a worker stops between cancellation and replacement, the record remains available for an authorized retry instead of starting an unrelated order. A transport retry of the same request still uses the original idempotency key and replays the stored result; a new order revision needs a new orderVersion and a new semantic request key.

Find the resulting records

The inbound-order detail preserves the buyer, external PO, revision, operation, Store view, customer, working quote, original PunchOut quote, context, cXML payload ID and Magento order ID. The technical payload section contains sanitized copies of the original request, normalized order and processing response.

After order creation, open the linked record under Sales > Orders to verify the customer PO number, customer, addresses, PunchOut payment method, products and totals.