1. Configuring and Managing B2B Messaging
  2. Order Acknowledgment to OAGIS 10.1 Acknowledge Purchase Order Transformation

Order Acknowledgment to OAGIS 10.1 Acknowledge Purchase Order Transformation

There are two OAGIS 10.1 Acknowledge Purchase Order transformation predefined message definitions OAGIS_10.1_ACK_PO_IN and OAGIS_10.1_ACK_PO_COLLAB_MSG_IN.

Both message definitions can be used for the use cases of accepting or rejecting the purchase order as a whole or at the line level. They should not be used for more complex use cases that involve purchase order changes or if Allow Delivery on Purchase Orders that are Pending Supplier Acknowledgment is enabled.

Use the OAGIS_10.1_ACK_PO_IN message definition if you have the use cases and criteria described and you use either CollaborationMessagingService or CollaborationMessagingV2Service for message delivery.

Use the OAGIS_10.1_ACK_PO_COLLAB_MSG_IN message definition if you have the use cases and criteria described and you use CollaborationMessagingService for message delivery.

Acceptance or rejection can apply at two levels of an order:

  • Header

  • Line

Manage Your Acknowledgment Codes

Suppliers communicate acceptance or rejection using different codes, and the codes used aren't standardized among suppliers.

To process the acknowledgment, the XSL must detect these code values in the document and interpret them properly. To enable this, the XSL file contains lists of code values, documented in the table that follows. The lists in the XSL file contain commonly used codes, and you can to modify them based on the codes used by your suppliers.

Order Level

Code List Name

Code values

Header

orderAccept

ACCEPT, AT

Header

orderReject

REJECT, RD

Line

lineAccept

ACCEPT, IA

Line

lineReject

REJECT, IR, RD

Line Schedule

scheduleAccept

ACCEPT, IA

Line Schedule

scheduleReject

REJECT, IR, RD

Define the Default Reject Reason

The default reason for rejection is provided in the XSL file (defaultRejectReason is Not Provided). You can use the default reason or provide your own reason by modifying the XSL file. If no reason for rejection is provided in the payload, the default reason for rejection from the XSL file is used.

Set the Required Acknowledgment in Procurement

The Required Acknowledgment setting in the purchase order determines if lines are required in the PO Acknowledgment.

From the Required Acknowledgment drop-down list:

  • Select Document to process only the header code acknowledgment values. This is for the simple case of accepting or rejecting the purchase order as a whole.

  • Select Document and Schedule to accept, reject, or change the purchase order at the line level. For most B2B use cases, you will need to select Document and Schedule.

Acknowledge Purchase Order Inbound Message Processing

The inbound Acknowledge Purchase Order message processes acknowledgment code values provided at each level: header, line, and line schedule.

If the acknowledgment code value provided in the payload at any level (header, line, or line schedule) is invalid or not provided, then message processing is skipped. And a message is logged with a status of skipped.

Here's an example of header-level acknowledgment code:

<Status>
   <Code>REJECT</Code>
   <Reason>Rejection Reason</Reason>
</Status>
Note: If no reason for rejection is provided in the payload, the default reason for rejection from the XSL file is used.

Common use cases for using the Acknowledgment Purchase Order inbound process are:

Accept a Purchase Order

To accept a purchase order as a whole, the acknowledgment code value provided at the header level in the payload must be a value that's in the orderAccept acknowledgment code list.

All lines must be in the payload, with acknowledgment code values that exist in the lineAccept acknowledgment code list.

Line schedules are required in the payload, and they must contain valid acknowledgment code values that are in the scheduleAccept acknowledgment code list.

Reject a Purchase Order

To reject a purchase order as a whole, the acknowledgment code value provided at the header level in the payload must be a value that's in the orderReject acknowledgment code list. The entire purchase order is rejected, regardless of any acknowledgment code values at the line or line schedule level.

All lines must be in the payload, but acknowledgment codes aren't required. If provided, they're not evaluated.

The line schedules are required in the payload, but acknowledgment codes aren't required. If provided, they're not evaluated.

Here's an example of accept or reject at line level:

<!--ACCEPT/REJECT AT LINE LEVEL -->
<PurchaseOrderLine>
     <LineNumberID>1</LineNumberID>
     <Status>
        <Code>REJECT</Code> 
        <Reason>Rejection Reason @ Line Level</Reason>   
     </Status>
     <PurchaseOrderSchedule>
        <LineNumberID>1</LineNumberID>
        <Status>
               <Code>ACCEPT</Code>
        </Status>
     </PurchaseOrderSchedule>
     <PurchaseOrderSchedule>
        <LineNumberID>2</LineNumberID>
        <Status>
               <Code>REJECT</Code>
               <Reason>Rejection Reason @ Schedule Level</Reason>
        </Status>
     </PurchaseOrderSchedule
</PurchaseOrderLine>
Note: If a reason isn't provided, then the defaultRejectReason is used.

Accept a Purchase Order and Reject Some Purchase Order Lines

To accept a purchase order with some rejected lines, the acknowledgment code value provided at the header level in the payload must be a value that's in the orderAccept acknowledgment code list.

All lines must be in the payload, and each line must have an acknowledgment code value that's in the lineAccept or lineReject acknowledgment code list.

The line schedules must be provided in the payload, and they must contain valid acknowledgment codes that are in the scheduleAccept or scheduleReject list of acknowledgment codes.

Related Topics