Using EDI and Split Stream Processing

PeopleSoft Receivables enables you to receive a payment (cash and remittance advice combined) or just the remittance (remittance information without cash) in an EDI transmission.

When you receive the remittance advice and the cash information at different times and through different channels, you can use a variety of methods to match them. This helps you identify and apply the payments.

PeopleSoft Receivables supports both European and U.S. EDI formats. The European EDI standard is EDIFACT, and the supported format is CREEXT. The U.S. standard is ANSI-X12; its supported format is 820. In both formats:

• One transmission can contain a payment (cash and remittance information combined) or just cash.

• One transmission can contain only a remittance (the corresponding cash information to be transmitted separately).

  This scenario introduces the need for split stream processing.

This documentation discusses how to:

1. Load business documents into staging tables.

2. Confirm that data loaded successfully.

3. Run the Payment Loader process.

4. Delete unmatched customer or item remittances.

Split stream processing matches and unites the two parts of a payment, the cash information and the remittance advice, when they are received at different times and possibly from different data sources. EDI, lockbox, and bank statement processing support the transmission of cash by itself. Only EDI processing and the Excel Payment Upload process support the transmission of a remittance advice by itself or cash and remittance.

Split Stream Examples

Typically both the cash information and the remittance advice are received through EDI, as shown in the following example in which the customer sends the EDI remittance directly to the supplier or the customer sends the cash to their bank, their bank sends cash to the supplier's bank, and the supplier's bank sends EDI cash to the supplier.

The customer sends the EDI remittance directly to the supplier or the customer sends the cash to their bank, their bank sends cash to the supplier's bank, and the supplier's bank sends EDI cash to the supplier

In this example, the customer sends you two EDI transmissions. The remittance advice is sent directly to you. The cash information is sent to the customer's bank, then to your bank, and then to you. As a result, you receive two separate EDI transmissions, one with cash and one with remittance information. You use split stream processing to match them and form the complete payment (linked cash and remittance information).

The common denominator for all methods of receiving split stream data is that the remittance information is received by EDI; only the source of the cash information varies. The method that customers use to send the cash to their bank or to your bank is irrelevant to split stream processing. Your only concern is how your bank transmits the cash information to you: as an EDI transmission, in a lockbox file or, as in the following example, as a receipt on a bank statement:

The bank transmits the cash information as an EDI transmission, in a lockbox file or, as in the example in the diagram, as a receipt on a bank statement

The following example shows transmission of cash information by way of a lockbox, where the customer sends an EDI remittance directly to the supplier or the customer mails a check to the supplier's bank, which sends a lockbox file, which includes the check, to the supplier.

Transmission of cash information by way of a lockbox, where the customer sends an EDI remittance directly to the supplier or the customer mails a check to the supplier's bank, which sends a lockbox file, which includes the check, to the supplier

U.S. and European business practices differ. In the United States, you usually receive payment in a lockbox file, but you are unlikely to receive payments from bank statements. In Europe, you probably do not use a lockbox, but you probably receive payments from bank statements.

To receive payments and remittance information in an EDI file:

1. Using a third-party translator, translate the file into a PeopleSoft business document format.

   See Receiving Payments in an EDI File.

2. Publish the data in the business document in the Application Messaging queue.

   The subscriber program loads the data into data tables.

3. Confirm that the data loaded.

4. Run the Payment Loader process to move the data from the staging tables into the payment application tables.

5. View PeopleSoft Application Engine messages.

6. Check for errors at the deposit level on the All Deposits page or Incomplete Deposits page.

7. Correct errors in the deposit and payment entry pages and the Payment Interface Duplicates component (ERROR_CORRECTION).

8. If you use cash control accounting and you have a duplicate out-of-balance deposit, run the Cash Control process to create the cash control accounting entries.

   See Creating Cash Control Accounting Entries.

If you receive a business unit for a deposit in the EDI file, the system assigns that business unit to the deposit. Otherwise, it uses the business unit that you assigned to the bank account on the External Accounts - Account Information page. If both business units are missing, the system uses the business unit that is assigned to the operator that runs the Payment Loader process.

Use the PeopleSoft Integration Broker to set up the EDI interface.

For more information, see the product documentation for PeopleTools: Integration Broker and PeopleTools: Integration Broker Testing Utilities and Tools.

Use the File Inbound page (EO_FILE_INBOUND) to load business documents into staging tables.

Navigation:

Enterprise Components > Integration Definitions > Inbound File Rule > File Inbound

This example illustrates the fields and controls on the File Inbound page. You can find definitions for the fields and controls later on this page.

To set up and use the EDI process:

1. Set up the file identifier to point to a file.

   Field or Control	Description
   File Identifier	Displays an identifier pointing to the file.
   Inbound File	Enter the path and file name that you want for the inbound flat file when you import into the PeopleSoft Receivables system.
   Index Flag	Select only if the inbound file is an index file.
   File Layout ID	Enter an ID that identifies the file layout.
   LUW Size, Program Name, and Section	Leave blank.
   Create Message Header and Create Message Trailer	Deselect these check boxes.
   Definition Name	Change the value to PAYMENT_LOAD.
   Message Name	Change the value to PAYMENT_LOAD.

2. Enter run parameters on the Inbound File page (EO_FILETOMSG). Navigate to Enterprise Components > Integration Definitions > Initiate Processes > Inbound File Publish > Inbound File.

   Field or Control	Description
   File Identifier	Enter the file identifier that you defined on the File Inbound page.
   Index Flag	Select only if the inbound file is an index file.

3. Click Run to run the EOP_PUBLISHF process, which loads data from the file and publishes the data as application messages.

   Select the following process name on the Process Scheduler Request page: EOP_PUBLISHF.

4. Use the Process Monitor to verify that the process finished successfully.

5. Verify that the subscriber processed the message and loaded the data into EC tables (Enterprise Components) on the Business Document Detail page (EC_BUSDOC_02).

   The value for the EC Completion Status field should be Done.

Use the Summary page (EC_BUSDOC_01) to confirm that the banking data loaded successfully.

Navigation:

PeopleTools > EDI Manager > View EDI Audit Trail > Business Document Summary > Summary

For more information, see the product documentation for PeopleTools: Supported Integration Technologies.

Use the Payment Interface page (PAYLOAD_REQUEST) to define the run parameters for the Payment Loader process and run the process.

Navigation:

Accounts Receivable > Payments > Electronic Payments > Process Payment Interface > Payment Interface

This example illustrates the fields and controls on the Payment Interface page. You can find definitions for the fields and controls later on this page.

Use the Delete Remittance - Customer page (MATCH_ERROR_CU) to delete unmatched customer remittances in the staging tables.

Use the Delete Remittance - Item page (MATCH_ERROR) to delete unmatched item remittances in the staging tables.

Navigation:

Accounts Receivable > Payments > Electronic Payments > Delete Remittance > Customer

Accounts Receivable > Payments > Electronic Payments > Delete Remittance > Item

If the cash information precedes the remittance information and you have already run the Payment Loader process for the cash information, the cash information is already loaded into the payment application table. Thus, the applicable remittance information does not match the cash information. Instead, the applicable remittance information remains in the staging tables as unmatched unless you run the option that matches the payment that you already loaded into the payment application table. You can manually correct this by deleting the unmatched remittance information on the Regular Deposits - Totals page. Then enter the remittance information with its associated payment in the reference information fields on the Regular Deposits - Payments page.