Clickable Business Models eBusiness Education Acronyms Cross References
B2B Content Standards EC Technology Standards Glossary Implementation Guidelines
Implementation Options General Recommendations References Methodology/Legends
 Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search
 Order Models Index | Supporting Documentation | Downloads | FAQs |
EIDX Order Models - Supporting Documentation

Response to/Acknowledgment of Discrete Purchase Order

Special Notes:   

 


Definitions

Receipt Acknowledgment - a/k/a Functional Acknowledgment, Control MessageWhen one party (e.g. buyer) sends an electronic message to another party (e.g. seller), the recipient sends back a signal back advising the sender that the message reached the intended destination, and indicating whether or not the message was syntactically correct and in conformance to the standard identified in the message.  The receipt acknowledgment is called a "business signal" by some in order to distinguish it from a business document containing business data.  A receipt acknowledgment has no legal authority - it does not address the business contents of the sent document.  The origin and destination are usually eBusiness gateways.  The signal sent back to the originator generally indicates that the message was received at the recipient's gateway; it does not guarantee that the message made into the recipient's back-end application.  The reliability of the interface between the recipient's gateway and recipient's back-end application should be determined as part of the testing and implementation process.

Acknowledgment (Order)
An acknowledgment advises a buyer that a purchase order has been received, and indicates whether the supplier has accepted all or part of the order. An acknowledgment may advise the buyer if any changes have been made or action is required, such as a rescheduling of dates, adjustment to price and/or quantity, etc.


Types of Responses/Acknowledgments

Acknowledgment/Response, Original

Re-acknowledgment

Change Order Acknowledgment/Response

Seller-initiated change

PO Change Request Denial

Order Status report

Ship Notice


Narrated Examples of Responses to an Order

This entire section is new (not previously published) material.

First, a couple of important definitions: 

Manual Process

Enter Order on Supplier's Web Site

Receive Order on Supplier's Web Site

Electronic Order, B2B, Application to Application

In traditional EDI, one normally does not establish electronic linkages with suppliers that have not gone through an approval process.  New services like marketplaces and public exchanges open up the possibility that I may send orders electronically to a supplier with whom I do not have an established electronic linkage.  Am I likely to order a mission critical item this way - without supplementing the process with human-to-human interaction?  There are a lot of discussions about whether or not this is an appropriate use of exchanges.  You may use a reverse auction to locate a resource for a mission-critical part.  If the resource you locate is not on your approved supplier list, then you may need to have some business rules in place describing the circumstances under which you can or cannot award an order to a non-approved supplier, and rules governing what types of responses/acknowledgments are required.  Is the supplier a member of the same public exchange you are using?  What did you do to evaluate and approve your exchange when you became a member?  What criteria does the exchange use for approving membership of other companies (who may be your suppliers) in the exchange?  Is the supplier is a member of another exchange that your exchange interconnects with?  What criteria does your exchange use to approve interconnections to other exchanges, and do those other exchanges have rules for who can become members?


Acknowledgments:  When and What to Send

As a seller accepts line items in an order and applies shipment dates to the buyer's requested schedule dates,  PO acknowledgment messages are generated to convey the status of each line item and its ship or delivery dates.

Some standards have multiple PO response/acknowledgment messages defined.  In those standards, it was usually to distinguish between acknowledgments to original orders, re-acknowledgments, and acknowledgments to change orders.    Since some buyers may identically process all PO and Change Order acknowledgment messages, they may accept original acknowledgments data and re-acknowledgments data all as if they were 855 transactions.  This may happen if they are not concerned about the CHANGE ORDER SEQUENCE NUMBER (BCH05) and they are mostly interested in just getting the current schedule date without the technicality of the 865 transaction.  This method can be agreed upon between trading partners.


Usually only one original acknowledgment message should be sent for any line item in a purchase order.  That means that any purchase order with more than one line item may have multiple PO acknowledgment messages associated with the entire purchase order.  If all the line items are acknowledged all at once, then the entire purchase order will have only one PO acknowledgment messages.  After a line item had one PO acknowledgment messages generated for it, all subsequent acknowledgments should be 865 transactions for the given line item according to the definition of the 865 transaction.

Purchase Order Status Pending

Some buyers cannot process PO responses with a 'Pending' status at the header level; if received, the PO response is rejected or kicked-out as an exception; the buyer may not process other important information in the response.  The intention of the 'Pending' status is so that a seller can notify the buyer that the order has successfully processed into their back-end system, but is not dispositioned yet.  The seller then follows-up with a subsequent PO response message to accept or reject the order.  At implementation time, trading partners should explicitly discuss whether pending status can be used and how it will be processed.

Order Acknowledgments vs. Change Order Acknowledgments

Since some buyers may process all 855 and 865 transactions identically, they may accept original acknowledgments data and re-acknowledgments data all as 855 transactions.  This may happen if they are not concerned about the CHANGE ORDER SEQUENCE NUMBER (BCH05) and they are mostly interested in just getting the current schedule date without the technicality of the 865 transaction.  This method can be agreed upon between trading partners.

PO Time to Respond

Purchase order acknowledgments should be sent within one to five days after the original purchase order or change order is sent.  One day turn around is usually expected.  The acknowledgment turn around is often stated in the trading partner agreement.  If the transaction takes longer than the time specified by any agreement, the applications may need a review.

Schedules Pending

Until the actual ship or delivery dates are determined, the 855 acknowledgment transaction may arrive with ACK01 set to  'schedule pending' (code SP).  Most of the seller's schedules may already be determined, which will have the appropriate ACK01 value (see next page).  It is better to receive a schedule pending code within one to five days of receipt of the change order, then to defer information any longer in the original acknowledgment.

Schedule segments sent as 'schedule pending' will need subsequent transactions with the actual delivery or ship dates.  When the actual date is finally set by the supplier, the entire line item is re-acknowledged, i.e., all the schedules are resent even if only one had an outstanding 'schedule pending'.

The schedule pending code should not be sent in change order acknowledgments.  They can be sent in the 855 transaction.  The 865 transaction should wait until the new schedule data is determined.

ACK01 (DE668)

MEANING

SP

Item Accepted - Schedule Date Pending

Closed Items

CLOSED ITEMS, meaning all shipments completed in the past, are never re-acknowledged.  Only the original 855 acknowledgment or applicable 865 acknowledgments were sent as schedules were determined.


Second Transaction/Message

X12: BCA04 (DE328) RELEASE NUMBER

X12: BCA05 (DE327)CHANGE ORDER SEQUENCE NUMBER

X12: BCA11 (DE279) PURCHASE ORDER CHANGE REQUEST DATE

The following data elements have the following considerations.  Most data elements on the BCA segment do not need explanations.

BCA04 Release Number
Usually release number is associated with orders based on a material release.  Release number (BCA04) is not expected to have data in discrete purchase orders, which this document addresses.

BCA05 Change Order Sequence Number
The Change Order Sequence Number (BCH05) from the 860 Change Order transaction should be returned in the BCA05 in the Change Order Acknowledgment 865 transaction .  For details, refer to “Change Order Sequence Number” above in the section on the 860 Change Order.

BCA11 Purchase Order Change Request Date
Like the Change Order Sequence Number (DE327), the Purchase Order Change Request Date (DE279) from the Change Order 860 transaction should be returned in the BCA11 data field..  This field may be an important field to match the 865 transaction to the 860 transaction.  On a seller initiated change order acknowledgment, the BCA11 should be blank.


Items and Schedules Acknowledged

<Splitting line items - reasons suppliers create new lines items include when shipping from more than one warehouse and seller system requires separate line items - 2 seller line items equate to 1 buyer line item (called partialling' also called partialling when seller splits buyer's PO into >1 sales order); should be made invisible to the buyer.  Another reason - if the item ordered must always be ordered with another item and buyer did not include both items on the order.>

ACK segments in the 865 transaction are the counter part segments to the SCH segments in the change order  860 transaction.  The ACK contains the details of the supplier’s schedule.

The first time that supplier schedule dates are set, 855 transaction(s) were sent for the line items.  As a line item or its associated schedule changes are accepted or the requested change is denied by the sales order system, a change order acknowledgment 865 transaction is generated. 

For discussion, when a 'line item' change is mentioned, it means either a change at the line item level and/or a schedule level change associated with the given line item.

The 865 transaction contains only line items which are changed or denied.  Whenever a line item or any one of its schedules is changed, all the schedules are returned in an 865 transaction to convey the response to the 860 transaction.

If several line items have changes, all the line items and associated schedules may not be returned in a single 865 transaction.  If particular line item changes are delayed by the supplier, perhaps waiting for approval, then the line items may be split into several 865 transactions.  However, it is important that every line item found in the 860 transaction have a corresponding acknowledgment in an 865 transaction even it takes several 865 transactions.

Unchanged line items and associated schedules are not re-acknowledged.  Also in the short term, suppliers may not be able to provide denied change orders in the acknowledgment.

DTM and SCH segments for Customer Request Date

Optionally, DTM or SCH segments may be returned with the buyer's request dates.  One of these segments may be sent based on the trading partner's needs.  They are not necessarily sent to all trading partners. Some trading partners do not want or need their own request dates returned.

A DTM segment in the 855 or 865 acknowledgment transaction may be sent with the buyer’s requested schedule date.  A SCH segment in the 855 or 865 acknowledgment transaction may be sent with the buyer's requested schedule dates AND the quantity.  The dates may be delivery or ship dates.

The date in the DTM or SCH is the most current 'customer request date' in the supplier's system.  It should correspond to the customer request date in the 860 transaction if that was the changed schedule.   It is not the original or first request date from the 850 transaction.  This customer request date in the 865 transaction may be used to match to the SCH in the 860 transaction.  When the match is found, the date in the ACK segment may be applied in the purchase order in the buyer's system.  These dates may be helpful for matching if schedules are split by the supplier.  

The meaning of the dates in the DTM and SCH segment are the same as noted above.  However, the SCH quantities may be confusing if the schedule was split by the supplier.  The SCH quantity would be the quantity after the schedule split.  If the original request in the 860 transaction was for 10,000 units, but they are split into two groups of 5,000 units, the SCH would reflect the 5,000 units which would not help in the matching process.  The buyer’s system may be looking for the full 10,000 in the SCH06.

Example of ACK and DTM/SCH segments in the 865 transaction:

ACK*IA*1000*EA*017*950308
(required segment)

Where a schedule is acknowledged as Item Accepted (IA) for 1000 units each with an Estimated Delivery Date (017) of March 8, 1995.

DTM*002*950306
(optional segment – use instead of SCH)

Where March 6, 1995 is the buyer’s delivery requested date in the corresponding 860 transaction  (for buyer initiated change) or the last customer request date on the sales order (for seller initiated change).

SCH*1000*EA****002*950306
(optional segment – use instead of DTM)

Where March 6, 1995 is the buyer’s delivery requested date and the quantity is 1000 units in the corresponding  860 transaction  (for buyer initiated change) or the last customer request date on the sales order (for seller initiated change).

Consistent Qualifiers

Delivery dates are often called ‘dock dates’, i.e., the time that the product arrives on the buyer’s dock.  Ship dates are dates when products leave the supplier’s warehouse.  The transit time to the buyer’s dock is usually a known constant number of days between the locations.  The qualifiers in the ACK and DTM segments should both indicate delivery or both indicate ship dates.  Keep the qualifiers consistent. 

 

ACK Segment

DTM or SCH Segment

DELIVERY DATES:

ACK04

017

Estimated Delivery or

DTM02

002

Delivery  Requested or

 

ACK04

067

Current Delivery

SCH06

002

Delivery Requested

 

 

ACK Segment

DTM or SCH Segment

SHIP DATES

ACK04

011

Shipped or

DTM02

010

Requested Ship or

 

ACK04

068

Current Schedule Ship

SCH06

037

Do Not Ship Before

 

THE EIDX GUIDELINE RECOMMENDS THE FOLLOWING CODES FOR THE ACK01, LINE ITEM STATUS CODE.
 

ACK01

MEANING

ACK01

MEANING

AC

Item accepted and shipped

IH

Item on hold

AR

Item accepted and released for shipment

IP

Item accepted - price changed

DR

Item accepted - date rescheduled

IQ

Item accepted - quantity changed 

IA

Item accepted

IR

Item rejected

IC

Item accepted - changes made

IS

Item accepted - substitution made 

ID

Item deleted

SP

Item accepted -schedule date pending

 

When a line item or its schedules are changed, the following codes are expected in the PO change acknowledgment ACK segment.  The LINE ITEM STATUS CODE (ACK01) should be accurate.

 

860 CHANGE ORDER

RESULTING ACKNOWLEDGMENT

  865 ACK01 (1 per schedule)

 

CHANGE AT ITEM LEVEL:

1

DELETED ITEM

Line item is acknowledged when deleted; It is never resent after this 865 is sent.

ID

2

CLOSED ITEM due to a change which caused an immediate shipment

 

Acknowledge the line item once.

AC

 

3

CHANGE AN ITEM

Acknowledge only the line items which changed.  Send all the schedules for that line item. Sending closed schedules is optional.  They probably are not necessary.

Send appropriate code from the above table.

 

 

CHANGE AT SCHEDULE LEVEL:

4

ADD/CHANGE/DELETE A SCHEDULE

Acknowledge the associated line item. Send all the schedules for the line item.  Sending closed schedules is optional.  They probably are not necessary.

Send appropriate code from the ACK Code table above.

 


Change Order Rejects

Acknowledgment Type

If all change order line item requests or the limited header level change requests must be rejected, the Acknowledgment Type (BCA02) may be returned with the code RD, RF, or RJ depending upon the X12 version/release.

BCA02 (DE587)

MEANING

RD

Rejected with Detail  - available in X12 versions 003010 and higher; it may be used if necessary by the trading partner agreement.

RF

Reject with Exception Detail Only

RJ

Rejected - No detail; recommended when all the change order line items are rejected.  There is no need to send detail for a total rejection.

RO

Rejected with Counter offer.  Not recommended by EIDX.  Instead use code AC (Acknowledge With Detail and Change).

Line Item Status Code
If a specific change order line item request must be rejected, the Line Item Status Code (ACK01) should be returned with the value 'IR' for 'item rejected'.  

ACK01 (DE668)

MEANING

IR

Item Rejected

 


Schedule Level Denials

There is no method to code specific schedule level denials in the X12 transaction.   The supplier will assign their best possible delivery or ship date to the customer request date.  A code will not be returned to indicate that the specific customer date was 'rejected'.  One of the following codes may be used to indicate that the exact customer request is not applied to the sales order.

BCA02 (DE587)

MEANING

AC

Acknowledge - With Detail and Change

AE

Acknowledge - With Exception Detail Only

ACK01 (DE668)

MEANING

IC

Item Accepted - Changes Made

 


Last updated 05 January 2003