Integrated Business Communications Alliance

INFORMATION: Articles & Standards:

White Paper: A Starting Place for eCommerce

What’s it All About?

Over the past few years, IBCA has begun a number of projects using the U.P.C. bar codes and electronic ordering (EDI and e-commerce) to streamline the procurement process within its supply chain.  The goal has been to provide a starting place to automate a number of ordering and fulfillment functions.  Recent surveys conducted by IBCA indicate that more that 90% of the manufacturers and distributors either accept electronic orders now or will in the near future.  The same survey also indicated that more than 80% of the manufacturers and distributors use or plan to use bar codes to verify receipts and shipments.  These order placement and fulfillment activities are collectively referred to as e-commerce.

The goal now is to facilitate electronic transfer of these documents over the Internet.  This white paper deals with the business-to-business (B2B) environment that is somewhat different from the business to consumer (B2C) environment.  This is because B2B transactions involve repeat orders from long-term customers, and in these relationships there is a need to drive costs out of the buy/sell activities and to automate the payment and receipt of the payment process.

Survey results also indicate that the companies who want to place and receive orders and payments are at all levels of technical capabilities.  Therefore, an implementation path leading to widespread use of e-commerce must include the simplest methods and then progress to the more sophisticated methods.  Those who are EDI capable are encouraged to continue its use with others who share their capabilities.  For some, this may be the easiest method to expand the number of trading partners using e-commerce.  The implementation path explained here deals with the most fundamental of issues; identifying the product(s) to be ordered and arranging for some form of electronic payment; i.e. payment cards (P-card) or electronic funds transfer (ACH).

The simplest way to place an order and arrange for payment can be seen in the typical P-card transaction over the Internet.  Since anyone using the Internet will need to handle these types of transactions, we have selected this as a starting place.  This is a useful starting place because the same backbone can be used to receive orders as to place orders.  Therefore, it doesn’t make any difference whether a company is initially interested in efficiency on the buying side of the operation or increased efficiency and a positive impact on market share on the selling side of the operation.  In other words, this is important to any company.

As we mentioned before, different companies are at different levels of capability and technical understanding.  We will be discussing the use of simple flat files (see Appendix A, B, C and D) that conform to a standard established by the IBCA, a nonprofit organization dealing with cross-industry standards (www.insightu.org/transactions.htm).  We would also like to acknowledge and thank Profile Systems for providing electronic and hard copy of the Standard Product Identification Export Files and the Purchase Order and Invoice Flat file.  These standards have been developed and tested over the past several years and have direct element-to-element compatibility with the widely used, ANSI X12-based EDI Pro standards (www.insightu.org/transactions.htm).  Furthermore, they serve as baseline documents for those developing the next generation XML documents.  This means that the documents are upward and downward compatible.  While it is understood that some, and perhaps many systems, will have capabilities far beyond the transactions described here, this approach represents a starting place that will serve as the foundation for much more sophisticated methods with much greater capabilities.

The implementation path will only work if certain “rules” are followed.  Companies wishing to move forward to the more sophisticated transactions and methods are encouraged to do so but must provide compatibility with the least sophisticated systems.  To accomplish this “entry level” e-commence and then to move forward, everyone in the supply chain must agree to:

  1. Use the U.P.C. method of product identification.
  2. Use the IBCA Standard U.P.C. Matching Files. (Appendix A and B)
  3. Use the IBCA Standard Transactions. (Appendix C and D)

These requirements are nothing new.  The U.P.C. and its cousin the EAN have been in use for years.  The baseline purchasing transaction is what the banks and credit card companies refer to as “Level III” purchasing information and is used for millions of transactions each year.  For those familiar with ANSI X12 standards, the IBCA transaction documents contain the same information found in the ANSI X12-based EDI Pro standards (www.insightu.org/transactions.htm).  This is all the information required by the trading partners as well as the processing and authorizing banks.

The Transaction Scenario, Internet Connection and Types of Documents

Note: Many of the same capabilities presented here may be available through the use of an application service provider (ASP), a portal serving a trading community or a network service provided by a computer system or software provider.  In those situations the standard IBCA files referred to in this document should be used when dealing outside the private network or intranet.  If the standard files and documents are used, they provide a universal method to communicate whether dealing inside or out side the network.  This is, by definition, an “open system.”

At the time the order is placed, the buyer will provide all the information necessary to identify the product, the shipment destination and P-card or ACH number.  The transaction is simple but the explanation can become complex because there are different categories of Internet connections and different kinds of electronic documents.

As shown in the diagram below, the buyer uses the Internet to contact a seller and place the order.  The seller will contact the bank to get authorization for the use of the P-card and to request payment.  This all sounds simple enough, but when a company discusses this with banks, system designers, software providers and information services (IS) staff, it can become complex.  The complexity stems from the wide range of capabilities that systems can provide.  Therefore it is important for a non-technical person to be able to explain how he or she would like to conduct business and to be able to understand the options that a bank or a system supplier would like to provide in order to leverage operating efficiencies. 

The recommended starting place is to use the simple flat file (ASCII text file) that can be imported or exported by almost any system.  The flat file conforms to the IBCA standards mentioned earlier (Appendix A, B, C, and D – www.insightu.org/transactions.htm).  It can be imported into the host either with a manual assist or automatically.  If a company is already set up to receive ANSII X12 documents, the standard flat file, because it conforms to a standard and is the same every time, can be converted.  If and when the XML documents become available, the IBCA standard can be tagged to make them compatible.

At the risk of oversimplification, we will deal with 3 categories of Internet connections, shown in the diagram and explained below, and 3 types of documents, also explained below.

 

Note: The “Internet” can also be an intranet of activities on a single server

Categories of Connections:

  1. Category 1 (the dotted line) is the simplest where the terminal, connected to the Internet, is not connected to the host at the same time.  They just exist within the same organization.  People can access the Internet but the Internet is not accessible through the host system.  If a person wanted to place an order, he or she would use a terminal to go online and then the person would use a keyboard to type in the information.  When a company receives orders, a person goes to the terminal and basically picks up e-mail and prints it out.
  2. Category 2 (the dashed line ) is where the terminal connected to the Internet can export a file that can be imported into an application running on the host at another system.  To receive orders in this kind of system, a person will pick up an e-mail and then the system will convert the e-mail to a file that the host can import into the order entry application.
  3. Category 3 (the bold line) is where the Internet is accessible from terminals on the system and, most importantly, information can flow between the host and the Internet.  Firewalls and security are critical to these systems.

Types of Documents

  1. Flat Files are simply text files.  Being able to receive a flat file does not mean that a system can use it.  An application running in a computer must know the nature of the information and the meaning of each file.  Standard flat flies follow rules set down by trading partners or trade associations representing a supply chain.  A standard for a flat file will define the data content and sequence of data elements (www.insightu.org/transactions.htm).
  2. EDI files conform to the EDI X12 or EDIFACT standard.  They are identical to the files in use today that are sent “point to point” or through a VAN.  The only difference is that they are transmitted over the Internet rather than on a dedicated telephone line.
  3. XML files conform to the extendable markup language (XML) and work with an understood and agreed to field designator directory.  These closely resemble the content of the X12 documents.

The complexity is seen between the Host and the Internet connection.  This can be a category 1, 2 or 3 Internet connection and the information going across categories 2 and 3 can be a flat file, X12 or XML document.

Industry Implementation Path

In order for a supply chain to move forward with e-commerce, all of the companies must agree to conform to a “baseline” file layout for the most fundamental of transactions.  Sophisticated companies are not asked to abandon their EDI activities but they are asked to facilitate the simple documents as a starting point for the good of the entire supply chain.

Ultimately, the most efficient systems will interact seamlessly and in real time using XML directory-driven transactions.  Much work is being done right now to make such systems viable; however much work remains to be done.  Of course, there will be acceptance issues and other facts of human nature that will slow progress.  The point is that there is no reason to wait for the XML work to be complete.  The “first steps” explained here must be accomplished no matter how sophisticated the systems may become.  These steps will also provide a first level of efficiency that can provide almost immediate payback and support the viability of the e-business premise.  Fundamentally, an industry or company implementation path can progress from simply placing or taking orders, and receiving or making P-card or ACH payments from two simple flat files:

  1. The product master file contains information including catalog number, U.P.C., description and price, etc.  The key is the U.P.C. number.  The product master file is used to load the inventory records.  Those records are then used by the computer system to generate purchase orders in procurement systems and to process customer orders in order entry systems.
  2. The other file is an order that uses the U.P.C. to identify the item and then “ship to” and payment information, etc.

(See samples at www.insightu.org/transactions.htm).

Using the U.P.C. and Product Files as the Starting Point

In order to send and receive orders and payments, some fundamentals must be in place.  First of all, stock items must all be identified with U.P.C. numbers because the U.P.C. number will be used to identify the items that are being ordered, shipped and paid for.  Distributor inventory master files must be matched to the manufacturer’s file using the U.P.C. number as a starting point.  An important point must not be overlooked.  After the initial matching, then the files must be maintained.  This maintenance is called synchronization.  Any time something changes in a product master file, which is controlled by the manufacturer, the item master files throughout the supply chain must be synchronized with the manufacturer’s file.  Therefore it is important to have two capabilities, one for start-up matching and the other for ongoing synchronization.

It is a relatively straightforward task to add the U.P.C. number to an inventory record.  It is much more complex to keep descriptions, prices and other elements of information synchronized.  But since the U.P.C. Matching File is a simple ASCII text file (see Appendix A and www.insightu.org/transactions.htm) the matching file is a good place to start.  Whether a system is sophisticated and uses ANSI X12 EDI, or not, the files containing the necessary elements of information in the necessary format can be exported from the database.  As mentioned earlier, everyone in the supply chain must conform to the agreed to IBCA document standard.

The second, more comprehensive Product Information Export File is used to maintain databases.  The information contained in the Product Information Export File is based on the UCC IC ANSI X 12 832.  This “flat file” can simply be exported from a database or imported without sophisticated EDI mapping.  Furthermore, if a company has invested in EDI, the standard document can be transcribed by their own system software or by various third parties.

These individual documents and/or files must be transmitted from the manufacturer to the rest of the supply chain.  Since both the sending and receiving companies represent a diverse group who are at all levels of technical capability, the communication media must serve them all.  When the 2 types of files are available, a company can: 1) place U.P.C. information on a CD or e-mail it or put the file at their web site so companies can simply import it to their data base; 2) use the ANSI X 12, 832 to send the file over a VAN or go point-to-point.

Manufacturers at the most sophisticated levels must be able to provide the least sophisticated transmission media.  Then distributors, regardless of technical level, can begin to use the technology.  Concern has been voiced that this is “yet another standard”.  It is not.  A review of the transactions described in this document reveals that they are all simple subsets that are directly related to the more complex ANSI X 12 transactions and the field definitions directly relate to the XML tags that are under development.

As the diagram indicates, the IBCA Standard Flat File or Document is the universal record that any translator can read and import, export or convert to X12 or XML.  This allows software providers, third party VANS or Internet portals to handle the files or translation.  Any of the companies can be tested to ensure that what they take in and what they put out does work.

Once companies are capable of importing and exporting the standard files, they will be able to test that the fields required by their software do match and then they can begin to communicate using the simple flat files where appropriate and the complementary ANSI X 12 or XML documents when necessary.

What Companies Must Do:

At minimum, manufacturers must be able to produce a simple U.P.C. Matching File that conforms to the IBCA standard file format (Appendix A).

Companies using the U.P.C. must be able to append the files in their computers with the U.P.C. product identification numbers.  Matching software of this nature may be available from a computer system or software supplier, a service bureau, a VAN or a catalog company.

The highest form of automating the matching process also involves the most comprehensive file, the file is basically the ANSI X12 832, and sets the system up for continuous, fully-automatic synchronization (Appendix B).

Once manufacturers and distributors have added the U.P.C. to the product master file, then they can use the U.P.C. number as the key for any later file updates.  The 832 or its Internet-enabled, flat file counterpart can be used to do this “synchronizing” on an ongoing basis.

Transactions

As mentioned earlier, a flat file containing what banks refer to as Level III information (Appendix C) could be used to get the ball rolling.  This is because many companies accept P-cards or credit cards, and since level III information contains product and payment information, it contains everything necessary for simple transactions.  Anyone placing orders is asked to be able to do so by sending a file containing Level III information.  This designation refers to item level detail that banks use to process payment cards or credit cards.  For those who are familiar with ANSI X12 standards, it is much of the same information contained in remittance advise segment of the 850 (see sample at www.insightu.org/transactions.htm).  The form of payment can be an electronic check (ACH) or a P-card number.

Companies who receive orders with Level III remittance information must have the capability to send the necessary information to the processing bank and receive the authorization.  The specific arrangements should be made with your commercial bank.  Some banks can provide additional software if necessary.  Many computer system suppliers and business software systems also provide this capability.

Companies who place orders using Level III information must also be capable of receiving the reconciliation files from the bank that made the payment.  This is the transaction that closes the loop and matches the transaction number assigned when the order was placed with the number provided with the notification of payment.  Some banks can provide assistance in obtaining the necessary software and some business software systems provide this with their accounting package.

As companies move forward with their e-commerce implementation, they can use the flat transaction documents described in Appendix C and others identified at the IBCA web site.

Qualification

The goal is to be able to:

Match and synchronize product files automatically.
Receive and transmit orders.
Receive and make payments.

Therefore, transmission software as well as file structures must comply with the IBCA standards.  To ensure that files conform to the standard and that software does process the files correctly, there must be a process to validate compliance to the IBCA standard and system capability.  When a company has validated its compliance and capability, it is called “Qualified.”

There are a number of different things that a company must do to be 100% Qualified.  These capabilities are the steps to full qualification.  Companies who manufacture or label their own products sold in the supply chain must have or provide the things listed below:

  1. Master files must be tagged with U.P.C. numbers and the IBCA U.P.C. Matching File must be available.

  2. All products must carry U.P.C. bar code labels on the lowest unit of sale.

  3. Multi packs or master cases must carry the appropriate UCC Shipping Container Code.

  4. Even if companies are not EDI capable, they must be able to send and receive orders (using the standard IBCA forms) with the U.P.C. number to identify items on the order.

  5. Companies must be able to transmit and receive the standard transaction documents over the Internet or via a VAN.

  6. Manufacturers and distributors must establish a registration and verification process to have all documents and bar codes verified to be in compliance.  They must have an identified point of contact who can field questions should problems arise with data transfer or bar code quality.

In order for software providers, VANs, internet portals and catalog providers to be “Qualified,” they should be registered too and have their input and output capabilities verified.  They must have a point of contact where new information or alerts about problems can be directed.

Trading partners must establish the qualification process.  When testing for qualification, companies will set up file test criteria and have the capability to:

  1. Verify field structure for U.P.C. matching files.

  2. Review U.P.C. labels for layout and completeness.

  3. Transmit and receive all the documents.

  4. Maintain specifications for all transaction sets.

  5. Run matching software and synchronizing software against dummy files.

“Product Category” UNSBSC codes are used in the level III documents.

Appendix A -- IBCA U.P.C. Matching File (see www.insightu.org/transactions.htm)

Appendix B -- Standard Product Information Export File (see www.insightu.org/transactions.htm)

Appendix C -- Payment Card Layout Excel from First Data (see www.insightu.org/transactions.htm)

Appendix D -- Flat Files (see www.insightu.org/transactions.htm)

 

IBCA  Phone: 215.489.1722  Email: kelleyt@quadii.com

© 2005 Integrated Business Communications Alliance