..
..
...
..
.
.
.
.
.
.
.
.
.
Produce Marketing Association
Electronic Data Interchange
TABLE OF CONTENTS
FOREWORD. . . 1
SECTION I . . . 3
INTRODUCTION . . . 3
SECTION II . . . 4
ECRANDEFR:TECHNOLOGY INITIATIVES . . . 4
Electronic Data Interchange . . . 5
Product Identification . . . 7
Bar Code Technology . . . 8
Summary . . . 9
SECTION III . . . 10
EDI IN PRODUCE:BUSINESS PERSPECTIVE . . . 10
Grocery Dry-Goods vs. Produce . . . 10
Business Drivers and Benefits . . . 11
Roadblocks and other considerations . . . 12
Summary . . . 14
SECTION IV . . . 15
PRODUCT IDENTIFICATION:BARRIERS AND SOLUTIONS. . . 15
Enabling EDI through Product Identification. . . 15
Maximizing EDI Benefits . . . 16
Current Product Identification Framework . . . 16
Technical Overview . . . 18
Product Identification (database synchronization) . . . 23
Option 1) Bulk Produce: PLU Codes . . . 23
Option 2) Bulk Produce: Extending the PLU Code . . . 25
Option 3) Packaged Produce: PEIB UPC Item Codes . . . 27
Option 4) Direct Attribute Mapping . . . 28
Option 5) EDI Task Force Recommendation: UPC Case Codes . . . 29
UPC Case Codes: Bulk Produce . . . 32
UPC Case Codes: Packaged Produce . . . 34
Summary . . . 35
SECTION V . . . 36
EDI IN PRODUCE:TECHNOLOGY IMPLEMENTATION. . . 36
What does EDI in produce look like? . . . 36
EDI Data Considerations . . . 38
SECTION VI . . . 40
EDIIMPLEMENTATION:PRACTICAL CONSIDERATIONS . . . 40
Planning. . . 40
Software, Hardware & Services . . . 40
How do I begin? . . . 43
Summary . . . 43
APPENDIX A: EFFICIENT CONSUMER RESPONSE; EDICORE COMPETENCIES (GROCERY) . . . 44
APPENDIX B: INTERNET . . . 46
GLOSSARY OF TERMS . . . 48
..
..
..
..
..
Foreword
For several years, members of the produce industry have discussed the potential benefits of EDI technology, but as of late 1998 few companies have actually achieved any degree of success.
In late 1997, the Produce Marketing Association appointed the Electronic Data Interchange Task Force to investigate how companies can implement EDI in the produce industry. Doug Grant, David Oppenheimer Group, served as chairman of the task force. Serving on the task force were Mike Agostini, Food Lion, Inc.; Kathryn Courtney, Calavo Growers of California; Jim Doherty, Washington Apple Commission; Dick Fox, Uniform Code Council; Jobie
Johnson, The Tobi Company, Inc.; Terry Rudkin, Sunkist Growers, Inc.; Kent Shoemaker, Red's Market; Stephen Whitney, Canadian Produce Marketing Association; Tim York, Markon Cooperative, Inc.; and Greg Zwanziger, SUPERVALU, Inc.
PMA’s role is one of sponsorship, providing the EDI Task Force with assistance and
coordination where necessary. Volunteer task force members represent various segments of the produce industry, including retail, foodservice distributors, wholesalers, and
grower/shippers. Beyond the initial document, the EDI Task Force will continue to work on case code attribute standards and EDI transaction data elements, as well as participating in PMA-sponsored events to further EDI use in the produce industry.
This report explains how companies can implement EDI in the produce industry. Current issues and considerations are analyzed, and recommendations provided to overcome barriers. The overall intention is to educate readers about what EDI is, what it can do for their businesses, and how to make it work. The first four sections are intended for a general business audience (those people that may be involved in making EDI decisions for their companies), and the last two sections are intended for a more technical audience (those people charged with
implementing EDI).
• Section I provides a general introduction to EDI.
• Section II introduces the ECR (Efficient Consumer Response) and EFR (Efficient Foodservice Response) initiatives and provides a historical overview of EDI, product identification, and bar code technology as it relates to grocery retail and the product distribution chain.
• Section III highlights the potential business benefits and discusses current roadblocks preventing EDI from being widely implemented in produce.
• Section IV examines the product identification issues in greater depth and provides recommendations for use in EDI.
• Section V discusses specific EDI transaction sets for use in the produce industry.
• Section VI discusses hardware, software and communications options to implement EDI technology.
The wave of the future is in binding companies together such that they seamlessly move product through the distribution chain with maximum efficiency.
Implementation of EDI should be viewed as a journey, not an end in itself. It will take an ongoing investment of skilled personnel, technology, and financial
..
..
..
..
..
Section I
Introduction
Electronic Data Interchange (EDI) is a key enabling tool that can play a vital role in driving inefficiencies out of the supply chain and facilitate new strategic business processes. The goal of this report is to expedite the adoption of EDI and related technologies in the produce industry. The basic foundation to make this a reality has already been set in the dry grocery sector. This report focuses on how these enabling technologies can be applied in fresh produce to help businesses work together to create stronger relationships while eliminating unnecessary costs from the produce distribution chain.
The key to unlocking these efficiencies can be found by embracing industry standards. Through organizations such as the Uniform Code Council (UCC) and the Produce Marketing Association (PMA), voluntary industry guidelines have been developed for EDI, product identification, and bar coding. Representatives from all sectors of the industry worked together to define these voluntary
standards.
These industry standards are voluntary guidelines set forth by these organizations. Companies are encouraged to adopt these guidelines to drive unnecessary costs and inefficiencies out of the supply chain. Proponets of this paper hope companies will view these guidelines as a necessary part of doing business, and incorporate them into their future plans.
EDI has been used for over 25 years and has proven to generate substantial savings for many industries. EDI is successfully being used in the grocery dry goods section, but has experienced limited implementation in the fresh produce section. The purpose of this report is to outline current issues and provide recommendations to overcome these hurdles.
..
..
..
..
..
Section II
ECR AND EFR: Technology Initiatives
In January 1993, the grocery industry announced the Efficient Consumer Response (ECR) initiative. The main objective is to drive unneeded costs (estimated up to $30 billion) from the grocery distribution system. Processes within the distribution chain were analyzed. To address areas of inefficiency and cost, several business and technology initiatives were recommended for deployment; including Electronic Data Interchange (EDI), product identification, and bar coding. All ECR initiatives (including continuous replenishment, category management, cross-docking, and returnable packing cases) rely on EDI technology to fully enable and maximize benefits.
The ECR Electronic Commerce Process Improvement Group has identified the EDI transactions that provide the core foundation that is necessary to do business within the dry-goods side of the grocery industry. At this time only the purchase order and invoice transactions have achieved critical mass. Companies that have not yet implemented these two transactions are already significantly behind the rest of the industry. In the long-term, the produce industry will need to consider all identified transactions to continue to improve efficiencies in the distribution chain. (See Appendix A.)
The key trading partners to consider for ECR initiatives include: grocery retailers and operators providing goods and services to consumers, and suppliers (mainly grower/shippers) that provide goods and services to retailers and operators. Other trading partner relationships take an intermediary role in the distribution chain. They include wholesalers, food distributors, food processors, buying groups, brokers, distributors, cooperatives, importers and exporters. Regardless of where a firm is situated within the distribution chain, it may take on part of the buying role of the retailer and/or the provisioning role of the supplier depending on the business transaction. Therefore, despite the structural complexity of the produce industry, most firms perform common processes such as ordering, shipping/receiving, and billing – all of which are addressed by EDI technology.
The Efficient Foodservice Response (EFR) began its work to capture $14.3 billion in savings in January 1997. Like ECR, EFR focused on some core initiatives. The three core initiatives of EFR are standard product identification, bar coding and
EDI. It was estimated that EDI would help save the foodservice industry up to $6.6 billion annually (close to 50% of the entire initiative). The transactions recommended for the foodservice industry are similar to those recommended by ECR, except in a different order. The transactions in both initiatives hold the promise of efficiencies and savings, both of which the food industry can no longer ignore.
Electronic Data Interchange
Electronic Data Interchange (EDI) is not new technology; in fact, it has been in wide use in nonagricultural industries such as transportation, grocery, automotive, finance, health care, and petroleum since the 1970s. Literally billions of dollars have been saved, and EDI continues to have a profound effect on improving efficiencies for many industries.
As with the produce industry, these industries traditionally conducted business on paper, often using preprinted business forms to exchange information. However, with the explosive growth of products and services during the 1970s and 1980s, these industries found a more expedient, cost-effective means to communicate and process business transactions. Computers and high-speed communications technology produced a solution to the 'paper' avalanche - electronic data interchange or EDI.
Early electronic interchanges used primitive, proprietary formats agreed upon between individual trading partners. However, the disadvantages of developing and programming for a wide range of varying business document formats required by different trading partners mitigated much of the benefit in the early stages of electronic commerce.
As early as the 1960s the transportation, manufacturing, and financial industry groups formed cooperative efforts to develop and administer intra-industry standards for business transactions such as purchase orders, bills of lading, invoices, and remittances. The trend continues today, in adding new business transactions and further refining standards to work across all EDI-enabled industries.
Both national and international EDI standards have been developed and are in use today. ASC X12 is the national standard used in North America; and other countries throughout the world have developed their own national standards. EDIFACT was developed to bring a global solution to EDI standards and is gaining widespread acceptance when utilizing EDI between countries. Each of these standards define the ‘format’ and ‘content’ of the EDI transaction; much like how an envelope has a standard format for the address, and the content inside can
be a letter, a check, etc. However, the specific content (and meaning of the data) inside EDI transactions is further defined by different industry segments.
Today the Uniform Code Council (UCC) administers the Uniform Communication Standards (UCS) and the Voluntary Inter-industry Commerce Standards (VICS) EDI publications and maintenance process. UCS is used predominately in the grocery and foodservice channels and related sectors, while VICS is used in the general retail sectors such as apparel and hardware lines. Both UCS and VICS are subsets of the ANSI X12 standard. Because the national standards must accommodate a wide variety of industries and their practices, hundreds of elements that are unneeded in the grocery and foodservice industries are included in the ‘generic’ national standard. The purpose of developing these industry subsets is to narrow the scope of the standards to the specifics of a common industry, giving each party a more clearly defined approach to doing business utilizing EDI. This minimizes the need for each organization to program differently for each of their trading partners.
“Retailers indicate that EDI was used for over half of all their grocery volume in 1996, and expect usage to increase up to 90% by the year 2000. EDI usage is mature on the dry goods side of grocery, so the expected increase will need to include perishables. Historically, the produce industry as a whole has lagged behind with 1997 usage from Grower/Shippers at 2.4 % and Retailers at 14.7%. However, all produce firms are very optimistic about EDI, estimating that by the year 2002, produce industry usage rates will increase to between 33% and 50%.”
(FreshTrack‘97)
Although the future growth of EDI in the produce industry looks promising, a large technology and knowledge gap exists for produce firms wishing to implement EDI. Especially frustrating is the confusion over product identification terminology and lack of usage guidelines. Overall, there needs to be a better understanding of EDI and its linkage with other key technologies.
Proprietary data exchange solutions have been developed to try to create supply chain solutions for the produce industry. While proprietary EDI solutions can provide a quick hit in getting things moving, they usually bog down when they are to rolled out to a wide number of partners. Unfortunately proprietary solutions typically lock companies into formats developed by one or a few members of the industry and force people to utilize specific hardware and/or software. This becomes a major stumbling block to driving efficiencies throughout the industry. The standards process itself creates a forum to assure that all members of the industry evaluate business requirements. Furthermore, utilizing standard EDI formats allows companies to choose from a wide range of EDI software and hardware service providers offering robust solutions to more closely meet their
needs. EDI translation software makes it far easier to interface with a company’s internal applications.
This report focuses on establishing EDI between retailers and suppliers. It does not specifically address Direct Store Delivery systems, or data exchange between growers and shippers. It is important to note that there are many other entities providing services for the produce industry, many of which are fully capable of conducting EDI transactions today. These include customs, warehouses, shipping lines, air cargo, trucking firms, and financial institutions to name a few. The original investment in EDI technology will continue to provide value as EDI is extended into these other areas.
It is due to the long history and experiences of others that the produce industry can enjoy today the efficiencies of EDI standards, and thereby avoid the pitfalls of imposing different proprietary EDI formats on each other.
Product Identification
During the mid-1980s, two national associations representing the fresh produce industry – PMA (Produce Marketing Association) and the UFFVA (United Fresh Fruit and Vegetable Association) developed a joint task force aimed at improving product identification of both bulk and packaged produce sold at retail.
The main problem to address at the time was suppliers assigning their own UPC Item code to each packaged produce item. While this method worked in dry goods, it caused problems in produce since there are often multiple suppliers for a given retail SKU (stock-keeping unit). This led to the need to group produce items into commodities in order to make scanning at retail checkout practical.
In the late 1980s, the initial task force working on these issues formalized itself into the PEIB (Produce Electronic Identification Board). The PEIB developed two generic code sets as follows:
• PEIB PLU codes (Price Look Up codes for produce sold in bulk)
• PEIB UPC Item codes (for packaged fixed-weight items)
It’s important to note that the main objective of these standard codes is to provide retailers an industry standard code set (PEIB PLU/UPC Item codes) for their POS (point-of-sale) checkout systems.
Today, the PEIB continues to accept applications for new item identity numbers representing a widely used commodity, variety, size, grade, weight or unit of packaged produce. (These standard codes are documented in the PMA publication ‘A Guide to Coding Fresh Produce.’)
“Retailers report that almost 100 percent of total grocery sales (dry goods and perishables) are coded for checkout in some electronic format. For produce, UPC Item codes account for 40 percent, PLU codes for 50 percent, with the remainder being retailer-assigned PLU codes” (FreshTrack’97).
Product identification terminology used throughout this document is as follows: (the term ‘product code’ will be used throughout the document unless a specific term is required for clarification).
• Generic PEIB PLU codes.
• Generic PEIB UPC Item codes.
• Supplier-maintained UPC Item codes (used in dry goods and fresh-cut packaged produce).
• Supplier-maintained UPC Case codes (or SCC-14 Case code).
• Supplier proprietary product codes and descriptions.
• An ‘item’ can be referred to as a ‘product,’ ‘package,’ or ‘consumer pack’ and refers to the contents inside of a ‘case.’ This includes, bulk produce (with PLU) and packaged produce (with UPC item code), both of which are identified at retail checkout. Generally, an ‘item’ is equivalent to the retail SKU (stock-keeping unit).
• The ‘case’ is one of many ‘units of sale’ types (e.g. trays, bins, bales, master cartons, or other terms for the case – boxes/cartons). In other words this is the packaging unit on the supplier’s price or product code list. For ease of use, the term ‘case’ in this document refers to all types of ‘units of sale’ for produce. The ‘case’ is the primary level of packaging the supplier provides and is used throughout the ordering, shipping, and billing processes in the supply chain.
• The ‘pallet’ or ‘shipping unit’ refers to the temporary collection of cases. Pallets are marked with uniquely numbered ‘license plates’ for logistics purposes.
Bar Code Technology
In another initiative aimed at deploying technology, the GMA (Grocery Manufacturers of America) applied newly developed UCC Case (and pallet) marking standards to the grocery industry. The results were published in the 1996 document ‘Case Markings: A Common Language for Shipping Containers.’ In 1996, PMA endorsed the UCC Case marking guidelines and product identification as incorporated in this publication. This was an important step in advancing EDI for produce in that it provided a framework in which EDI transactions can take place with necessary specificity at the case level (see Section IV).
The UCC Case marking standards provide a common numbering scheme for identification and tracking of items, cases, and pallets. In other words, they
provide structure and format of the printed data, whereas product identification gives meaning to the data. The case marking standards are:
• UPC Item Code (the Universal Product Code identifies the ‘item’ and acts as the ‘unit of sale’ between the retailer and the consumer).
• SCC-14 (the ‘Shipping Container Code’ identifies the ‘case,’ and acts as the ‘unit of sale’ between retailer and supplier. The SCC-14 code is commonly referred to as the ‘Supplier-maintained UPC Case Code’ or ‘UPC Case Code’).
• SSCC-18 (the Serial Shipping Container Code uniquely identifies ‘pallets’ and other shipping units).
UPC, SCC-14, and SSCC-18 codes have associated bar-code symbols
(UPC/EAN, UCC/EAN-128 and Interleaved 2 of 5), which allow the codes to be scanned and automatically fed into various applications. The bar codes themselves are simply a series of bars and spaces that contain various numbering schemes (including UPC, SSC-14, and SSCC-18 codes).
By scanning the item, case, or pallet bar code at any stage in the distribution chain, any person handling the produce can have real-time product information described in the format of his or her internal computer system.
“Over one-half (63.6%) of the produce grower/shipper segment report that they are using case coding to some degree today.” (FreshTrack’97) Moving away from hand-written and nonstandard formats to the new UCC Case marking
standards will play a significant role in improved accuracy and efficiency throughout the distribution chain. Sharing shipment information (via EDI) prior to arrival will lead to better scheduling and efficient handling. Lastly, utilizing bar code scanning technology will provide accurate, real-time information and reduce labor costs associated with product tracking, shipping and receiving, and quality control.
Summary
The ECR and EFR initiatives are the major drivers in improving efficiencies for the food industry. To maximize the benefits of EDI, product identification and bar coding should be given strong consideration for implementation.
In comparison to EDI, which provides the ‘information flow,’ bar codes relate to the physical product flow. Product identification then provides the linkage between EDI and physical bar codes.
..
..
..
..
..
Section III
EDI in Produce: Business Perspective
“In 1997, retailers report using an average of 178 produce suppliers; with large retailers averaging 355. However, over two-thirds of their purchases were acquired from their top 10 suppliers.” (FreshTrack’97)
There are few industries where trust, reputation, and reliability are as essential to success as in the produce industry. The fact that we’re dealing with a perishable product, with variable quality, availability, and price makes it very difficult to automate through technology. The produce industry will always remain a ‘high-touch’ industry requiring constant attention to ensure high product quality, and to ensure that it is delivered to the right customer at the right time. The benefit of EDI is that it will take away much of the paperwork and associated manual effort and will allow more time for ‘high-touch,’ customer-focused activities.
The highest probability of success with EDI will likely be with those firms that initially focus on their key business partners. Business practices are
well-established and understood, and the level of trust is high: important ingredients to establishing an EDI program. Once EDI is established with key partners, the return on investment will be high relative to the number of business transactions conducted.
With all things being equal, business trade will go to those companies that can perform efficiently and cost-effectively. There are few technologies that have the potential of EDI to achieve this goal. EDI provides an end-to-end information flow that supports the sales and distribution of produce from the grower to retail. It binds ‘trading partner’ relationships together, provides more accurate, relevant, and timely information, and at the same time reduces manual entry work and associated paper.
Grocery Dry Goods vs. Produce
On the dry goods side of grocery, EDI is becoming well-established between trading partners. Purchases are driven from the retailer (pull model), which in turn drives supplier processing cycles for replenishment. For each retailer ‘item’ (or SKU) there is a single supplier providing the product at a given time. Dry goods
have a long shelf life, and prices and supply are relatively stable. The number of retail items within a ‘case’ and the number of ‘cases’ per pallet is pre-determined. The ‘case’ is the unit of sale between buyer and seller. Cases are marked with the UPC Case code (or SCC-14 code). Associated EDI transactions use the UPC Case code to synchronize buyer/supplier databases. Overall with dry goods, the ‘content’ of the EDI transaction is relatively straightforward.
On the produce side of grocery, EDI is not well-established although there has been tremendous interest in the industry to move forward. Many retailers view produce departments as a way to differentiate themselves from competitors. Computer automation and information gained through EDI (and other sources) are essential tools for business success. Traditionally, purchases are driven from the supplier (push model), in which produce is put on the market with varying quantity, quality, and price. As there are often multiple suppliers for ‘essentially’ the same product through the year, the produce industry is in large part still commodity-based.
There are few examples of ‘continuous replenishment’ or ‘vendor-managed inventories’ in the produce industry. Demand and supply are more volatile compared with dry goods. However, with new techniques in farming and better distribution and quality control practices, more accurate market forecast
information is becoming available. Together with utilizing category management and CPFR (collaborative planning and forecast replenishment) guidelines, produce is starting to move from a ‘push’ to a ‘pull’ sales/distribution model. Retailers want to reduce costs and ensure supply, which leads toward establishing a continuous replenishment program, whereby business transactions are repeatable with minimal changes. (Contract pricing and specific products are agreed to and supplied for a period of time, as opposed to unique ‘one-off’ orders.) If produce firms can move toward a continuous replenishment model, even greater return on investment will be realized for EDI technology.
Business Drivers and Benefits
Consolidation in the produce industry continues; buying groups and suppliers are getting larger and fewer. Many are strongly committed to EDI because of the potential for efficiencies and cost savings. Companies that can establish EDI programs with their key business partners will achieve a significant competitive advantage.
Grocery retailers have seen the benefits of EDI in dry goods, and want to achieve the same (or greater) benefits in produce. Given the perishable nature of produce, retailers still want the highest and most consistent quality available. Throughout the distribution chain, there is a drive toward reduced shrinkage and loss, and
minimizing rejection at receipt. To achieve these goals, sales and logistics information needs to be shared in a timely manner to ensure overall accuracy of information.
Without question, EDI will result in a major paradigm shift for most companies. Overall, staff will enter much less raw data into the system and deal with less paper; freeing time for value-added, knowledge-based functions (such as, demand/supply forecasting, expanding product and market knowledge, contract sales, category management, etc.). EDI will allow for improved business
relationships, because it will free personnel up from ‘clerical’ work, allowing more quality time with business contacts and performing more value-added functions. As a result, firms will be able to deliver higher value and have greater capacity for growth.
Many potential benefits of EDI will be realized in the produce industry as follows:
• Provides a common ‘trading’ platform available industrywide.
• EDI capability will likely be a mandatory requirement for doing produce business in future.
• Strengthens trading partner relationships.
• Paper not lost or delayed in mail, or held up in other processing.
• Invoices are more likely to get paid on time, with fewer short-pays.
• Reduction in telephone calls, paper and postage costs.
• More timely and accurate updates of data resulting in better decision-making.
• Less time performing data entry, allowing more time for retailer service.
• Better audit trail and reconciliation.
• Enhances category management by providing detailed supplier performance data (vs. scan data which is not supplier specific).
• Data is formatted and shared in a consistent way across the industry.
• Better ability to recall product through the distribution chain for food safety purposes.
• The speed of electronic communications for business transactions is well- suited to the fast pace of the produce industry.
Roadblocks and Other Considerations
With all the potential benefits gained by implementing EDI, why hasn’t the technology yet made significant inroads in the produce industry? The largest stumbling block is lack of product code guidelines and incompatible product code
data stored on retailer and supplier computer systems. Further problems arise due to the nature of the produce industry: multiple suppliers for a single SKU at retail, shipping substitute produce from that which was originally ordered, volatile pricing and availability. Finally, there are the common problems many firms encounter when implementing any new technology: lack of existing systems functionality, lack of technical knowledge, other priorities, and cost of implementation.
Current use of EDI in produce is via proprietary systems (which are not usable industrywide), or via the industry standard EDI with transactions lacking product code data which allows automation at the receiving end (for example, sending product descriptions only without an associated product code). Most retailer systems store PEIB PLU/UPC Item code data with no linkage to supplier proprietary product codes.
The produce industry is also unique in that ‘what is ordered’ may not always be ‘exactly what is received’ (this may occur as much as 20 percent of the time). Depending on availability and quality at shipping, warehouse staff may substitute product that is ‘deemed’ to be substitutable for a particular retailer. Most often, variations are in grade, pack, label, brand, and size.
A small percentage of produce is sold on a ‘consignment’ basis, where pricing is determined once the product has been physically received and assessed by the retailer. Other pricing changes can take place after the sale such as market and quality adjustments and product returns.
With the fast pace of the produce industry, (prices and availability fluctuating daily) it would be difficult to use EDI to keep retailers’ systems fully up to date in the same manner done with grocery dry goods (EDI transactions such as Item maintenance, Pricing, and Promotion). Even with EDI, the sales cycle will likely require some communication via the telephone (or other technologies including facsimile, Internet e-mail, and web sites) to convey produce quality, pricing, availability, and terms of sale.
The long-term trend of the produce industry is a migration toward a ‘pull’
sales/distribution model. This may result in a more stable environment in which to form contract agreements, where quality, volume, distribution, and pricing are set for a specified length of time. This ‘pull’ model is very favorable for firms wishing to receive a high return on EDI investment as it allows for a greater degree of automation with minimal human intervention.
• Retailers often have separate business processes and computer systems for
produce and dry goods. In some cases, systems originally built for dry goods have been retrofitted for use in produce, with inherent limitations not easily overcome.
• There is a lack of ‘success’ stories in the produce industry. Very few companies are successfully using EDI in a fully integrated manner.
• Skilled software developers knowledgeable in the produce industry are scarce. Of these, many are committed to other projects such as solving the Year 2000
problem.
Summary
EDI is proven in other industries including grocery dry goods, and promises to offer the produce industry many benefits. However, there are many issues and considerations, such as product identification, which have hampered the speed of implementation in produce.
..
..
..
..
..
Section IV
Product Identification: Barriers and Solutions
Enabling EDI Through Product Identification
Why is product identification such a major stumbling block for implementing EDI in the produce industry? After all, ordering, shipping, invoicing, and other transactions take place thousands of times daily between business partners, so why is it so difficult for EDI to perform some role in automation?
First, most sales transactions between business partners require a person at each firm to play the role of an interpreter. For example, the buying process involves describing the product of interest so that both parties have a clear understanding. Typically, these are qualitative factors that allow price determination at the ‘case’ level (for example, origin, commodity, variety, size, grade, and pack). Once other details of the transaction are completed, it takes a person at both companies to interpret the product information correctly and update their respective computer systems. As subsequent transactions take place for the same sales order (confirmations, receiving, shipping, invoices, payments, etc.), the manual interpretation process is repeated at each step in order to update computer systems. Most often this involves interpreting a paper document sent from the business partner, and performing the necessary data entry work.
Computer systems are not adept at performing this kind of interpretation. Product descriptions alone are not usable for automation of EDI transactions. Instead, computers need to match associated product codes to interpret the information correctly.
Throughout the produce industry, computer systems store product codes and descriptions differently. Retail buyer systems typically store data at a summary level using PEIB PLU/UPC Item codes, or proprietary product codes. Supplier systems store data at a much more detailed level (in their own proprietary product code format), mainly to support logistics and other information requirements of their business. Both buyers and suppliers have legitimate business reasons for storing product data in their respective formats and levels. Unfortunately, this means that product code data across the industry is currently incompatible to conduct EDI transactions between trading partners.
Fully enabled EDI requires product code data to be synchronized between buyer and supplier databases. The produce industry must agree on the method used to define and synchronize product codes. Otherwise, EDI can only reach the level of performing the role of an expensive fax machine – the return on investment isn’t there long-term.
Some companies have quickly started their EDI programs by not concerning themselves about product identification and database synchronization. For
transactions such as invoices, they send product descriptions only. The result is that the receiver of the EDI transaction will not be able to integrate the data and
automate his system. (Manual data entry will be required.) The first priority in establishing EDI with trading partners is to synchronize product codes between their computer systems.
Maximizing EDI Benefits
At this time, few trading partners have established ‘fully integrated’ EDI. However, there are a few companies that are using their own proprietary EDI methods in a limited degree, or are using X12 standards but in a ‘non-integrated’ fashion. Again, there are two main methods of EDI implementation. The simplest approach is ‘non-integrated,’ whereby one trading partner issues an EDI transaction, and the other trading partner receives it but must re-key the information into his computer system (much like re-entering a computer fax transmission or taking an order over the phone). With the more advanced ‘fully integrated’ method, the receiver of the EDI transaction ‘maps’ inbound transactions to his business application, performing the necessary data translation automatically. The closer implementation is to the ‘fully integrated’ method, the greater the benefits that will be realized.
The highest degree of efficiency can be attained through establishment of a
continuous replenishment model. EDI Purchase Order requests may be triggered at retail, or inventory replenishment is fully managed by the supplier.
The following section reviews the product identification framework in use today, and covers some of the key issues that the EDI Task Force considered before arriving at a recommendation.
Current Product Identification Framework
“Retailers store on their computer systems an average 507 SKUs for their produce departments, and suppliers store an average of 425 SKUs. Produce sold in bulk form (PEIB PLU codes) accounts for 75% of the volume, compared to packaged produce (PEIB UPC Item codes) at 25%,” (FreshTrack’97). Note that a small
percentage of both PEIB PLU/UPC Item codes in use today are retailer-assigned (i.e. not generic across the industry).
While useful in tracking sales volume, price, and identifying produce at retail check out, PEIB PLU/UPC Item codes do not track the supplier, and only define produce at a summary level. (Note: the PEIB UPC Item code does provide more detail than the PLU code.)
In contrast, suppliers typically store several thousand product codes, with some large suppliers storing tens of thousands. Suppliers maintain their own unique set of product codes and associated descriptions. For example, in addition to ‘product origin’ being at the level of country or state, the supplier stores detail down to a county, ranch, or even orchard level. Similar levels of detail may be maintained for grades, size, pack, and other attributes. In theory, if supplier product codes were to be rolled up into a summary level, they would represent the average 425 SKUs per supplier as reported above. Retailer and supplier product codes currently do not match in format, in definition, or in relationship.
Suppliers receiving product from other business partners must perform other product code translations (such as importers receiving product from offshore, shippers or distributors receiving product from other growers).
The foodservice industry tends to store product code data in a similar manner as produce suppliers. They often maintain their own unique set of product codes and descriptions at a similar level of detail to that of suppliers. (See Option 4 “Direct Attribute Matching.”)
In essence, the produce industry as a whole is characterized by a summary-level ‘product identification’ at retail checkout, with increasing levels of ‘product identification’ detail through the distribution chain.
Technical Overview
PEIB PLU Code
At retail checkout, the PLU code identifies the item, and the quantity or weight determines the sale price. PLUs define the commodity, variety, high-level size description (large or small), and a high-level origin (North America East, West, Central, etc.). Retailers enter (or initialize) the PLUs into their computer system to create their internal SKU (stock-keeping unit) code.
S y m b o l o g y
D a t a C o n t e n t
7
1 2 3 4 5
1 2 3 4 5
9UPC Structure with Bar code
U
PC Item Code
For grocery dry goods, the UPC Item code defines a ‘packaged’ product. The UPC Item codes are comprised of a manufacturer ID and product ID (which is used as a reference key to the product description). The combination of
manufacturer ID and product ID provides a unique identification of the product. The UCC assigns one manufacturer ID to the supplier (see Section VI - How do I begin).
The supplier then assigns product IDs to each UPC Item Code description
maintained in his database. The supplier in turn notifies the retailer of the UPC Item code (and description), which is then entered (or initialized) into their computer system to form their SKU.
For the produce industry, the PEIB has defined generic UPC Item codes, identified by the manufacturer ID of 33383, and 5-digit product ID’s which are associated to specific product descriptions (see the PMA ‘Guide to Coding Fresh Produce’). The retailer enters the PEIB UPC Item code to setup a SKU for the packaged item.
The PEIB UPC Item codes are comprised of the following attributes: Item Number (same as the 5-digit Product ID), Region Area (Origin of the produce at a country or state/province level), Variety, Grade, and a combined size/weight/count
UPC Case Code
The UPC Case code has exactly the same structure as the UPC Item code (described above). The difference is that the product ID number and associated description always refer to the case (the ‘unit of sale’ between retailer and supplier).
For most industries, the supplier assigns product ID’s to each UPC Case Code description maintained in his database. The supplier in turn notifies the retailer of the UPC Case code (and description) to synchronize product codes. Both parties must maintain the same product ID and reference it to associated internal product codes/descriptions on their respective computer systems.
It is highly desirable for produce industry suppliers to mark cases with the UPC Case code (or even better the SCC-14 code below). This will allow retailers to better track cases as they are received and distributed to store locations. For grocery dry goods and food services segments, it is a prerequisite to mark cases before establishing an EDI trading partner relationship.
SCC-14 Case code
SCC-14 in UCC/EAN-128
The SCC-14 Case code performs exactly the same role and has similar structure as the UPC Case code. The main difference is that the SCC-14 Code conforms to international standards. The SCC-14 Case code is the preferred format to physically mark cases.
‘(01)’ indicates that the bar-code structure is in SCC-14 format.
( 0 1 ) 0 0 6 1 4 1 4 1 0 0 0 4 1 8 1 digit Pckg Indicator 12 digit core # 1 digit check digit
‘0’ indicates that the package is a case or carton.
‘0614141’ indicates a specific manufacturer (or grower/shipper). ‘00041’ indicates a database key used to cross-reference a product description.
‘8’ check digit (calculates integrity of previous numbers listed).
SSCC-18 License Plate
SSCC-18 in UCC/EAN-128
The SSCC-18 license plate is comprised of a manufacturer ID and a serialized number (instead of product ID) to uniquely track the pallet. The serialized number is generated by the supplier and acts much like a car ‘license’ plate.
‘(00)’ indicates that the bar-code structure is in SSCC-18 format. ‘1’ indicates a package type of “pallet.”
‘0714141’ indicates a specific manufacturer (or grower/shipper).
‘555555555’ indicates a database key to cross-reference a product description. ‘7’ check digit (calculates integrity of previous numbers listed).
( 0 0 ) 1 0 7 1 4 1 4 1 5 5 5 5 5 5 5 5 5 7 Pckg Type Company Prefix Serial No. Check Digit
( 0 0 ) 0 0 6 1 41 4 1 1 23 4 56 7 89 0 SSCC 0 0614141 123456789 0 SHIP TO POST 45458 B/L 853930 PRO 2895769860 GRAND SUPPLIER RUE ROYALE 92 1000 BRUSSELS BELGIUM GREAT VALUE MKTS. 8163 NEW CAJUN RD. DAYTON, OHIO 45458 USA FROM TO ( 421) 45458
The grocery industry is migrating from proprietary ‘pallet tags’ to the SSCC-18 as it provides a standard, flexible format and meets international standards. The SSCC-18 can be used for tracking product from grower to the point at retail where the pallet is broken down. For EDI, the 856 Ship Notice manifest transaction would contain all SSCC-18 (pallet tag) entries for the shipment.
4 The SSCC-18 is the single mandatory piece
Product Identification (Database Synchronization)
The key factor in determining a product identification solution is the ‘level’ at which the retail buyer wishes to conduct EDI transactions. In other words, this is the level of detail that trading partners computer systems would need to store product code data to achieve fully integrated EDI.
The main roadblock to overcome is that the PEIB PLU/UPC Item codes are not specific enough for suppliers to fulfill an order. For bulk produce, a single PLU may potentially match to hundreds of supplier product codes. For packaged fixed-weight produce, PEIB UPC Item codes are more specific than PLU numbers, but still lack the detail necessary to conduct fully integrated EDI.
The EDI Task Force evaluated several options before arriving at a
recommendation. Each of the options was assessed as to whether they could work in a fully integrated EDI mode of operation.
Some produce firms currently use one of the following options to conduct EDI transactions, but have either unique trading partner relationships, or are using the option in a non-integrated fashion. Again, the purpose of the EDI Task Force is to provide voluntary EDI guidelines for the produce industry as a whole. It is up to each company to decide whether to adopt the guidelines or continue with its own EDI implementation method.
Option 1) Bulk Produce: PLU Codes
Again, PLUs define the commodity, variety, high-level size description (large or small), and a high-level origin (North America East, West, Central, etc.). The following example outlines the limitations of using the PLU to conduct fully integrated EDI.
Retail Buyer Database
The retail buyer would select the desired PLU code and associated description.
PLU Commodity Variety
4023 Grapes Red Seedless
A supplier would be selected from a list of suppliers that could potentially carry product within the PLU 4023 description.
Supplier’s Database
Upon receiving the EDI transaction, the supplier’s system would match the PLU code 4023 against its internal product code database which might look like this:
PLU Origin Commodity Variety Size Pack Label
4023 Ca GRAP Ruby Red 500 Bag 10lb AB
4023 Ca GRAP Flame 700 Wrap CD
4023 Ca GRAP Emperatriz 700 Wrap EF
4023 SA GRAP Flame 900 Bag GH
4023 CH GRAP Ruby Red 900 Bag IJ
Note: Most suppliers would need to add a PLU code field to their database structure. The field would be populated with the PLU code that best corresponds to the product code/description(s) on their system.
In this example, the supplier could potentially ship any product that meets the criteria of PLU code 4023. In this example, the produce that could potentially be shipped may be either California, South Africa (SA), or Chile (CH), and may be any variety that fits a ‘Red Seedless,’ and any size, pack, or label currently in inventory. This illustrates the fact that the PEIB PLU is not specific enough for the supplier to determine the exact produce requested. At a minimum, a supplier would need a further detail on size, a pack description, and possibly a more specific origin definition.
In practice, the PLU code method may work in a limited fashion if the supplier maintained a small set of product codes (e.g. only California origin, with specific varieties and pack styles). The retailer would have to know that for a given PLU, the selected supplier could only ship a specific narrow set of produce.
For large suppliers with a wide selection of produce, the supplier would have to maintain a database of “acceptable” produce (i.e. product code profile) for every retailer wishing to conduct business using the PLU code method. For example, a specific retailer (Jack’s Grocery) might only accept California and Chilean Ruby Red grapes (700 -900), with any pack, grade, or label. When the PLU 4023 is matched against the supplier’s database, only the list of “acceptable” product would
be available for shipment for a given retailer. At best however, the ‘product code profile’ would only narrow down the set of produce that the retailer may potentially require. For example, a product code profile for a given retailer might narrow the selection to the following:
PLU Origin Commodity Variety
4023 Ca GRAP Ruby Red 700
4023 CH GRAP Ruby Red 900
The main disadvantages are:
• PLUs are not specific enough to conduct fully integrated EDI.
• High maintenance effort from the supplier would be required to maintain ‘product code profiles’ for each trading partner.
• This option is counter to the UCC standards used throughout all other industries including grocery dry goods.
• There would be no tie-in to the UPC Case code (or SCC-14 code). (Cases could not be scanned to display product descriptions.)
• This does not address requirements of packaged fixed-weight produce.
• There is no direct link back to the supplier for tracking purposes.
Option 2) Bulk Produce: Extending the PLU Code
The main limitation of PLU Codes is that they do not provide enough detail to conduct fully integrated EDI. This second option examines the possibility of extending the PLU Code to resolve this problem.
Unlike other non-agricultural industries, produce retailers tend to view many products they buy in 'commodity' terms. The 'commodity' concept is that there is no tie between the product and the supplier. That is, oranges from one supplier are really no different from oranges from any other supplier. As a result of this
'commodity' view, some suggest creating an industry standard for product codes. One example involves extending the existing PLU codes, such that product
information could be managed at both a PLU summary level and at a ‘case’ level of detail.
For example, a PLU 4022 refers to Grapes, White/Green Seedless. An extended PLU might look like the following.
CA402214700284B Where:
CA = Origin (California)
4022 = PLU (Grapes, White/Seedless) 14 = Variety (Perlette)
700 = Size (700) 284 = Pack (8/16#Bag) B = Grade
Product information could be viewed at the current PLU level (i.e. 4022), or viewed at increasingly greater levels of detail, such as CA4022, CA402214, CA402214700, CA402214700284, and CA402214700284B, and the corresponding product descriptions would be available for display.
CA402214700284 Calif, Grapes (White/Seedless), Perlette, 700, 8/16lb Bag The PLU 4022 code would remain as the sticker code on the fruit. The extended PLU code would need to be maintained in each trading partner’s computer system. These new codes would need to be developed and maintained by a central
governing body such as the PEIB.
The main attraction to this proposal is that trading partners need only translate (or map) their product codes once to an industry standard product code, and not have to synchronize codes with every trading partner they do business with.
However, there are many disadvantages:
• Extended PLU codes would be difficult to maintain; there could be several thousand unique codes required for ‘case’ level specificity across the industry.
• A great deal of effort would be involved in establishing formats and data content per commodity type.
• A centralized administration could not respond in a timely manner to address the many variations of product codes associated with new product introduction.
• This method is counter to the UCC standards used throughout all other industries including grocery dry goods.
• There would be no tie-in to the UPC Case code (or SCC-14 code) due to a limitation of 99,999 numbers in the product ID field. (Cases could not be scanned to display product descriptions.)
• This does not address requirements of packaged fixed-weight produce.
• There is no direct linkage back to the supplier for tracking.
• Trading partner computer systems would have to undergo major software changes and data conversions to incorporate extended PLU codes.
• Trading partners would need to update their databases every time new extended PLU codes are released.
Clearly, there are far too many disadvantages to extending PLU code proposal. Other “industry standard product code” proposals would suffer the same
disadvantages. Administratively and practically, it would be far too costly, time-consuming, and have too many limitations to serve the produce industry well into the future.
Option 3) Packaged Produce : PEIB UPC Item Codes
Again, the main attributes of the PEIB UPC Item code are Region Area, Variety, Grade, and a combined size/weight/count field. This provides enough detail to define packaged items within the case, but does not describe how the case itself is packed. For example, a UPC Item code number 00027 (Washington, Red Delicious, Washington Fancy, 2 ¼”, 5lb bag) could be sold with 8 x 5lb bags per carton, 7 x 5lb bags per carton (club store pack), or other variations.
To resolve this limitation, one option would be to build a UPC Case code using the PEIB UPC Item code with an extension of a Pack Indicator to describe variations in how the items are packed within the case.
The PEIB UPC Item code has the following format:
UPC Item code Region Commodity Variety Grade Size/Wt/Cnt
The UPC Case code built from the UPC Item code and Pack Indicator could be held on the retailer’s database as follows:
UPC Case code Region Commodity Variety Grade Size/Wt/Cnt PkIn
33383108070001 Florida Grapefruit Ruby Red U.S.#1 Poly Bag 10lb 5 33383108070002 Florida Grapefruit Ruby Red U.S.#1 Poly Bag 10lb 20
The 0001/0002 field extensions would in turn reference a Pack Indicator table. Several hundred entries would need to be agreed to industrywide.
Again, the UPC Item code as defined by the PEIB would not change. However buyers and suppliers would need to maintain common UPC Case code
descriptions, which would comprise the PEIB UPC Item code with the additional Pack Indicator.
The main disadvantages are:
• Extended PEIB UPC Item codes would be difficult to maintain; as there are several hundred unique Pack Indicator codes required for ‘case’ level specificity across the industry.
• This is not a flexible approach for the long term. Additional attributes may be required in the future, which may result in further extensions.
• Scanning a case would only return the PEIB UPC Item code description, without the Pack Indicator information.
• This does not address the requirements of bulk produce.
Note: Fresh-cut produce items typically use supplier defined UPC Item codes. Therefore, EDI would be conducted in the same manner as grocery dry goods.
Option 4) Direct Attribute Mapping
This option applies only to trading partners who maintain similar levels of product code detail. Companies using this method successfully typically have few trading partners with large transaction volumes. (These include the foodservice segment, transactions between growers and shippers, and retailers who only store product codes at the ‘case’ level.)
In this option, trading partners agree to send product code attributes in a specific format. Translation tables are maintained for every trading partner relationship, covering every produce item for which they wish to conduct EDI transactions. In the following example, Company 2 expects to receive data in the format sent by Company 1. When the data is received, it is translated into the Company 2 product description format. Field attributes may need to be split or consolidated, and possibly re-arranged to map correctly.
Company 1
Region Commodity Variety Pack Size
NZ APPL Braeburn RDT Xfancy 090
Company 2
Region Commodity Variety Size Pack Grade
NZ Apples Braeburn 090 Display Tray XFCY
The main disadvantages are as follows:
• This only applies to those companies who store product information at a similar ‘case’ level of detail.
• It requires high maintenance overhead, as each trading partner requires unique translations for their range of produce items.
• There is no standard definition for the attributes used, their data formats, or their order of sequence.
Option 5) EDI Task Force Recommendation: UPC Case Codes
The goal of the EDI Task Force is to provide a recommendation that will address the requirements of the produce industry well into the next millenium. The UPC Case code recommendation provides a robust and flexible framework to accommodate the changing requirements of the produce industry.
Retailers and suppliers may conduct EDI transactions at a case level (e.g. the same general level of detail that business is conducted today via the telephone/fax). UPC Case codes are specific
enough to allow for fully integrated EDI throughout the ordering, inventory, and payment cycles.
All other EDI-enabled industries including grocery dry goods successfully use the UPC Case code method. With UPC Case codes, the supplier determines the level of product specificity through a product numbering process. UPC Case codes and associated description attributes are in turn synchronized with the retailer’s database.
There are many benefits to this recommendation:
• Enables fully integrated EDI between trading partners.
• No requirement for centralized industry administration of product codes.
• Conforms to all other EDI-enabled industries, including grocery dry goods.
• Allows for the same level of detail in EDI transactions as currently conducted via telephone/fax (ordering, inventory, and payment cycles).
• The UPC Case code is unique and can be tracked worldwide throughout the distribution chain (from grower to the point at retail where the produce is removed from the case).
• The UPC Case code method handles both bulk and packaged fixed-weight produce.
• Cases can be scanned throughout the distribution chain (with product descriptions displayed in each firm’s specific format).
• Cases can be tied back to the supplier for tracking purposes (supplier performance, product recall, etc.).
• Core and secondary product attributes can be used industrywide for category management and industrywide performance benchmarking.
With all these benefits, why hasn’t the produce industry adopted UPC Case codes for EDI much earlier? The main reason is that it would be problematic to assign product IDs to every product code on a supplier’s database (especially where large suppliers have thousands of product codes). To overcome this barrier, the EDI Task Force is suggesting a new technique for implementing UPC Case codes.
First, it’s important to understand that both retailer and supplier computer systems need to continue storing product code data in the current manner. The retailer must store PEIB PLU/UPC Item codes to manage produce (for demand forecasting, shelf space management, goods sold, etc.). The supplier needs to store detailed proprietary product codes (for forecasting, crop management, quality control, logistics, grower reporting, etc.).
The new technique proposed by the EDI Task Force is for both retail buyer and supplier computer systems to store an intermediate level UPC Case code, which bridges the gap
between supplier proprietary codes and retailer PEIB PLU/UPC Item codes. This new technique will drastically reduce the quantity and complexity of mapping codes between trading partners.
The supplier would first determine the key attributes which constitute the ‘selling level’ of a ‘case’ of produce. These attributes may vary between commodities (e.g. apples and citrus), but as a whole these are attributes that determine price at the ‘case’ level. Ideally, only the ‘core attributes’ outlined below should be used (although for some commodities, secondary attributes may be required). The key to making the UPC Case code method work for produce is for the supplier to use as few attributes as possible when defining UPC Case codes. Further, suppliers should only exchange the set of UPC Case codes that they expect to use in EDI transactions with each specific retailer. By following these guidelines, the UPC Case code method will be much closer in usage to that of EDI in grocery dry goods. The attributes to consider when assigning UPC Case codes are as follows.
Core Attributes:
The attribute names (commodity, pack, etc.) aren’t consistent throughout the produce industry, so examples and short definitions are provided for clarification.
• Origin (US, NZ, Tx, Ca, Fl, etc.)
- Describes geographically where the produce is grown (short or long form for country, state, region, etc.)
• Commodity (Apples, Grapes, Oranges, Kiwi, etc.)
- Describes the category (or species) of produce (see PEIB’s ‘Guide to Coding Fresh Produce’ for valid entries)
• Variety (Braeburn, Perlette, Valencia, etc.)
- Each commodity has associated varieties (see PEIB’s ‘Guide to Coding Fresh Produce’ for valid entries)
• Size (30, 90, 500, Small, Jumbo, etc.)
- Each commodity/variety has associated sizes; informal industry standards per commodity/variety.
• Pack (8/5lb bags, Tri-layer, Volume-Fill, 30/6 Ounce, etc.)
- Describes how the inner contents of the ‘case’ is packed; informal industry standards.
Some commodities may require additional attributes to achieve the desired ‘selling’ level. For example, many citrus products require that the ‘grade’ attribute is included.
• Grade (Extra Fancy, Choice, US#1, KAC#1)
- Provides a high-level ‘quality’ description; formal and informal industry standards).
• Label (Joe’s Best, etc.).
- The description that a supplier (grower, shipper, wholesaler, etc.) uses to describe its product. Often the labels are short-form company names.
• Pack-Type (bin, bale, etc.)
- Alternate packaging types (to describe alternate types of shipping containers).
The next major project for the EDI Task Force is to standardize the format and data values for ‘core’ and ‘secondary’ case code attributes. This will provide consistency across the industry in terms of being able to match ‘attributes’ between computer systems (using the 888 Item Maintenance transaction). As well, standardized case code attributes will greatly improve category management analyses, data warehousing activities, and cross-industry analyses.
UPC Case Codes: Bulk Produce
The following example illustrates how each trading partner system would need to be structured, and how they would be linked together (via the UPC Case code) to support the ordering process. (Note: description formats will vary from one system to another.)
Retail Buyer Database
The retail buyer would first select the desired PLU code and associated description.
PLU Code Com Var Size
4129 Apple Fuji Small
The buyer would then drill-down to select a supplier with associated UPC Case codes. In this example ‘Joe’s Distributing’ (manufacturer ID 12345) is selected and three UPC Case codes would be available for selection.
1234500001 Wa Apple Fuji 080 12/3lb 1234500002 Wa Apple Fuji 090 12/3lb 1234500003 Wa Apple Fuji 100 12/3lb
Note: The retailer system could be designed to have various drill-down options (e.g. drill-downs on Origin and Commodity, then to various suppliers’ UPC Case codes).
Supplier Database
Following the same example, the supplier had previously determined that the ‘sell-level’ only requires ‘core’ attributes. Secondary attributes (in this case ‘grade’ and ‘label’) would still remain on the supplier’s database, but would not be used to define the UPC Case code.
UPC Case code Origin Com Var Size Pack Grade Label 1234500001 Wa Apple Fuji 080 12/3lb xfancy Sierra 1234500001 Wa Apple Fuji 080 12/3lb xfancy Lucky 1234500001 Wa Apple Fuji080 12/3lb xfancy Primo 1234500001 Wa Apple Fuji080 12/3lb xfancy Gold 1234500001 Wa Apple Fuji 080 12/3lb fancy Sierra 1234500001 Wa Apple Fuji 080 12/3lb fancy Lucky 1234500001 Wa Apple Fuji 080 12/3lb fancy Primo 1234500001 Wa Apple Fuji 080 12/3lb fancy Gold 1234500002 Wa Apple Fuji 090 12/3lb xfancy Sierra 1234500002 Wa Apple Fuji 090 12/3lb xfancy Lucky 1234500002 Wa Apple Fuji 090 12/3lb xfancy Primo 1234500002 Wa Apple Fuji 090 12/3lb xfancy Gold 1234500002 Wa Apple Fuji 090 12/3lb fancy Sierra 1234500002 Wa Apple Fuji 090 12/3lb fancy Lucky
1234500002 Wa Apple Fuji 090 12/3lb fancy Primo 1234500002 Wa Apple Fuji 090 12/3lb fancy Gold 1234500003 Wa Apple Fuji 100 12/3lb xfancy Sierra 1234500003 Wa Apple Fuji 100 12/3lb xfancy Lucky 1234500003 Wa Apple Fuji 100 12/3lb xfancy Primo 1234500003 Wa Apple Fuji 100 12/3lb xfancy Gold 1234500003 Wa Apple Fuji 100 12/3lb fancy Sierra 1234500003 Wa Apple Fuji 100 12/3lb fancy Lucky 1234500003 Wa Apple Fuji 100 12/3lb fancy Primo 1234500003 Wa Apple Fuji 100 12/3lb fancy Gold
In the example above, only three UPC Case codes need to be mapped between trading partner systems, as opposed to 24 UPC Case codes if they were assigned sequentially (as per the traditional method of product ID assignment).
Note that the supplier could potentially have hundreds of product codes, with several attributes beyond ‘grade’ and ‘label,’ yet only three UPC Case codes would be required for mapping purposes.
Ideally, the UPC Case code assigned on the supplier’s computer system should match to the UPC Case code (or SCC-14 code) printed as a bar code on the case. This will avoid the extra work involved throughout the distribution chain in mapping different UPC Case codes together. (In the event that the supplier does not have control of the UPC Case code printed on the case, additional translation tables may be required).
When establishing UPC Case codes, suppliers need to consider all retailers with whom they plan to conduct EDI. Once the supplier establishes the ‘selling-level’ for each commodity he handles, it would be very difficult to then provide multiple selling levels customized for each retailer.
Again, ‘packaged produce’ refers to fixed-weight produce that has been packaged (shrink-wrapped, bagged, etc.) and has been bar coded with the PEIB UPC Item code.
The UPC Case code method would work in the same manner and achieve the same benefits as for bulk produce described above.
Retail Buyer Database
The buyer first selects the desired PEIB UPC Item code as follows:
UPC Item code Origin Commodity Variety Grade Size/Wt/Cnt
3338310807 Florida Grapefruit Ruby Red U.S.#1 Bag 10lb
Next, the buyer would drill-down to select a supplier with associated UPC Case codes. (Note: the following UPC Case code record would also need to store the UPC Item code to provide a link for the drill-down.)
UPC Case code Origin Commodity Variety Grade Pack
1234500201 Florida Grapefruit Ruby Red U.S.#1 Bag 5/10lb In this example, the UPC Case code of 1234500201 is chosen with a pack attribute indicating 5 - 10lb bags.).
Supplier’s Database
UPC Case code Origin Commodity Variety Grade Pack
1234500201 Florida Grapefruit Ruby Red U.S.#1 Bag 5/10lb 1234500202 Florida Grapefruit Ruby Red U.S.#1 Bag 10/10lb 1234500203 Florida Grapefruit Ruby Red U.S.#1 Bag 12/10lb In this example, the UPC Case code 1234500201 would be matched, and the supplier could fulfill the order as requested.
Note: Fresh-cut produce items typically use supplier defined UPC Item codes. Therefore, EDI would be conducted in the same manner as grocery dry goods. Summary
The issue of product identification is a difficult one for the produce industry. Various options are reviewed with regard to their suitability to fully integrated EDI.
A new UPC Case code technique designed specifically for the produce industry is recommended to conduct EDI for both bulk and packaged fixed-weight items. Some produce companies have implemented EDI in a non-integrated manner to get the base technology established. The long-term recommendation is to use the UPC Case code method to maximize the benefits of fully integrated EDI.
..
..
..
..
..
Section V
EDI in Produce: Technology Implementation
What Does EDI in Produce Look Like?
Generally for the produce industry, for each truck shipment of produce, there can be one or more retailer orders (with one or more drop locations), one or more pallets per order (from one or more suppliers), and a variable number of cases per pallet (from one or more growers). However, even the most complex transactions in the distribution chain can be handled with transactions such as a Purchase Order, Order Commits, Shipping, Receiving, Product Location, Invoicing, etc.
When deployed for dry goods or perishables, EDI between retailers and suppliers can include all or parts of the following standard UCS EDI transactions. Other EDI transactions are available for other applications such as DSD (direct store delivery) systems.
Base Transactions
875 Grocery Products Purchase Order
The equivalent of the normal order-taking process which is now largely conducted by telephone or fax between supplier and retailer.
There are two methods for initiating the 875 Purchase Order. For both methods details of the sale will still be negotiated over the telephone.
1) The supplier enters the purchase order into its computer system. This generates an 875 Purchase Order, which is transmitted and loaded directly into the buyer’s computer system. The buyer would simply need to “approve” the purchase order on screen, greatly reducing the buyer’s data entry effort. 2) The buyer enters the purchase order into its computer system, which generates
an 875 Purchase Order, which is transmitted and loaded to the supplier’s computer system, and inventory would be committed to the order if possible. The supplier would review the order request and enter any missing data (e.g.
