CompTIA EIDX Document Identification: Line Item Numbers
Line Item Numbers in ASC X12 are specified in the PO101, LIN01, etc. This is not true in EDIFACT. In EDIFACT, the number in LIN01 indicates the occurrence of the LIN in the message. In EDIFACT, line item numbers are in RFF segments.

EDIFICE description of LIN01 Line Item Number:
"It is required to assign a number to the line items within a message. The number is assigned by the sender of the message. The first line item within a message will be numbered ‘1’ and further line items will be incremented by ‘1’ for each new line."

EDIFICE description of Segment Group 25 RFF Line Item Number in ORDERS message:
"Within an order this must be a unique number which will be the key for identification of the line item. The number is assigned by the buyer, and it can only be assigned once during the lifetime of the order. It will be used, where needed, to refer to the original line item on any subsequent transactions relating to the order. Normally, the first line number on an order will be numbered ‘1’ and further line items will be incremented by ‘1’ for each new line. This DE must be used when DE1153 = ‘LI’."

At first this seems arbitrary, until configuring product options are examined. See the "PRODUCT OR COMPONENT OPTIONS" section. The examples illustrate the difference between ASC X12 and EDIFACT.

Line item numbers should be sent by the buyer if it is important that they be received back on response documents (acknowledgments, ship notices, invoices, etc.) in order to match the responses correctly to the original purchase order.

Line Item Numbers Not Used
Some trading partners that manage Blanket Purchase Orders (BPOs) as part of the same forecasting application that generates Material Release or other types of planning schedules may not use line item numbers in their BPOs. Typically, these trading partners have applications that are designed to disallow the same part number to be on an order more than once. In which case, line item numbers may seem to be as irrelevant, and the line item number is not needed in response documents such as acknowledgments, ship notices and invoices.

Trading partners should be prepared to accommodate this type of situation. If the receiver’s application must have a customer line item number, dummy values might be calculated by the application interface program. Likewise, the buyer’s application might be coded to ignore the dummy line item numbers if they are sent in a response document. This is an example where the use of single-item BPOs are recommended, since in this case, line item number is always 1.

Line Item Numbers Used
It is very important that the line item number not be changed from the original line item number in the purchase order. Line item number is likely to be a key value used to match the change order line item of the purchase order in the buyer's system to the sales order in the supplier's system. If a purchasing system should renumber line items, because line items are deleted or closed, it may be difficult to match the line items in the seller's system. Also since part numbers are often repeated on line items within a given purchase order, the part number alone may not suffice for the line item matching. Never renumber line items. This practice should be corrected as soon as possible to avoid this serious problem.

Likewise, the integrity of the line item number in the purchase order should continue in the original acknowledgment transaction and the change acknowledgment returned to the buyer.

Crossing Applications and Transaction/Messages
The integrity of the line item number should be maintained across all applications and all transactions/messages. For example, if the line item number is five (5) characters long and the line item is used in a bar code, all five (5) characters should be used in the bar code. For example, the buyer should not expect that five (5) numbers of the bar code be transmitted in the purchase order, but that only four (4) of the numbers be used in the bar codes. This rule applies to all other data elements also.

Line Item Number Length
Earlier ASC X12 versions/releases limited ASSIGNED IDENTIFICATION to six digits. New versions/releases allow up to eleven (11) digits. The maximum allowable length is six digits in DE 1082 Line Item Number in EDIFACT.

The EDIFACT standard only allows 200000 occurrences of the SG25.LIN segment group on a purchase order, and ASC X12 allows only 100,000 line items on a purchase order. In reality, most legacy applications have only a two or three digit line item number field, and few applications allow for more than 100000 items per transaction. EIDX recommends the continued use of a maximum of six digits for line item number to accommodate the more realistic length of a line item number in the Electronics Industry and avoid system constraints. Check with the trading partner for their system constraints.

Actual Data Length
Although it is called "Assigned Identification" DE350 in ASC X12, it is common practice to have the "Line Item Number" placed in DE350. It is called "Number", but it is not defined as a numeric field. It is alphanumeric. Though the standards allow large numbers, some industries may be using the fields for unique identifiers other than a numeric counter; hence, the longer data fields.

The purchase order system could generate 1, 01, 001, 0001, 00001, or 000001. Unfortunately, systems do not equate 1, 01, 001, 0001, 00001, and 000001 without data manipulation because there is positional comparison.

The seller's system should maintain the integrity of the data without padding the number with leading zeros so the acknowledgments return the data exactly as sent by the seller. The data should be treated as an alphanumeric identifier, rather than as a number. The actual data length in all the purchase order related transactions should be consistent.

The following tables illustrate the problem. Assume that the seller system must hold six positions to accommodate all their customers. They store the number exactly as the buyer sent the data. When the computer compares the entire field of six positions, it compares each position separately.

If a buyer sends, ‘1 ‘ and the seller stores it as ‘001’, a mismatch will occur, because '1 blank blank blank blank blank' does not equal '0 0 1 blank blank blank'.