This chapter provides an overview of PeopleSoft eSettlements and discusses:
Setup and processing in the Buyer Direct model.
Setup and processing in the Business Service Provider model.
Role-based implementation.
Integrate with the Oracle Supplier Network.
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. |
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:
Setting up the Buyer Direct model.
Processing in the Buyer Direct model.
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:
Specify the Buyer Direct model.
Create and name your own roles and permission lists.
Create at least one user in a PeopleSoft Payables administrator role type.
Create a buyer template.
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.
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."
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.
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:
Enter vouchers into the system.
Enter self-service and XML invoices in PeopleSoft eSettlements, and enter vouchers in PeopleSoft Payables.
Review invoices in self-service pages.
Run the PeopleSoft Payables Voucher Build Application Engine process (AP_VCHRBLD) to create vouchers.
Run the Matching Application Engine process (AP_MATCH).
Approve invoices and invoice lines, if required.
Run pay cycle to select payments.
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
When implemented as the Business Service Provider model, multiple buyers are involved, and all of the same features and functionality apply.
This section discusses:
Setting up the Business Service Provider model.
Processing in the Business Service Provider model.
For a Business Service Provider implementation:
Create a buyer bank account and a buyer template.
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.
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.
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.
Create buyer pay cycles and assign associated security.
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."
Specify security by defining which suppliers the supplier administrator can access, and establish processing preferences for the supplier administrator role.
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.
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:
Create purchase orders, invoices, and receipts.
Review invoices in self-service pages.
Run the PeopleSoft Payables Voucher Build process to create vouchers.
Run the Matching process.
Approve invoices and invoice lines, if required.
Run pay cycle to select payments.
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.
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.
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.
This section provides an overview of the integration with the Oracle Supplier Network and discusses how to receive Invoices from 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:
Purchase orders and change orders from PeopleSoft to the OSN supplier (outbound transactions). The purchase order is passed to suppliers through OSN. Suppliers can decide their delivery method, and monitor transactions on OSN.
Purchase order acknowledgement (POA) or a POA with changes from the OSN supplier to PeopleSoft (inbound transactions). The supplier's POA is sent through OSN to PeopleSoft.
Advanced Shipping Notification (ASN) from the OSN supplier to PeopleSoft (inbound transaction). The supplier's ASN is sent through OSN and loaded into PeopleSoft as an advanced shipment receipt (ASR) where you can create a receipt in PeopleSoft.
Invoices from the OSN supplier to PeopleSoft (inbound transaction). The supplier's invoice is sent through OSN and loaded into PeopleSoft where you can create a voucher in PeopleSoft eSettlements.
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.
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
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. |
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:
The Oracle Supplier Network transmits the invoice from the OSN supplier.
The PeopleSoft connector, fscm_epo_OSNListeningConnector, catches the inbound message which is routed to the EM_VOUCHER_IN service operation.
The routing on the service operation contains the transformation program SAC_OAG72INV that converts the invoices in OAG XML to vouchers in PSXML.
The handler EmVoucherIn, that is defined on the service operation, is executed to update the voucher staging tables in PeopleSoft.
The Voucher Build process is then executed to create a voucher.
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:
Service operation: EM_VOUCHER_IN
Message: EM_VOUCHER_IN version
Application Engine transformation program: SAC_OAG72INV
Routing: ORACLE_SN_VOUCHER_IN
Node: PSFT_ORACLE_SUPPLIER_NETWORK
Queue: EM_VOUCHER_IN
Handler: EmVoucherIn
Connector: fscm_epo_OSNListeningConnector
PeopleSoft Service Operation |
OSN Transaction Name |
cXML Equivalent |
EM_VOUCHER_IN |
OAG Process Invoice 002 |
PeopleSoft eSettlements will receive XML invoices (cXML) Invoice Detail |