|
CompTIA EIDX Document Identification Contents
- Using References
- Third-Party Reference
Data
- Identification of Order
Numbers
Using References
Limit on References That Trading Partners
Must Maintain
In general, the buyer should limit the number of references
which sellers are expected to maintain in their systems and send
back in response documents. The buyer should not expect the seller
to maintain references needed only by the buyer; the buyer should
maintain such references in their own applications. The seller should
be responsible for handling only those references necessary for
conducting business or necessary for systems processing, e.g., identifiers
for matching response documents to original documents. This recommendation
applies to data elements throughout transactions/messages, including
the following:
| ASC
X12 SEGMENTS |
EDIFACT
SEGMENTS |
BEG,
BCA, etc. |
BGM |
PO1,
POC, etc. |
LIN,
PIA, etc. |
REF |
RFF |
Examples of Reference Types:
- Part identifiers
- Drawings
- Third party’s references (order number, part number, etc.)
- Contract numbers, price quote numbers, delivery quote numbers,
etc.
- Export reference numbers
- Project numbers
Returning Buyer's Reference Numbers and Codes
While buyers should limit the number of references that the
seller must maintain, some references are critical for the buyer
to be able to process and match response documents. Data from initiating
transactions in a business process should be returned exactly
as they were received. Otherwise, the return of cross-referenced
or converted codes will require the initiating trading partner to
cross-reference the codes back to their initial internal codes.
In no case should leading or trailing zeros, spaces, or special
characters such as dashes be added to any data. Such a practice
results in data which will not match the original data that was
sent.
| Data
that should be returned in response documents |
Notes |
| Purchase Order Number |
Also sending the
sales order number is optional but recommended. |
| Buyer’s Carrier
Codes |
The seller’s
carrier codes may not be meaningful to the buyer’s system
unless they also cross-reference seller carrier codes. It is
best to use SCAC codes so neither system needs to cross-reference
the code. |
| Buyer’s Line
Item Numbers |
Line item numbers
are not always used, but if used, they are important to the
buyer. This number is often used to match the data to the original
data sent. |
| Buyer’s Part
Number |
Integrity of the
buyer’s part number should be retained. Seller part data
may also be returned, but the buyer part number must be returned.
|
| Buyer’s Part
Number’s Revision Number |
Integrity of the
buyer’s part number’s revision number should be retained. |
| Buyer’s Release
Numbers |
If the buyer’s
release number is used, it is often important to the buyer.
This number is often used to match the response data to the
original data sent. release numbers should be returned in response
transactions. The use of release numbers is becoming more prevalent
between some trading partners. It is even used in lieu of the
supplier’s invoice number in payment/remittance advice
transactions/messages (820/PAYORD/REMADV). |
| Unit of Measure |
Integrity of the
buyer’s unit of measure should be retained. |
Re-Sending References
The specific product data which is needed in a transaction depends
on the transaction. Most often, it suffices to send only the
buyer part and associated engineering change number, and/or the
supplier part and associated engineering change number for component
orders
The following items are recommended:
- Engineering Changes (X12/UN Qualifier = ‘EC’) should
always be re-sent since it is critical to determine the correct
product.
- If any drawing numbers and/or references are sent, they need
only to be included in the initial transactions of the procurement
process, i.e., the purchase order.
- Drawing numbers and/or references need not be returned in transactions
noted in the tables on the following pages. This data is already
in the buyer's purchase order system.
- Do not depend on re-sending drawings and/or references in Purchase
Order Change transactions/messages in order to notify a trading
partner that they have changed. There is no code available for
the 860 (ASC X12) or ORDCHG (UN) Purchase Order Change transaction/message
that indicates that a change has been made to references (usually
drawings). The only way the recipient can tell if these codes
have changed is to do an element by element comparison. There
is no guarantee that the references are sent in the same order
as on the original PO. It is also not easy to tell if drawings
have been added or deleted. There are two recommended methods
for conveying specification changes:
Method 1: One of the functions of the 841
Product Specification (ASC X12, EDIFACT equivalent yet to be identified)
is to convey specification changes and effective dates. The sender
can indicate whether the changes apply to all open orders or to
specific orders.
Method 2: If a product’s specification changes, and
existing order can be closed out, issue new order which calls out
the new drawings and other references.
Expected References in a Standard Procurement
Process
These recommendations apply in an environment where the buyer
is regularly procuring inventory parts which have a buyer part number
assigned, and where an established relationship exists between buyer
and seller as trading partners. This is traditionally modeled between
OEMs and manufacturers/suppliers. In the distributor and manufacturer/supplier
relationship, only vendor part numbers are exchanged.
| |
Product/Service
Product ID |
|
|
|
| |
Buyer
Part ‘BP’ |
Engineering
Change ‘EC’ (for the Buyer Part) |
Vendor
Part ‘VP’ |
Secondary
Packaging Drawing |
Other
Drawing References |
| Purchase Order (Discrete
or Blanket) |
YES |
YES |
ADVISED |
YES |
YES |
| Purchase Order Acknowledgment |
YES |
DEPENDS* |
ADVISED |
DEPENDS |
NO |
| Purchase Order Change |
YES |
YES |
ADVISED |
YES |
FOR ADDED LINES |
| PO Change Acknowledgment |
YES |
DEPENDS |
ADVISED |
DEPENDS |
NO |
| Planning Forecast |
YES |
YES |
ADVISED |
ADVISED |
IF PRECEDES PO |
| Material Release
Forecast |
YES |
YES |
ADVISED |
YES |
NO |
| Discrete Release |
YES |
YES |
ADVISED |
YES |
NO |
| SMI** Forecast |
YES |
YES |
ADVISED |
YES |
NO |
| Invoice |
YES |
DEPENDS |
ADVISED |
DEPENDS |
NO |
| Ship Notices |
YES |
DEPENDS |
ADVISED |
DEPENDS |
NO |
*This is per trading partner agreement. Many partners
do not need anything other than their own BP on response documents.
** Supplier Managed Inventory
Third-Party Reference Data
Transactions/messages referencing a third-party can pass
between any of the following trading partners:
- End-Customer (OEM)
- Distributor
- Contract Manufacturer (CM)
- Component Supplier
Terminology Used for Three-Party Models
When an order is placed in a two-party model, one party is the
buyer and the other is the seller. In a three-party model, the buyer
sending an order to component supplier might be an end-customer
or the buyer might be a distributor or contract manufacturer. To
the CM, the OEM is a buyer, and to the OEM, the CM is a seller.
Sometimes when a seller ships an order to a contract manufacturer,
that CM is the end-customer, and sometimes another party (the CM’s
customer) is the end-customer. To minimize confusion, the following
terminology is recommended:
| Term
Used to Identify a Third Party |
Usage |
| Buyer |
Use in traditional
sense to identify the party that is directly purchasing goods. |
| Component Supplier
(CS) |
Used by a prime
contractor, contract manufacturer or distributor to identify
an component supplier as a third party. |
| Contract Manufacturer
(CM) or Subcontractor |
Used by a prime
contractor or component supplier when identifying a contract
manufacturer as a third party. |
| Distributor (DS) |
Used by an end customer
or component supplier when identifying distributor as a third
party |
| Original Equipment
Manufacturer (OEM) |
Used by a contract
manufacturer, distributor or component supplier to identify
an end-customer as a third party. This term is synonymous with
"Prime Contractor"; the latter term is preferred,
since not all Prime Contractors (end-customers) are OEMs. |
| Prime Contractor
(PC) |
Used by a distributor,
contract manufacturer or component supplier when identifying
an end-customer as a third party. Historically, this term is
synonymous with "OEM"; "Prime Contractor"
is preferred, since not all end-customers are OEMs. |
| Seller |
Use in traditional
sense to identify the party that is directly selling goods. |
| Third-party Warehouse |
Use to identify
a third-party warehouse. |
Third-Party Identifiers
When referencing a third party in a transaction/message, the
sender and receiver may need to be able to identify who the third
party is, what the third party’s order number is, the third
party’s part number, etc. Which qualifiers/ identifiers are
used depends on which party is sending data to which, and who the
third party is. Third-party identifiers are included in the appropriate
sections in this document.
Identification of Order Numbers
In ASC X12, some segments have elements specifically meant
to carry certain order numbers, i.e., a field specifically meant to
carry the buyer’s purchase order number. Other order number references
are sent in REF Reference segments. In EDIFACT, order numbers of all
types are always sent in RFF Reference segments.
| X12
REF01 (DE128) /
UN RFF01 (DE1153) |
MEANING |
COMMENT |
CG |
Consignee’s
Order Number |
Used to identify
order number of a third party. Use for contract manufacturer’s
order number. |
CO |
End Customer’s
Order Number |
Used by a contract
manufacturer or distributor to reference the end customer’s
or prime contractor’s order when sending data to a component
supplier. |
PO |
Purchase Order Number
|
Buyer’s purchase
order number |
VN |
Vendor Order Number
|
Seller’s sales
order number |
|
contact
us 
