Understanding Voucher Build Source Transactions

Use the PeopleSoft Purchasing vendor rebate functionality to create and manage rebate claims with vendors. Then use PeopleSoft Payables to settle the claim vouchers for PeopleSoft Order Management and Receivables.

The PeopleSoft Purchasing Process Claims Application Engine process (PO_PRCSCLAIM) initiates the Claim Settlement Process for AP Application Engine process (PO_CLMSETTLE_AP), which in turn populates the voucher staging tables with claim voucher data for processing by the Voucher Build process.

Consignment inventory is a supply chain management strategy in which you store goods in a business unit without paying the supplier until after the goods are consumed. The Consignment Inventory feature, which enables you to implement this strategy across an entire enterprise, integrates a variety of functions within PeopleSoft Purchasing, Inventory, Production Management, Cost Management, and Payables.

In PeopleSoft Payables, the Voucher Build process creates voucher record sets for consigned items that have been consumed and costed. It does this by:

• Extracting data from the Depletion Accounting Entry table (CM_DEPLETE).

• Selecting rows for which the Voucher Build status is T (to be vouchered) or E (error).

• Processing these rows according to the processing option that is set for supplier location (using the Consign Voucher field on the Supplier Information - Procurement Options page at the supplier location level.

Processing options are:

When the Voucher Build process finishes processing a row in the Depletion Accounting Entry table by creating or staging a voucher, the process updates the status of that row to V (vouchered). If an error occurs during processing, the Voucher Build process changes the status to E.

Voucher details come from these sources:

• The price is extracted from the purchase order, or the receipt if no purchase order exists.

• Distribution information is extracted from the distribution lines on the receipt.

• Order detail is extracted from the IN_DEMAND table.

Other voucher data that is extracted from the purchase order or receipt includes:

• Unit of measure (UOM) and UOM conversion rate.

  Note: The Depletion Accounting Entry table stores data in the item's standard UOM; the Voucher Build process converts this to the receipt supplier's UOM.

• Invoice ID from the packing slip number that is referenced on the original receiver.

• Supplier and supplier location.

• PeopleSoft Payables business unit.

The CM_ACTUAL_COST table identifies the receipt with the depleted transaction. For the same receiver line or distribution, it is summed for one voucher or distribution line.

The Voucher Build process assigns voucher IDs for each voucher based on the next voucher ID that is available from the PeopleSoft Payables business unit. The process uses the packing slip number on the receiver as the invoice ID. To prevent duplicate invoice IDs, the process increments the ERS_INV_SEQ number field by one each time a packing slip is used as the invoice ID.

Voucher Build pre-edit errors for Consigned Inventory vouchers are logged on the Consigned Inventory Voucher Exceptions page.

PeopleSoft Payables generates refund checks for PeopleSoft Receivables. The Receivables Refund Application Engine process (AR_REFUND) populates the voucher staging tables with refund voucher data for processing by the Voucher Build process.

The Matching process calls the Voucher Build process to automatically create debit memo adjustment vouchers to resolve matching exceptions between the amount on a voucher and the purchase orders and receivers that are associated with that voucher. You can dispatch debit memo information to the supplier using print, phone, fax, email, or electronic data exchange (EDX). The creation of the debit memo voucher requires:

• An agreement with the supplier that allows the adjustment to the voucher.

  You define this agreement on the Supplier component (VNDR_ID).

• A match rule that allows debit memo vouchers.

  Match rules are defined on the Match Rule Type page, the Match Rules page, and the Match Rule Control page.

• The Matching process to be run.

  You can run the Matching process in batch or you can initiate the Matching process from the Match Workbench.

The Voucher Build process provides support for data that is connected through EDI.

This flowchart illustrates how the EDI Manager integrates with the Voucher Build process.

Typically, you use a private value-added network (VAN) to exchange EDI transactions. However, you can also use the internet, a dedicated link, or a sole-source provider.

The Voucher Build process creates ERS vouchers from procurement receipt records. The receipts must be priced and have extended merchandise amounts.

The Voucher Build process creates ERS vouchers from receipts that reference a purchase order, as well as receipts that do not (non-PO receipts). For non-PO receipts, the process creates ERS vouchers only for receipt lines that have unit prices (priced receipts). These unit prices can be populated online from the item master or supplied by an external receipt load interface module.

To create ERS vouchers, you must identify the supplier location as an ERS supplier and set up the PeopleSoft Payables business unit (on the Payables Definition - Voucher Build page) to allow ERS transactions. You establish ERS options on the Procurement Control - ERS Options page, but you can also override them on the Payables Definition - Voucher Build page.

The Voucher Build process creates separate ERS vouchers for each packing slip that is referenced on a single receipt and multiple ERS vouchers from a single receipt, as receipt lines are marked as received. You can either create the ERS voucher invoice date from the receipt date or let the freight terms on the ERS receipt determine whether to use the receipt of the shipment date as the invoice date.

If the same packing slip number is used as the invoice number on multiple ERS vouchers (because an ERS receipt was partially invoiced), the pre-edit subprocess adds an ERS sequence number (ERS_INV_SEQ) to the ERS voucher header. This prevents the Duplicate Invoice Checking feature from rejecting ERS vouchers that have the same packing slip number and have been built from the same receipt.

You can search using packing slip number information on two voucher entry pages:

• Regular voucher entry, on vouchers with an ERS source type.

• Summary Invoice Entry voucher.

The Billing Generate AP Vouchers SQR process (BIGNAP01) initiates the creation of PeopleSoft Payables vouchers for interunit bills. The process takes interunit billing information from the PeopleSoft Billing tables and populates the PeopleSoft Payables voucher staging tables with voucher data for processing by the Voucher Build process.

The Spreadsheet Voucher feature provides an offline entry component that you use to enter invoice data. The Voucher Build process handles the defaults and edit processing, similarly to quick invoice processing. PeopleSoft provides you with an Microsoft Excel file that you can use to create multiple voucher entry worksheets.

The Voucher Build process assigns match delay days to XML transactions that require matching based on the PeopleSoft Payables hierarchy, business unit, origin, control group, supplier, and the ability to override on the voucher. As an example, if the match delay days are five days, the system adds five days to the entry date to determine the match due date. If you do not define match delay days on the PeopleSoft Payables hierarchy, the Voucher Build process will not assign match delay days and use the entry date as the match due date. On the Match Request page, enter a date in the As of Date field to work in conjunction with the match due date. The Matching process selects only the vouchers that are ready to be matched as of that date. Match delay days are only applicable to EDI, XML, Document imaging, Spreadsheet vouchers, Online, Quick and Self Service invoices. These types of transactions usually are processed in the system before the purchase order lines are received. Using match delay days enables you to wait to include these transactions in the Matching process.

The Summary Invoice Entry component enables you to enter minimal invoice and purchase order information, such as supplier, PO number, invoice number, invoice date, nonmerchandise amounts, and gross amount, to create a voucher. The Voucher Build process builds the voucher, including the voucher lines and distribution lines, from the selected purchase order and associated receipts.

The Quick Invoice Entry component provides efficient data entry for large volumes of similar invoices or invoices for which you can rely on defaults to complete most of the voucher details. The Quick Invoice Entry component contains minimal online edits; default and edit processing is handled by the Voucher Build process.

The Voucher Build process assigns match delay days to Quick Invoice transactions that require matching based on the PeopleSoft Payables hierarchy, business unit, origin, control group, supplier, and the ability to override on the voucher.

PeopleSoft Pay/Bill Management generates payable time information for contractors that the Voucher Build process can build into vouchers. The Front Office to AP Application Engine process (FO_TO_AP) submits contractors' payable time to the voucher staging tables for voucher build processing.

As a part of the procurement card reconciliation process, PeopleSoft Purchasing stages PCard prepayment voucher and regular voucher data in the voucher staging tables. The Voucher Build process then creates payments and accounting entries for the PCard transactions. You can create both the expense and payment accounting entries from the PCard transactions in PeopleSoft Payables, and you can process PCard transactions against purchase orders.

For purchase order-related transactions, the merchandising supplier is retained on the voucher line to support the matching process, if applicable.

PCard vouchers are excluded from these Voucher Build process pages:

• Voucher Build (VCHR_BATCH_RQST).

• Voucher Build Application Engine Process (AP_VCHRBLD).

PeopleSoft Lease Administration generates lease payment information that the Voucher Build process can build into vouchers. The Voucher Build - Staged Voucher Selection process (AP_VB_STGVCH) transmits the lease payment data to voucher staging tables. The process applies PeopleSoft Payables defaulting logic, and then calculates the appropriate VAT and sales and use taxes. Though the process can create positive or negative vouchers, it does not create prepayment vouchers.

If the real estate transaction is withholding applicable but the supplier is not configured for withholding, the process generates an exception. You must correct the errors, by defining withholding values for the supplier and the voucher, to continue processing the voucher.

The Voucher Build process also updates the detailed lease payment transactions with the associated voucher ID after this ID has been assigned by the Voucher Build process. PeopleSoft Lease Administration appends a three-digit sequence number to the lease payment number. This number is handled by the system as a voucher ID number, not as an invoice number. Because of this functionality, you must ensure that the Assign Invoice ID option is selected for these vouchers so that the system assigns the voucher ID number as the invoice ID number.

The Voucher Build process creates vouchers from recurring voucher contracts that were established using the contracts functionality in PeopleSoft Purchasing.

The Voucher Build process controls the release of the vouchers based on the contract release date option that is specified for the PeopleSoft Payables business unit on the Payables Definition - Voucher Build page.

The Voucher Build process selects contract data that is staged to the contract staging tables. In addition to the general Voucher Build edits, the process also ensures that the total gross amount does not exceed the maximum limit for the contract. If the voucher exceeds the limit, the Voucher Build process logs an error in the contract tables and does not process the voucher. When Voucher Build processes the staged contracts, it increases the cumulative total for the contract by the total gross amount for the new vouchers and registers the contract lines by sending data to the CNTRCT_EVT_VCHR table.

The Voucher Build process builds the associated nonmerchandise charge records for miscellaneous, freight, and tax charges that are associated with the recurring contract voucher.

If the contract has some retention amounts, the Voucher Build process creates a voucher with two scheduled payment records, one for the amount to be paid now and one for the retention amount that is created and placed on hold.

The Voucher Build process creates adjustment vouchers for RTV transactions that are created in Purchasing. If an RTV adjustment does not reference a receipt, it is treated as a nonmatch RTV. Through the PeopleSoft Payables default hierarchy, you can either create automatic adjustments for RTV transactions that require credit memos or pass those transactions to the Quick Invoice Entry tables for review before further processing. You can maintain pending adjustment transactions by adding a reference to supplier credit memo documents or by making other adjustments before having the Voucher Build process turn them into adjustment vouchers. The RTV transactions have a Vendor RTV action code that indicates whether the credit memo should be generated and the nature of the RTV transaction. This table lists the RTV action codes:

Before processing RTV transactions, you must enable RTV credit memo processing for PeopleSoft Payables business units on the Payables Definition - Voucher Build page and specify the voucher adjustment option.

The Voucher Build process accesses the RTV tables to obtain the information that is required to create adjustment vouchers and creates miscellaneous charges for any RTV fees. Sales tax and VAT applicability codes are taken from the original voucher, if they are available. The Voucher Build process accesses the RTV records that require vouchers to be created and assigns the voucher ID number.

When the Voucher Build process creates an RTV credit voucher that must be rematched, the following fields or sets of fields in the Voucher component are unavailable for modification:

• Advanced Supplier Search.

• Invoice Number.

• Invoice Date.

• Pay Terms.

• Supplier.

• Voucher line amount.

If the RTV credit voucher does not have to be rematched, the Invoice ID and Invoice Date fields are available for edit.

The following Voucher component fields or sets of fields are always available for modification, regardless of whether the RTV credit voucher needs to be rematched:

• Voucher header amounts, including freight, miscellaneous, sales and use tax, and VAT, when applicable.

• Invoice Number.

• Invoice Date.

• Distribution line amounts.

PeopleSoft eSettlements loads self-service invoices to the quick invoice entry tables for processing by the Voucher Build process.

The Voucher Build process assigns match delay days to self-service invoices that require matching based on the PeopleSoft Payables hierarchy, business unit, origin, control group, supplier, and the ability to override on the voucher.

PeopleSoft Payroll, Student Administration, and other external systems can process supplier payments, such as payroll deductions, through PeopleSoft Payables using the inbound Voucher EIP. The Voucher EIP uses Application Messaging and the VOUCHER_BUILD message definition to populate the voucher staging tables with the necessary information for building voucher record sets.

This flowchart illustrates the VOUCHER_BUILD message subscription process.

To view the VOUCHER_BUILD application message definition in detail, see the Enterprise Integration Point Catalog.

PeopleSoft Payroll and Student Administration, as well as third-party applications, publish voucher data to the application message, and PeopleSoft Payables subscribes to it. The subscription process transfers the contents of the message to the inbound voucher staging tables. The Voucher Build process then builds voucher records from the staged data and writes them to the PeopleSoft Payables voucher tables.

If external parties send bad data (for example, an invalid business unit) as part of the message, the subscription process flags the message as being in error. You must intervene manually using the application messaging error correction feature to correct the data before the message can be processed successfully. When you save the message after correcting the data, the message status is automatically set to Reprocess.

The Voucher Build process assigns voucher IDs if they aren't passed by the application message. When the Voucher Build process finishes processing a staged record, the record is deleted from the staging table.

Two ways are available to integrate XML invoices with the Voucher Build process:

• Using XML invoices that are mapped to the VOUCHER_BUILD message definition for integrating with the Voucher Staging tables using Application Messaging.

  This process is also known as the Voucher EIP.

  Note: The Spreadsheet Voucher feature uses the Voucher EIP process (VOUCHER_BUILD) to import files to the PeopleSoft systems.

• Using XML invoices that are defined in the Open Applications Group (OAG) standardized format, which are handled in Integration Broker, mapped to the PeopleSoft invoice structures by the Transform OAG to PSFT Invoice Application Engine process (EM_INV_OAG), and connected to the quick invoice tables using the EM_VOUCHER_IN application message definition.

  Important! When you are building XML invoices using Integration Broker, the date format must be YYYY/MM/DD, or the subscription process fails.

The OAG XML invoice interface with the Voucher Build process is discussed in full in separate documentation.

PeopleSoft Payables users should also know that:

• PeopleSoft Payables users may need to define codesets in Integration Broker that differ from those that are used by eSettlements.

• OAG XML invoices must use the GL_Element tag to identify the Account ChartField if the invoice includes distribution information.

• The Voucher Build process assigns match delay days to XML transactions that require matching based on the PeopleSoft Payables hierarchy, business unit, origin, control group, supplier, and the ability to override on the voucher.

  If you do not define match delay days on the PeopleSoft Payables hierarchy, the Voucher Build process will not assign match delay days. As an example, if the match delay days are five days, the system adds five days to the entry date to determine the match due date. On the Match Request page, enter a date in the As of Date field to work in conjunction with the match due date. The Matching process selects only the vouchers that are ready to be matched as of that date. Match delay days are only applicable to EDI, XML, Document imaging, Spreadsheet vouchers, Online, Quick and Self Service invoices. These types of transactions usually are processed in the system before the lines are received. Using match delay days enables you to wait to include these transactions in the Matching process.