Frequently Asked Questions (FAQ) 
(Last Update 4/23/2004)

 

Q.) What is EDI?

A.) EDI is an acronym for Electronic Data Interchange.  It's a term used to describe a standardized means of exchanging information between two or more computer systems, usually in a business environment. ANSI (The American National Standards Institute) has created a set of these standards known as X.12 that is widely used in the Wholesale Distribution / Supply industry.  There is no single solution for utilizing EDI.  It's more of a concept than a specific computer tool.


Q.) What support does DAC provide for EDI?

A.) DAC Provides two primary software modules to support EDI.  They are "DAC EDI Retailer" (Used primarily by a distributor to communicate with a retailer) and "DAC EDI Vendor" (Used primarily by a distributor to communicate with their vendors). These two modules are the primary components of the CV1 Integration Module (CIM). 


Q.) What is CIM?

A.) CIM is an acronym for CV1 Integration Module.  CIM consists of a series of server processes which create transaction data going to your trading partners (such as invoices) as well as process transaction data coming from your trading partners (such as purchase orders).  CIM constantly monitors DAC for events that occur throughout the business day-- such as price changes or orders being posted.  These events trigger a "dispatch" of data from DAC in the form of a series of messages.  These messages are ultimately routed to one of a variety of storage places.  One of these is an ASCII file ("Flat" file) in the I-Series QDLS file system.


Q.) Does CIM's output conform to the ANSI X.12 standard?

A.) No. CIM uses a proprietary format for the data.  However, there are many third-party translation software packages and services (such as GE Global Exchange, Sterling, and others) that can translate CIM proprietary format into X.12 compatible data.  A recent development at NACS (National Association of Convenience Stores) is a revamping of the X.12 specifications for the purpose of constructing a simplified, industry-wide, XML-based EDI standard.  When and if this specification becomes available, DAC may provide direct support for it, thereby alleviating the need for translation software and services.


Q.) Does CIM support the importing of ANSI X.12 data?

A.) No. CIM only imports proprietary DAC data.  However, much like CIM's output, the data can be translated with third-party software packages.


Q.) What does the data that CIM generates look like?

A.) Refer to CIM Transaction Reference for explanations and visual examples of the various transactions and transaction sets.


Q.) How do I make CIM generate some data?

A.) First, check with your CDR account representative to ensure that your system is properly licensed for either EDI Retailer or EDI Supplier.  Next, start the integration module by typing 'edistart' at any DAC menu.  Finally, from the main DAC menu, take option 9, then option 9 again, then option 3.  This will take you to CIM's automatic configurator.  Follow the prompts from there to setup a target account.  Once this is complete, CIM will automatically begin creating files containing relevant information and placing them into the proper QDLS folder.  Allow up to two hours for these files to appear.


Q.) Where does the data that CIM generates go?

A.) There are several options known as "Delivery Methods" which can be setup in the CIM Profile.  Each profile can have one delivery method.  The primary delivery method is an ASCII file ("Flat" file) in the QDLS file system. (Other options include an I-Series DATAQ object (Local or DDM), or a program object parameter.)  

    In order to have access to the QDLS file system and use the files that CIM generates, you must have the IBM licensed product known as "Client Access Express for Windows" installed.


Q.) Is the data that CIM generates suitable for use in other computer systems (such as my vendors or customers)?  I mean, isn't that the whole purpose of it?

A.) The raw data that CIM generates is probably NOT automatically usable in another computer system unless the other computer system is aware of the format in which CIM generates the data.  This is why the specifications are made public.  If your retailer has programming abilities you should give them the "Retailer Implementation Guide for CV1 Integration Module".


Q.) I have a customer with a computer system that wants to receive EDI data from me.  Can they?

A.) This is a two part answer.  First, DAC can certainly generate data and put it somewhere for you.  But, how it gets to the customer is a communication/networking issue.  DAC's EDI functionality ends before this point.  Second, just because your customer can receive your data doesn't mean they know what to do with it.  Usually, one of three things happens:  

1.) They want to receive data in their format.  
2.) They are satisfied with DAC's format  
3.) They want to use ANSI EDI which will require you to use a third-party EDI translation software package or service.  

In any event, DAC's responsibility ends before any of these issues arise.  Therefore, the problem is beyond the scope of this FAQ and must be handled on a case-by-case basis.


Q.) Can my AS/400 use the Internet to send and receive files to and from my Vendors and Customers?

A.) Yes.  CIM provides two FTP-based services which sends and/or receives files to and from an FTP server.  (FTP is a popular File Transfer Protocol which is used to send files over the Internet.)  If your Vendor or Customer has FTP capabilities, you can take advantage of these services to automatically send files to them and retrieve files from them. (See the user's guide for more information on these services)

    In order for this to happen, your AS/400 must have Internet access.  If your AS/400 is already part of your local network (which it probably is), it can access the Internet in much the same way as your PCs do.  If your network does not already have Internet connectivity you'll need to contact a local Internet Service Provider (ISP) and have them supply you with a connection and the proper hardware.  Basically, they will need to provide the following:

1.) A static Internet connection such as DSL, ISDN, Cable, or other.

2.) A firewall/router configured to allow FTP network traffic to and from your AS/400.


Q.) Is there any other way besides the Internet to send files to my Vendors and Customers?

A.) Yes. CIM generates files and places them in the QDLS file system.  There are numerous ways for these files to be delivered from there.  The simplest solution is to copy the files to a diskette using Client Access, and give the diskette to your Vendor or Customer.  This quickly becomes impractical in larger installations due to the manual effort involved.  The best solution is to establish Internet access for your AS/400 and automate the transfer of files.


Q.) Why are some of the CETE specs so long?  Is it really necessary?  Sometime, the CETE is longer than the transaction data!

A.) The theory behind CETEs is that it gives an individual CIM message enough information for it to be delivered on its own.  That is, it does not depend on other discrete messages in order for proper identification and routing to occur.  It may depend on the successful delivery of other messages in order to process correctly, but that is another matter.  (This is the case with transaction sets).  In order for each CIM message to have independence, each message must include its own envelope information.  The theory behind delivering messages in this fashion is that it separates the transaction data from the delivery mechanism.  This is generally a good thing considering the complexity and variety of modern computer networking environments, but it does come at a price- the overhead of the CETE data.  In simplistic environments, an optimized CETE which contains very little data may be available.


Q.) When I start the CIM Interface, a lot of jobs are starting.  What's all this?

A.) The CIM methodology breaks the tasks of rendering and delivering CIM data into several discrete steps.  This streamlines the process and allows for better application performance.


Q.) What is OPM and why should I care?

A.) OPM stands for Original Process Model.  It is the original integration functionality that DAC provided.  Efforts to improve the utility of DAC's integration functionality led to a major overhaul of DAC's entire integration philosophy.  This new philosophy (known as CETE)  was a radical departure from OPM.  It was therefore in the best interest of everyone to not try and "marry" the two.  OPM was left untouched and still functions as it always has.  CETE is much more flexible and performs better.  You should consider phasing-out any OPM-based  dependencies where possible.


Q.) What is CETE and why should I care?

A.) CETE stands for CV1 Electronic Transaction Envelope.  It is a blanket term describing DAC's philosophy for rendering, delivering, and processing integration-related data.