Upgrading PeopleSoft EDI Transactions From PeopleSoft 7.5 to PeopleSoft 9.0

This chapter provides an overview of the PeopleSoft EDI Manager upgrade and discusses how to:

• Compare key features of PeopleSoft EDI Manager and PeopleSoft Integration Broker.

• Identify PeopleSoft EDI Manager upgrade paths.

• Review the differences between PeopleSoft 7.5 flat file EDI processing and PeopleSoft 9.0 flat file EDI processing.

• Obtain file layouts.

Understanding the PeopleSoft EDI Manager Upgrade

PeopleSoft EDI Manager is a flat file-oriented tool used to import and export data between application tables and third-party systems. The publish-and-subscribe architecture of PeopleSoft Integration Broker enables more zero-latency data transmittal, direct business-to-business communication, and Extensible Markup Language (XML) adoption.

Note. Many customers use PeopleSoft EDI Manager to load legacy data or implement batch interfaces with other applications. PeopleSoft recommends that you use FLOs instead of EDI maps for this purpose. There is no direct upgrade path from the EDI map definition to the File Layout Definition (FLD). But PeopleSoft EDI Manager records can be reused in FLDs, which can be accessed through PeopleCode and PeopleSoft Application Engine. This chapter addresses the traditional EDI processing, which involves external trading partners and standard EDI formats, such as X.12 or EDIFACT.

Comparing Key Features of PeopleSoft EDI Manager and PeopleSoft Integration Broker in PeopleTools 9.0

The following table compares PeopleSoft EDI Manager and PeopleSoft Integration Broker at a feature level:

Note. In PeopleSoft 7.5, the EDI Manager supports the concept of a generic trading partner ID that is linked to customers, vendors, banks, and so forth. It provides a rudimentary mapping function to link the ID to the internal customer value. Many customers prefer using translation software to map this data. Therefore, inbound data to PeopleSoft requires the actual customer or vendor ID stored within the application tables. If an invalid ID is transmitted, an error condition is reported.

See Also

Enterprise PeopleTools 8.48 PeopleBook: Integration Tools

Identifying PeopleSoft EDI Manager Upgrade Paths

When communicating with your trading partners, you have several options for data transportation. You can use value added networks (VANs), direct internet connections, or FTP. You must decide whether to preserve the data in XML format or transform it into a standard EDI format, such as X.12 or EDIFACT.

Note. Manual upgrade steps still exist. Modifications to most of the EDI transactions existing in PeopleSoft 7.5 and prior include additional data elements. Map these new fields within translator products as needed and notify the trading partners. Obtain any necessary adapters directly from transformation vendors. Find the right syntax of specific service operations (headers, body, trailers, and so on) and other technical and setup specifications of PeopleSoft integrations in the Integration Services Repository (ISR) and the PeopleSoft Software Development Kit documentation.

This section discusses the following upgrade paths:

• Communicate directly with your trading partners using XML.

• Integrate PeopleSoft XML and standard EDI formats, such as X.12 or EDIFACT.

• Continue to exchange flat file information between your EDI translator or FTP system.

See Also

The Integration Services Repository (ISR)http://www.peoplesoft.com/corp/en/iou/isr/index.jsp

Communicating Directly With Your Trading Partners Using XML

Work with each trading partner who transmits data using HTTP. Partners accustomed to exchanging EDI transactions using EDI Manager flat files must adapt the PeopleSoft Integration Broker architecture. They may also need to translate between different XML formats.

Note. This path is most useful for bringing new trading partners into your eCommerce network.

Consider the following advantages when using this upgrade path:

• Batch window elimination: transmit data with near-zero latency between trading partners.

• Small- to mid-size trading partners use browser-based forms to exchange XML data directly with internal systems.

• VAN charge elimination.

• Completely internet-based, using generally available tools (for example, parsers and style sheets).

Consider the following disadvantages when using this upgrade path:

• Major impact on trading partners.

• No upgrade path from customer PeopleSoft EDI Manager transactions to XML. However, XML data elements are similar to those in EDI business document files.

• New configuration required to use PeopleSoft Integration Broker technology.

Sending Outbound XML to a Trading Partner

To send outbound XML to a trading partner:

1. If necessary, use PeopleSoft Integration Broker to build a transformation that maps the PeopleSoft XML to the trading partner's XML format.

2. Define a PeopleSoft node to represent the trading partner, and set up the PeopleSoft Integration Broker.

   The specified URL points to the trading partner's web server.

3. If the trading partner uses one of the industry-standard connectors packaged with the PeopleSoft Integration Broker, configure the node to use this connector.

4. If the trading partner does not support any industry-standard connectors, build a connector to transport XML data, and register the connector on the PeopleSoft Gateway.

5. Initiate your publish functions within the PeopleSoft applications.

Receiving Inbound XML from a Trading Partner

To receive inbound XML from a trading partner:

1. If necessary, use PeopleSoft Integration Broker to build a transformation that maps the trading partner's XML to the PeopleSoft XML format.

2. Define a node within PeopleSoft to receive this data, and set up the PeopleSoft Integration Broker.

3. If the trading partner uses one of the industry-standard connectors packaged with PeopleSoft Integration Broker, configure the node to use this connector.

4. Configure the trading partner's system so that it posts to the proper connector on the PeopleSoft Gateway.

5. Begin receiving data from your trading partner.

See Also

Enterprise PeopleTools 8.48 PeopleBook: Integration Tools

Integrating PeopleSoft XML and Standard EDI Formats Such as X.12 EDI or EDIFACT

In this scenario, PeopleSoft exchanges EDI data utilizing PeopleSoftXML and transformations to or from industry standard EDI formats. Most EDI vendors now support XML formats and can receive XML, translate the fields to standard EDI field formats, such as X.12 EDI or EDIFACT, and write the data to a flat file. (They can also deposit the EDI transactions onto the VAN of your choice.) Conversely, they can also receive inbound transactions from the VAN, map the fields to PeopleSoft XML format, and publish to the PeopleSoft Integration Broker Gateway.

Note. This is the best approach for maintaining your investment in translation software while using PeopleSoft Integration Broker architecture. It is not a strong option if your current translation software does not support XML.

Consider the following advantages when using this upgrade path:

• Batch windows reduction: data can be transmitted between PeopleSoft and the translation software with zero latency, then pooled into appropriate batches for transmission to the VAN.

• Preserves investment in EDI standards support, minimizing impact to trading partners because they receive the same basic documents as they did in PeopleSoft 7.5.

• Removes dependency on PeopleSoft EDI Manager.

• Provides a stepping stone to pure XML business-to-business architecture.

• Uses delivered PeopleSoft EDI XML transactions.

Consider the following disadvantages to using this upgrade path:

• Requires major EDI maps rewrite for the translation application or the VAN.

• Still incurs VAN charges.

Converting Existing Outbound Translation Maps to Use XML

To convert existing outbound translation maps to use XML:

1. Customize new EDI maps to convert the XML data into the customer's required format, such as X.12 or EDIFACT.

2. Define a node within PeopleSoft to represent the trading partner, and setup the PeopleSoft Integration Broker.

   The specified URL points to the trading partner's web server.

3. If the translator uses one of the industry-standard connectors packaged with PeopleSoft Integration Broker, configure the node to use this connector.

4. If the trading partner does not support any industry-standard connectors, build a connector to transport XML data, and register the connector on the PeopleSoft Gateway.

5. Initiate your publish functions within the PeopleSoft applications.

Converting Existing Inbound Translation Maps to Use XML

To convert existing inbound translation maps to use XML:

1. Customize new EDI maps to convert the customer format to XML data.

2. Define a node within PeopleSoft to receive this data, set up the PeopleSoft Integration Broker.

3. If the translator uses one of the industry-standard connectors packaged with PeopleSoft Integration Broker, configure the node to use this connector.

4. If the trading partner does not support any industry-standard connectors, build a connector to transport XML data, and register the connector on the PeopleSoft Gateway.

5. Configure the trading partner's system so that it posts to the proper connector on the PeopleSoft Gateway.

6. Begin receiving data from your trading partner.

Exchanging Flat File Information Between Your EDI Translator or FTP System

This section discusses setup steps and specific field deltas that occur when translating between PeopleSoft Integration Broker and FLOs.

See Understanding the Differences Between PeopleSoft 7.5 Flat File EDI Processes and PeopleSoft 9.0 Flat File EDI Processes for a detailed description of the differences between EDI flat file processing in PeopleSoft 7.5 and PeopleSoft 9.0.

For outbound transactions, configure the batch publish utility to generate a flat file. Service Operations supporting outbound EDI integration have a file layout definition set up to work with their associated batch publish rules. The flat file is deposited into a subdirectory accessible by the translation software. (Most EDI transformation software sweep subdirectories looking for available transaction files.) The format of these files closely matches previous PeopleSoft EDI Manager files, minimizing the changes in the process of mapping to the format.

For inbound transactions, you can load data into PeopleSoft using the Inbound File Publish utility. This utility reads a flat file that mimics PeopleSoft EDI Manager format, then publishes it to the PeopleSoft Integration Broker as XML data for inbound processing. Service Operations supporting EDI integration have a file layout definition and file rules already set up. The files generated in this manner follow the same rules as XML, with these exceptions:

• A flat file has the same field sequence as the XML, but every field in the XML has a tag.

• Fields in the flat file do not have a tag, as each field instead has a fixed position in each row within the file.

• Row IDs.

  ECFILEROWIDs from EDI maps still exist. These typically follow a pattern, though the pattern may differ from EDI transaction to EDI transaction. The ECFILEROWID is the first field for every record in the definition. The convention is as follows:

  Level1  000
  
  Level1  100
  
  Level2  200
  
  etc.
  

• Audit action.

  The AUDIT_ACTN field is defined on each record in the FLD. The file utilities copy this field between the record and the appropriate PSCAMA on a level-by-level basis. This field is defined as the second field for every record in the FLD. A blank audit action represents a record that did not have any changes to it; this record is included to preserve parent/child relationships. Thus, a lower level record may contain the changed data.

• A "control record" that determines the format of the file's layout exists at the top of each PeopleSoft EDI Manager flat file.

  This control record is commonly referred to as the "999" or "998" record. The 999 record specifies the trading partner identifiers related to the document's sender and receiver. These IDs resolve to a specific map format using a database query in PeopleSoft EDI Manager. The 998 record specifies the actual map name and transaction ID.

  The new FLO also supports control records. PeopleSoft Application Designer specifies the format of the record, which then instructs the file object processor how to interpret the record data. The convention used for PeopleTools 9 EDI transactions becomes the 998 record.

  The following is the record specification:

  AAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBB

  AAAAAAAAAA is the 10-character file layout ID. This is the 998 record.

  BBBB... is the file layout ID name of up to 30 characters.

  Note. Two EDI transactions continue to use PeopleSoft EDI Manager in PeopleSoft 9.0: Accounts Payable Voucher (inbound) and Payment (outbound).

Consider the following advantages when using this upgrade path:

• Maintains more legacy investment than other options.

• Minimizes impact to trading partners because standard EDI formats are still transmitted to the partner.

• Requires no additional investment in XML-based software.

Consider the following disadvantages when using this upgrade path:

• Maintains batch processing.

• Reduced performance due to multiple passes through the data (translator, file utility, and Integration Broker).

• Maintains reliance on old PeopleSoft EDI Manager file formats.

• Does not provide direct trading partner communication.

• Still incurs VAN charges.

By providing flat file variations for each of the supported EDI transactions, PeopleSoft 9.0 supports an upgrade path for EDI translator products. The partner products certified for PeopleSoft 7.5 and earlier on PeopleSoft EDI Manager migrate easily to support the new file layout objects. Most transactions retain the basic structure and contain relatively minor field changes.

In turn, the EDI translation software remaps the new versions of these transactions to standard EDI formats and further reduces any deltas. For example, if PeopleSoft has added a new field to a file for an invoice deemed irrelevant for the implementation, the translator can mask the field. Hence, the standard EDI format is generated in the same manner as prior releases.

Converting Standard EDI Flat File Outbound Transactions into PeopleSoft Business Document Flat File Format

To convert standard EDI flat file outbound transactions into PeopleSoft business document flat file format:

1. Modify existing maps making changes for row IDs, audit actions, control records, and any layout changes made in the latest versions.

2. With standard delivered PeopleSoft service operations, update the appropriate batch publish rule to create a flat file, instead of XML

3. Activate the appropriate service operations.

4. Initiate publish functions within your PeopleSoft applications.

Converting Standard EDI Flat File Inbound Transactions into PeopleSoft Business Document Flat File Format

To convert standard EDI flat file inbound transactions into PeopleSoft business document flat file format:

1. Modify existing maps making changes for row IDs, audit actions, control records, and any layout changes made in the latest versions.

2. Create a file rule to determine the directory that will receive the inbound transaction data, or update an existing file rule that's already associated with the message being transmitted with the destination of the subdirectory.

3. Set up the PeopleSoft Integration Broker.

4. Begin receiving data from your trading partner.

See PeopleSoft Enterprise Supply Chain Management Integration PeopleBook, “Activating Application EIPs”

See PeopleSoft Enterprise Supply Chain Management Integration PeopleBook, “Establishing Publish Rules Using the Publish Utility”

Reviewing the File Layout Definition Properties Dialog Box

The following is an example of a File Layout Definition Properties dialog box. The layout type is fixed, as it was with PeopleSoft EDI Manager.

The EDI transaction's data record structure appears as follows:

XXXYAAABBBBB

where:

• XXX is the three-character ECFILEROWID.

• Y is the one-character AUDIT_ACTN flag.

• AAABBBB.... are the fields.

Reviewing File Definitions

The following file example contains three distinct file definitions:

For this file definition example, consider the following:

• The PO_REQUEST_FOR_QUOTE_RESPONSE control record has a single transaction.

• The PURCHASE_ORDER_ACKNOWLEDGEMENT record has two transactions.

• The ADVANCED_SHIPPING_RECEIPT has a single transaction.

Reviewing Impacted Fields

Some message definition control fields are discarded during file processing.

PeopleSoft Integration Broker definitions contain record definitions that reuse or point to a record previously defined in PeopleSoft Application Designer. File Layout Designer, however, creates a copy of the record in a new file layout definition and enables you to add additional fields to each record definition. The File Layout Designer record and the original record definition become separated and do not share attributes.

PeopleSoft Integration Broker also implements a control record of its own, called the PeopleSoft Common Application Message Attributes record (PSCAMA). The PSCAMA contains attributes that specify what language code, process instance, message sequence, and audit action is used. The PSCAMA acts as a sibling record to every regular record in the message definition. One primary use of the PSCAMA is to determine whether a particular record of data has been updated, inserted, or deleted (the AUDIT_ACTN field).

Note. The file layout definition does not require a PSCAMA record.

Understanding the Differences Between PeopleSoft 7.5 Flat File EDI Processes and PeopleSoft 9.0 Flat File EDI Processes

There are significant differences between the method you use to process EDI transactions in PeopleSoft 7.5 and the method you use to process in EDI transactions in PeopleSoft 9.0. In PeopleSoft 7.5, you use the EDI Manager to process EDI transactions. In PeopleSoft 9.0, you use the PeopleSoft Integration Broker to process EDI transactions.

The PeopleSoft EDI Manager is a flat file-oriented tool used to import and export data between application tables and third-party systems. PeopleSoft Integration Broker offers a more automated, timely, and efficient way to send data across systems then was previously available. The publish and subscribe architecture of PeopleSoft Integration Broker technologies enables more zero-latency data transmittal, direct business-to-business communication, and Extensible Markup Language (XML) adoption.

In PeopleSoft 9.0, you maintain the ability to process EDI transactions using flat files. This flexibility enables you to transition to the publish and subscribe technology as business requirements and trading partner relationships demand this functionality.

This section provides overviews of:

• The inbound process using flat files in PeopleSoft 7.5 and 9.0.

• The outbound process using flat files in PeopleSoft 7.5 and 9.0.

Note. You can process EDI transactions using multiple methods from a source trading partner to a destination trading partner. This section describes a basic EDI transaction process flow for PeopleSoft 7.5 and PeopleSoft 9.0. There can be many variations on this theme.

Understanding the Inbound Process Using Flat Files in PeopleSoft 7.5 and PeopleSoft 9.0

This section provides overviews of:

• PeopleSoft 7.5 inbound process using flat files.

• PeopleSoft 9.0 inbound process using flat files in the PeopleSoft format.

• PeopleSoft 9.0 inbound process using flat files in X.12 EDI format.

Processing PeopleSoft 7.5 Inbound Flat File EDI Transaction Processes

The following diagrams illustrate the PeopleSoft 7.5 inbound flat file EDI transaction process:

PeopleSoft 7.5 Inbound Flat File EDI Transaction Process (1 of 2)

PeopleSoft 7.5 Inbound Flat File EDI Transaction Process (2 of 2)

To process inbound flat file EDI transaction in PeopleSoft 7.5:

1. The source trading partner initiates a process that generates a flat file containing EDI transactions in the sources format.

2. The file is passed to a middleware translation tool that generates an outbound file in the appropriate EDI format (X.12, EDIFACT, etc).

   Depending on the relationship with various trading partners' data mapping, transformations may occur at this point to meet trading partner-specific mapping requirements. The formatted file is then sent on to the source trading partner's VAN—a private network used for exchanging EDI transactions. However, networks can also be the Internet, a dedicated link, or a sole-source provider.

3. The source trading partner’s VAN distributes the flat file to the destination trading partner’s VAN.

4. The source trading partner and destination trading partner can use the same VAN.

5. The destination trading partner receives the flat file from the VAN.

   A middleware tool is used to convert the source file into the appropriate PeopleSoft Business Document file format. This process includes a conversion from the sources EDI format (X.12, EDIFACT, etc). Additional translation requirements may be required if the source trading partner is sending a generic file that does not meet the destination trading partner's data requirements.

6. The destination trading partner performs the Inbound EC Agent process (EDI Manager) in PeopleSoft to load the transactions into staging tables.

   The Inbound EC Agent process inputs the electronic data flat file, translates the data using the PeopleSoft Business Document layout, and stages the data into the staging tables.

7. PeopleSoft applications initiate processes that read the transactions from the staging tables, perform validations, and load the data to the actual PeopleSoft application database tables.

   If errors are found in the transactions, use error handling to fix the errors and resubmit the transactions.

Note. The mapping functions (mapping to and from the standard EDI formats) may be done at the source trading partner’s site, the source or destinations VAN, or at the destination trading partner's site, depending on the relationship established with the trading partners and the VANs.

Processing PeopleSoft 9.0 Inbound Flat File EDI Transaction Processes in the PeopleSoft Format

A flat file that uses the PeopleSoft format can be generated by a third-party system in this PeopleSoft format or generated by a third-party system and then converted to the PeopleSoft format by a middleware product. A flat file could also come from another PeopleSoft system. The PeopleSoft inbound file publish utility converts the data from a flat file to an XML file using the PeopleSoft format. The inbound data is then placed in the message queue, checked for errors, and then moved to the inbound staging tables to be processed by the individual PeopleSoft application.

The following diagrams illustrate the PeopleSoft 9.0 inbound flat file EDI transaction process:

Inbound flat file EDI transaction process for PeopleSoft 9.0 using the PeopleSoft format (1 of 2)

Inbound flat file EDI transaction process for PeopleSoft 9.0 using the PeopleSoft format (2 of 2)

To process PeopleSoft 9.0 inbound flat file EDI transactions in the PeopleSoft format:

1. The source trading partner initiates a process that generates a flat file containing EDI transactions in the sources format.

2. The file is passed to a middleware translation tool that generates an outbound file in the appropriate EDI format (X.12, EDIFACT, etc).

   Depending on the relationship with various trading partners' data mapping, transformations may occur at this point to meet trading partner-specific mapping requirements. The formatted file is then sent on to the source trading partner's VAN—a private network used for exchanging EDI transactions. However, networks can also be the Internet, a dedicated link, or a sole-source provider.

3. The source trading partner’s VAN distributes the flat file to the destination trading partner’s VAN.

   The source trading partner and destination trading partner can use the same VAN.

4. The destination trading partner receives the flat file from the VAN.

   A middleware tool is used to convert the source file into the appropriate PeopleSoft Business Document file format. This process includes a conversion from the sources EDI format (X.12, EDIFACT, etc). Additional translation requirements may be required if the source trading partner is sending a generic file that does not meet the destination trading partner's data requirements.

5. The destination trading partner performs the Inbound File Publish process that changes the flat file transactions to XML and then writes them to a message queue.

   The Inbound File Publish process inputs the electronic data flat file, translates the data using the PeopleSoft File Layout Definition and rules, and then publishes the data to the PeopleSoft Integration Broker as XML transactions.

6. PeopleSoft Integration Broker subscription processes (OnNotify Handlers) are automatically executed that retrieve the data from the message queue and write it to stage tables.

7. PeopleSoft applications then read the transactions from the staging tables, perform validations, and load the data to the actual PeopleSoft application database.

8. If any errors are found in the transactions, use error handling to fix the errors and to resubmit the transactions.

Processing PeopleSoft 9.0 Inbound Flat File EDI Transaction Processes in X.12 EDI Format

An inbound flat file can be generated by a third-party system in this X.12 EDI flat file format or generated by a third-party system and then converted to the X.12 EDI flat file format by a middleware product. An EDI flat file could also come from another PeopleSoft system. Once received by your PeopleSoft system, the PeopleSoft Integration Broker uses transforms to convert the data from an X.12 EDI flat file format to the PeopleSoft format. The inbound PeopleSoft-formatted XML data is then placed in the message queue, checked for errors, and then moved to the inbound staging tables to be processed by the individual PeopleSoft application.

The following diagrams illustrate the PeopleSoft 9.0 inbound flat file X.12 EDI transaction process:

Inbound flat file EDI transaction process for PeopleSoft 9.0 using X.12 EDI format (1 of 2)

Inbound flat file EDI transaction process for PeopleSoft 9.0 using X.12 EDI format (2 of 2)

To process PeopleSoft 9.0 inbound flat file EDI transactions in X.12 EDI format:

1. The source trading partner initiates a process that generates a flat file containing EDI transactions in the sources format.

2. The source trading partner's VAN distributes the flat file to the destination trading partner's VAN.

   The source trading partner and destination trading partner can use the same VAN.

3. The destination trading partner performs the Inbound File Loader process which changes the X.12 EDI formatted flat file to an X.12 EDI formatted XML transaction and publishes it to the Integration Broker. A pre-defined file layout definition is used by the Inbound File Loader when generating the X.12 EDI XML transaction. The Integration Broker, using pre-defined transform routines then generates an XML transaction in PeopleSoft's format.

   Pre-defined file layout definitions and Transformation examples are provided for the inbound 840 (Sales Quote Load) and 850 (Sales Order Load) X.12 EDI formats.

   Note. These examples require customizations for individual trading partner requirements. Other inbound X.12 EDI transactions can be supported by creating transforms using the same concepts provided in the example transform programs.

4. PeopleSoft Integration Broker subscription processes (OnNotify Handlers) are automatically executed that retrieve the data from the message queue and writes the data to stage tables.

5. If any errors are found in the transactions, use error handling to fix the errors and to resubmit the transactions.

Understanding the Outbound Process Using Flat Files in PeopleSoft 7.5 and PeopleSoft 9.0

This section provides overviews of:

• PeopleSoft 7.5 outbound process using flat files.

• PeopleSoft 9.0 outbound process using flat files in the PeopleSoft format.

• PeopleSoft 9.0 outbound process using flat files in X.12 EDI format.

Processing PeopleSoft 7.5 Outbound Flat File EDI Transaction Processes

The following diagram illustrates part of the PeopleSoft 7.5 outbound flat file EDI transaction process:

PeopleSoft 7.5 Outbound Flat File EDI Transaction Process (1 of 2)

PeopleSoft 7.5 Outbound flat file EDI transaction process (2 of 2)

To process PeopleSoft 7.5 outbound flat file EDI transaction processes :

1. The source trading partner initiates a PeopleSoft application process that retrieves the transactional data from the PeopleSoft application database tables and loads the EDI transactions into PeopleSoft staging tables, or prepares the data so it can be picked up by the EDI Manager process.

2. The source trading partner performs the Outbound EC Agent process (EDI Manager) in PeopleSoft to read the EDI transactions from the staging tables and generate a flat file.

3. The Outbound EC Agent process reads the staging tables, translates the data using the PeopleSoft Business Document layout, and generates a flat file.

   The file is passed to a middleware translation tool that generates an outbound file in the appropriate EDI format (X.12, EDIFACT, etc). Depending on the trading partner relationship, data mapping transformations may occur at this point to meet a trading partner's specific mapping requirements. The formatted file is then sent on to the source trading partner's VAN.

4. The source trading partner’s VAN distributes the flat file to the destination trading partner’s VAN.

5. The destination trading partner receives the flat file from the VAN.

   A middleware tool is used to convert the source file into the format required for the destination trading partner’s business application software.

6. The destination trading partner loads the flat file into their business application system.

Processing PeopleSoft 9.0 Outbound Flat File EDI Transaction Processes in the PeopleSoft Format

PeopleSoft can generate a PeopleSoft-formatted flat file. This flat file can be received by a third-party system or processed by a middleware product and then received by a third-party system.

The following diagrams illustrate the PeopleSoft 9.0 outbound flat file EDI transaction process:

Outbound flat file EDI transaction processing PeopleSoft 9.0 using the PeopleSoft format (1 of 2)

Outbound flat file EDI transaction process for PeopleSoft 9.0 using the PeopleSoft format (2 of 2)

To process PeopleSoft 9.0 outbound flat file EDI transactions in the PeopleSoft format:

1. The source trading partner initiates a PeopleSoft application process that retrieves the transactional data from the PeopleSoft application database tables and loads those EDI transactions into PeopleSoft staging tables, or prepares the data so it can be picked up by the Publish Outbound Message process.

2. The source trading partner performs the Publish Outbound Message process that retrieves the transactions from the staging tables or application tables and creates a flat file.

   The Outbound File Publish process reads the staging tables, translates the data using the PeopleSoft File Layout Definition and rules, and generates a flat file. The flat file is then sent to the VAN.

3. The file is passed to a middleware translation tool that generates an outbound file in the appropriate EDI format (X.12 EDI, EDIFACT, etc).

4. The source trading partner’s VAN distributes the flat file to the destination trading partner’s VAN.

5. The destination trading partner receives the flat file from the VAN.

   A middleware tool is used to convert the source file into the format required for the destination trading partner’s business application software.

6. The destination trading partner loads the flat file into its business application system.

Processing PeopleSoft 9.0 Outbound Flat File EDI Transaction Processes in X.12 EDI Format

PeopleSoft can generate a X.12 EDI formatted flat file.

The following diagrams illustrate the PeopleSoft 9.0 outbound flat fileX.12 EDI transaction process:

Outbound flat file EDI transaction processing PeopleSoft 9.0 using X.12 EDI format

To process PeopleSoft 9.0outbound flat file EDI transactions in X.12 EDI format:

1. The source trading partner initiates a PeopleSoft application process that retrieves the transactional data from the PeopleSoft application database tables and loads those EDI transactions into PeopleSoft staging tables, or prepares the data so it can be picked up by the Publish Outbound Message process.

2. The source-trading partner performs the Publish Outbound Message process that reads the staging tables or application tables, and publishes the data as XML to the Integration Broker, based on the options set in the batch publish rules (XML options).

3. The Integration Broker then transforms the data as specified on the active routings for the service operation and delivers the transformed data using the connector designated on the routing or node. For X.12 EDI data, this connector will often write a file to a directory or FTP server, but could be sent directly to a trading partner's gateway.

   Transformation examples are provided for the outbound 810 (Billing Invoice), 845 (Sales Quote Notice), 855 (Sales Order Acknowledgement), and the 856 (Advanced Shipping Notice).

   Note. These examples require customizations for individual trading partner requirements. Other outbound X.12 EDI transactions can be supported by creating transforms using the same concepts provided in the example transform programs.

4. The source trading partner's VAN distributes the flat file to the destination trading partner's VAN.

5. The destination trading partner receives the flat file from the VAN. A middleware tool is used to convert the source file into the format required for the destination trading partner’s business application software.

6. The destination trading partner loads the flat file into its business application system.

Obtaining File Layouts

To obtain the file layout definitions for EDI transactions, view and print the file layouts directly from the PeopleSoft Application Designer.

This section provides an overview for obtaining file layouts, and discusses how to print a file layout for an EDI transaction.

Understanding File Layouts

The File Layout Definition report contains information necessary to assist you with your flat file EDI transaction processing. The report includes all fields in the file layout, the sequence of the fields, the type of field (character and number), the length of the fields, and the starting position of the fields.

The following are two examples of a file layout definition report:

File Layout Definition report for the Advanced Shipping Notice EDI transaction generated in the PeopleSoft Application Designer (1 of 2).

File Layout Definition report for the Advanced Shipping Notice EDI transaction generated in the PeopleSoft Application Designer (2 of 2).

Printing the File Layout for an EDI Transaction

To print the file layout for an EDI transaction:

1. Open an instance of the Application Designer.

2. Select File, Open.

   The Open Definition dialog box appears.

3. In the Definition drop down menu, Select File Layout, enter the EDI transaction name in the Name field, and click Open.

   The file layout definition you specified opens.

4. With the file layout definition open, select File, Print Preview.

   The File Layout Definition Report appears for the file layout specified. Scroll through the report to view the complete file layout definition online.

5. In print preview mode, click the Print button.

   The File Layout Definition Report is routed and printed at the printer you select.