Order Response xCBL Mapping

Response Type Code

In the xCBL 3.5 Order Response document sent back by the supplier, the header level Response Type Code element is required. The value provided by the supplier is checked against the following table to determine the appropriate supplier action to use for Procurement's processing of the order response. If the value of "Other" is used for the Response Type Code then the description for "Other" will be used in the lookup.

There are a few cases when Procurement is unable to process the order response as a result of the specified Response Type Code value. Specifically, if the value is "Other" and the description for other is missing, if the value is not found in the following table or, finally, if the Supplier Action maps to Unsupported. In each one of these cases an XPC error document will be sent to the supplier.

Response Type Code	Supplier Action	Order Status
Accepted	Accepted As Is	Accepted
AcceptedContentsRejected	Changed	Accepted With Changes
AcceptedWithAmendment	Changed	Accepted With Changes
AcceptedWithAmendmentInDetailSection	Changed	Accepted With Changes
AcceptedWithAmendmentInHeadingSection	Changed	Accepted With Changes
AcceptedWithAmendmentNoConfirmationIsRequired	Changed	Accepted With Changes
AcceptedWithoutAmendment	Accepted As Is	Accepted
AcceptedWithoutReserves	Accepted As Is	Accepted
AcceptedWithReserves	Changed	Accepted With Changes
AcknowledgeNoDetailOrChange	Unsupported	No Status
AcknowledgeWithDetailAndChange	Changed	Accepted With Changes
AcknowledgeWithDetailNoChange	Unsupported	No Status
AdviceWithDetails	Unsupported	No Status
AdviceWithoutDetails	Unsupported	No Status
Agreed	Accepted As Is	Accepted
AlreadyDelivered	Accepted As Is	Accepted
ApprovedAsAmended	Changed	Accepted With Changes
ApprovedAsSubmitted	Accepted As Is	Accepted
AuctionHeld	Unsupported	No Status
AuthorityDeclined	Unsupported	No Status
AuthorityToDeduct	Unsupported	No Status
BuyerClaimsAgainstInvoice	Unsupported	No Status
Changed	Changed	Accepted With Changes
ChargeBackToSeller	Unsupported	No Status
Checked	Unsupported	No Status
ConditionallyAccepted	Changed	Accepted With Changes
Countersued	Unsupported	No Status
CourtActionDismissed	Unsupported	No Status
DirectDocumentaryCreditCollection	Unsupported	No Status
FinalResponse	Unsupported	No Status
GroupedCreditAdvices	Unsupported	No Status
GroupedDebitAdvices	Unsupported	No Status
InitialClaimReceived	Unsupported	No Status
InterimResponse	Unsupported	No Status
LegalActionPursued	Unsupported	No Status
MeetingHeld	Unsupported	No Status
NoAction	Changed	Accepted With Changes
NotAccepted	Not Accepted	Not Accepted
NotAcceptedProvisional	Not Accepted	Not Accepted
NotChecked	Unsupported	No Status
NotInProcess	Unsupported	No Status
NotProcessed	Unsupported	No Status
OriginalConfirmationOfOriginalAnnouncement	Unsupported	No Status
OriginalConfirmationOfRevisedAnnouncement	Unsupported	No Status
PaymentDenied	Unsupported	No Status
Pending	Unsupported	No Status
PendingAwaitingAdditionalMaterial	Unsupported	No Status
PendingAwaitingReview	Unsupported	No Status
PendingIncomplete	Unsupported	No Status
Rejected	Not Accepted	Not Accepted
RejectedDuplicate	Not Accepted	Not Accepted
RejectedNoDetail	Not Accepted	Not Accepted
RejectedNotAsAgreed	Not Accepted	Not Accepted
RejectedResubmitWithCorrections	Not Accepted	Not Accepted
RejectedViolatesIndustryPractice	Not Accepted	Not Accepted
RejectedWithCounterOffer	Not Accepted	Not Accepted
RejectItemChange	Not Accepted	Not Accepted
RejectWithDetail	Not Accepted	Not Accepted
RejectWithExceptionDetailOnly	Not Accepted	Not Accepted
ResultDisputed	Unsupported	No Status
ResultOpposed	Unsupported	No Status
ResultSetAside	Unsupported	No Status
SellerRejectsDispute	Not Accepted	Not Accepted
SellerWillIssueCreditNote	Unsupported	No Status
Settlement	Unsupported	No Status
SingleCreditItemOfAGroup	Unsupported	No Status
SingleDebitItemOfAGroup	Unsupported	No Status
UnderInvestigation	Unsupported	No Status

Order Status

In the xCBL 3.5 Order Response document sent back by the supplier, the header level Order Status element is optional. However, Procurement does require an order to have an Order (Supplier) Status, as can be seen on the Order Status screen and elsewhere. Therefore, even if the supplier does not specify one in the Order Response document, Procurement will ensure an order has an order status.

The logic Procurement uses to determine an order's status is as follows. When an order is first created the status is set to No Status. After a supplier sends a response to the order the order status will be whatever the supplier provides. However, if the optional Order Status element is not present, then the status will be looked-up in the Response Type Code table above using the Response Type Code value in the search.

For instance, if the supplier does not provide an order status and the Response Type Code is AcceptedWithoutAmendment then the order status will be Accepted.

Purpose Code

In analyzing the order choreography between xCBL based buyers and suppliers one could expect the required Purpose element in the xCBL 3.5 Order Response document to have a part to play. In fact, for Procurement it does not and is mentioned here specifically to avoid ambiguity.

The Purpose element is not used by Procurement. Because it is a required element suppliers will typically put Original for the purpose code. However, regardless of what the supplier enters here it is ignored by Procurement.

Change Order Support

The buyer and supplier trading partners, before doing business, should decide whether or not Change Order is supported. If either party initiates a change order and the other party does not support change order then a negative impact to the business may result.

Once the agreement is made between trading partners, the Procurement Administrator should configure the Supports Change Requests option for the supplier, accordingly. With Change Order disabled for the supplier, the buyer may not request a change or cancel the order.

Procurement users may also be restricted from issuing change requests or cancel orders based on the application privileges assigned to the users. Procurement users are assigned to Administrator defined roles. Roles are simply a set of predefined privileges. Furthermore, Create Change Order and Cancel Order are two Order related privileges that may be added to a role. Therefore, a user will only be able to take the Create Change Request or Cancel Order actions if the user is assigned to a role that has these privileges.