Supply Chain Transaction Flow

As background, in the 1970’s through 1990’s various industry segments worked together and defined their business processes, resulting in the development of the many EDI transaction sets.  Key industries included food and beverage, general retail, automotive, banking, material management, motor carrier, ocean, rail, air, and warehouse services.  Over the years additional industry subsets developed, including foodservice, meat and poultry, seafood, direct store delivery, and produce. The characteristics of each industry’s products has resulted in variations in their electronic commerce implementation.  

While EDI was developed as a business-to-business exchange, the information exchanged supports the ultimate product user, including the consumer. The EDI transaction is the common conduit that links the trading parties. With the introduction and continued growth of consumer online purchasing, many industries have updated and upgraded their original implementations to align themselves with the personal computer/smartphone and internet/ecommerce developments of the 21st century.

Historically, trading parties called each other on the telephone, discussed the items of interest, and struck a deal.  This would lead to an order being generated by converting it into a simple EDI order transaction. The main problem with this process was that the buyer had minimum item information, and what was ordered was often not what was received since there was a lack of understanding and documentation about the product.

Today, the supply chain process for trade items begins with the trade parties bilaterally sharing trade item information using a standardized information exchange process, commonly known as data alignment. Different industries have developed different transaction sets and processes to convey item information.  This document describes the basic supply chain flow for trade items.  There are additional processes and transaction sets that support the basic supply chain process for trade items, such as planning schedule, procurement, request for quote, inventory inquiry and product activity.

As part of adequately understanding the item’s attributes, a key requirement in the supply chain process is that the trade item be assigned a unique, unambiguous identifier which allows all trade parties the ability to identify and handle the trade item in an expeditious manner.  The supply chain transaction sets accommodate, and in many instances require, use of a product identifier.  The use of an identifier, such as the GS1 Global Trade Item Number 688267529313, is easier for a computer system to handle than a text identifier such as ‘100% Orange Juice’.

In a global supply chain with products sourced-from and delivered-to trade parties all over the world, a vendor or buyer-assigned product identifier is typically not globally unique. The lack of a customer-facing unique global identity can impact the ability to track and trace a product as it moves through the supply chain.

Should there be a need to recall a product, the unique global identity enhances the recall process, along with the production lot or batch information. Also, if the identity of the product cannot be readily understood by the trading partners or trading partner systems, the order, delivery, invoice, and payment processes can be negatively impacted resulting in various service delays, which in turn may impact the item’s ultimate receiver.

Additionally, in an online ecommerce world, a unique global product identifier allows the consumer to compare attributes and pricing of an item from any seller- not just one down the road.

For the following processes, it is assumed that the 997 Functional Acknowledgment transaction set is issued as a response to the received transaction set, unless otherwise noted.  Use of the 997 Functional Acknowledgment is critical to all parties as it confirms receipt of the originating transaction and its useability to the receiving party.

In trade party arrangements where an intermediary servicing party provides EDI services, it is critical that processes are established to ensure that the sender and receiver are not blindsided by missing or inaccurate information or notifications from the intermediary party. To ensure processing continuity, it is imperative that all parties have formal agreements, procedures and arrangements designed to handle one-off situations.

Trading partner roles for these item exchanges include buyers, brokers, carriers, consolidators, customs, customers, distributors, financial institutions, public warehouses, sellers, seller warehouses and third-party logistics service providers. A trading party relationship can generally be viewed as being a sender and receiver or a buyer and seller.  A trading partner relationship does not preclude the use of intermediaries who provide valuable services for the sender or receiver parties – such as warehouse or transportation services.

The following diagrams are simplified for presentation purposes. There is a basic sequence of actions in the general supply chain process, which includes data alignment, the order process, the delivery process, the invoice process, and the payment process. Within each process are a series of options that the trade parties may observe. Certain transactions can be transmitted at various times in the supply chain cycle, not just in the order depicted here.

The basic item supply chain process is comprised of the following process steps and EDI transaction sets:

• Item Information exchanged between the trade parties. The buyer and seller will typically have several conversations (in-person, via email, etc.) about the products of interest. For the supply chain to function appropriately and efficiently, and to ensure that the buyer receives the correct product, the buyer and seller need to have a common understanding (including detailed information) about the products or services that will be delivered.
  • 832 Price/Sales Catalog (non-food) or
  • 888 Item Maintenance (food) or
  • 897 Data Synchronization
• Purchase Order. The purchase order process establishes the legal contract between the parties about the purchase.
  • 850 Purchase Order
  • 855 Purchase Order Acknowledgement
• Delivery process. The delivery process advises the buyer about product that is being shipped, comprised of one or more purchase orders.
  • 856 Ship Notice/Manifest
• Invoice process. Based on the terms of sale and/or delivery of products, the seller will transmit an invoice to the buyer requesting payment.
  • 810 Invoice
• Payment process. Based on the agreed-upon terms of sale, the buyer will pay for the delivered products.
  • 820 Payment Order/Remittance Advice

1. Catalog

832 Price/Sales Catalog

The 832 Price/Sales Catalog transaction set is used in the Item Data Alignment process and is basically a one-way transmission of item information from a seller to a buyer (i.e., sender to a receiver). The 832 Price/Sales Catalog transaction set is used by trade parties in general merchandise, such as clothing, footwear, housewares, jewelry, pharmaceuticals, and hard goods.

The seller transmits, at a minimum, key item information that is needed by the buyer for the order process as well as information that is needed by the ultimate consumer to make an informed purchase decision. The buyer will typically store the item information in a price/sales catalog/database.

The typical/historical 832 Price/Sales Catalog process accommodates information about the vendor selling unit and the consumer unit. If there are other item configurations pertinent to the seller – buyer relationship, they may also be included.

Item information that may be conveyed between the parties includes the unique item identifier, item name, selling unit information (physical attributes including length, width, height, depth, weight, color), and consumer unit information (physical attributes, including length, width, height, depth, weight, color, use instructions, etc.). The information will vary somewhat dependent on the item’s classification, such as clothing versus shoes versus hard goods. The information may include item price at the time the catalog information is transmitted, or such information may be conveyed later.

Regardless of the item, the receiving party/buyer needs sufficient information about the item so that appropriate ordering, delivery, marketing, transportation, planogram, and sales information are available to support its business processes.

Within a typical 832 Price/Sales Catalog process, the transaction is transmitted from the seller to the buyer on an agreed-upon schedule. An item may be added, deleted, or modified in a transmission. Over the lifetime of a trade item, many 832 Price/Sales Catalog transaction sets can be transmitted from the seller to the buyer. Every 832 Price/Sales Catalog transaction is followed by a 997 Functional Acknowledgment transaction from the receiver back to the sender.

The use of the 832 Price/Sales Catalog process attempts to ensure that the trade parties have accurate item information and the same information in their respective databases. Should the trade parties not coordinate their respective item information, there is a possibility that the wrong product is delivered to the buyer.

• When there is one seller and one buyer, the process can be relatively simple.
• When there is one seller and multiple buyers, the process gets a bit more complex for the seller to maintain accurate information amongst all buyers.
• When the buyer has multiple suppliers, the process for the buyer gets a bit more complex. The buyer needs to ensure accurate information as to which product was delivered by which supplier.

Regardless of which of the above scenarios is pertinent, the buyer and seller need to implement a series of processes and controls to ensure an orderly flow of information. The use of EDI transactions helps provide consistent control over the business processes.

2. Item Maintenance

888 Item Maintenance

The 888 Item Maintenance transaction set is used in the Item Data Alignment process and is a one-way transmission of item information from a seller/supplier to a buyer (i.e., sender to a receiver). The 888 Item Maintenance transaction set is used by trade parties in the food and beverage industries, such as foodservice, produce, and meat and poultry.

The seller transmits, at a minimum, key item information that is needed by the buyer for the order process as well as information that is needed by the ultimate consumer to make an informed purchase decision. The buyer will typically store the item information in an item database.

The 888 Item Maintenance process accommodates information about the vendor selling unit and the consumer unit. If accommodates other item configurations, such as unitized shipment and module information, as necessary.

Item information that may be conveyed between the parties includes the unique item identifier, item name, parties relevant to the product (e.g., broker, vendor, etc.), reference information (e.g., contract number, etc.), selling unit information (e.g., physical attributes including length, width, height, depth, weight, color), consumer unit information (e.g., physical attributes, including length, width, height, depth, weight, color, use instructions, etc.) and item description. The information may include item prices (e.g., selling price, bracket price, etc.).

Similar-to the 832 Price/Sales Catalog transaction set, it also handles item descriptions and product pricing.

3. Product Maintenance

896 Product Dimension Maintenance

The 896 Product Dimension Maintenance transaction set allows for the seller/supplier to provide the physical characteristics of items and may be used in computerized shelf space management systems.

The transaction supports adding dimension data or updating previously provided information.

4. Price Maintenance

879 Price Information

The 879 Price Information transaction set allows a manufacturer, supplier, broker, or other trade party to provide or revise item pricing information.

5. Data Synchronization

897 Data Synchronization

The 897 Data Synchronization transaction set is used in the Item Data Synchronization process. The transaction was developed to support the data requirements for the data synchronization process that makes use of certified data pools, a trading partner registry, and a data synchronization network.

A supplier loads product information to a source data pool and is responsible for ensuring item data accuracy. Key item information, including the item's unique identifier, are sent to a data pool for inclusion in an item registry.

A buyer interested in the products of a specific seller will subscribe to that supplier.  Item information is pushed to the buyer(s). The supplier is responsible for maintaining accurate item information and feeding updates to the source data pool, who in-turn provides updated information to the item's subscribers.

Information passed to or from a data pool can make use of the 897 Data Synchronization transaction set as per the supplier or buyer request. Information that flows within the data synchronization network is in a proprietary XML format.

The 897 Data Synchronization transaction set may be used between trade parties in place of the 832 Price/Sales Catalog or 888 Item Maintenance transaction sets. The 897 Data Synchronization transaction set provides a higher level of item information than that of the 832 Price/Sales Catalog or 888 Item Maintenance transaction sets, including:

• Support for additional item hierarchy levels (pallet, case, level below each, etc.)
• More types of item information (food diet type, item certifications, etc.)
• Enhanced and expanded text capabilities (item warranty, short and long descriptions, and functional use)
• More categories of items (pharmaceutical, beverages, etc.)
• Augmented consumer-focused information, and
• Complete food item nutritional information.

6. Purchase Order Process

850 Purchase Order
855 Purchase Order Acknowledgment

The 850 Purchase Order transaction set is used to provide for customary and established business practices relative to the placement of purchase orders for goods and services. The transaction supports both simple and complex orders, and accommodates various types and levels of information, including:

• Buyer and Seller party information
• Unique purchase order identification
• Order Currency (if the sale pertains to different currencies)
• Tax information
• Allowances and charges
• Packaging information
• Carrier details
• Product price
• Product-related dates
• Delivery scheduling requirements
• Product subline detail, such as to describe a kit (Ex: lamp and lamp shade)

If item and trade party information has been previously shared amongst the trade parties and the parties are making use of unique item identifiers, the 850 Purchase Order transaction can be simple and straightforward, as limited or no text information is required to be transmitted – which reduces transaction set complexity and thereby increases throughputs for all related parties. Rather, the order can be comprised of the trade parties’ names or unique identifiers, the item identifiers, quantity ordered, price, delivery location and delivery date.

The 855 transaction is reporting back from the seller’s purchase order system after the 850 Purchase Order data has been processed. The 855 transaction may affirm the order or may indicate changes to the 850 Purchase Order.

Two additional transaction sets that may be used in the Purchase Order Process include:

• 860 Purchase Order Change Request - Buyer Initiated
  The 860 transaction may be used by the buyer:
  • To request a change to a previously submitted purchase order, or
  • To confirm acceptance of a purchase order change by the seller.

• 865 Purchase Order Change Acknowledgment/Request - Seller Initiated
  The 865 transaction may be used by the seller:
  • To convey acceptance or rejection of changes to a previously submitted purchase order from the buyer, or
  • Is used by the seller to accept, reject, or modify a purchase order.

The combination of the 850 Purchase Order, 855 Purchase Order Acknowledgment, 860 Purchase Order Change Request – Buyer Initiated and 865 Purchase Order Change Acknowledgment/Request – Seller Initiated transaction sets enable the initiating ordering process as well as updates to the order process, from both the buyer and seller.

While the order process can be relatively simple, implementing it needs to accommodate the business processes as well as the technology processes of all involved parties, which adds complexity. When implementing the purchase order process, the timing and time requirements for creating, scheduling, and transmitting of a transaction, and the receipt and processing of transactions on the receiver end need to be thought through. Purchase orders have cut-off dates, and failure to meet such a constraint may mean that an order is shipped but not based on the latest information from one of the trading partners.

While EDI is typically thought of as a batch process, many processes today require real-time processing, which EDI does accommodate. There are many companies that allow certain EDI processes to kick-off based on process criteria rather than on a fixed time schedule.

For trade parties that have not implemented the 860 or 865 transaction sets, multiple iterations of the 850 Purchase Order and 855 Purchase Order Acknowledgment under the same purchase order number may be allowed, up to an agreed-to cut-off point. Or purchase order changes may be handled by telephone, fax, or email.

While EDI keeps the systems in-synch, if an external process – such as a telephone call or email is used, the ‘new’ information needs to be added to the appropriate system information in a timely manner. Otherwise, what gets delivered may not be what the buyer is expecting.

7. Shipment Information

856 Ship Notice/Manifest

At a certain agreed-upon point in the order process no additional changes can be allowed to the order to meet the agreed-upon delivery schedule. The supplier builds the outbound shipment – pallets, cases, drums, etc. – and prepares the shipment for loading and delivery.

As the supplier builds the outbound shipment, information about the items that comprise the shipment – item identification, quantity, lot and batch or serial numbers, item dates, etc. - is captured and loaded to a shipment database for the order. That information is used to build the 856 Ship Notice/Manifest transaction set.

To assist the delivery process and provide for item track and trace functionality, many suppliers will assign a unique identifier to the shipment containers, including cases or pallets. The case or pallet markings will allow for barcode or radio frequency identification capture of the item as it moves from one location to another, including through the transport process. [Note: There are additional carrier/transport EDI transactions that are used to capture the movement of items between supplier and buyer locations, including by air, common carrier, and train. Case or pallet markings enable quicker movement of items during the transport process and are a crucial component of the modern supply chain].

The 856 Ship Notice/Manifest transaction set is a critical transaction that ties the order to the delivery process. If done accurately and correctly, the transaction provides a ‘short-cut’ for the buyer’s receiving process to match incoming product to the open orders in the order system by use of case or pallet markings. The MAN segment (Marks and Numbers) information is matched to the inbound containers by means of the case or pallet barcode or RFID data capture.

• If the supplier is new to the 856 Ship Notice/Manifest process, the receiver will want to verify the shipment against the transaction to confirm that the two exactly match. This means that most, if not every, container/item is checked against the order. The supplier and buyer will typically have a meeting to review the delivery process to iron out any issues.

• If the delivered order and the incoming 856 Ship Notice/Manifest transaction are known to match based on prior shipment history, the physical order can be matched to the electronic order and the order can be marked ‘complete’ by the system. When the shipment arrives, the shipment can be put away in the warehouse or a stock location without any further handling.

• Implementing the 856 Ship Notice/Manifest transaction requires that the sender implement stringent processes and controls to ensure that the shipment container information is captured accurately and the information is routed to the delivery system to create the outbound EDI transaction.

Use of the 856 Shipment Notice/Manifest transaction has grown to include international shipments which may have additional reporting requirements. Recent enhancements to the transaction set include the ability to provide insurance value, declared value, shipment value, pay-on-delivery, and landed cost value for the shipment or individual shipment orders.

As technology has improved over the years, and as businesses have implemented closer working relationships with their trading partners, businesses have looked at streamlining their operations to reduce overall costs. One area discussed was the possibility of remittance payment based on the shipment information.

If 'Supplier A' consistently delivers what is stated in the 856 Shipment Notice/Manifest transaction, why not include invoice information and preclude the need for a separate invoice?

For those industry and trade parties that wanted this option, the 857 Shipment/Billing Notice was developed. When the 857 Shipment/ Billing Notice transaction set is used, a separate invoice is not transmitted between the parties. While it streamlines the operation between the trade parties, systems changes will typically be required on both sides to accommodate the ‘combined’ process.

While the 856 (or 857) allow the seller to notify the buyer about product delivered, should there be a problem, the buyer needs to be able to notify the seller as to what was received and identify discrepancies. Telephone calls, email and faxes take the process outside of electronic commerce efficiencies.

• The 861 Receiving Advice/Acceptance Certificate was created to allow the receiver to notify the sender of the actual product received. The sender than has positive confirmation that the shipment was received whole, or not. This transaction can be important to both parties especially when the cargo is of high value, represents a restricted product category, has special handling requirements, or has other special attributes of concern to the trade parties.

8. Invoice

810 Invoice

As part of the purchase order process, the price of each product must be agreed upon as one of the factors necessary to create a legally binding contract between the seller and buyer. Either upon delivery of the goods or services, or at another agreed-upon time, the seller will provide the buyer with an invoice for the products or services sold, indicating the monies due.

The 810 Invoice transaction set is used to convey invoice information for goods and services. The invoice supports simple or complex information requirements as may be needed based on the product or product category.

At a minimum, the invoice must include a purchase order reference, the total invoice amount including charges, less allowances, before terms discount. Other information may include:

• A description of the product or service
• Purchase Order or contract reference
• Measurements
• Packaging
• Reference data
• Pertinent dates
• Tariff data
• The names of relevant parties to the purchase
• Destination quantity breakout
• Delivery locations
• Tax data
• Subline data
• If relevant, port and vessel information

The invoice data must be complete enough such that the buyer can match the order data to the invoice’s line data. The use of unique product identifiers coupled with a unique purchase order number aids the buyer in clearing open purchase order line items from the order database.

Upon receipt of the invoice, the buyer’s systems will validate the invoice information against their open order database. Should there be a problem with the invoice, the buyer will contact the seller regarding any discrepancies. Once the buyer has completed processing of the invoice, the validated invoice may then be scheduled for payment according to the agreed-upon terms.

9. Payment

820 Payment Order/Remittance Advice

The last step in this process is issuing payment for the delivered goods and services.

The 820 Payment Order/Remittance Advice transaction set accomplishes the payment process by supporting several different payment-related scenarios. It can represent a:

• Payment order only
• Remittance advice only
• Payment order and Remittance Advice

When used as a payment order only, the transaction is transmitted to a financial institution directing funds to be transferred from an originating company (the payer/buyer) to the receiving company (the payee/seller). Payment may be made using one of several different financial mechanisms, the most common of which are check, ACH (Automated Clearing House) or Federal Reserve Wire Transfer. Each payment format has its own unique informational requirements that must be met to enable a payment.

• Unless paying in-full (based on the invoice), the payer will need to provide information to the payee as to how the moneys are to be applied. Without such information, it may be impossible for the payee to clear the invoice from the system.

As a remittance advice only, the transaction is sent from the payer to the payee informing the payee that payment is pending or will be received for the identified invoices.

• The remittance advice allows the payee (seller) to pre-apply payment to the open invoice line items and clear invoices from the system (assuming the information is transmitted prior to the payment). Payment is made by the agreed-to payment format, such as check or ACH.
• While some companies may fax or email a remittance advice to the seller, this does not represent an optimum solution for either party as it will typically require manual processing, which adds more time and introduces possible errors to the overall process.

As a payment order and remittance advice, the payment and remittance information flow through the payment network together, such as by using the ACH system. This process begins with the originating financial institution receiving a file that contains both payment and remittance detail, which then travels through the ACH network to the receiving financial institution, who then provides the information to the receiving financial party.

• By sending ‘dollars and data’ together, there are typically fewer reconcilement issues when applying the payment.
• By sending remittance data through the financial network, the sender and receiver will also typically incur additional changes due to the larger payload going through the ACH network.

The 820 Payment Order/Remittance Advice is an efficient transaction that provides options for initiating payment and remittance advice information between trade parties.

The Supply Chain EDI transaction sets offer sellers and buyers a set of tools that will streamline the product data and order-to-cash business to business processes for the day-to-day buy/sell activities of the modern enterprise. These transactions also support business to consumer activities making use of online selling and purchase processes. The EDI data can be integrated with other systems to support existing and new directions as commerce continues to evolve.