This topic provides an overview of the cXML Purchase Order (OrderRequest) in conjunction with cXML specifications for BuyerQuest.

Overview

The BuyerQuest platform may be configured to transmit Purchase Orders in cXML to Suppliers. The necessary configuration is shown here, along with cXML specifications.

cXML Outbound Purchase Order Overview

cXML PO Method in Supplier Record

Settings for Purchase Order cXML Integration are found in the 'cXML PO Method' section of each supplier record. The supplier record can be accessed by going to Menu > Suppliers > Manage Suppliers and clicking on a specific supplier in the grid.

Supplier Must Return HTTP Response for Transmissions Received

Suppliers must return an HTTP response, including body, for every transmission they receive.

Successful transmissions require a 200 OK response. Transient errors require a 500 error reponse.

Server-side errors require a 400-level error response.

See below for a sample success response.

Purchase Order Outbound to Supplier - cXML Annotated Specification

An Excel version of the specification is included here:

POOutboundtoSupplier2022Mar10.xlsx

Purchase Order cXML Sections

A PO cXML message broadly consists of three important elements: Header, Order Request, and ItemOut. These elements are described in further detail below.

Header

The Header section contains authentication information and addressing. This information is used to authenticate the request. Specific user information does not apply and should not be included in the Header section.

Request

The Request element follows the Header element and includes order-specific information, such as an order identification number or date. The following information is included within the BuyerQuest cXML Request:

ItemOut

ItemOut information is included in the BuyerQuest ‘body’ of the message. This section will contain the following item-specific information by line:

Note:

1. IF PO has Shipping Level = Header Level THEN:
   • Shipping Location and Deliver To of the 1st Line Item are exported in <ShipTo> on Header Level
   • Need By are exported in requestedDeliveryDate for each Line Item with appropriate value
2. IF PO has Shipping Level = Line Level THEN:
   • Shipping Location of the 1st Line Item is exported in <ShipTo> on Header Level
   • Deliver To of each Line Item is exported in <Extrinsic name="DeliverTo">
   • Need By are exported in requestedDeliveryDate for each Line Item with appropriate value
3. Billing Location of 1st Line Item is exported in <BillTo> on Header Level despite Billing Level = Header Level OR Line Level
4. Shipping Method of 1st Line Item is exported in <Shipping> on Header Level despite Shipping Method Level = Header Level OR Line Level
5. Payment Method of 1st Line Item is exported in <Extrinsic name="PaymentMethod"> on Header Level despite Payment Method Level = Header Level OR Line Level

Accounting in cXML PO

Accounting can be displayed in the cXML PO. To enable this ability, go to ADMIN > Show Menu >  Suppliers > Manage Suppliers > Click into a Supplier that has PO Transmission Method = cXML> General tab > 'Include Accounting' = Yes and Save

See: Manage Supplier Information

When 'Include Accounting' = Yes:

• <Distribution> tags are included within the cXML PO
• Accounting data is sent under the <Distribution> element.
• There may be multiple <Accounting> under <Distribution> depending on how many accounting splits there are for the PO.
• Value of name in <Accounting> element = "Accounting String X". X is 1, 2, 3 etc depending on the number of times accounting is split. For the first accounting string it will be 'Accounting String 1' for the second accounting string it will be 'Accounting String 2'
• There may be multiple <AccountingSegment> under <Accounting>. Each <AccountingSegment> corresponds to the Accounting Group within the accounting string.
  • Value of id under <AccountingSegment> = Id of the accounting group
  • Value of Name under <AccountingSegment> = Name of the accounting group
  • Value of Description under <AccountingSegment> = Id of the accounting value.
• For split accounting, the percentage distribution is sent under <charge>.
• Value of Money currency under <charge> = the percentage allocated to this Accounting split

Example:

PO cXML Example

PO cXML Example.xml

Next Steps

Please prepare to provide the following required information upon request:

1. Supplier contact's information for setup and testing
2. URL, username, password, and shared secret for receiving test cXML POs
3. URL, username, password, and shared secret for receiving production cXML POs

In 16.2.0, we have added the ability to associate a CVV with a credit card token.

Some suppliers require the card security code (CVV) to automate credit card processing. Until now, BuyerQuest could send a persistent payment token (card number + expiration), but CVV was not available via cXML (it was only captured/displayed through the UI).

With this enhancement, BuyerQuest can now (when enabled per supplier):

• Create a new, unique “per-PO” GUID token for each Purchase Order using TokenEx Retokenize (1:many token scheme).

• Capture CVV using TokenEx CVV-only mode iFrame, and associate the CVV to that per-PO GUID token (not to the persistent token).

What changes in the outbound PO cXML

When enabled:

• BuyerQuest sends the per-PO GUID token (the token that has the CVV association) in the outbound PO cXML.

• BuyerQuest does not send the persistent token for that PO.

• The token is placed in the same logical area currently used for credit card token transmission; any additional field (if required) is added in a backward-compatible way and only for enabled suppliers.

Retry behavior

The PO cXML is not sent until BOTH are successful:

1. The per-PO GUID token is created (Retokenize), and

2. CVV is captured and associated to that GUID token.

If export is retried later:

• The system must ensure the CVV association is still valid; if not, it will require CVV re-entry before sending again.

See related topics: