Data Specifics
(Last Update 1/15/2004)


    In order to understand how data is formatted and assembled (for exported data) and parsed and processed (for imported data) you must have an  understanding of the following key concepts:

CIM Message:

A CIM message consists of a CETE and a CIM Transaction. It represents a complete and transmittable unit of information. The following diagram illustrates the components of a CIM Message.

A single CIM transaction, such as an item update, can be delivered in a single Message.  For transaction sets, such as a sales order or invoice containing multiple "detail lines", multiple Messages will be used to deliver the transactions.  Generally, there is a one-to-one relationship between a Transaction and a Message.  The important thing to note about a CIM Message is that it's comprised of a CETE and a Transaction-- both of which are independent constructs.   A CIM Message "glues" these two constructs together.  

    Because CETEs and Transactions come in a variety of formats, CIM Messages will vary in length.  When processing CIM Messages, you must determine which CETE you are using by examining the first 7 characters of the message.  If the value is "CETE200", you are using CETE version 2.00.  If the value is "CETE300", you are using CETE version 3.00 and so on...  If the first 4 characters do not equal "CETE", you are using version 1.00.  Version 1.00 does not include a CETE version identifier.  See the next section for more information on the various CETE versions.

  The following is an actual sample of a CIM Message:

JOHN           E10111080371743 00002                     IT103XY100461A & C CLASSIC LIGHT 10/12          010000300007PAKBOXCAS   000010001000010000017878987        1.5 PACK  N.00              028200008862   100461         028200002327                          123456A&C       00003A//

For more information on how to determine which version of CETEs and Transactions are being used, visit Specification Determination Guide

CETE:

    CETE is a specification that represents the describing portion of CIM messages. As mentioned above, each CIM message contains two parts:

  1. A description of the transaction data (CETE)
  2. The transaction data itself. (CIM Transaction)

        CETE can be thought of as an "envelope" for transaction data. CIM messages are never delivered without a CETE. Much like an envelope sent through the U.S. Postal Service, a CETE envelope contains elements such as a Source (Return Address), a Target (Mailto Address), and chronological stamping (Post mark).  Additionally, just as real-world envelopes come in many shapes and sizes, there are various CETEs within which data may be delivered.  For data exported from CV1, the system will determine which CETE is used.

    The following tables describe the available CETEs and their purposes:
Version 1.00
Usage This is the original CETE.  When sending non-transaction-set messages, this is probably the best choice.  Transaction sets are NOT supported using this CETE envelope.
Comments When this CETE is used, the transaction data in the CIM Message starts in physical position 65.

Field Description

 Starts At

Length

 Data Type Required?

Comments

Target

 1

15

 A N

Whom the data is targeted to. If omitted, the receiving system assumes ownership.

Target Qualifier

 16

1

 A N

What is being represented in "Target". Valid values are "M" (manufacturer), "S" (supplier), and "R" (retailer).  If omitted, Target field is ignored.

Chronological ID #1

 17

15

 A N

Provides a chronological sequence. The data should be incorporated using this sequence, ascending. 

Chronological ID #2

32

5

 A N

Provides additional chronological sequencing. The data should be incorporated using any previous Chronological fields as well as this one.

Chronological ID #3

37

5

 A N

Provides additional chronological sequencing. The data should be incorporated using any previous Chronological fields as well as this one.

Source

 42

15

 A N

Who is this data coming from.

Source Qualifier

 57

1

 A N

What is being represented in "Source". Valid values are "M" (manufacturer), "S" (supplier), and "R" (retailer)

Topic

 58

2

 A Y

What data is contained in the transaction portion of this message. See each PIDF data description for the topic code for that data.

Version

 60

3

 A Y

What PIDF version is the transaction data portion stored in?

Action

 63

1

 A Y

What Action is to be performed? Valid values are 
A = Data is being added.
D = The data is being deleted.
X = A complete image of the data is being sent.  Whether the data is being added or deleted is unknown.

Agent?

 64

1

 A Y

Indicates if this message represents itself and/or other transactions.  Transactions that are part of a set must have a single "Agent" transaction.  Normally, this will be the pilot.  For transactions that are not part of a set, they are "self represented".

Y = This transaction is the agent for itself or a set of other transactions.

N = This transaction is part of a set and is not the agent transactions.
Total Length   64      

 

Version 2.00
Usage This CETE is optimized for use in transaction sets. It can represent all transactions in a set, but a better choice would be to use V3.0 to represent non-agent transactions.
Comments When this CETE is used, the transaction data in the CIM Message starts in physical position 95.

Field Description

 Starts At

Length

 Data Type Required?

Comments
CETE Mark 1 7 A Y Literal "CETE200" which identifies this version of the CETE

First Chronological ID

 8

15

 A Y

Provides a chronological sequence. The data should be incorporated using this sequence, ascending.

Second Chronological ID

 23

5

 A N

Provides additional chronological sequencing. The data should be incorporated using any previous Chronological fields as well as this one, ascending.

Third Chronological ID

 28

5

 A N

Provides additional chronological sequencing. The data should be incorporated using any previous Chronological fields as well as this one, ascending.

Target

 33

15

 A N

Whom the data is targeted to.

Target Qualifier

 48

1

 A N

What is being represented in "Target". Valid values are "M" (manufacturer), "S" (supplier), and "R" (retailer)

Source

 49

15

 A N

Who is this message coming from?

Source Qualifier

 64

1

 A N

What is being represented in "Source". Valid values are "M" (manufacturer), "S" (supplier), and "R" (retailer)

Topic

 65

2

 A Y

What data is contained in the transaction portion of this message. See each transaction description for the topic code for that data.
Transaction Encoding Method 67 1 A N How is the transaction encoded? P=PIDF, X=XML, *Blank=PIDF

Version

 68

3

 A Y

What is the version of the transaction?

Transaction ID

 71

15

A Y

ID which uniquely identifies the transaction contained in the message.  Source, Source Qualifier, and Transaction ID combined creates a system-wide unique transaction.

Transaction Set  Count

86

8.0

N Y

How many individual messages comprise the transaction set (Including all Pilot/Trailer Transactions).  

Agent?

94

1

 A Y

Indicates if this message represents itself and/or other transactions.  Transactions that are part of a set must have a single "Agent" transaction.  Normally, this will be the pilot.  For transactions that are not part of a set, they are "self represented".

Y = This transaction is the agent for itself or a set of other transactions.

N = This transaction is part of a set but is not the agent transaction.
Total Length   94      

 

Version 2.01
Usage This CETE is optimized for use in transaction sets. It can represent all transactions in a set, but a better choice would be to use V3.0 to represent non-agent transactions.
Comments When this CETE is used, the transaction data in the CIM Message starts in physical position 106.

Field Description

 Starts At

Length

 Data Type Required?

Comments
CETE Mark 1 7 A Y Literal "CETE200" which identifies this version of the CETE

First Chronological ID

 8

15

 A Y

Provides a chronological sequence. The data should be incorporated using this sequence, ascending.

Second Chronological ID

 23

5

 A N

Provides additional chronological sequencing. The data should be incorporated using any previous Chronological fields as well as this one, ascending.

Third Chronological ID

 28

5

 A N

Provides additional chronological sequencing. The data should be incorporated using any previous Chronological fields as well as this one, ascending.

Target

 33

15

 A N

Whom the data is targeted to.

Target Qualifier

 48

1

 A N

What is being represented in "Target". Valid values are "M" (manufacturer), "S" (supplier), and "R" (retailer)

Source

 49

15

 A N

Who is this message coming from?

Source Qualifier

 64

1

 A N

What is being represented in "Source". Valid values are "M" (manufacturer), "S" (supplier), and "R" (retailer)

Topic

 65

2

 A Y

What data is contained in the transaction portion of this message. See each transaction description for the topic code for that data.
Transaction Encoding Method 67 1 A N How is the transaction encoded? P=PIDF, X=XML, *Blank=PIDF

Version

 68

3

 A Y

What is the version of the transaction?

Transaction ID

 71

15

A Y

ID which uniquely identifies the transaction contained in the message.  Source, Source Qualifier, and Transaction ID combined creates a system-wide unique transaction.

Transaction Set  Count

86

8.0

N Y

How many individual messages comprise the transaction set (Including all Pilot/Trailer Transactions).  

Agent?

94

1

 A Y

Indicates if this message represents itself and/or other transactions.  Transactions that are part of a set must have a single "Agent" transaction.  Normally, this will be the pilot.  For transactions that are not part of a set, they are "self represented".

Y = This transaction is the agent for itself or a set of other transactions.

N = This transaction is part of a set but is not the agent transaction.
Exclusive Transaction? 95 1 A N Indicates if this transaction is exclusive from this particular source.  Once an exclusive transaction is successfully processed, any subsequent attempt to process a transaction with the same transaction ID will result in a critical transaction error.

Y = This transaction is exclusive.

Ignore Redundancy Option? 96 1 A N Indicates if the dispatch request was processed in CIM while ignoring the target's option to suppress redundant data.

Y=Suppress Redundant Data option was ignored.

*Blank=Suppress Redundant Data option was not ignored.
Reserved 97 9 A N Reserved for future use.
Total Length   105      

 

Version 3.00
Usage This CETE is optimized for use in transaction sets. It can represent only a non-agent message from a transaction set. When creating a transaction set, you may use the more robust V2.0 CETE to construct the agent message and  use the leaner V3.0 CETE to construct all subsequent non-agent messages. You MUST use this technique if you want to use the V3.0 CETE.  Messages delivered using V3.0 with no corresponding agent delivered with V2.0 will be discarded!
Comments When this CETE is used, the transaction data in the CIM Message starts in physical position 69.

Field Description

 Starts At

Length

 Data Type Required?

Comments
CETE Mark 1 7 A Y Literal "CETE300" which identifies this version of the CETE

First Chronological ID

 8

15

 A Y

Provides a chronological sequence. The data should be incorporated using this sequence, ascending.

Second Chronological ID

 23

5

 A N

Provides additional chronological sequencing. The data should be incorporated using any previous Chronological fields as well as this one, ascending.

Third Chronological ID

 28

5

 A N

Provides additional chronological sequencing. The data should be incorporated using any previous Chronological fields as well as this one, ascending.

Source

 33

15

 A N

Who is this message coming from?

Source Qualifier

 48

1

 A N

What is being represented in "Source". Valid values are "M" (manufacturer), "S" (supplier), and "R" (retailer)

Topic

 49

2

 A Y

What data is contained in the transaction portion of this message. See each transaction description for the topic code for that data.

Version

 51

3

 A Y

What is the version of the transaction?

Transaction ID

 54

15

A Y

ID which uniquely identifies the transaction contained in the message.  Source, Source Qualifier, and Transaction ID combined creates a system-wide unique transaction.

Total Length   68      

 

CIM Transaction:

A CV1 CIM Transaction represents a single, logical unit of work.  They may be dispatched individually or as part of a Transaction "Set".  Each transaction has its own version number.  Over time, specific transactions may be enhanced.  When this occurs, the version of the transaction is changed.  DAC will, by default, begin to utilize the newer transaction version when exporting data.  It is possible to designate which transaction version to use for individual targets.  This allows a specific target to continue to receive transactions formatted at a given version rather than utilize the most recent transaction version-- thereby maintaining data compatibility.

Visit the following link to view an index of available transactions:

CIM Transaction Set

    A CIM Transaction Set is defined as one or more individual CIM messages that should be processed as a whole. It consists of two outer encapsulating CIM messages with other inner CIM messages between them. The inner CIM messages comprise the logical transaction. The outer CIM messages provide an encapsulation mechanism and define the structure of a transaction set. Inner CIM messages may consist of discrete, stand-alone messages, or may themselves be part of a nested transaction set. The following illustrates an example of both a simple transaction set and a nested transaction set.

Simple, non-nested transaction set: Sales Order

Sales Order Pilot Transaction
Sales Order Header Transaction
Sales Order Detail Transaction
Sales Order Detail Transaction
Sales Order Trailer Transaction


    In most business systems, a Sales Order typically consists of "Header" information followed by one or more detail lines. In the above illustration, the sales order has one header transaction and two detail transactions. Collectively, these three individual transactions form the body of a transaction set. The Pilot and Trailer CIM messages are used to encapsulate the body of the transaction set. In the target system, the three encapsulated messages should be processed as a logical transaction. In this example, the net effect would be that a particular sales order is created in the target system.

Nested transaction set: Sales Order Summary

Sales Order Summary Pilot Transaction
Sales Order Pilot Transaction
Sales Order Header Transaction
Sales Order Detail Transaction
Sales Order Detail Transaction
Sales Order Trailer Transaction
Sales Order Pilot Transaction
Sales Order Header Transaction
Sales Order Detail Transaction
Sales Order Detail Transaction
Sales Order Detail Transaction
Sales Order Trailer Transaction
Sales Order Summary Trailer Transaction

    A sales order summary transaction set represents ALL sales orders for some entity (I.E. All sales orders for a given customer, or all sales orders for a given employee). The summary may consist of many individual Sales Order transaction sets. As illustrated above, the Sales Order Summary represents a transaction set which contains one or more "nested" Sales Order transaction sets within it.

View an index of available transactions and transaction sets:

    Certain fields in the CETE portion of a CIM message play a vital role when using transaction sets.  Transaction ID must be the same for all transactions in the set.  This is how the CIM Transaction Gateway knows that a set of transactions belong together.  Additionally, Transaction ID should be unique for the set with no other Transaction Set using the same Transaction ID.   

    The CIM Transaction Gateway will process all transactions in the set in the order dictated by the Chronological IDs.  These fields must have a numerical value which causes the transactions to be processed in the proper sequence as documented.  Generally, a transaction set pilot should have the lowest numerical value, and the transaction set trailer should have the highest.

PIDF Data Types:


    This section describes the different data formats for PIDF-based data. 

Numeric (N)

    Data is considered to be a positive integer.  Only 0 - 9 should be placed in a field of this format.  Data should be zero-filled to span the entire length of the field. Spaces are not allowed.

Alpha-Numeric (A)

Data consists of free-form text.  Any characters in the EBCDIC character set are valid.

Real (R)

    Data consists of a "Real" number.  This is a very flexible representation of a numeric value. The value may be left-justified or right-justified within the field.  Leading zeros may or may not be present.  Only the characters 0-9,  common numeric formatting characters, and spaces are allowed. A period (.) marks the fractional precision of a numeric value.  The "Format/Comment" sections for a field should be observed and conformed to for best results. Valid numeric formatting characters are:

What follows are samples of valid "Real" formatted data:

1234
$1234.00
$1,234.00-
$1,234.00+
-$1,234.00
+$1,234.00
1234.56
.56
.56789
12345.6789
00001234