|
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:
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 DocumentsNote: 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:
Types of 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 PathIn 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:
(See samples at www.insightu.org/transactions.htm). Using the U.P.C. and Product Files as the Starting PointIn 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:
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. TransactionsAs 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. QualificationThe goal is to be able to:
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:
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:
“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 |