Understanding EDI Transaction Mapping

This topic discusses:

  • EDI transaction mapping.

  • New EDI transactions.

  • PeopleSoft business document format.

PeopleSoft applications store transaction data in tables in the PeopleSoft database. For an application to process an EDI transaction, it needs the transaction data in its tables. So the first step in processing an EDI transaction is transferring the data from an incoming EDI Transaction Set file into the application tables. Similarly, the first step in generating an EDI transaction for delivery to a trading partner is getting the transaction data out of the application tables into an EDI Transaction Set file.

You specify how the EDI agent transfers data between EDI Transaction set files and application tables by creating electronic commerce maps. Two kinds of electronic commerce maps are available:

  • Inbound maps, which transfer incoming transaction data into your PeopleSoft database.

  • Outbound maps, which create outgoing EDI documents from transaction data in the database.

Map profiles specify the maps to which your trading partners have access.

We deliver PeopleSoft applications with a number of EDI transactions already defined. You can use PeopleTools to add support for additional transactions. Here are the major steps in the process.

To process new EDI transactions:

  1. Use PeopleTools to develop the application that processes the transaction.

    Create the database tables and the pages that users need to process the transaction.

  2. Define a PeopleSoft Business Document format based on the EDI format for the transaction.

    At this step, think about how the data from the EDI document needs to map to the PeopleSoft application tables.

  3. Write a translation program that converts EDI documents into PeopleSoft Business Document format.

    Usually, you will have an EDI translator program to do this step.

  4. Create staging tables to serve as a temporary holding area between the PeopleSoft document and the application tables.

  5. Create maps to copy data between the PeopleSoft business documents and the staging tables.

  6. Write an application load procedure that transfers data from the staging tables to the application tables.

The PeopleSoft Business Document Format topic documents step 5 in this procedure.

A PeopleSoft business document is an ASCII file that contains the data for one or more EDI transactions. It contains transaction data and control information, which tells the system what type of transaction it is, who it came from, and how parts of the document relate to each other.

A PeopleSoft business document is divided into records, separated from each other with a carriage return/line feed (CR/LF) pair. Each record is divided into fixed-length fields. One of the fields in the record, usually the first one, is a record ID field that specifies the record type: a header, detail line, summary line, and so on. The remaining fields depend on the type of record.

The first record in a PeopleSoft business document is always a control record. The control record specifies the type of transaction contained in the following lines and the trading partners involved. Based on the control record, the EDI agent retrieves the mapping definition for the specified transaction and the data conversion options relevant to the trading partner.

The EDI agent reads the records in the document one at a time. For each record following the control record, the EDI agent reads the value in the record ID field and uses it to determine the PeopleSoft record definition to use to parse the rest of the record. The PeopleSoft record definition specifies the location, size, and data type of the remaining fields in the record. The EDI agent copies the data from the document into staging tables in the database, following the rules in the mapping definition.

When the EDI agent encounters a new control record, identified by the record ID 999 or 998, it retrieves the mapping definition for the new transaction type and repeats the process. Within the flat file, the control records:

  • Enable a third-party translator or trading partner, upon receiving the file, to determine what the data contains (999 only).

  • Enable PeopleSoft EDI Manager, upon receiving the file, to determine what the data contains (999 and 998).

Most transactions include a variety of record types: a header, detail lines, schedules, summary lines, and so on. The layout of the records within a PeopleSoft business document follows a logical pattern. All detail lines linked to a particular parent or header line must follow the parent record.

Note: The EDI agent processes transactions at the “unit of work” level, corresponding to the ST/SE level in X.12 format. Each transaction should be a unit of work that you want the EDI agent to commit or roll back as a unit, such as a single purchase order or invoice.

Let’s look at an example:

001 Header Line 1
002 Detail Line 1A
002 Detail Line 1B
002 Detail Line 1C
001 Header Line 2
002 Detail Line 2A
002 Detail Line 2B

This file has two header lines and five detail lines. The EDI agent determines which detail lines go with which header lines based entirely on their order.

When the EDI agent processes this PeopleSoft business document, it works through the records in order. First, it processes header line 1 using the work record that’s appropriate for record ID 001. Next, it processes detail line 1A using the work record for record ID 002.

If you ask the EDI agent to calculate a value, such as the sum of all the detail lines, it determines which detail lines to group together based on their position. It calculates the value for all detail lines since the most recently encountered header line.

999 Record Format

This reserved record identifier acts as a control record to switch map definitions within a data file. The layout looks like this:

Field

Description

Value

1–3

Record Identifier.

‘999’

4–18

Transaction ID.

Char

19–22

External entity code.

Char / Values :

CUST or VNDR

23–38

External trading partner ID.

Char

39–42

Internal alias entity code.

Char / Values :

AP,AR,OM, ...

43–58

Internal trading partner alias ID.

Char

998 Record Format

This format allows the specification of a PeopleSoft map ID directly in the data contents. This type of map definition can be used when trading partner conversions are not needed or not available. All other data conversion functionality can be used.

Field

Description

Value

1–3

Record identifier.

‘998’

4–13

PeopleSoft EC map ID.

Char

14–23

PeopleSoft trading partner profile ID.

Char

24–33

PeopleSoft data conversion profile ID.

Char