Understanding PeopleSoft eSettlements

This chapter provides an overview of PeopleSoft eSettlements and discusses:

Click to jump to parent topicPeopleSoft eSettlements Overview

You implement your PeopleSoft eSettlements application based on either the Buyer Direct model or the Business Service Provider model.

Buyer Direct Model

In this implementation, a single buying organization (buyer) controls the application. This model is based on a one-to-many relationship: one buyer provides an interface for many suppliers. A buyer deploys this model by requesting—or requiring—that its suppliers post invoices to the system. The PeopleSoft eSettlements application functions as an invoice settlement solution in which electronic invoices—including supplier self-service invoices—combine with online dispute and resolution, workflow, email notifications, and electronic payments to enable real-time collaboration with suppliers. Suppliers can directly access invoice status and payment information using the internet—minimizing disruptive inquiries and lowering support costs—and the buyer can effectively manage all aspects of invoices, disputes, and payments. Advantages of this model include visibility of business processes, decentralization of approvals, extended payables visibility to selected suppliers for self-service electronic invoices, and collaboration in reconciliation and issue resolution. The entire payables process is streamlined, reducing administrative costs, minimizing disputes, and enabling faster settlement.

Business Service Provider Model

In this implementation, a consolidator controls the application. This model is based on a many-to-many relationship: a consolidator hosts the system and provides an interface between multiple suppliers and buyers. The consolidator acts as a trusted intermediary, collecting or aggregating invoices from multiple suppliers for multiple buyers. This structure eliminates the need for a point-to-point connection. The consolidator setup varies from market to market, depending on the needs of the buyers and suppliers in each industry the consolidator serves.

Click to jump to parent topicSetup and Processing in the Buyer Direct Model

In this implementation, the buyer controls the PeopleSoft eSettlements application, which functions as a front end for the buyer's PeopleSoft Payables application.

This section discusses:

Note. To implement either the Buyer Direct or the Business Service Provider model, you must first establish your control data by defining information in the PeopleSoft system's global, core, and additional application tables. The information that you define in these tables lays the foundation for your PeopleSoft eSettlements-specific setup.

For a Buyer Direct implementation:

  1. Specify the Buyer Direct model.

  2. Create and name your own roles and permission lists.

  3. Create at least one user in a PeopleSoft Payables administrator role type.

  4. Create a buyer template.

  5. Enable PeopleSoft Payables business units as PeopleSoft eSettlements buyers.

    If you enable PeopleSoft Payables business units for use as PeopleSoft eSettlements buyers, ensure that the business unit is set up for automatic voucher numbering. Auto-numbering is used for self-service and XML invoices.

  6. Enable PeopleSoft Payables vendors as PeopleSoft eSettlements suppliers.

    If financial sanctions validation is enabled, and you are enabling a PeopleSoft Payables vendor with a financial sanctions status of Blocked or Review, the system displays a warning message that the vendor selected is currently under financial sanctions review. You can decide to proceed with creating the supplier. However, the system does not allow payments to a supplier with a financial sanctions status of Blocked or Review.

    Note. How the system validates your suppliers is dependant upon how you set up financial sanctions validation options. Financial sanctions validation is discussed in detail in another chapter in this PeopleBook and in PeopleSoft Source-To-Settle Common Information PeopleBook, "Maintaining Vendor Information."

    See Registering Suppliers.

    See Understanding Financial Sanctions Validation.

  7. Create a local supplier administrator, who then completes supplier registration by adding information specific to the selling entity. The supplier administrator can then create new user profiles for additional individuals within the organization.

    Note. Creation of a supplier treasurer is required if the supplier subscribes to payment notifications.

  8. Create an agreement.

    This is a multistep process. The buyer administrator (or system administrator) initiates an agreement and offers it to the supplier. The supplier administrator reviews the terms and adds its organization's terms for the buyer before approving and returning the agreement to the buyer for completion.

Note. In the preceding steps, it is assumed that you have already implemented PeopleSoft Payables.

Once you've set up the Buyer Direct model, processing follows these steps:

  1. Enter vouchers into the system.

  2. Enter self-service and XML invoices in PeopleSoft eSettlements, and enter vouchers in PeopleSoft Payables.

  3. Review invoices in self-service pages.

  4. Run the PeopleSoft Payables Voucher Build Application Engine process (AP_VCHRBLD) to create vouchers.

  5. Run the Matching Application Engine process (AP_MATCH).

  6. Approve invoices and invoice lines, if required.

  7. Run pay cycle to select payments.

  8. Approve and create payments.

    Note. If payment approval is required, first create and assign pay cycle security.

Note. If financial sanctions validation is enabled, and you are using PeopleSoft Payables functionality, the system performs validations similar to those performed during the PeopleSoft Payables process.

See Understanding Financial Sanctions Validation.

See Also

Setting Auto-Numbering for Manual Payments

Click to jump to parent topicSetup and Processing in the Business Service Provider Model

When implemented as the Business Service Provider model, multiple buyers are involved, and all of the same features and functionality apply.

This section discusses:

For a Business Service Provider implementation:

  1. Create a buyer bank account and a buyer template.

  2. Create buyers (buying organizations) and assign their security and processing parameters.

    Buyer registration populates several underlying PeopleSoft tables, creating a PeopleSoft Payables, Purchasing, and General Ledger business unit for each buying entity, along with all necessary procurement processing options.

  3. Create local buyer administrators.

    The first user profile that you create for each new buying entity is its local buyer administrator. You also assign business unit security and data access to the buyer administrator, defining the buying entities to which the buyer administrator has access. Then, you define the processing options for the buyer administrator, including preferences such as the ability to record payments or override match exceptions.

  4. Create local buyer users (this is done by each buying organization's buyer administrator).

    The buyer administrator then completes the implementation process, updating and finalizing the registration for the buying entity by specifying matching preferences and creating additional users within the organization.

  5. Create buyer pay cycles and assign associated security.

  6. Create a selling entity (supplier) by defining subscription and system access, and then create a local supplier administrator for this new supplier.

    If financial sanctions validation is enabled at the installation level, and you create a new supplier, the system validates the supplier against the financial sanctions lists either when you attempt to save the supplier or on an ad hoc basis, depending on how you set up financial sanctions validation. If there is a possible match, the system updates the supplier's financial sanctions status on the Vendor Information component (VNDR_ID) to Review and displays a warning message that the supplier is currently under financial sanctions review. You can decide to proceed with creating the supplier. However, the system does not allow payments to a supplier with a financial sanctions status of Blocked or Review.

    Note. How the system validates your suppliers is dependant upon how you set up financial sanctions validation options. Financial sanctions validation is discussed in detail in another chapter in this PeopleBook and in PeopleSoft Source-To-Settle Common Information PeopleBook, "Maintaining Vendor Information."

    See Registering Suppliers.

    See Understanding Financial Sanctions Validation.

  7. Specify security by defining which suppliers the supplier administrator can access, and establish processing preferences for the supplier administrator role.

  8. Register suppliers.

    The supplier administrator completes supplier registration by adding information specific to the selling entity. The supplier administrator can create new user profiles for additional individuals within their organization. Creation of a supplier treasurer is required if the supplier subscribes to payment notifications.

  9. Create agreements.

    The buyer administrator initiates an agreement and offers it to the supplier. The supplier administrator reviews the terms and adds its organization's terms for the buyer before approving it and returning it to the buyer for completion.

Once you've set up a Business Service Provider model, processing follows these steps:

  1. Create purchase orders, invoices, and receipts.

  2. Review invoices in self-service pages.

  3. Run the PeopleSoft Payables Voucher Build process to create vouchers.

  4. Run the Matching process.

  5. Approve invoices and invoice lines, if required.

  6. Run pay cycle to select payments.

  7. Approve and create payments.

Note. If financial sanctions validation is enabled, and you are using PeopleSoft Payables functionality, the system performs validations similar to those performed during the PeopleSoft Payables process.

See Understanding Financial Sanctions Validation.

Click to jump to parent topicRole-Based Implementation

Because PeopleSoft eSettlements is complex and configurable, several roles and steps are involved in the implementation of a new system.

This section provides an overview of role types and role names.

Click to jump to top of pageClick to jump to parent topicRole Types and Role Names

Whether you implement the Buyer Direct model or the Business Service Provider model, you must employ certain roles in the setup. You can attach PeopleSoft eSettlements role names to a role type to control access and enable processing. Depending on your organization's needs, new users may be assigned to various buyer or supplier roles. The system provides predefined role types, and you can set up your own roles using the delivered data as a reference. After you define your roles, the system administrator must then map the roles to the delivered PeopleSoft eSettlements role types. This step ensures that the system can identify how the new roles are used within PeopleSoft eSettlements.

Note. When you create a system administrator, ensure that you complete all of the user preferences, including the default setID.

Establishment of various roles is required, depending on the email notification options and the invoice approval levels that you specify during buyer registration. Roles are also required to enable prepayments, urgent payments, payment cancellations, and line-level routing to operational users.

In the Business Service Provider model, if a buyer subscribes to payment processing by PeopleSoft eSettlements, you must create a pay cycle for the new buyer. If the buyer subscribed to the self-service or to the automated pay cycle and also requires pay cycle approval, you also establish pay cycle security for the user that is responsible for approving payments.

Here are the delivered buyer role types and associated role name mappings that you can use as a reference when setting up roles:

Note. To use roles in PeopleSoft eSettlements, you must map the roles that you set up to the appropriate delivered, predefined PeopleSoft eSettlements role types.

Buyer Role Type

Buyer Role Name

Buyer Administrator

EM_BUYER_ADM

Buyer Accountant

EM_BUYER_ACCT

Buyer User

EM_BUYER_TREAS

EM_APPROVER_1

EM_APPROVER_2

EM_APPROVER_3

EM_BUYER_MTCH_MGR

EM_BUYER_RECV

EM_BUYER_SUPV

Here are the available supplier role types and associated role names:

Supplier Role Type

Supplier Role Name

Supplier Administrator

EM_SELLER_ADM

Supplier User

EM_SELLER_AR

EM_SELLER_CM

EM_SELLER_CSP

EM_SELLER_TREAS

In the Business Service Provider model there are also two host administrator role types assigned by the consolidator: host functional administrator (EM_HOST_ADM_FUNC), and host technical administrator (EM_HOST_ADM_TECH).

In the Buyer Direct model, you set up a payables administrator role and map it to the system administrator role type.

Note. The host administrator must set up at least one buying entity for each buyer (business unit), and one selling entity for each supplier.

Once the initial setup is complete, the local buyer administrator and local supplier administrator can create additional users to suit their particular organization's needs.

Click to jump to parent topicIntegrating with the Oracle Supplier Network

This section provides an overview of the integration with the Oracle Supplier Network and discusses how to receive Invoices from the Oracle Supplier Network

Click to jump to top of pageClick to jump to parent topicUnderstanding the Integration Between PeopleSoft eSettlements and the Oracle Supplier Network

The Oracle Supplier Network (OSN) is an hosted service offering in which buyers and sellers use a common hub for exchanging and monitoring transactions. The integration between OSN and PeopleSoft enables you to pass the following transactions:

The following diagram illustrates the communication protocols between PeopleSoft, the Oracle Supplier Network, and the OSN suppliers. PeopleSoft should use OAG (Open Applications Group) XML for the outbound transaction since OSN supports incoming OAG messages over HTTP. The OSN suppliers can send and receive messages using cXML or OAG.

Overview of PeopleSoft to Oracle Supplier Network Integration

For outbound transactions from the PeopleSoft eProcurement or Purchasing applications, the PeopleSoft Integration Broker (Integration Gateway) uses application engine transformation programs and the fscm_epo_OSNListeningConnector IB connector to convert XML messages that use the PeopleSoft format (PSXML) into OAG XML files. For inbound transactions from the Oracle Supplier Network to PeopleSoft eSettlements, OAG XML messages are sent to the PeopleSoft Integration Gateway where transformation programs and the fscm_epo_OSNListeningConnector IB connector convert the incoming files into the PSXML format.

Click to jump to top of pageClick to jump to parent topicPrerequisites

To set up the connection between eProcurement, eSettlements and the Oracle Supplier Network (OSN), you must register with OSN and invite your suppliers to register with OSN.

See Oracle Supplier Network User Guide

Click to jump to top of pageClick to jump to parent topicPages Used to Receive Invoices From the Oracle Supplier Network

Page Name

Definition Name

Navigation

Usage

Voucher Build

VCHR_BATCH_RQST

Accounts Payable, Batch Processes, Vouchers, Voucher Build

Run this process to create voucher record sets from many sources including XML invoices. See Processing Batch Vouchers.

Voucher Inquiry

AP_VOUCHER_INQUIRY

Accounts Payable, Review Accounts Payable Info, Vouchers, Voucher, Voucher Inquiry

Search for and review vouchers and any payment information. See Reviewing Voucher Information.

Click to jump to top of pageClick to jump to parent topicReceiving Invoices from the Oracle Supplier Network

Invoices can be transmitted from OSN suppliers to PeopleSoft where they are received as vouchers in PeopleSoft Payables through eSettlements: The following steps are used:

  1. The Oracle Supplier Network transmits the invoice from the OSN supplier.

  2. The PeopleSoft connector, fscm_epo_OSNListeningConnector, catches the inbound message which is routed to the EM_VOUCHER_IN service operation.

  3. The routing on the service operation contains the transformation program SAC_OAG72INV that converts the invoices in OAG XML to vouchers in PSXML.

  4. The handler EmVoucherIn, that is defined on the service operation, is executed to update the voucher staging tables in PeopleSoft.

  5. The Voucher Build process is then executed to create a voucher.

  6. The Voucher Inquiry page can be used to review vouchers.

Note. In order to receive invoices from OSN suppliers, PeopleSoft Payables and PeopleSoft eSettlements must be installed. A link to the PeopleSoft eSettlements application and to the PeopleSoft eSupplier Connection application is provided within the Oracle Supplier Network on the Trading Partners section.

The PeopleSoft system is delivered with the following setup for receiving invoices from OSN, this data may need to be altered for your environment:

PeopleSoft Service Operation

OSN Transaction Name

cXML Equivalent

EM_VOUCHER_IN

OAG Process Invoice 002

PeopleSoft eSettlements will receive XML invoices (cXML) Invoice Detail