Setting up and Processing Entry Event for Various Applications and Transactions
This topic discusses how to:
Use a single entry event code in multiple documents or products.
Use entry events for requisitions and PO reversals and closures.
Process vouchers, payments, and cash-clearing transactions with entry events.
Use entry event codes for upward and downward adjustments in both unexpired and expired funding.
Process Receivables transactions and direct journals with entry events.
To use an entry event code in multiple documents or for multiple products, you must identify each process and its steps in the entry event code definition. Using the PeopleSoft procure-to-pay process as an example, you can enter an entry event code one time in the requisition document. It then flows through the entire process creating entry event transactions for each document. Before an entry event code can successfully move between documents and products, you first must set it up to run for each of the processes in the procure-to-pay cycle.
The PeopleSoft procure-to-pay cycle consists of several documents and processes. Entry event processing uses the following processes:
REQPOST
POPOST
VCHRPOST
PAYMENT
You must set up an entry event code and associate it with all four processes.
See Entry Event Code Definition Page.
Example of Defining One Entry Event Code to Use with Multiple PeopleSoft Applications
Here is an example of how to define an entry event code for multiple PeopleSoft applications:
Set up the PROCURE entry event code.
Term
Definition
Entry Event
PROCURE
Description
Requisition to Cash Clearing
In the Entry Event Process group box, add the REQPOST process.
Term
Definition
Entry Event Process
REQPOST
Effective Date
01/01/1900
Status
A
In the Entry Event Step group box, add the REQPOST step.
Term
Definition
Entry Event Step
REQPOST
Account
696800 (example)
Source Record Jrnl Template
Not applicable (NA)
Journal Template
EE_PURCH
In the Offset Accounts group box, add the preencumbrance and general expenses offset accounts.
Term
Definition
DR/CR
DR
Account and Short Desc
696700 (example) - Preenc Res
DR/CR
CR
Account and Short Desc
696500 (example) - GenExpOffs
In the Entry Event Process group box, add the POPOST process.
Term
Definition
Entry Event Process
POPOST
Effective Date
01/01/1900
Status
A
In the Entry Event Step group box, add the POPOST step.
Term
Definition
Entry Event Step
POPOST
Account
696800 (example)
Source Record Jrnl Template
Select if a source record journal template exists.
Journal Template
EE_PURCH
In the Offset Accounts group box, add the encumbrance and general expenses offset accounts.
Term
Definition
DR/CR, Account, and Short Desc
DR, 696600 (example), Enc Res
DR/CR, Account, and Short Desc
CR, 696500 (example), GenExpOffs
In the Entry Event Process group box, add the VCHRPOST process.
Term
Definition
Entry Event Process
VCHRPOST
Effective Date
01/01/1900
Status
A
In the Entry Event Step group box, add the ACCRUAL step.
Term
Definition
Entry Event Step
ACCRUAL
Account
696800 (example)
Source Record Jrnl Template
Select this option.
Journal Template
NA
In the Offset Accounts group box, add the general expenses and accounts payable offset accounts.
Term
Definition
DR/CR, Account, and Short Desc
DR, 696500 (example), GenExpOffs
DR/CR, Account, and Short Desc
CR, 200000 (example), Accts Paybl
In the Entry Event Process group box, add the PAYMENT process.
Term
Definition
Entry Event Process
PAYMENT
Effective Date
01/01/1900
Status
A
In the Entry Event Step group box, add the PAYMENT step.
Term
Definition
Entry Event Step
PAYMENT
Account
NA
Source Record Jrnl Template
Select this option.
Journal Template
NA
In the Offset Accounts group box, add the accounts payable and bank disbursement offset accounts.
Term
Definition
DR/CR, Account, and Short Desc
DR, 20000 (example), Accts Paybl
DR/CR, Account, and Short Desc
CR. 10006 (example), UBANK Disb
The PeopleSoft Purchasing procure-to-pay process illustrates how you can use the same entry event code to handle reversals and closures.
Entry Event Requisition Reversal and Close
When you create and source a requisition to a PO, the Commitment Control budget processor liquidates the preencumbrance amount and increases the encumbrance amount. To ensure that the entry event accounting lines that you generated with the requisition are also reversed, the predefined entry event REQPOST process contains these predefined entry event steps:
REQCLOSE
REQPOST
REQREVRSAL
When you create and source a requisition to a PO, the Commitment Control budget processor liquidates the preencumbrance amount for the budget and increases the encumbrance amount for the budget.
This also occurs in the entry event transactions if you add the REQREVRSAL step to the existing entry event process REQPOST. This ensures the correct setup of the debit and credit accounts so that they credit the proprietary account for preencumbrance and debit the general expense offsets.
The entry event processor also creates closure entries for a closed requisition with a portion that is not sourced to a PO. You must set up the REQCLOSE step for the REQPOST process. You set up the debit and credit accounts similarly to the REQREVRSAL step to credit the proprietary account for preencumbrance and debit the general expense offsets.
To create the reversing and closing entry event transactions for the requisition, you must run the entry event processor for the requisition after you create and budget-check the PO. You can run the entry event processor for all business units, the business unit for the requisition, or the specific requisition that you created. Select and use the accounting entries inquiry to review all of the entries, the entry event reversals, and the closures for the requisition.
Exceptions to the Reversal and Close Processes
Here are some exceptions to using the reversal and close process:
Closing a PO that is sourced from a requisition.
When you source a requisition to a PO and the PO is canceled or closed, you can leave the requisition open to source it to another PO. If you keep the requisition open, the system cannot create reversal or closure entry event transactions until you source the requisition to another PO and budget-check the PO. However, if you close the requisition, the system creates the reversal and closure entries.
Closing a PO without processing the entry events for the requisition.
Because the entry event process for Purchasing uses the output from the Commitment Control processor, no changes occur to the entry event transactions until you budget-check the source document (PO or requisition) and run the entry event processor. In a rare case, you might create, budget-check and source a requisition to a PO, and then budget-check the PO and attempt to close it without running the entry event processor on the requisition. You cannot close the PO until you run the entry event processor on the requisition.
Copying a PO to a voucher.
During the procurement process, you can copy a PO and its associated entry event code into a voucher. However, the entry event code setup must contain the VCHRPOST process for the system to create the entry event transactions when you post the voucher. Regardless of whether you copy the entry event code to the voucher and process it within Payables, when you budget-check the voucher, you can create reversals and closure entries for the copied PO. If the entry event code used in the distribution lines of the copied PO has the steps POREVERSAL and POCLOSE defined for the POPOST process, you can create closing and reversal entries for the PO.
Closing or finalizing a voucher without creating entry events for a PO.
As with sourcing a requisition to a PO, the entry event processor uses the output from the Commitment Control processor to create entry event transactions. You cannot close or finalize a voucher that you created from a PO until you run the entry event processor on the PO. There may be a rare case where you create, budget-check, copy a PO to a voucher, and then budget-check the voucher. If you attempt to close the voucher without running the entry event processor on the PO, an error occurs requiring you to run the entry event processor on the PO.
You can set up entry events to create transactions for vouchers, payments, and cash clearing. You must set up the entry event codes with the predefined VCHRPOST, PAYMENT, and CASHCLRNG processes and steps. Depending on the entry event transactions that you want to create for an entry event code, you must set up different steps for each process. In some cases, you do not set up the CASHCLRNG process for an entry event code. You can set up the following processes and steps to create the pro forma entries:
|
Process |
Steps |
|---|---|
|
VCHRPOST |
|
|
PAYMENT |
Note: The last two steps are included in the PAYMENT process that uses cash clearing. |
|
CASHCLRNG |
CASHCLR (cash clearing). |
Once you create and budget-check a voucher, you can generate entry event transactions by running the entry event generator at the same time as voucher post or separately by selecting The Accounts Payable Voucher Post process must create entry event transactions before steps included in the VCHRPOST process can create them.
The voucher that you pay includes the payment accounting information. If you enter an entry event code on the voucher or you copy an entry event code to the voucher from a PO, the system carries the code to the payments created for that voucher. When you create payments from vouchers, you can generate entry event transactions by running the entry event generator at the same time as payment post, or separately by selecting The Accounts Payable Payment Post process must create entry event transactions before steps included in the PAYMENT process can create them. If you use Payables, you must set up cash clearing steps for the PAYMENT process associated with an entry event code to create payment entry event transactions.
If you set up cash clearing for Payables and you want to create entry event cash clearing entries, you need to associate the entry event code with the CASHCLRNG process and the step CASHCLR. All reconciled payments create entry event transactions if you associate an entry event code with the CASHCLRNG process. The system can run the entry event processor to generate entry event transactions simultaneously with the Cash Clearing process, or you can generate them separately by selecting
Upward and downward adjustments include adjustments for both unexpired and expired funding. Each has entry event configuration to handle different accounting.
Adjustments for unexpired funding are very similar to adjustments for expired funding where changes to purchase order or voucher transactions are recorded as upward or downward adjustments. The difference is that the funding is still current for unexpired adjustments and therefore the accounting is not the same. To be considered unexpired, the Unexpired checkbox must be selected for the Prior Year Adjustment ChartField on the Budget Definition page, and the budget date must fall between the Begin and Expiration dates as defined on the Budget Definition page. Additionally, for new POs or vouchers the Budget Fiscal Year must be less than the Accounting Fiscal Year. For a PO change order or Voucher adjustment, the Original Budget Fiscal Year must be less than the Adjustment Accounting Fiscal Year.
Funding is designated as expired on the Prior Year Adjustment ChartField tab of the Commitment Control Budget Definition page. If the budget date on a PO or voucher is between the defined expired and end dates, the funding is considered expired and could be subject to upward or downward adjustment accounting.
In the following cases, the system must automatically generate separate budgetary debit and credit accounts for U.S. federal government adjustments to POs and vouchers that are processed after the funding has an unexpired or expired status:
When an existing PO is either increased or decreased in a period during which the funding has changed to unexpired or expired state.
When a new PO is entered against a period in which funding has changed to an unexpired or expired state and no goods, services, or invoices were received.
When a voucher is processed against an existing PO for more or less than the PO amount in a period during which the funding has changed to an unexpired or expired state.
When a voucher that is not tied to a PO is entered in a period during which the funding has changed to an unexpired or expired state.
When an adjustment voucher is entered in a period during which the funding has changed to an unexpired or expired state.
This section discusses:
Entry event definitions for upward and downward adjustments in PeopleSoft Purchasing and Payables.
Upward and downward adjustments in PeopleSoft Purchasing.
Upward and downward adjustments in PeopleSoft Payables.
Upward and downward adjustment reversals.
To generate these budgetary debit and credit accounts, you select an entry event code when you enter the adjustment to the PO or when you enter the PO voucher that points to the predefined entry event source transaction definitions and the predefined entry event processes and steps.
Before you can enter and process these upward and downward adjustments in an unexpired or expired funding period, you must:
Set up an Prior Year Adjustment ChartField for your budgets.
Navigate to to access the Prior Year Adjustment page. The information that you enter on this page determines whether a fund is unexpired or expired when you run the budget processor for a document.
Create entry event data to use in Purchasing or Payables to automatically generate and update the budgetary debit or credit accounts for the adjustment if the fund is unexpired or expired.
Verify that the users who enter and process the Purchasing or Payables upward and downward adjustments have permission to override budget-checking errors for expired-year funding.
See User Preferences - General Ledger Page.
See Entry Event Page.
Entry Event Definitions for Upward and Downward Adjustments in PeopleSoft Purchasing and Payables
Access the Budget Definitions - Prior Year Adjustment ChartField page (Commitment Control, Define Control Budgets, Budget Definitions, Prior Year Adjustment ChartField).
To use entry events for creating budgetary account adjustments in Purchasing and Payables:
Verify that the following entry event source definitions exist.
Warning! These values are predefined; do not change them.
Entry Event Source Definition
Description
Source Record
Target Record
Temporary Record
PO_POADJUP
PO expired upward adjustment.
EE_PO_UP_VW
EE_PO_ACCTG_LN
EE_PO_TMP
PO_POADJDN
PO expired downward adjustment.
EE_PO_DN_VW
EE_PO_ACCTG_LN
EE_PO_TMP
PO_UPUX
PO unexpired upward adjustment
EE_PO_UP_UX_VW
EE_PO_ACCTG_LN
EE_PO_TMP
PO_DNUX
PO unexpired downward adjustment
EE_PO_DN_UX_VW
EE_PO_ACCTG_LN
EE_PO_TMP
PO_UXCLADJ
PO unexpired close adjustment
EE_PO_UXCLS_VW
EE_PO_ACCTG_LN
EE_PO_TMP
AP_VCHADJ
Voucher upward or downward adjustment.
EE_VCH_TMP
EE_VCH_ACCTG_LN
NA
Verify that the following entry event process steps exist for these entry event processes.
Warning! These values are predefined; do not change them.
Entry Event Process
Process Steps
Process Step Description
Process Step Characteristics
POPOST
POUP
PO expired upward adjustment.
Entry event source transaction: PO_POADJUP.
Field name and value: BALANCING_LINE, Y.
Field name and value: CLOSED_VALUE, N.
POPOST
PODN
PO expired downward adjustment.
Entry event source transaction: PO_POADJDN.
Field name and value: BALANCING_LINE, Y.
POPOST
POUPUX
PO unexpired upward adjustment.
Entry Event source transaction: PO_UPUX.
Field name and value: BALANCING_LINE, Y.
POPOST
PODNUX
PO unexpired downward adjustment.
Entry event source transaction: PO_DNUX.
Field name and value: BALANCE_LINE, Y.
VCHRPOST
ACRDN
Voucher expired downward adjustment.
Entry event source transaction: AP_VCHADJ.
Field name and value: DST_ACCT_TYPE, APA.
Field name and value: POSTING_PROCESS, ACCR.
VCHRPOST
ACRUP
Voucher expired upward adjustment.
Entry event source transaction: AP_VCHADJ.
Field name and value: DST_ACCT_TYPE, APA.
Field name and value: POSTING_PROCESS, ACCR.
VCHRPOST
ACRUPUX
Voucher unexpired downward adjustment.
Entry event source transaction: AP_VCHADJ.
Field name and value: DST_ACCT_TYPE, APA.
Field name and value: POSTING_PROCESS, ACCR.
VCHRPOST
ACRDNUX
Voucher unexpired downward adjustment.
Entry event source transaction: AP_VCHADJ.
Field name and value: DST_ACCT_TYPE, APA.
Field name and value: POSTING_PROCESS, ACCR..
Use the entry event codes for the predefined upward and downward adjustments as the basis for setting up your own entry event codes.
Upward and Downward Adjustments Processing in PeopleSoft Purchasing
This section discusses how to process upward and downward adjustments in Purchasing.
PO upward and downward adjustments are initiated by any change to a PO that applies to expired or unexpired year funding.
Here are some important considerations:
The accounting date entered on the Purchase Order Header page is used for the accounting date on the resulting entry event transactions.
The budget date on the PO distribution line is checked against the Prior Year Adjustment ChartField dates and attributes to determine whether funding is current, unexpired, or expired. Changing the budget date can affect whether the funding is in an expired year. Changing the accounting or budget date for funding subject to unexpired can affect whether the funding changes to an unexpired state.
If a PO has expired-year funding and has been budget-checked in current year, but the entry events have never been generated, the adjustment amount is calculated by taking the current budget-checked PO amount minus the last amount budget-checked in the current year.
If a PO has expired-year funding and has never been budget-checked while in the current year, no adjustments are necessary.
See “Creating Requisitions Online” in the PeopleSoft Purchasing documentation Understanding the Requisition Business Process.
Here is an example of upward adjustment for unexpired funding. Suppose the existing PO, PO 2, is for 7,000.00 USD against a fund subject to unexpired funding adjustments. Due to a contract adjustment, the PO increases to 8,600.00 USD. The organization received no goods, services, or invoices. The budget date is between the begin and expiration dates on the Prior Year Adjustment ChartFields tab of the Budget Definition page and the Original Budget Fiscal Year is less than the Adjustment Fiscal Year. This would be classified as an unexpired upward adjustment.
To enter and process the PO for the unexpired upward adjustment:
Enter the 1,600.00 USD upward adjustment change order to PO 2.
Approve the PO change order.
Budget check the PO change order. The budget processor checks the Prior Year Adjustment ChartField attributes and dates to see if the funding is subject to unexpired.
Once the PO passes budget checking, run the entry event processor to generate the entry events.
The EE processor checks to see if the Original Budget Fiscal Year is less than the Adjustment Accounting Fiscal Year and therefore, requires unexpired adjustment accounting. The system calculates the difference between the PO current amount and the lines posted to the Entry Event accounting line record.
In this example, the entry event processor generates the following budgetary accounting lines:
4450 (Allotments - Unexpired Authority) — $1,600.00.
4881 (Upward Adjustment of Prior Year Unpaid Unexpended Obs) — <$1,600.00> .
Proprietary accounting entries: NONE.
Here is an example of upward adjustment for expired funding. Suppose that the existing PO called PO 1 is for 7,000.00 USD against an expired fund. Due to a contract adjustment, the PO increases to 8,600.00 USD. The organization received no goods, services, or invoices. Budget date is between the expired and end dates on the Prior Year Adjustment ChartFields tab on the Budget Definition page. This would be an expired upward adjustment to the PO.
To enter and process the PO for the expired upward adjustment:
Enter the 1,600.00 USD upward adjustment change order to PO #1.
Approve the PO change order.
The Commitment Control budget processor checks the Prior Year Adjustment ChartField to see if this change applies to expired-year funding. If the fund year has expired, the budget processor issues an error and stops processing.
Check the budget error messages.
If the error message indicates that budget checking failed because the fund year has expired, then override the budget error.
Rerun the budget processor to ensure that the budget information is valid.
Once the budget is valid, run the entry event processor to generate the entry events.
The system calculates the difference between the PO's current amount and the lines posted to the entry event accounting line record.
Note: Your standard general ledger budgetary accounts may be different than the accounts used in this example.
In this example, the entry event processor generates the following budgetary accounting lines:
4650 (Allotments - Expired Authority) - $1,600.00.
4881 (Upward Adjust of Prior Year Unpaid Unexpended Obs) - <$1,600.00>.
Proprietary accounting entries: NONE.
See “Creating Requisitions Online” in the PeopleSoft Purchasing documentation Understanding the Requisition Business Process.
Upward and Downward Adjustments Processing in PeopleSoft Payables
This section discusses how to process upward and downward adjustments for Payables.
Payables voucher upward adjustments are created when:
The PO voucher is greater than the PO.
The voucher has no PO associated with it but has unexpired or expired year funding.
The PO voucher is less than the PO and is marked as final.
Here are some important considerations:
If a voucher is finalized at the header level, all voucher distribution lines in the voucher can have adjustments.
If the voucher is finalized at the line level, all voucher distributions for the line can have adjustments.
If the voucher is finalized at the distribution level, only distributions that are marked as final can have adjustments.
If a PO is in unexpired funding and the voucher is in unexpired funding (current year), no adjustments to the voucher are necessary.
If the PO is in expired-year funding and the voucher is in expired funding, no adjustments need to be made to the voucher.
If the voucher has not been created from a PO and the voucher is in unexpired or expired funding, there should be an adjustment for the full amount of the voucher.
Note: Your standard general ledger budgetary accounts and proprietary accounts may be different than the accounts used in these examples.
Here is an example for expired funding. Suppose that a PO exists for 8, 600.00 USD against an expired fund. A PO voucher was created for 9,000.00 USD against the PO.
Use these steps to enter and process the voucher for the upward adjustment:
Ensure that the PO voucher was entered into Payables for 9,000.00 USD and applies to expired-year funding.
The budget processor fails the PO voucher.
Budget checking fails and issues a budget-checking error for the voucher indicating that the voucher applies to an expired funding year. Unexpired funding will not cause a budget checking failure.
Override the budget checking for this voucher.
Run budget checking again to ensure that the voucher budget status is valid.
Run Voucher Posting to generate the proprietary accounting entries.
6100 (Operating Expense) - 9,000.00 USD
2110 (Accounts Payable) - <9,000.00> USD
Run the entry event processor to generate the accounting entries.
The processor calculates the difference between the voucher and the PO and adjusts the budgetary entries upward.
The system generates the following budgetary entries:
4650 (Allotments - Expired Authority) - 400.00 USD
4881 (Upward Adjust of Prior Year Unpaid Unexpended Obs.) - <400.00> USD
4801 (Unexpended Obligations - Unpaid) - 9,000.00 USD
4901 (Unexpended Authority) <9,000.00> USD
3100 (Unexpended Appropriations) - 9,000.00 USD
5700 (Expended Appropriations) - <9,000.00> USD
Payables voucher downward adjustments are created when the following characteristics apply to the voucher:
The PO voucher is less than the PO.
The voucher has unexpired or expired year funding.
The voucher is marked final.
For example, a PO exists for 4,700.00 USD against an expired fund. A PO voucher is processed against the PO for 2,700.00 USD.
Use these steps to enter and process the voucher for the expired downward adjustment:
Ensure that the PO voucher is entered into Payables for 2,700.00 USD and applies to expired-year funding.
Because the PO amount is greater than the voucher amount, the commitment control budget processor does not issue an error, and it passes the budget checking.
Run Voucher Posting to generate the following accounting entries.
6100 (Operating Expense) - 2,700.00 USD
2110 (Accounts Payable) - <2,700.00> USD
Run the entry event processor to generate the following accounting entries.
The processor calculates the difference between the voucher and the PO and adjusts the budgetary entries downward.
The system generates the following budgetary entries:
4871 (Downward Adjustment of Prior Year - Unpaid Unexpended Obs) - 2000.00 USD
4650 (Allotments - Expired Authority) - <2000.00> USD
4801 (Unexpended Obligations - Unpaid) - 2,700.00 USD
4901 (Unexpended Authority) <2,700.00> USD
3100 (Unexpended Appropriations) - 2,700.00 USD
5700 (Expended Appropriations) - <2,700.00> USD
See “Entering and Processing Vouchers Online: General Voucher Entry Information” in Entering Regular Vouchers.
Upward and Downward Adjustments Reversals
This section discusses how the system handles upward and downward adjustments reversals.
Reversal processing for entry event generated adjustments is required when the voucher has been posted and:
The voucher is unposted, then any adjustments created for a voucher are reversed.
The voucher is partialized, then the voucher is selected for reverse processing based on:
Whether the voucher is budget checked and in unexpired or expired year funding.
Whether the voucher has been posted at least once.
Whether the voucher is partialized at the distribution level.
If so, only final distributions that have been processed can have adjustments.
You can set up entry events to create transactions for items, payments, credit cards, drafts, direct debits and direct journals. You must set up the entry event codes with the predefined ARUPDATE and ARDIRJRNL processes and steps.
For all Receivables transactions except Direct Journals, the Entry Event process can be run as part of the AR posting job, Receivables Update (ARUPDATE). Navigate to . On the Receivables Update - Options page of the run control request, select the Process Entry Events check box to automatically run the Entry Event process after ARUPDATE runs. You can also use the Options page to automatically run Journal Generator to create GL journals. You must enter the accounting definition name for the standard entries (ARDEFN), and if you want to create GL journals for the supplemental (entry event) entries, enter EGAROIDEFN in the Entry Event Definition Name field.
This example illustrates the fields and controls on the Options page for running the Entry Event process as part of Receivables Update.
For all Receivables transactions, including Direct Journals, the Entry Event process can be run as a stand-alone process on the Request Entry Event Processor page (PST_EE_RUN_REQUEST). Navigate to .
This example illustrates the fields and controls on the Request Entry Event Processor page for running Receivables transactions, including Direct Journals.
For Direct Journal transactions, the Entry Event processor is expecting the journal to be posted successfully to the General Ledger before creating Entry Event entries. The process flow for Direct Journals would be as follows:
Enter a Direct Journal and mark it complete.
(Optional) Run the budget processor if necessary.
Run Journal Generator to generate GL journals using the accounting definition ARDIRJRNL.
Run the Entry Event processor.
Run Journal Generator to generate GL journals for the Entry Event entries, using the accounting definition EGARDJDEFN.
You can use the Modify Accounting Entries page to view both the standard and supplemental (entry event) accounting entries for Direct Journals.
See Journaling Payments Directly to the General Ledger.
Use the Journal Entry Drill Down page to view the GL journals for both the standard and supplemental (entry event) accounting entries.
See Reviewing the Source Accounting Entries for Journal Lines .