[Core Federal Financial System\
Software Qualification Test]{.smallcaps}

PeopleSoft Test Execution Variances

[November 14, 2023]{.smallcaps}

# Contents {#contents .H1-No-Number .unnumbered}

[Introduction 1](#introduction)

[Variance Types 1](#variance-types)

[Execution Variances 3](#execution-variances)

[Variance 1: Variance Post Separate Documents for Travel Advance and
Obligation
3](#variance-post-separate-documents-for-travel-advance-and-obligation)

[Variance 2: Post IPAC Payment without Suspension due to Automatic
Population of Accounting Classification Information from the Contract
5](#post-ipac-payment-without-suspension-due-to-automatic-population-of-accounting-classification-information-from-the-contract)

[Variance 3: Use Two Documents to Post Invoice with Multiple Due Dates
8](#use-two-documents-to-post-invoice-with-multiple-due-dates)

[Variance 4: Post Obligation without Error Message or Suspension due to
Inability to Change BPA Accounting Classification Information
11](#post-obligation-without-error-message-or-suspension-due-to-inability-to-change-bpa-accounting-classification-information)

[Variance 5: Process Invoice Adjustments by Unposting the Original
Vouchers, Changing the Line Amounts, and Re-Posting the Vouchers in the
Current Period
12](#process-invoice-adjustments-by-unposting-the-original-vouchers-changing-the-line-amounts-and-re-posting-the-vouchers-in-the-current-period)

[Variance 6: Post Separate Obligation Document Increase before
Prepayment Increase
14](#post-separate-obligation-document-increase-before-prepayment-increase)

[Variance 7: Record Change in Organization Code on Payment Voucher with
a Zero Dollar Adjustment Voucher
16](#record-change-in-organization-code-on-payment-voucher-with-a-zero-dollar-adjustment-voucher)

[Posting Variances 18](#posting-variances)

[Variance 8: Reverse Previous Spending Entry and Post New Status Instead
of Recording Net Change
18](#reverse-previous-spending-entry-and-post-new-status-instead-of-recording-net-change)

[Variance 9: Reverse Receipt Entries upon Recording of Invoice
22](#reverse-receipt-entries-upon-recording-of-invoice)

[Variance 10: Use Unbilled Account Receivable Account When the
Prepayment or Advance on a Reimbursable Agreement is Decreased by
Recording Earned Income
25](#use-unbilled-account-receivable-account-when-the-prepayment-or-advance-on-a-reimbursable-agreement-is-decreased-by-recording-earned-income)

[Variance 11: Use Accounts Payable Instead of Disbursement-in-Transit
Account Instead for Late Payment Interest
28](#use-accounts-payable-instead-of-disbursement-in-transit-account-instead-for-late-payment-interest)

[Variance 12: Post Spending Entries by Line Item
29](#post-spending-entries-by-line-item)

[Variance 13: Run Credit Memo Offset Entries through the
Disbursement-in-Transit Account
32](#run-credit-memo-offset-entries-through-the-disbursement-in-transit-account)

[Variance 14: Post Advances and Prepayments Against an Expenditure
Voucher for the Entire Amount of the Expense, Not 'Net' of Advance
33](#post-advances-and-prepayments-against-an-expenditure-voucher-for-the-entire-amount-of-the-expense-not-net-of-advance)

[Variance 15: Roll-Back Funding to the Highest Level of the Budget
Execution and Restore It Back to a Lower Organization Level, Where Not
Done in Test Script
35](#roll-back-funding-to-the-highest-level-of-the-budget-execution-and-restore-it-back-to-a-lower-organization-level-where-not-done-in-test-script)

[Variance 16: Generate Fiscal Year-End Entries to Close General Ledger
Accounts Based on the Combinations of Accounting Classification Elements
(Chartfields)
38](#generate-fiscal-year-end-entries-to-close-general-ledger-accounts-based-on-the-combinations-of-accounting-classification-elements-chartfields)

[Variance 17: Combine the SGL B134 Appropriation Used Entry into One
Transaction, with the Related Expenditure Entry, in Non-Reimbursable
Funds
40](#combine-the-sgl-b134-appropriation-used-entry-into-one-transaction-with-the-related-expenditure-entry-in-non-reimbursable-funds)

[Variance 18: Use Alternate Posting Model for Upward and Downward
Spending Adjustment Entries
42](#use-alternate-posting-model-for-upward-and-downward-spending-adjustment-entries)

[Variance 19: Use Negative Debit and Credit Postings for
System-Generated Reversals of Allowances for Loss
52](#use-negative-debit-and-credit-postings-for-system-generated-reversals-of-allowances-for-loss)

[Processing Variances 55](#processing-variances)

[Variance 20: Use 'Recurring PO Voucher' Contract Transactions For Lease
Installments, Without Automatic Liquidation of the Related Commitment
55](#use-recurring-po-voucher-contract-transactions-for-lease-installments-without-automatic-liquidation-of-the-related-commitment)

[Variance 21: Post Purchase Order and Voucher to Accounting Period (AP)
12 Instead of Adjustment AP 13
58](#post-purchase-order-and-voucher-to-accounting-period-ap-12-instead-of-adjustment-ap-13)

[Variance 22: Use Accounting Periods 998 and 999 for Pre-Closing
Adjustments and Year-End Closing Entries
60](#use-accounting-periods-998-and-999-for-pre-closing-adjustments-and-year-end-closing-entries)

[Variance 23: Post Fiscal Year 2001 Closing Entries at the Budget Object
Class Level
61](#post-fiscal-year-2001-closing-entries-at-the-budget-object-class-level)

[Variance 24: System Assigns Payment Schedule Numbers
62](#system-assigns-payment-schedule-numbers)

[Variance 25: Record Adjustment to Fiscal Year 2001 Beginning Balance in
Accounting Period (AP) 998 Instead of AP 0
64](#record-adjustment-to-fiscal-year-2001-beginning-balance-in-accounting-period-ap-998-instead-of-ap-0)

[Reporting Variances 65](#reporting-variances)

[Variance 26: Report Additional FACTS Attributes on the Transaction
Register
65](#report-additional-facts-attributes-on-the-transaction-register)

[Variance 27: Report Activity Under GRANT01 and Unfunded Construction
Contract CN01 as Extra Level of Detail on Trial Balances due to Use of
Project Accounting Classification Element (Chartfield)
66](#report-activity-under-grant01-and-unfunded-construction-contract-cn01-as-extra-level-of-detail-on-trial-balances-due-to-use-of-project-accounting-classification-element-chartfield)

[Setup Variances 68](#setup-variances)

[Variance 28: Use Accounting Classification Element to Control The
Spending Limits of BPAS and Contracts
68](#use-accounting-classification-element-to-control-the-spending-limits-of-bpas-and-contracts)

[Variance 29: Use Subaccounts for FACTS Attributes
71](#use-subaccounts-for-facts-attributes)

[Variance 30: Configuration for Allotment Withdrawals in Test Steps
FM1.24 And FM1.25
73](#configuration-for-allotment-withdrawals-in-test-steps-fm1.24-and-fm1.25)

[Variance 31: Derivation of Public Law Numbers
74](#derivation-of-public-law-numbers)

## Introduction

This document contains test variance information approved by the Joint
Financial Management Improvement Program (JFMIP) for testing:

> **PeopleSoft Financial Management Solutions (FMS) Version 8.8**

JFMIP employs a formal qualification test to determine whether subject
financial management system (FMS) products comply with all published
requirements.

For more information about testing in general and other key JFMIP
programs, please log on to our web site (www.jfmip.gov) or contact Mr.
Stephen Balsam (stephen.balsam@gsa.gov).

## Variance Types

Qualification test steps are designed to produce exact SGL posting and
reporting results. To maintain the integrity of the test process and
ensure that the expected results are achieved, the vendor is not allowed
to combine, separate, re-sequence, skip, or modify individual test
steps, posting effects, or other expected results without prior consent.

In cases where a product cannot process a step as specified, the vendor
can request a variance. Variance requests identify the affected steps,
the execution problem, and proposed alternative.

Table 1 contains types of variances and guidelines for how JFMIP will
view the proposed variances.

  -----------------------------------------------------------------------
  Table 1. Variance Categories        
  ----------------------------------- -----------------------------------
  Type of variance                    Guideline

  *Setup.* Setup variances can occur  Minor setup differences that can be
  when the vendor uses different      directly cross-walked to expected
  configuration or assumption data    results are generally allowed. The
  than what were provided in the test use of account code suffixes to
  plan.                               establish sub accounts would be
                                      considered acceptable variance
                                      provided these sub accounts roll up
                                      as intended and are not used for
                                      other unexpected posting results.
                                      Wholesale substitutions of
                                      specified fund codes, BOCs, SGL
                                      accounts, programs, and projects
                                      are not permitted.

  *Posting.* A posting variance can   If the FMS can be configured to use
  occur when a subject package is     the prescribed posting rules, JFMIP
  designed to post transactions in a  expects it to be tested that way
  manner different from the posting   (without a variance). An
  model specified by JFMIP. Note: the alternative-posting model may be
  test rules governing the use of     allowed, if the net effect of the
  alternate document numbers to       alternative model matches the
  reference SGL posting results are   specified result. The use of
  not considered a variance.          journal vouchers to accomplish
                                      posting results is prohibited
                                      unless specifically cited as being
                                      allowed in a given test step.

  *Execution.* A step execution       Execution variances may be
  variance can occur in cases where a acceptable if their initiation is
  tested package completes a test     automatic or system controlled,
  step using multiple separately      they achieve the expected results,
  initiated documents or batch        and do not cause a misstatement of
  processes.                          funds availability (real-time) or
                                      period-end financial position.

  *Function.* A functional variance   All tested functionality is
  occurs in cases where a tested      considered mandatory.
  package was not designed to support 
  a stated requirement (e.g., produce 
  a report, produce a query result.   
  or perform process control).        

  *Reporting.* A format variance      Treasury- and OMB-defined formats
  occurs when a package does not      cannot be changed. In cases where
  generate a required output report,  the test is based on an example
  query result, or transaction file   format, variances may be approved
  according to test step cited form   provided all requested information
  and content rules.                  is presented comprehensively.

  *Process.* A process variance       JFMIP expects differences in the
  occurs when the way a package       way an FMS handles complex posting
  handles a multi-step test case      processes. The basis for allowing a
  differs from the test-specified     process variance is whether the
  approach (e.g., starting balances,  intended result is achieved and
  year-end closing, API, cost         whether the end-to-end process is
  distribution).                      automatic.

                                      
  -----------------------------------------------------------------------

The following sections list details of each approved variance for this
vendor package test.

## Execution Variances

### Variance Post Separate Documents for Travel Advance and Obligation

#### A. Description of Test Execution Variance

PeopleSoft delivers an edit that requires an obligating document to pay
an advance. For this reason, in test steps TD4.4, PT1.1 and PT2.1,
PeopleSoft will require the travel order and the advance to be separate
documents. The additional document numbers used during the processing of
scenarios TD4.4, PT1.1 and PT2.1 will cause variations in the Orig Doc
column for the Transaction Reference data. This will be seen in the
paycycle scenarios that apply to the Travel Advances when they get paid.

The posting of the travel order will be made to accounts 4610/4801. This
will be reversed when the travel advance is posted. The travel advance
will record the prepayment to 4610/4802, as well as the posting to
1410/1010. JFMIP will see the posting of the travel order and the
subsequent liquidation/reversal of the travel order obligation in
addition to the JFMIP expected results. This is consistent with
PeopleSoft's alternate posting model for the movement of spending
documents (commitment to obligation to expenditure), as described in
further detail in PeopleSoft variance #8.

For example, in test step TD4.4, the difference in document numbers and
in the related general ledger (GL) postings will be as follows:

  ------------------------------------------------------------------------------------------------------------
  Step       Doc\     Trans\     DR.\      Cr.\      Amt     Doc\         Trans\   DR.\      Cr.\      Amt
             Id       Id         Acct      Acct              Id           Id       Acct      Acct      
  ---------- -------- ---------- --------- --------- ------- ------------ -------- --------- --------- -------
  JFMIP                                                      PeopleSoft                                
  Expected                                                   Expected                                  
  Results                                                    Results                                   

  TD4.4      TD4OB6   TD4OB6.1   4610.01   4802.01   1,000   TD4OB6                4610.01   4801.01   1,000

                      TD4OB6.1   1410.01   1010.01   1,000   TD4OBV6               4801.01   4610.01   1,000

                                                             TD4ADV6               4610.01   4802.01   1,000

                                                             TD4ADV6               1410.01   1010.01   1,000

                                                                                                       
  ------------------------------------------------------------------------------------------------------------

There is no net effect on the general ledger account balances.

#### B. Reason for Variance

The variance exists due to the Government required edit that an
obligating document exists and be referenced on an advance payment.

Requirement FME-34 states: Record advance payments made, such as travel
advances, contract advances, and grants. Ensure that an obligating
document exists prior to recording an advance.

#### C. Benefit to the Government

The benefit to the Government is compliance with the requirement
referenced in section B., above. In addition, the Government will have a
complete audit trail of all transactions.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

The direct change to the Test Materials is the posting of separate
obligation and advance documents in test steps TD4.4, PT1.1 and PT2.1.

### Post IPAC Payment without Suspension due to Automatic Population of Accounting Classification Information from the Contract

#### A. Description of Test Execution Variance

PE11.7 involves suspending an IPAC payment due to missing accounting
classification data elements such as organization code and object class.
These data elements are knows as chartfields in PeopleSoft.

Prior to PE11.7 IPAC payment, PE11.5 establishes the second installment
of the recurring transactions for this lease. In prior PE11 scenarios,
the accounting classification data elements are established on the
contract, one time, and automatically populated on the recurring po and
the installment vouchers. The accounting distribution line does not need
to be re-entered by the user or by the IPAC file when the IPAC vendor
payment data is imported into the system.

With PeopleSoft, like with the PE11.5 script, the accounting
classification entries for the recurring transaction are populated when
the recurring transaction is created. The only accounting classification
structure element that would change as the transaction goes from unpaid
to paid expenditure is the SGL accounts, and this is handled by the
entry event, which is the PeopleSoft concept for transaction code.
Therefore, the situation in the PE11.7 script resulting in a suspended
transaction would not exist. The IPAC payment would impact the same
accounting classification (with the exception of the account code) as
established in PE11.5. Since PE11.5 is a posted expenditure transaction,
it would not be possible for the organization code and object class code
to NOT be present, and thus not possible to emulate the suspend/hold
condition that the script is looking for.

PeopleSoft will process test step PE11.7 by importing the IPAC file,
however, we will not generate the error message desired in the script,
instead we will proceed with the actual posting of the IPAC payment in
PE11.11.

PeopleSoft is still able to fully meet PMC-27. This core systems
requirement does not mention the error checking capability by accounting
classification structure elements that is required in this script.
PMC-27 specifically states:

"Automatically generate transactions to reflect disbursement activity
initiated by other agencies and recorded in Central agency electronic
systems (such as OPAC/IPAC). Capture related information required by the
Central agency system for each transaction (e.g., purchase order number,
reimbursable agreement number, ALC)."

Among the edits performed by PeopleSoft's Inbound IPAC processor are:

-   PO in file must agree to PO of target voucher,

-   Contract (Reimburseable Agreement) in file must agree to contract
    reference on PO

-   Invoice ID in file must agree to invoice ID of target invoice

-   Sender ALC must agree to ALC on 'Vendor' file of vendor assigned to
    PO,

-   Receiver ALC must agree to ALC of Agency customer (customer of
    PeopleSoft, this ALC is stored within the 'Bank' structures of
    PeopleSoft.)

-   Treasury symbol of sender must exist in Treasury symbol definition
    within PeopleSoft

-   Treasury symbol of receiver must agree with Treasury symbols
    assigned to Fund Codes on distribution of Voucher

-   Gross amount of file must agree to gross amount of target voucher.

The specific elements mentioned in PMC-27 (purchase order number,
reimbursable agreement number (contract ID), and ALC (for both sender
and receiver) are all addressed within the edits listed above.

#### B. Reason for Variance

As described above, the PeopleSoft product would not allow an error
condition as requested in PE11.7 to exist; the payment transaction
leverages the accounting classification established with the
invoice/voucher. PeopleSoft's IPAC design prevents the user from
exposure to accounting classification structure mismatches between the
data in the IPAC file and the actual payment transactions.

#### C. Benefit to the Government

With our application, the government agency using our product could not
encounter the error tested. Accordingly, the benefit to the government
is that the users wouldn't have to spend any time working on error
correction, and could focus more efforts on decision-making instead of
error correction. At the same time, many edits are performed, beyond the
specifications of PMC-27, to ensure a proper match between the inbound
data and the Agency user.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

The IPAC transaction will not be suspended, as requested in PE11.7, nor
will any accounting classification data be corrected in PE11.11. To
minimize the reconciliation effort, the transaction will actually be
posted in step PE11.11.

### Use Two Documents to Post Invoice with Multiple Due Dates

#### A. Description of Test Execution Variance

PE2.7 stipulates to receive a single invoice for goods purchased from
JMK Company, and to calculate a due date of 2/21/02 for the dairy
products and 3/13/02 for the other products.

PeopleSoft will process 1 invoice in this scenario; each invoice line
item will have its own voucher header record, one for the dairy product
and a separate voucher for the other products. One voucher will be
entered for the milk product, and the 'Copy PO' feature will be used to
copy the PO line for the milk product to the voucher. This voucher will
default to a term of net 30 based on vendor terms in the vendor record.
The default terms will be overridden and manually assigned a term of
'Net 10', the various dates entered (Invoice, Invoice Receipt).
Subsequently, the application will automatically compute the due date
for the dairy product using the 'Basis Date' feature, combined with the
payment terms and will automatically schedule the payment based on that
date. This describes how the invoice information is entered and
processed to automatically calculate the first prompt pay due date for a
single invoice.

A second voucher will be entered, and the 'Copy PO' feature used to copy
the remaining lines of the PO onto the voucher. The voucher will default
to a term of net 30 based on vendor terms in the vendor record, the same
dates will be populated (Invoice and Invoice Receipt), and the terms and
the 'Basis Date' feature will be used by the system to determine the due
date for the non-dairy product as described above. The system will
automatically calculate the appropriate prompt pay due dates for the
differing prompt pay due date terms. This describes how the invoice
information is entered and processed to automatically calculate the
second prompt pay due date for a single invoice.

The payment inquiry will be used to inquire on the one invoice id number
to show that there are two separate due dates to accommodate the varying
products on the one vendor invoice. A screen shot of this capability is
provided below:

  -----------------------------------------------------------------------
  ![](media/image1.png){width="5.9944444444444445in"
  height="4.239583333333333in"}

  -----------------------------------------------------------------------

#### B. Reason for Variance

PeopleSoft Payables specifies terms (net30, net10, etc.) at the voucher
header level. Multiple vouchers can be processed against a single
invoice. We will use this flexibility for this particular scenario to
support multiple terms associated with a single invoice.

#### C. Benefit to the Government

The government will be able to track the vendor invoice by two separate
due dates, if necessary.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

Impacts only test step PE2.7, as follows:

  -------------------------------------------------------------------------------------------------
  Step       Doc\     Trans\     DR.\   Cr.\   Amt    Doc\         Trans\     DR.\   Cr.\   Amt
             Id       Id         Acct   Acct          Id           Id         Acct   Acct   
  ---------- -------- ---------- ------ ------ ------ ------------ ---------- ------ ------ -------
  JFMIP                                               PeopleSoft                            
  Expected                                            Expected                              
  Results                                             Results                               

  PE2.7      PE2V15   PE2V15.1                        PE2V15       PE2V15.1                 350

                                                      PE2V15.2                              4,980
  -------------------------------------------------------------------------------------------------

There is no impact from an accounting perspective. The impact will be
that two general ledger transaction ids will be processed rather than
one. PeopleSoft will use PE2V15.1 and PE2V15.2 as the two transaction
ID's to record these two different payment amounts. The first
transaction will hit the same accounts for the 'milk' amount (\$350).
The second transaction will hit all the same accounts with the remaining
amount (\$4,980).

### Post Obligation without Error Message or Suspension due to Inability to Change BPA Accounting Classification Information

#### A. Description of Test Execution Variance

The JFMIP Test Script requests that a message be received when a user
changes an Obligation's Chartfield inherited from a Procurement
Contract. Our current ability to lock the Chartfields inherited from a
Procurement Contract to any source document will prevent the user from
modifying the fields thus not requiring a message. A ChartField is an
element of the accounting classification structure.

#### B. Reason for Variance

The reason for this variance is that our Procurement Lock feature does
not allow a user to add, update or delete any classification structure
elements on Obligations or any document created from a Procurement
Contract. As required in a JFMIP Scenario the user should receive an
error message when attempting to record an obligation with a different
Chartfield value than the Procurement Contract.

We have provided a more **"preventative"** solution with our Chartfield
Lock feature that totally restricts a user from accessing any accounting
classification structure elements inherited from the source Procurement
Contract.

#### C. Benefit to the Government

The inability for a user the change the accounting classification
structure element due to the Chartfield Lock feature will provided by
ensuring that the value can and will not be changed once that Obligation
has been created from the Procurement Contract.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

PE6.4: Due to not being able to change the accounting classification
structure values, the current requirement to receive an error message
will not occur. Our Chartfield Lock feature is a preventative measure
and will not allow any changes to any inherited Chartfields.

### Process Invoice Adjustments by Unposting the Original Vouchers, Changing the Line Amounts, and Re-Posting the Vouchers in the Current Period

#### A. Description of Test Execution Variance

A couple of the test scenarios surrounding Payables functionality
require adjustments to invoice/voucher amounts. For example, in Cycle 6,
test step PE1.6, the invoice/voucher is adjusted downward by a total of
\$15,000.

The simplest way to achieve this in PeopleSoft is to 'Unpost' the
voucher, which simply reverses the original accounting entries in the
current period, change the original voucher line amounts, and re-post
the original voucher in the current period. The voucher for PE1.3 has
two lines that need to be decreased to perform the modification that is
described in the script. The user will modify line 1 from 47,000 to
40,000 and will modify line 2 from 68,000 to 60,000. This approach
allows the user to modify the original voucher document, as required in
PMB-05. The approach results in the same net accounting impact as the
JFMIP scenario.

The PeopleSoft approach posts both the 'unpost' and 'repost' entries
(depicted in the Expected Results below) on the date of the adjustment
depicted in the script. For PE1.6, for example, the effective date, per
the script, is 2/28/2002. This is the date the unpost and repost entries
are posted. For PE15.7 the script effective date is 11/30/2002, which is
the accounting date for the entries posted by PeopleSoft for the test.

Reference requirement PMB-05: Allow a warehoused payment to be modified,
cancelled, and put on hold.

  ---------------------------------------------------------------------------------------------------------------
  Step               Doc\     Trans\     DR.\   Cr.\   Amt     Doc\               Trans\   DR.\   Cr.\   Amt
                     Id       Id         Acct   Acct           Id                 Id       Acct   Acct   
  ------------------ -------- ---------- ------ ------ ------- ------------------ -------- ------ ------ --------
  JFMIP Expected                                               PeopleSoft                                
  Results                                                      Expected Results                          

  PE1.6              PE1VI6   PE1VI6.1   4901          7,000   PE1.6              Unpost   4901          47,000

                                                4610   7,000                                      4610   47,000

                                         2110          7,000                               2110          47,000

                                                6100   7,000                                      6100   47,000

                     PE1VI6   PE1VI6.2   5700          7,000                               5700          47,000

                                                3107   7,000                                      3107   47,000

                                                                                  Repost   4610          40,000

                                                                                                  4901   40,000

                                                                                           6100          40,000

                                                                                                  2110   40,000

                                                                                           3107          40,000

                                                                                                  5700   40,000

  Similar entries                                              Similar entries                           
  for line 2 of the                                            for line 2 of the                         
  invoice/voucher,                                             invoice/voucher.                          
  transaction ID's                                                                                       
  PE1VI6.3 and                                                                                           
  PE1VI1.4                                                                                               

                                                                                                         
  ---------------------------------------------------------------------------------------------------------------

This variance only impacts invoice/voucher PE1VI3, which originates in
test script PE1.3 and is adjusted in test script PE1.6, and
invoice/voucher PE15VI3 in test script PE15.7/PE15.8, both of which will
be using the Unpost feature.

Related variances include TEVR 03---Posting Model for Liquidation of
Allotments, which addresses the original entries in the spending chain,
and TEVR 32---Streamlined Entry, which address the combination of
accounting pairs from multiple 'Transaction Codes' used by JFMIP to a
single 'Entry Event' used in the PeopleSoft Application.

#### B. Reason for Variance

The Unpost feature provides a simple, intuitive, consistent, auditable
method to adjust an existing voucher.

#### C. Benefit to the Government

Satisfies financial/accounting requirements of the scenario with a
simple, consistent, auditable approach.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

No changes to Test Materials, other than alternate general ledger
entries that have the same net effect.

### Post Separate Obligation Document Increase before Prepayment Increase

#### A. Description of Test Execution Variance

If a prior year prepayment requires a change, then a change order must
first be processed against the purchase order that relates to the
prepayment. This is the specific handling for scenario AO 8.3.

Test steps AO8.X depict the obligation of funds with subsequent
Prepayment and Expenditure of previously obligated and prepaid amounts.
FME-34 suggests that obligated amounts should exist prior to the
establishment of a prepaid amount. To address the scenario with the core
requirement in mind, PeopleSoft will process a change order against the
original PO. The change order will increase the obligated amount by 100,
from 900 to 1,000, and produce the appropriate budget error for expired
funds. A following step will increase the prepayment amount.

  ---------------------------------------------------------------------------------------------------
  Step            Doc\     DR.\    Cr.\   Amt     Doc\            Trans\   DR.\    Cr.\   Amt
                  Id       Acct    Acct           Id              Id       Acct    Acct   
  --------------- -------- ------- ------ ------- --------------- -------- ------- ------ -----------
  JFMIP Expected                                  PeopleSoft                              
  Results                                         Expected                                
                                                  Results                                 

  Prior                                           No variation in                         
  Transactions:                                   prior                                   
  AO8.1, AO8.2                                    transactions.                           

  AO8.3           AO8NC2   4610           100     AO8.3           AO8OB1   4610           100

                                   4882   100                                      4881   100

                           1450           100                                             

                                   1010   100                     AO8NC2   4801           100

                                                                                   4802   100

                                                                           1450           100

                                                                                   1010   100

                                                                           4881           100

                                                                                   4882   100

                                                                           4802           100

                                                                                   4801   100

                                                                                          []{.mark}
  ---------------------------------------------------------------------------------------------------

#### B. Reason for Variance

Provide a proper methodology for increases to obligations and
prepayments.

#### C. Benefit to the Government

Addresses scenario and core requirements for both a financial accounting
and document flow process.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference) {#d.-resulting-changes-to-the-test-materials-list-individually-by-test-step-number-report-name-or-other-reference-5 .unnumbered}

Additional postings to the general ledger in test step AO8.3; net effect
is the same.

### Record Change in Organization Code on Payment Voucher with a Zero Dollar Adjustment Voucher

#### A. Description of Test Execution Variance

Test step PE13.3 posts an adjustment from one organization code to
another. The purpose of this variance is to explain how this transaction
is processed, including the related impact on payment processing.

For PE13.3, PeopleSoft used an Adjusting Voucher, document reference
PE13VI2. This voucher is 'linked' back to the original voucher, PE13VI1
in PE13.1. In the adjusting voucher, the net amount of the voucher is
'0', as it credits organization code 13400 for the adjustment amount,
and debits organization code 13000 for the same amount.

[Different posting model]{.underline}---During payment processing, the
JFMIP posting model posts only the adjusted/corrected line item (with
the corrected organization code) thru payment scheduling and payment
confirmation for test step PE13.3. PeopleSoft posts both the original
line items and the adjusting line items thru scheduling and
confirmation. The net result is the same balances for all accounts at
any point in time.

The processing of the adjustment voucher varied slightly from the
original test to the retest. During the original test, due to a data
entry error where the bank code on the adjusting voucher (PE13VI2) was
different from that on the original voucher (PE13VI1), a second paycycle
was run just to process the adjusting voucher and posting the scheduling
and confirmation entries. During the retest, the bank code was
corrected, and the adjusting voucher was picked up during the same
paycycle process as the original voucher.

It should be noted, though, that the entries generated were the same
from the original test and the re-test. The only difference was in which
payment process/paycycle generated the entries.

  --------------------------------------------------------------------------------------------------------------
  Step       Trans\     Org     Acct   Acct   Amount     Step         Trans\    Org     Acct   Acct   Amount
             ID                 Dr     Cr                             ID                Dr     Cr     
  ---------- ---------- ------- ------ ------ ---------- ------------ --------- ------- ------ ------ ----------
  JFMIP                                                  PeopleSoft                                   
  Expected                                               Expected                                     
  Results                                                Results                                      

  PP4.1      PP4SP1.3   13000   2110          1,523.68   PP4.1        PE13VI1   13400   2110          1,523.68

                        13000          2120   1,523.68                          13400          2120   1,523.68

                                                                      PE13VI2   13400   2120          1,523.68

                                                                                13400          2110   1,523.68

                                                                                13000   2110          1,523.68

                                                                                13000          2120   1,523.68

  PP4.2      PP4SP2.4   13000   2120          1,523.68   PP4.2        PE13VI1   13400   2120          1,523.68

                        13000          2110   1,523.68                          13400          2110   1,523.68

                                                                                                      

                                                                      PE13VI2   13400   2110          1,523.68

                                                                                13400          2120   1,523.68

                                                                                13000   2120          1,523.68

                                                                                13000          2110   1,523.68

  PP4.3      PP4SP3.3   13000   2110          1,523.68   PP4.3        PE13VI1   13400   2110          1,523.68

                        13000          2120   1,523.68                          13400          2120   1,523.68

                                                                      PE13VI2   13400   2120          1,523.68

                                                                                13400          2110   1,523.68

                                                                                13000   2110          1,523.68

                                                                                13000          2120   1,523.68

  PP4.4      PP4CD5.3   13000   4901          1,523.68   PP4.4        PE13VI1   13400   4901          1,523.68

                        13000          4902   1,523.68                          13400          4902   1,523.68

                        13000   2120          1,523.68                          13400   2120          1,523.68

                        13000          1021   1,523.68                          13400          1021   1,523.68

                                                                      PE13VI2   13400   4902          1,523.68

                                                                                13400          4901   1,523.68

                                                                                13400   1021          1,523.68

                                                                                13400          2120   1,523.68

                                                                                13000   4901          1,523.68

                                                                                13000          4902   1,523.68

                                                                                13000   2120          1,523.68

                                                                                13000          1021   1,523.68

                                                                                                      
  --------------------------------------------------------------------------------------------------------------

This variance only impacts document steps PP4.1 thru PP4.4 as noted
above.

#### B. Reason for Variance

Difference in posting model between JFMIP and PeopleSoft FMS.

#### C. Benefit to the Government

Not applicable.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

Separate document and entries for the Adjustment Voucher appear on
PeopleSoft reports, including those for the paycycle. Additional General
Ledger entries are posted that net to zero.

## Posting Variances

### Reverse Previous Spending Entry and Post New Status Instead of Recording Net Change

#### A. Description of Test Execution Variance

This variance is meant to cover the difference in JFMIP and PeopleSoft
posting models for the movement of a commitment (RQ) to an obligation
(PO), and the movement of an obligation (PO) to an expenditure (VCH).
This variance also applies to increases or decreases (change orders) to
commitments and obligation documents. Invoice changes, under 2-way match
only, are covered by variance 5. The combining of the B134 SGL entry
with the spending entry is covered by variance #17.

In the case of payment vouchers, this variance relates to all payment
vouchers, including those in a 2-way, 3 way or 4-way match scenario. If
an agency uses receipt accrual on a perpetual basis, then there are
additional entries for vouchers received in a 3-way match scenario are
covered by variance #9. The fundamental difference between variance 8
and 9 relates to using or not using receipt accrual. Both options are
available in PeopleSoft. Variance 8 shows examples where receipt accrual
would not be used on a perpetual basis, but could be used on a month end
basis. Variance 9 shows examples where receipt accrual is used when a
receiving report is posted. The detailed difference between variances 8
and 9 is that in variance 3, obligations are reversed for amount of the
voucher amount only, then voucher is posted; while under variance 9, the
receipt is reversed for full amount (and the obligation is reversed for
the voucher amount) and then it is re-posted for the difference if the
receiving report exceeds the voucher.

The JFMIP method shows the net effect of debits and credits that would
be required to record a decrease in a commitment and an increase in an
obligation with respect to a particular allotment budget, represented by
the 4610 or 4650 SGL account. The same is true for obligations that move
to expenditures. For example, if the commitment is for \$1000 and the
related final obligation is for \$900, the JFMIP postings for the
obligation document would be as follows:

  -----------------------------------------------------------------------------------------------------------
  GL\                          GL Account\               DR/CR\                     Amount   
  Account                      Description               Indicator                           
  -------------- ------------- ------------------------- ----------- -------------- -------- ----------------
  4701           Commitment                                          DR                      \$900

  4801           Obligation,                                         CR                      \$900
                 unpaid                                                                      

  4701           Commitment                                          DR                      \$100

  4610           Allotment                                           CR                      \$100

                                                                                             
  -----------------------------------------------------------------------------------------------------------

The PeopleSoft method liquidates/reverses the previous spending
document's impact on the allotment account, and records the gross amount
of the new spending document, as follows:

  ---------------------------------------------------------------------------------------------------
  GL\                          GL Account\                    DR/CR\                 Amount
  Account                      Description                    Indicator              
  -------------- ------------- ------------------------- ---- ------------- -------- ----------------
  4610           Allotment                               DR                 \$1000   

  4701           Commitment                              CR                 \$1000   

  4610           Allotment                               DR                 \$900    

  4801           Obligation,                             CR                 \$900    
                 unpaid                                                              

                                                                                     
  ---------------------------------------------------------------------------------------------------

The prior spending document (e.g., obligation) is reversed for the
(partial) amount of a subsequent partial spending document (e.g,
invoice). This also holds true for partial obligations that partially
liquidate requisitions.

The net result is the same between the JFMIP method and the PeopleSoft
method. A separate attachment, called PSFT-TEVR03 Accounting Model.xls,
explains these differences for the following types of transactions:

  ----------- -----------------------------------------------------------
  Example 1   Voucher Liquidating a PO where the PO and the Voucher are
              equal

  Example 2   Voucher Liquidating a PO where the Voucher is less than the
              PO (final for less)

  Example 3   Voucher Liquidating a PO where the Voucher is more than the
              PO (final for more)

  Example 4   PO Liquidating a RQ where the Requisition and Purchase
              Order amounts are equal

  Example 5   PO Liquidating a RQ where PO amount is less than the RQ
              (final for less)

  Example 7   Requisition Change Order

  Example 8   Downward Spending Adjustment

  Example 9   Upward Spending Adjustment

  Example 10  Example of a Partial Vch Liquidating a PO ("non-final"
              partial invoice)

  Example 11  Example of a Partial PO Liquidating a RQ ("non-final"
              partial PO)
  ----------- -----------------------------------------------------------

The effective dates or accounting dates of the entries, including
reversals follow the pattern listed below:

AL2CR7.2 obligation reversal/liquidation entry. The disbursement part of
the entry has an 11/5/01 effective date, but the obligation reversal
part of the entry has an 11/1/03 effective date. To summarize:

[JFMIP entries for AL2OT4 obligation:]{.underline}

Debit 4610 Credit 4801 Doc #AL2OT4.1 Effective date = 11/1/01

Debit 2179 Debit 2170 Doc #AL2OT4.1 Effective date = 11/1/01

[JFMIP entries for AL2CR7.2 disbursement:]{.underline}

Debit 4801 Credit 4902 Doc \# AL2CR7.2 Effective date: = 11/5/01

Debit 6100 Credit 2179 Doc \# AL2CR7.2 Effective date = 11/5/01

Debit 2170 Credit 1031 Doc \# AL2CR7.2 Effective date = 11/5/01

[PFT entries for AL2CR7.2 disbursement:]{.underline}

Debit 4801 Credit 4610 Doc \# AL20T4 Effective date = 11/1/01

Debit 2170 Credit 2179 Doc \# AL20T4 Effective date = 11/1/01

Debit 4610 Credit 4902 Doc \# AL2CR7.2 Effective date = 11/5/01

Debit 6100 Credit 1031 Doc \# AL2CR7.2 Effective date = 11/5/01

The system posting date of the entries is determined by the options set
on the journal generator template.

#### B. Reason for Variance

The reason for this variance is that when moving committed/obligated
balances between purchasing/payable documents, there is the potential
that the increase/decrease to one of the documents is different than the
increase/decrease to the other document. A common example is when the
unit price of a purchased item differs between the requisition and
purchase order or between the purchase order and invoice. To ensure that
the correct impact is recorded to the 4610 or 4650 balance, each
document is individually offset by 4610 or 4650.

#### C. Benefit to the Government

The benefit to the government is that the allotment balance will be kept
in synch with any changes that are made to the predecessor or successor
documents in a document cycle.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

This variance applies to the entire test, Cycles 0 through 21. Here is a
list of scenarios that require a different posting model due to this
variance:

  -----------------------------------------------------------------------
  AC2.6

  AL2.9

  AO1.2

  AO1.4

  AO10.1

  AO3.3

  AO4.2

  AO5.5

  AO6.2

  AO8.2

  AO9.1

  AR1.1

  FS2.3

  PE1.3

  PE10.4

  PE11.3

  PE11.5

  PE12.3

  PE16.3

  PE17.2

  PE17.4

  PE17.5

  PE2.4

  PE20.11

  PE20.5

  PE20.7

  PE20.8

  PE20.9

  PE21.2

  PE22.2

  PE23.6

  PE26.2

  PE3.10

  PE3.5

  PE3.6

  PE4.2

  PE5.4

  PE5.5

  PE6.8

  PE6.9

  PE7.2

  PE7.4

  PE8.3

  PE8.4

  PE8.5

  PE8.7

  PE9.2

  PE9.3

  PE9.4

  PP2.1

  PT1.2

  PT2.2

  PT3.2

  RO3.6
  -----------------------------------------------------------------------

###  {#section .unnumbered}

### Reverse Receipt Entries upon Recording of Invoice

#### A. Description of Test Execution Variance

The Receipt entry process within PeopleSoft performs the accrual
accounting entries (DR/CR pairs) in accordance with the required entries
for each of the goods/services receipt scenarios. However, when the
related invoice(s) is posted, PeopleSoft performs additional entries
(one set to reverse out the accrual, one to reverse the order, and
another to post the actual expenditure accounting entries). Original and
changed invoices, both the purchase order obligation and the receiving
report expenditure are reversed for their original (or latest) amounts,
the invoice amount is posted, and the receiving report is re-posted for
the difference from the voucher, if any.

The purpose of variance 9 is to identify how the receipt accrual
transactions are posted and reversed when the actual invoice is
received. The purpose of variance 8 is to identify the overall posting
model that relates to commitments, obligations and voucher-related
expenditures. The difference between variances 8 and 9 is that in
variance 8, obligations are reversed for amount of the partial voucher
only, then voucher is posted; while under variance 9, the receipt is
reversed for full amount (and the obligation is reversed for the voucher
amount) and then it is re-posted for the difference (by which RR exceeds
VCH).

The combining of the B134 entry with the spending entry is covered by
variance #17.

When a partial invoice is received and matched, two transactions are
processed:

-   one entry to reverse out the entire original receipt accrual,

-   one set to re-accrue the partial amount not yet matched to an
    invoice.

When the partial invoice is received, the actual expenditure accounting
entries are posted.

PE4RR3 is an example of a partial invoice and is shown below.

Note: For each step detailed below, the first three DR/CR pairs in the
PeopleSoft expected results represent the actual expenditure accounting
entries, the next three accounting entries identify the reversal of the
accrued expenditure that occurred on the receiving report and the
seventh DR/CR pair represents the liquidation of the original
obligation.

The accounting entries that will occur at the time of invoice entry are
as follows:

  ------------------------------------------------------------------------------------------------------------------------------------
  Step           Doc\               Trans\             DR.\   Cr.\   Amt    Doc\         Trans\    DR.\          Cr.\   Amt   
                 Id                 Id                 Acct   Acct          Id           Id        Acct          Acct         
  -------------- -------- --------- ----------- ------ ------ ------ ------ ------------ --------- ------ ------ ------ ----- --------
  JFMIP Expected                                                            PeopleSoft                                        
  Results                                                                   Expected                                          
                                                                            Results                                           

  PE2.7          PE2VI5             PE2VI5.1           NA     NA     NA     NA           PE2VI5           4610   4901         5,330

                                                                                         PE2VI5           3107   5700         5,330

                                                                                         PE2VI5           6100   2110         5,330

                                                                                         PE2RR4           4901   4801         5,330

                                                                                         PE2RR4           2110   6100         5,330

                                                                                         PE2RR4           5700   3107         5,330

                                                                                         PE2OB3           4801   4610         5,330

  PE4.4          PE4VI4             PE4VI4.1           NA     NA     NA     NA           PE4VI4           4610   4901         61,000

                                                                                         PE4VI4           3107   5700         61,000

                                                                                         PE4VI4           6100   2110         61,000

  (The above                                                                                                                  
  transaction is                                                                                                              
  the actual                                                                                                                  
  expenditure                                                                                                                 
  transaction                                                                                                                 
  that occurs                                                                                                                 
  when the                                                                                                                    
  invoice is                                                                                                                  
  posted.)                                                                                                                    

                                                                                         PE4RR3           4901   4801         66,115

                                                                                         PE4RR3           2110   6100         66,115

                                                                                         PE4RR3           5700   3107         66,115

  (The above                                                                                                                  
  transaction is                                                                                                              
  the reversal                                                                                                                
  of the                                                                                                                      
  original                                                                                                                    
  receipt                                                                                                                     
  accrual                                                                                                                     
  transaction)                                                                                                                

                                                                                         PE4RR3           4801   4901         5,115

                                                                                         PE4RR3           6100   2110         5,115

                                                                                         PE4RR3           3107   5700         5,115

  (The above                                                                                                                  
  transaction is                                                                                                              
  the re-accrual                                                                                                              
  of the                                                                                                                      
  remaining                                                                                                                   
  un-matched                                                                                                                  
  portion of the                                                                                                              
  receiving                                                                                                                   
  report.)                                                                                                                    

                                                                                         PE4OB2           4801   4610         61,000

  PE4.5                   PE4VI5    PE4VI5.1    NA            NA     NA     NA           PE4VI5           4610   4901         5,115

                                                                                         PE4VI5           3107   5700         5,115

                                                                                         PE4VI5           6100   2110         5,115

                                                                                         PE4RR3           4901   4801         5,115

                                                                                         PE4RR3           2110   6100         5,115

                                                                                         PE4RR3           5700   3107         5,115

                                                                                         PE4OB2           4801   4610         5,115

  PE5.7                   PE5VI5    PE5VI5.1    NA            NA     NA     NA           PE5VI5           4610   4901         90,000

                                                                                         PE5VI5           3107   5700         90,000

                                                                                         PE5VI5           1750   2110         90,000

                                                                                         PE5RR4           4901   4801         90,000

                                                                                         PE5RR4           2110   1750         90,000

                                                                                         PE5RR4           5700   3107         90,000

                                                                                         PE5OB2           4801   4610         90,000

  PE15.8                  PE15VI3   PE15VI3.1   4610          4901   45     NA           PE15VI3          4610   4901         8.055

                                                1750          2110   45     NA           PE15VI3          1750   2110         8.055

                                                3170          5700   45     NA           PE15VI3          3107   5700         8.055

                                                                                         PE15RR2          4901   4801         8.010

                                                                                         PE15RR2          2110   1750         8.010

                                                                                         PE15RR2          5700   3107         8.010

                                                                                         PE15OB1          4801   4610         8,010

                                                                                                                              
  ------------------------------------------------------------------------------------------------------------------------------------

Note that this alternate posting model pertains to the recording of
invoices after the separate recording of the receipt of goods/services
(3-way match) for the amount of the invoice or invoice adjustment.
PeopleSoft's alternate posting model approved under TEVR #8 pertains to
the recording of invoices without a prior goods/services receipt entry
(2-way match).

#### B. Reason for Variance

The variance is simply additional audit trial accounting activity and
not a net variance to the desired results. It is important that receipt
accrual transactions have a mechanism to be adjusted if the actual
voucher amounts differ from receipt accrual transaction. This is
especially highlighted in the PE15 scenarios.

#### C. Benefit to the Government

The reversal of the receipt accrual and posting the actual at the time
of voucher provides a detailed audit trail (especially desirable when
the actuals differ from the accrued amount).

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

The general ledger postings for the test steps noted in Section B,
above, will differ. The net effect on the general ledger will be the
same.

### Use Unbilled Account Receivable Account When the Prepayment or Advance on a Reimbursable Agreement is Decreased by Recording Earned Income

#### A. Description of Test Execution Variance

The overall business process for recording a Reimbursable Agreement with
an advance is as follows:

-   Create a contract for the Reimbursable Agreement in the Contracts
    module.

-   The Billing module will generate a bill without any general ledger
    impact for the amount of the advance.

-   The processing of the bill can create an open item (or a receivable)
    in the Receivables module without any general ledger impact for the
    amount of the advance.

-   If the open item (or receivable) is created, the user will record a
    collection of the open item in the Receivables module with the SGL
    general ledger impact of the advance (ie DR 4222, CR 4210, DR 1030,
    CR 2310, DR 4590, CR 4610).

-   Record expenditures in the Payables module or other legacy systems
    that feed the Projects module.

-   The Projects and Contracts module processing analyzes expenses and
    contract agreements to bill or reduce the advanced amount based on
    the contract parameters. As project costs are accumulated, the
    Projects module will either decrease an existing advance or send a
    bill to the reimbursable customer to recover the project costs based
    on the terms of the contract.

When the prepayment or advance on a reimbursable agreement is decreased
by recording earned income, the Projects module generates an extra set
of DR/CR to the unbilled account receivable account. The unbilled
Accounts Receivable is required when setting up the Accounting Rules to
create revenue transactions from the Projects Module. The Standard
General Ledger does not include an account specifically for the purpose
of recording an unbilled accounts receivable balance. Therefore,
PeopleSoft will use the 1310 account to represent the unbilled accounts
receivable. The 1310 account will be debited and credited during the
same transaction, so there will be no net affect on the ending balance
of 1310 for cycle five.

<table>
<colgroup>
<col style="width: 7%" />
<col style="width: 0%" />
<col style="width: 11%" />
<col style="width: 8%" />
<col style="width: 7%" />
<col style="width: 0%" />
<col style="width: 9%" />
<col style="width: 10%" />
<col style="width: 13%" />
<col style="width: 8%" />
<col style="width: 0%" />
<col style="width: 9%" />
<col style="width: 13%" />
</colgroup>
<thead>
<tr class="header">
<th colspan="2">Step</th>
<th>Doc<br />
Id</th>
<th>DR.<br />
Acct</th>
<th colspan="2">Cr.<br />
Acct</th>
<th>Amt</th>
<th>Doc<br />
Id</th>
<th>Trans<br />
Id</th>
<th>DR.<br />
Acct</th>
<th colspan="2">Cr.<br />
Acct</th>
<th>Amt</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td colspan="7">JFMIP Expected Results</td>
<td colspan="6">PeopleSoft Expected Results</td>
</tr>
<tr class="even">
<td>RO2.4</td>
<td colspan="2">RO2OT4</td>
<td></td>
<td></td>
<td colspan="2"></td>
<td>RO2.4</td>
<td>CAPC000606</td>
<td colspan="2">4252</td>
<td></td>
<td>90000</td>
</tr>
<tr class="odd">
<td></td>
<td colspan="2"></td>
<td>4252</td>
<td></td>
<td colspan="2">90000</td>
<td></td>
<td></td>
<td colspan="2"></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td colspan="2"></td>
<td></td>
<td>4222</td>
<td colspan="2">90000</td>
<td></td>
<td></td>
<td colspan="2"></td>
<td>4222</td>
<td>90000</td>
</tr>
<tr class="odd">
<td></td>
<td colspan="2"></td>
<td>2310</td>
<td></td>
<td colspan="2">90000</td>
<td></td>
<td></td>
<td colspan="2">1310C1</td>
<td></td>
<td>90000</td>
</tr>
<tr class="even">
<td></td>
<td colspan="2"></td>
<td></td>
<td>5200</td>
<td colspan="2">90000</td>
<td></td>
<td></td>
<td colspan="2"></td>
<td>5200</td>
<td>90000</td>
</tr>
<tr class="odd">
<td></td>
<td colspan="2"></td>
<td></td>
<td></td>
<td colspan="2"></td>
<td></td>
<td>CADFR00655</td>
<td colspan="2">2310</td>
<td></td>
<td>90000</td>
</tr>
<tr class="even">
<td></td>
<td colspan="2"></td>
<td></td>
<td></td>
<td colspan="2"></td>
<td></td>
<td></td>
<td colspan="2"></td>
<td>1310C1</td>
<td>90000</td>
</tr>
<tr class="odd">
<td></td>
<td colspan="2"></td>
<td></td>
<td></td>
<td colspan="2"></td>
<td></td>
<td></td>
<td colspan="2"></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td colspan="2"></td>
<td></td>
<td></td>
<td colspan="2"></td>
<td></td>
<td></td>
<td colspan="2"></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>R03.10</td>
<td colspan="2">RO3NC11</td>
<td></td>
<td></td>
<td colspan="2"></td>
<td>RO3.10</td>
<td>CAPC000729</td>
<td colspan="2">4251</td>
<td></td>
<td>6346.15</td>
</tr>
<tr class="even">
<td></td>
<td colspan="2"></td>
<td>4252</td>
<td></td>
<td colspan="2">6346.15</td>
<td></td>
<td></td>
<td colspan="2"></td>
<td>4222</td>
<td>6346.15</td>
</tr>
<tr class="odd">
<td></td>
<td colspan="2"></td>
<td></td>
<td>4222</td>
<td colspan="2">6346.15</td>
<td></td>
<td></td>
<td colspan="2">1310C1</td>
<td></td>
<td>6346.15</td>
</tr>
<tr class="even">
<td></td>
<td colspan="2"></td>
<td>2310</td>
<td></td>
<td colspan="2">6346.15</td>
<td></td>
<td></td>
<td colspan="2"></td>
<td>5200</td>
<td>6346.15</td>
</tr>
<tr class="odd">
<td></td>
<td colspan="2"></td>
<td></td>
<td>5200</td>
<td colspan="2">6346.15</td>
<td>RO3.10</td>
<td>CADFR00728</td>
<td colspan="2">2310</td>
<td></td>
<td>6346.15</td>
</tr>
<tr class="even">
<td></td>
<td colspan="2"></td>
<td></td>
<td></td>
<td colspan="2"></td>
<td></td>
<td></td>
<td colspan="2"></td>
<td>1310C1</td>
<td>6346.15</td>
</tr>
<tr class="odd">
<td></td>
<td colspan="2"></td>
<td></td>
<td></td>
<td colspan="2"></td>
<td><h2 id="section-1" class="unnumbered"></h2></td>
<td><h2 id="section-2" class="unnumbered"></h2></td>
<td colspan="2"><h2 id="section-3" class="unnumbered"></h2></td>
<td><h2 id="section-4" class="unnumbered"></h2></td>
<td><h2 id="section-5" class="unnumbered"></h2></td>
</tr>
</tbody>
</table>

Logic to present the billed amount has been added to the Federal
Customer Statement and the Reimbursable Agreement Inquiry to calculate
the billed amount based on the contract billed amount. The billed amount
for the Federal Customer Statement and the Reimbursable Agreement
Inquiry is no longer dependent upon any general ledger configuration.

#### B. Reason for Variance {#b.-reason-for-variance-9 .unnumbered}

The reason for the use of the Unbilled AR account is based on the
accounting architecture of the PeopleSoft Projects module. The
accounting architecture within the Projects module is to DR---Advance,
CR---UnBilled AR, DR Unbilled AR and CR- Revenue whenever a charge
against a project is used decrease advance. When PeopleSoft translates
this Projects accounting architecture to use the SGL Accounts, it
translates to the following DR/CR pairs:

> DR 2310 (Advance)
>
> CR Unbilled AR (Unbilled AR)\*
>
> DR Unbilled AR (Unbilled AR)
>
> CR 5200 (Revenue)

DR 4251 or 4252 (Reimbursements and Other Income Earned -Earned or
Collected)

CR 4222 (Unfilled Customer Order with Advance)

The unbilled receivable account is debited and credited when the
application of an advance is performed by the Projects module. This is
part of the Projects accounting architecture that cannot be suppressed.
The SGL does not have an account specified for the purposes of recording
unbilled receivables, therefore PeopleSoft chose an account to debit and
credit, and therefore having a net zero impact on the JFMIP expected
results.

#### C. Benefit to the Government

The benefit to the government is that agencies can utilize the baseline
PeopleSoft software to process reimbursable agreements that have
advances and those which do not have advances.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

The changes are reflected in detail in the 'Expected Results' matrix
above.

### Use Accounts Payable Instead of Disbursement-in-Transit Account Instead for Late Payment Interest

#### A. Description of Test Execution Variance

The Payment Schedules generated in Cycle 6, PP2.1 - PP2.3 include a late
interest penalty applied against an invoice/voucher. The posting model
followed by JFMIP is slightly different than that of PeopleSoft. The
accounting entries of each model is shown below:

  --------------------------------------------------------------------------------------------------------------------------------------------------------
  Step                          Trans\   DR.\          Cr.\            Amt     Step                         Doc\     DR.\           Cr.\            Amt
                                Id       Acct          Acct                                                 Id       Acct           Acct            
  ------------------ ---------- -------- ------ ------ ------ -------- ------- ----------------- ---------- -------- ------- ------ ------ -------- ------
  JFMIP Expected                                                               PeopleSoft                                                           
  Results                                                                      Expected Results                                                     

  PP2.1                                                                        PP2.1                                                                

  PP2SP1.2           Voucher                    2110          40,000                             Voucher             2110                  40,111   

                                                2120          40,000                                                         2120          40,111   

  PP2SP1.2           Interest            4610                 111                                Interest            4610                  111      

                                                4901          111                                                            4901          111      

                                         6100                 111                                                    6100                  111      

                                                2120          111                                                            2120          111      

                                         3107                 111                                                    3107                  111      

                                                5700          111                                                            5700          111      

  Similar entries                                                              Similar entries                                                      
  for line 2 of                                                                for line 2 of                                                        
  invoice/voucher,                                                             invoice/voucher                                                      
  entries PP2SP1.5                                                             PE1VI3.                                                              
  and PP2SP1.6                                                                                                                                      

                                                                                                                                                    
  --------------------------------------------------------------------------------------------------------------------------------------------------------

#### B. Reason for Variance

This is a simple difference in posting model. The only difference in
posting model for the Disbursement in Transit account is use of 2120
account instead of 2110 account for interest. Interest flows through the
payable account as well as the disbursement in transit account in
PeopleSoft Payables because that is how the Payables accounting
architecture is designed.

#### C. Benefit to the Government

Satisfies financial/accounting requirements of the scenario with a
consistent, auditable accounting model.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

The individual general ledger postings in test step PP2.1 will be
different, but the net effect on the general ledger will be the same.

### Post Spending Entries by Line Item

#### A. Description of Test Execution Variance

Scenario PE2.2 asks us to record a commitment with multiple lines. The
provided expected result reflects a single debit/credit accounting entry
pair for total (summarized) commitment amount for each accounting
classification code. PeopleSoft has processed this transaction to
reflect the individual detail of each commitment line by configuring the
Journal Generator Template to retain the transaction detail during
posting. All subsequent entries in the spending chain (i.e.,
obligations, receipts and payments) are also posted by line item, as
shown below.

  -----------------------------------------------------------------------------------------------------------------------------------------------------
  Step       Trans\                  DR.\   Cr.\          Amt           Doc\                    Journal\       DR.\               Cr.\          Amt
             Id                      Acct   Acct                        ID                      Id             Acct               Acct          
  ---------- -------- -------------- ------ ------ ------ ----- ------- ------------ ---------- -------------- ----------- ------ ------ ------ -------
  JFMIP                                                                 PeopleSoft                                                              
  Expected                                                              Expected                                                                
  Results                                                               Results                                                                 

  PE2.2               Commitment                                                     PE2.2      Commitment                                      

                      PE2CM1.1       4610          4700         5350                 PE2CM1     REQ0000566     4610        4700                 350

                                                                                                               4610        4700                 1800

                                                                                                               4610        4700                 3000

                                                                                                               4610        4700                 200

  PE2.3               Commitment                                                     PE2.3      Commitment     See related                      
                      Increase                                                                  Increase       posting                          
                                                                                                               model                            
                                                                                                               variance                         
                                                                                                               #3.                              

                      PE2CM2.1       4610          4700         100                  PE2CM1     REQ0000567     4700        4610                 350

                                                                                                               4700        4610                 1800

                                                                                                               4700        4610                 3000

                                                                                                               4700        4610                 200

                                                                                                               4610        4700                 350

                                                                                                               4610        4700                 1900

                                                                                                               4610        4700                 3000

                                                                                                               4610        4700                 200

  PE2.4               Obligation                                                     PE2.4      Obligation     See related                      
                                                                                                               posting                          
                                                                                                               model                            
                                                                                                               variance                         
                                                                                                               #3.                              

                      PE2OB3.1       4700          4801         5,330                PE2CM1     REQLIQ0570     4700                      4610   350

                      PE2OB3.2       4700          4610         120                                            4700                      4610   1900

                                                                                                               4700                      4610   3000

                                                                                                               4700                      4610   200

                                                                                     PE2OB3     OBL0000569     4610                      4801   350

                                                                                                               4610                      4801   1900

                                                                                                               4610                      4801   2880

                                                                                                               4610                      4801   200

  PE2.5               Receipt                                                        PE2.5      Receipt                                         

                      PE2RR4.1       4801          4901         5330                 PE2RR4     REC0000583     4801                      4901   350

                                     6100          2110         5330                                           6100                      2110   350

                                                                                                               3107                      5700   350

                      PE2RR4.2       3107          5700         5330                                           4801                      4901   1900

                                                                                                               6100                      2110   1900

                                                                                                               3107                      5700   1900

                                                                                                               4801                      4901   2880

                                                                                                               6100                      2110   2880

                                                                                                               3107                      5700   2880

                                                                                                               4801                      4901   200

                                                                                                               6100                      2110   200

                                                                                                               3107                      5700   200

  PE2.7               Invoice                                                        PE2.7      Invoice        See related                      
                                                                                                               posting                          
                                                                                                               model                            
                                                                                                               variances                        
                                                                                                               #6 and #32.                      

                      PE2VI5.1       N/A           N/A          N/A                  PE2OB3     OBLLIQ0629     4801               4610          350

                                                                                                               4801               4610          1900

                                                                                                               4801               4610          2880

                                                                                                               4801               4610          200

                                                                                     PE2VI5.1   VCH0000627     4610               4901          350

                                                                                                               6100               2110          350

                                                                                                               3107               5700          350

                                                                                     PE2VI5.2   VCH0000627     4610               4901          1900

                                                                                                               6100               2110          1900

                                                                                                               3107               5700          1900

                                                                                     PE2VI5.2   VCH0000627     4610               4901          2880

                                                                                                               6100               2110          2880

                                                                                                               3107               5700          2880

                                                                                     PE2VI5.2   VCH0000627     4610               4901          350

                                                                                                               6100               2110          350

                                                                                                               3107               5700          350

                                                                                                                                                

  PP1.2               Payment                                                        PP1.2      Payment                                         

                      PP1SP1.1       2110          2120         350                  PE2VI5.1   AP_PMT0631     2110               2120          350

                                                                                                                                                

  PP1.3               Confirmation                                                   PP1.3      Confirmation                                    

                      PP1CD2.1       4901          4902         350                  PE2VI5.1   AP00000662     4901               4902          350

                                     2120          1021         350                                            2120               1021          350

  PP2.1               Payment                                                        PP2.1      Payment                                         

                      PP2SP1.1       2110          2120         4980                 PE2VI5.2   AP_PMT0674     2110               2120          1900

                                                                                                               2110               2120          2880

                                                                                                               2110               2120          200

  PP2.2               Confirmation                                                   PP2.2      Confirmation                                    

                      PP2CD2.1       4901          4902         4980                 PE2VI5.2   AP00000678     4901               4902          1900

                                     2120          1021         4980                                           2120               1021          1900

                                                                                                               4901               4902          2880

                                                                                                               2120               1021          2880

                                                                                                               4901               4902          200

                                                                                                               2120               1021          200

                                                                                                                                                
  -----------------------------------------------------------------------------------------------------------------------------------------------------

#### B. Reason for Variance

PeopleSoft is capable of processing the posting spending data at
multiple levels of summarization by Chartfield (i.e., accounting
classification element) values. Specifically, the Journal Generator
Template defines the level at which the Journal Generator process will
post activity into the General Ledger. To maintain the detail associated
with each Entry Event code, we have chosen to process the posting of
data to retain the specific detail of each document line, without any
summarization.

#### C. Benefit to the Government

The flexibility allowed in how PeopleSoft can be configured for posting
will allow each client to tailor this process to their specific data
audit ability needs. Some agencies may chose to maintain the most
detailed level of data during posting to facilitate a more comprehensive
document review and posting approval process, or a line for line
reconciliation between a commitment document and its posted results.
Other agencies may only be concerned about specific fund, account, or
departmental impact and as a result may chose to summarize at a higher
level of Chartfield values.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

See section A for the changes to the test materials.

### Run Credit Memo Offset Entries through the Disbursement-in-Transit Account

#### A. Description of Test Execution Variance

During PP2.1, Create Treasury Schedule, a credit memo (document PE3VI5)
is applied against an invoice (PE3VI6). The accounting applied by
PeopleSoft for the invoice follows our standard, systematic accounting
model by clearing thru the 2120 account. For invoices that are offset by
a credit memo, we also release/apply the 'cash clearing' entries
(equivalent to the Schedule Confirmation entries) at the time of the
Payment Schedule. The net result is the same for both models:

  ------------------------------------------------------------------------------------------------------------------------------------------------
  Step          Trans\   DR.\                 Cr.\   Amt     Step                             Doc\     DR.\                  Cr.\           Amt
                Id       Acct                 Acct                                            Id       Acct                  Acct           
  ---------- -- -------- ------ ------ ------ ------ ------- ------------ ---------- -------- -------- ------ ------- ------ ------ ------- ------
  JFMIP                                                      PeopleSoft                                                                     
  Expected                                                   Expected                                                                       
  Results                                                    Results                                                                        

  PP2.1                                                                   PP2.1                                                             

  PP2SP1.8                      2110                 5,000                Document   PE3VI6                   2110                  5,000   

                                       1021          5,000                                                            2120          5,000   

                                4901                 5,000                                                    2120                  5,000   

                                       4902          5,000                                                            1021          5,000   

                                                                                                              4901                  5,000   

                                                                                                                      4902          5,000   

                                                                                                                                            
  ------------------------------------------------------------------------------------------------------------------------------------------------

This variance only impacts document PE3VI6, processed in paycycle
PP2.1 - PP2.3

#### B. Reason for Variance

This is a simple difference in posting model.

#### C. Benefit to the Government

Satisfies financial/accounting requirements.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

See Section A for difference in General Ledger postings in test step
PP2.1. Net effect is zero.

### Post Advances and Prepayments Against an Expenditure Voucher for the Entire Amount of the Expense, Not 'Net' of Advance

#### A. Description of Test Execution Variance

For applying advances and prepayments against an expenditure voucher,
the posting model followed by PeopleSoft is different from the posting
by JFMIP. PeopleSoft processes the expense voucher for the entire amount
of the expense, not 'net' of advance. This is only a mechanical
difference in the posting model, and does not result in any 'timing' or
account balance deviations.

The transaction series PT1 is depicted in Exhibit A at the bottom of
this document. The same model is used on all advance/prepay scenarios in
the test:

> PT1
>
> PT2
>
> AO4
>
> PE23
>
> PE20
>
> PT4 (no entries generated)
>
> PE16

The only differences relate to the amounts used in the transactions and
specific accounts used in the scenarios (for example, some use the 1410
account, others the 1450 account, or varying liability accounts such as
2110 or 2130). See Exhibit A, below, for the specific differences in the
posting models.

#### B. Reason for Variance

The reason for this variance is to utilize the delivered PeopleSoft
posting logic without making expensive changes to the software when the
net desired result is the same.

#### C. Benefit to the Government

This processing satisfies the functional and financial objectives of the
test steps with a consistent, flexible posting model for these
transactions.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

This is only a mechanical difference in the posting model, and does not
result in any 'timing' or account balance deviations.

Exhibit A follows:

![](media/image2.wmf)

The dr/cr pairs on the left represent the JFMIP dr/cr pairs, and the
dr/cr pairs on the right represent the PeopleSoft dr/cr pairs.

### Roll-Back Funding to the Highest Level of the Budget Execution and Restore It Back to a Lower Organization Level, Where Not Done in Test Script

#### A. Description of Test Execution Variance

##### Consistent Approach to Budget Journal Structure

JFMIP's script typically rolls-back the full budget execution cycle to
one level of the organization and restores it back to a lower level to
yield a valid budgetary/proprietary account equation at each level of
the organization structure. There are a few scenarios where JFMIP moves
funds directly to a lower level of the organization structure without
establishing budgets at higher levels of the organization structure.
PeopleSoft's approach to JFMIP's scenarios in these limited cases
involves posting additional budget-only journals to update the parent
budgets with the budget being established at a lower level of the budget
hierarchy.

PeopleSoft controls budgets by individual Project, Program,
Organization, Fund and by every other financial classification element
within the system. Further, for any of these classification elements,
PeopleSoft supports translations of detail values to hierarchical
levels---for example, ITSA's organizational structure. Per Appendix A,
JFMIP requires control at each level or the organizational structure. To
support this, PeopleSoft establishes and maintains budgets at each of
these levels. JFMIP's scenarios generally move funds down to a lower
level by backing out budget execution transactions and reentering these
transactions to the lower level. PeopleSoft follows this script exactly,
backing budget out at the current level of the organization structure
and reestablishing budget at the lower level, updating both budget and
general ledgers. JFMIP consistently moves budget from one level to the
other by backing out the budget and then moving it down to the next
level. There are a few scenarios where JFMIP moves funds directly to a
lower level of the organization structure without establishing budgets
at higher levels of the organization structure. This would cause budget
ledgers that support lower levels of the organization structure to
exceed the budget ledgers at a higher level. To support controlling
budgets in a hierarchical fashion, simultaneously controlling at each
level of the organization structure, and to *not* allow children budgets
to exceed their parents (an additional optional control within
PeopleSoft), PeopleSoft's approach to JFMIP's scenarios in these limited
cases involves posting additional budget-only journals to update the
parent budgets with the budget being established at a lower level of the
budget hierarchy. These budget-only journals can be posted individually
or via one of two automated approaches---(1) budget journal import, (2)
allocations. For the test, the budget journal import has been used to
load these budget-only journals. An example is the suballotment directly
to the Division level in Cycle 19. Here there is no step to update the
Directorate budget. Though PeopleSoft could configure their system to
allow this direct suballotment to the Division budget, via the
parent-child control setting, PeopleSoft takes the additional step of
updating the Directorate budget so that true hierarchical budgetary
control is supported even within the multiple levels of suballotments.
The Directorate budget update is performed without impacting the
accounting results in any way and at the same time maintains the
correlation between the budget ledgers and general ledger at each level
of the organizational structure.

#### B. Reason for Variance

The reason for this variance is to keep the funds control structure
consistent throughout the posting of all budget journals. While
PeopleSoft allows child ledgers to exceed parent ledgers, based on
budget definition configuration, PeopleSoft has not configured the
budget definitions to allow this so that the intent of the Appendix A
budget hierarchy is met. This is the approach that PeopleSoft has taken
to best meet the scenario expected results and to also meet the broader
federal funds control needs of the ITSA organization.

#### C. Benefit to the Government

Agencies are required to manage the SGL budgetary/proprietary equation
at the TAS level. Where an Agency manages this reconciliation at the TAS
level, PeopleSoft's translations enable simultaneous control at each
level of the organization and there would then be no need to backout and
repost the same set of transactions at each level of the organization
structure and this variance would not be applicable.

However, where an Agency manages the SGL budgetary/proprietary equation
below the TAS level, as does ITSA, PeopleSoft supports this detailed
level of reconciliation. PeopleSoft maintains budget control to support
the multi-level hierarchical budget per Appendix A. At the same time,
PeopleSoft supports maintaining the full budget execution cycle within
their general ledger at lower levels of the organization. Due to the
flexibility of PeopleSoft's funds control solution---"Commitment
Control", PeopleSoft is able to maintain this level of detail in both
its general ledger and its budget ledgers. This enables budget users and
financial analysts to access, view, and report within the PeopleSoft
module of their choice. Since PeopleSoft is a process-oriented system,
this enables budget users to access this data within the Commitment
Control module and allows general ledger users to access this data
within the General Ledger module. It is important to note here, that
PeopleSoft's budget ledgers offer translations of classification
elements to pre-defined levels for budgetary control. This allows, for
example, simultaneous control at each of the Agency, Bureau,
Directorate, Division, and Branch levels.

PeopleSoft's approach therefore supports true hierarchical controls at
each level of the organization, combined with enhanced access to data
from both the general ledger and budget user perspective.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

No changes are needed to the test materials as all accounting events are
processed exactly per the expected results. JFMIP will note processing
of additional budget-only journals (i.e., no general ledger journal
entries) posted for the following scenarios:

Cycle 9.1, TD1.2, TD5.1---to flow funding through organization 10000 as
part of the apportionment to organization 14000.

Cycle 19 FM1.18, FM1.19, FM1.20, FM1.21, FM1.22, FM1.23---to flow
funding through organization 13200 as part of the sub-allotments to
subordinate organizations.

### Generate Fiscal Year-End Entries to Close General Ledger Accounts Based on the Combinations of Accounting Classification Elements (Chartfields)

#### A. Description of Test Execution Variance

PeopleSoft requests a variance for the level of detail used to record
year-end closing entries. PeopleSoft generates year-end closing
transactions to close out revenue, expense, and other accounts based on
the combination of accounting classification elements (chartfields)
stored in the ledger. In some cases, this process generated additional
postings not expected by JFMIP. (An example of test step AY6.1 is
provided later in this document to demonstrate how PeopleSoft's approach
can vary from JFMIP). In other cases, PeopleSoft's year-end closing
process produced fewer entries than JFMIP expected results. Those
accounts that are closed into and remain on the books after the closing
process, such as the 3310 account, are summarized to a level of the
classification structure, as defined in the year-end closing rule.
PeopleSoft's year-end process nets closing activity to this summarized
level. This netting process generates, in some cases, fewer entries than
provided in JFMIP's expected results. Detailed examples that had a net
zero impact on the 3310 account are provided at the end of this
document.

Scenario AY6.1 asks PeopleSoft to record the year-end closing entries.
The execution script reflects closing entries delineated by the
following accounting classification structure elements: Fund Group,
Fiscal Year, and Organization. In order to automate the year-end
process, it is essential that the closing process be configured to
accommodate more accounting classification structure elements in the
closing calculations. One such accounting classification structure
element, which is critical, is the budget reference chartfield. This
chartfield is used to track the program year that is very critical for
the federal accounting of apportionments. PeopleSoft stores ledger
balances using the details in all chartfields, and the year-end-close
process is performed accordingly.

PeopleSoft establishes Budget Reference (program year) during budget
processing when the apportionment is recorded, but it does not apply to
the appropriation. No appropriation level transactions posted to the GL
will include a budget reference, while lower level transactions do
include budget references.

Since account 4450 is used when recording appropriations and
apportionments, General Ledger tracks distinct balances with and without
budget references. When the year-end-close process is run, each of those
distinct balances adheres to the closing rule for 4450, with a net
result of \$0.00.

The closing transactions for one particular budget are provided in this
variance as an example of how the PeopleSoft approach can vary from the
JFMIP approach.

Example for Test Step AY6.1

Fund Group: 0100DA

Fiscal Year: 2002

Organization: 13222

  -------------------------------------------------------------------------------------------------------------------------
  Step       Doc\         DR.\      Cr.\      Amt           Step         Doc\     Other\        DR.\   Cr.\   Amt
             Id           Acct      Acct                                 Id       Chartfield    Acct   Acct   
  ---------- ------------ --------- --------- ------------- ------------ -------- ------------- ------ ------ -------------
  JFMIP                                                     PeopleSoft                                        
  Expected                                                  Expected                                          
  Results                                                   Results                                           

  AY6.1      AY6OP1.103   4650.01             \$1,356,356   AY6.1        AY6OP1                 4650          \$1,356,356

                                    4610.01   \$1,356,356                         Budget        4610          \$3,000,000
                                                                                  Reference -                 
                                                                                  B2002                       

                                                                                  Object               4610   \$4,123,456
                                                                                  Class - 1110                

                                                                                  Object               4610   \$232,900
                                                                                  Class - 1210                

                                                                                  Budget        4450          \$3,000,000
                                                                                  Reference -                 
                                                                                  B2002                       

                                                                                  Budget               4450   \$3,000,000
                                                                                  Reference-                  
                                                                                  none                        

                                                                                                              
  -------------------------------------------------------------------------------------------------------------------------

Consistent with JFMIP Execution Script and Expected Results:

> Account 4450 closes directly to Account 4650
>
> Account 4510 closes directly to Account 4650
>
> Account 4119 closes directly to Account 4201

### Combine the SGL B134 Appropriation Used Entry into One Transaction, with the Related Expenditure Entry, in Non-Reimbursable Funds

#### A. Description of Test Execution Variance

PeopleSoft processes all voucher debit/credit transactions required by
the SGL with one entry event or transaction code. The SGL B134
appropriation used entry is being combined into one transaction with the
related expenditure entry, in non-reimbursable funds, throughout the
test. For example, the SGL B302 and B134 payment voucher transactions
that pertain to non-reimbursable funds (i.e., direct appropriations) are
defined by one entry event code in PeopleSoft to generate the three
applicable USSGL debit credit pair accounting entries. One entry event
code will generate all six accounts when vouchers are posted, as shown
below for Document ID AC2AE3.

The net result is the same between the JFMIP method and the PeopleSoft
method.

  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  Step                  Doc\        Trans\          DR.\   Cr.\                Amt    Doc\                               Trans\           DR.\          Cr.\         Amt   
                        Id          Id              Acct   Acct                       Id                                 Id               Acct          Acct               
  ---------- ---------- ------- --- -------- ------ ------ ------ ------ ----- ------ ------------ -------- ------------ --------- ------ ------ ------ ------ ----- ----- --
  JFMIP                                                                               PeopleSoft                                                                           
  Expected                                                                            Expected                                                                             
  Results                                                                             Results                                                                              

  AC2.6      AC2AE3.1           1            4801                        499                       AC2OB1   OBLLIQ0869             4801                        499         

  AC2.6      AC2AE3.1           2                                 4901   499                       AC2OB1   OBLLIQ0869                           4610          499         

  AC2.6      AC2AE3.1           3            6100                        499                       AC2AE3   VCH0000868             6100                        499         

  AC2.6      AC2AE3.1           4                                 2100   499                       AC2AE3   VCH0000868                           2110          499         

  AC2.6      AC2AE3.2           1            3107                        499                       AC2AE3   VCH0000868             4610                        499         

  AC2.6      AC2AE3.2           2                                 5700   499                       AC2AE3   VCH0000868                           4901          499         

                                                                                                   AC2AE3   VCH0000868             3107                        499         

                                                                                                                                                                           
  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The reversal of the obligation (OBLLIQ0869 entry, above) is covered by
the posting model approved under variance #8.

#### B. Reason for Variance

The reason for this variance is that one entry event code generates all
of the appropriate USSGL accounting entries at voucher post.

#### C. Benefit to the Government

The benefit to the government is that one entry event code creates three
debit credit pairs for a non-reimbursable voucher and that the user does
not need to know to enter two different entry event codes to generate
the required SGL debit credit pairs.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

For all non-reimbursable vouchers throughout the entire test, Cycles 0
through 21, the B134 appropriations used entry will be combined with the
spending entry.

### Use Alternate Posting Model for Upward and Downward Spending Adjustment Entries

#### A. Description of Test Execution Variance

The PeopleSoft Entry Event accommodates the processing of payables
transactions and their related upward or downward adjustment. The entry
event has two steps that store the appropriate debit credit pairs to
process an expenditure that has a related upward or downward adjustment.
The entry event steps represent expenditure accrual dr/cr pairs and
either the upward or downward adjustment dr/cr pairs. In the case of an
upward or downward adjustment, the system figures out two things: 1) is
the transaction an upward or a downward adjustment and 2) what is the
amount of the upward or downward adjustment. This way the user only has
to enter the amount of the voucher, and the system figures out the
spending adjustment analysis.

This variance applies to test steps in various AO test cases, as
specified in section D, below.

#### B. Reason for Variance

The reason for this variance is to utilize the delivered COTS upward and
downward adjustment functionality.

#### C. Benefit to the Government

The end-user does not need to be concerned with which transaction code
is being input on the original transaction. They do not need to
determine if the transaction is prior year, whether it was paid/unpaid,
expended/unexpended, etc to generate the correct accounting entries. The
Prior Year Adjustment Process is seamless to the end-user and produces
the correct accounting results. Although it produces some additional
entries, these entries net to zero. These additional entries are fully
auditable and reference the original document.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

The expected results will differ as follows:

<table style="width:100%;">
<colgroup>
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 10%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 10%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 14%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 14%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 17%" />
<col style="width: 0%" />
<col style="width: 13%" />
<col style="width: 0%" />
<col style="width: 16%" />
</colgroup>
<thead>
<tr class="header">
<th colspan="3"></th>
<th colspan="5"></th>
<th colspan="6" rowspan="2"></th>
<th colspan="8">JFMIP Expected Results</th>
<th colspan="5">PeopleSoft Expected Results</th>
</tr>
<tr class="odd">
<th colspan="3"></th>
<th colspan="5">Test Step</th>
<th colspan="4">Debit Accounts/<br />
Amounts</th>
<th colspan="4">Credit Accounts/<br />
Amounts</th>
<th colspan="2">Transaction<br />
ID’s AP</th>
<th colspan="2">Debit Accounts/<br />
Amounts</th>
<th>Credit Accounts/<br />
Amounts</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5">AO1.4—Upward Adj. For $37</td>
<td colspan="6">AO1VI2.3</td>
<td colspan="4"><p>4650.01</p>
<p>$37.00</p></td>
<td colspan="4"><p>4981.01</p>
<p>$37.00</p></td>
<td colspan="2"><p>AP—AO1VI2, line1</p>
<p>GL—VCH820</p>
<p>Prior Year Accrual</p></td>
<td colspan="2"><p>4650</p>
<p>$769.00</p></td>
<td><p>4901</p>
<p>$769.00</p></td>
</tr>
<tr class="even">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6"><p>AO1VI2.1</p>
<p>PE12OB3.1</p></td>
<td colspan="5"><p>4801.01</p>
<p>$750.00</p></td>
<td colspan="4"><p>4901.01</p>
<p>$750.00</p></td>
<td colspan="2"><p>AP—AO1VI2, line2</p>
<p>GL—VCH820</p>
<p>Prior Year Accrual</p></td>
<td colspan="2"><p>4650</p>
<p>$768.00</p></td>
<td><p>4901</p>
<p>$768.00</p></td>
</tr>
<tr class="odd">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6"><p>AO1VI2.2</p>
<p>PE12OB4.1</p></td>
<td colspan="5"><p>4801.01</p>
<p>$750.00</p></td>
<td colspan="4"><p>4901.01</p>
<p>$750.00</p></td>
<td colspan="2"><p>PO—0000000016</p>
<p>GL—OBLLIQ821</p>
<p>Obligation liquidation</p></td>
<td colspan="2"><p>4801</p>
<p>$750.00</p></td>
<td><p>4650</p>
<p>$750.00</p></td>
</tr>
<tr class="even">
<td></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="5"></td>
<td colspan="3"></td>
<td colspan="4"><p>PO—0000000017</p>
<p>GL—OBLLIQ822</p>
<p>Obligation liquidation</p></td>
<td colspan="2"><p>4801</p>
<p>$750.00</p></td>
<td><p>4650</p>
<p>$750.00</p></td>
</tr>
<tr class="odd">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="5"></td>
<td colspan="4"></td>
<td colspan="2"><p>AP—AO1VI2, line1</p>
<p>GL—VCH820 PY Spending Adjust.</p></td>
<td colspan="2"><p>4901</p>
<p>$18.00</p></td>
<td><p>4981</p>
<p>$18.00</p></td>
</tr>
<tr class="even">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="5"></td>
<td colspan="4"></td>
<td colspan="2"><p>AP—AO1VI2, line2</p>
<p>GL—VCH820 PY Spending Adjust.</p></td>
<td colspan="2"><p>4901</p>
<p>$19.00</p></td>
<td><p>4981</p>
<p>$19.00</p></td>
</tr>
<tr class="odd">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6"><p>AO1VI2.1</p>
<p>PE12OB3.1</p></td>
<td colspan="5"><p>6100.01</p>
<p>$750.00</p></td>
<td colspan="4"><p>2110.01</p>
<p>$750.00</p></td>
<td colspan="2"><p>AP—AO1VI2, line1</p>
<p>GL—VCH820 Prior Year Accrual</p></td>
<td colspan="2"><p>6100</p>
<p>$769.00</p></td>
<td><p>2110</p>
<p>$769.00</p></td>
</tr>
<tr class="even">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6"><p>AO1VI2.2</p>
<p>PE12OB4.1</p></td>
<td colspan="5"><p>6100.01</p>
<p>$750.00</p></td>
<td colspan="4"><p>2110.01</p>
<p>$750.00</p></td>
<td colspan="2"><p>AP—AO1VI2, line2</p>
<p>GL—VCH820 Prior Year Accrual</p></td>
<td colspan="2"><p>6100</p>
<p>$768.00</p></td>
<td><p>2110</p>
<p>$768.00</p></td>
</tr>
<tr class="odd">
<td></td>
<td colspan="5"></td>
<td colspan="6">AO1VI2.3</td>
<td colspan="5"><p>6100.01</p>
<p>$37.00</p></td>
<td colspan="3"><p>2110.01</p>
<p>$37.00</p></td>
<td colspan="4"></td>
<td colspan="2"></td>
<td></td>
</tr>
<tr class="even">
<td colspan="4"></td>
<td colspan="6">AO1VI2.4</td>
<td colspan="5"><p>3107.01</p>
<p>$1,537.00</p></td>
<td colspan="4"><p>5700.01</p>
<p>$1,537.00</p></td>
<td colspan="4"><p>AP—AO1VI2, line1</p>
<p>GL—VCH820</p>
<p>Prior Year Accrual</p></td>
<td colspan="2"><p>3107</p>
<p>$769.00</p></td>
<td colspan="2"><p>5700</p>
<p>$769.00</p></td>
</tr>
<tr class="odd">
<td colspan="4"></td>
<td colspan="6"></td>
<td colspan="5"></td>
<td colspan="4"></td>
<td colspan="4"><p>AP—AO1VI2, line2</p>
<p>GL—VCH820 Prior Year Accrual</p></td>
<td colspan="2"><p>3107</p>
<p>$768.00</p></td>
<td colspan="2"><p>5700</p>
<p>$768.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5">AO2.2—Upward Adj. For $11</td>
<td colspan="6">AO2NC2.1</td>
<td colspan="4"><p>4650.01</p>
<p>$11.00</p></td>
<td colspan="4"><p>4982.01</p>
<p>$11.00</p></td>
<td colspan="2"><p>AP—AO2NC2</p>
<p>GL—VCH807</p>
<p>Prior Year Accrual</p></td>
<td colspan="2"><p>4650</p>
<p>$11.00</p></td>
<td><p>4902</p>
<p>$11.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2"><p>AP—AO2NC2</p>
<p>GL—VCH807</p>
<p>PY Spending Adjust</p></td>
<td colspan="2"><p>4902</p>
<p>$11.00</p></td>
<td><p>4982</p>
<p>$11.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO2NC2.1</td>
<td colspan="4"><p>6100.01</p>
<p>$11.00</p></td>
<td colspan="4"><p>1010.01</p>
<p>$11.00</p></td>
<td colspan="2"><p>AP—AO2NC2</p>
<p>GL—VCH807</p>
<p>Prior Year Accrual</p></td>
<td colspan="2"><p>6100</p>
<p>$11.00</p></td>
<td><p>1010</p>
<p>$11.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO2NC2.2</td>
<td colspan="4"><p>3107.01</p>
<p>$11.00</p></td>
<td colspan="4"><p>5700.01</p>
<p>$11.00</p></td>
<td colspan="2"><p>AP—AO2NC2</p>
<p>GL—VCH807</p>
<p>Prior Year Accrual</p></td>
<td colspan="2"><p>3107</p>
<p>$11.00</p></td>
<td><p>5700</p>
<p>$11.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5">AO3.3—Downward Adj. For $3475</td>
<td colspan="6">AO3NC1.1</td>
<td colspan="4"><p>4801.01</p>
<p>$6,525.00</p></td>
<td colspan="4"><p>4902.01</p>
<p>$6,525.00</p></td>
<td colspan="2"><p>AP—AO3NC1</p>
<p>GL—AP_PMT833 PY Spending Adjust</p></td>
<td colspan="2"><p>4871</p>
<p>$3,475.00</p></td>
<td><p>4801</p>
<p>$3,475.00</p></td>
</tr>
<tr class="odd">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6">AO3NC1.1</td>
<td colspan="5"><p>4871.01</p>
<p>$3,475.00</p></td>
<td colspan="4"><p>4650.01</p>
<p>$3,475.00</p></td>
<td colspan="2"><p>AP—AO3NC1</p>
<p>GL—AP_PMT833 Prior Year Accrual</p></td>
<td colspan="2"><p>4650</p>
<p>$6,525.00</p></td>
<td><p>4902</p>
<p>$6,525.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2"><p>AP—AO3NC1</p>
<p>PO—AO3OB1</p>
<p>GL—OBLLIQ832 Obligation Liquid.</p></td>
<td colspan="2"><p>4801</p>
<p>$10,000.00</p></td>
<td><p>4650</p>
<p>$10,000.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO3NC1.1</td>
<td colspan="4"><p>6100.01</p>
<p>$6,525.00</p></td>
<td colspan="4"><p>1010.01</p>
<p>$6,525.00</p></td>
<td colspan="2"><p>AP—AO3NC1</p>
<p>GL—AP_PMT833 Prior Year Accrual</p></td>
<td colspan="2"><p>6100</p>
<p>$6,525.00</p></td>
<td><p>1010</p>
<p>$6,525.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO3NC1.2</td>
<td colspan="4"><p>3107.01</p>
<p>$6,525.00</p></td>
<td colspan="4"><p>5700.01</p>
<p>$6,525.00</p></td>
<td colspan="2"><p>AP—AO3NC1</p>
<p>GL—AP_PMT833 Prior Year Accrual</p></td>
<td colspan="2"><p>3107</p>
<p>$6,525.00</p></td>
<td><p>5700</p>
<p>$6,525.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5">AO4.5—Downward Adj. For $300</td>
<td colspan="6">AO4CR1.1</td>
<td colspan="4"><p>4802.01</p>
<p>$2,425.00</p></td>
<td colspan="4"><p>4902.01</p>
<p>$2,425.00</p></td>
<td colspan="2"><p>AP—AO4CR1</p>
<p>GL—VCH784 Prior Year Accrual</p></td>
<td colspan="2"><p>4650</p>
<p>$2,425.00</p></td>
<td><p>4902</p>
<p>$2,425.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO4CR1.2</td>
<td colspan="4"><p>4872.01</p>
<p>$300.00</p></td>
<td colspan="4"><p>4650.01</p>
<p>$300.00</p></td>
<td colspan="2"><p>AP—AO4CR1</p>
<p>GL—VCH874—PY Spending Adjust.</p></td>
<td colspan="2"><p>4872</p>
<p>$300.00</p></td>
<td><p>4801</p>
<p>$300.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2"><p>PO—AO4OB1</p>
<p>GL—OBLLIQ785</p>
<p>Obligation Liquid.</p></td>
<td colspan="2"><p>4801</p>
<p>$2,725.00</p></td>
<td><p>4650</p>
<p>$2,725.00</p></td>
</tr>
<tr class="even">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6">AO4CR1.1</td>
<td colspan="5"><p>6100.01</p>
<p>$2,425.00</p></td>
<td colspan="4"><p>1410.01</p>
<p>$2,425.00</p></td>
<td colspan="2"><p>AP—AO4CR1</p>
<p>GL—VCH784 Prior Year Accrual</p></td>
<td colspan="2"><p>6100.01</p>
<p>$2,425.00</p></td>
<td><p>1410.01</p>
<p>$2,425.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO4CR1.2</td>
<td colspan="4"><p>1010.01</p>
<p>$300.00</p></td>
<td colspan="4"><p>1410.01</p>
<p>$300.00</p></td>
<td colspan="2"><p>AP—AO4CR1</p>
<p>GL—VCH874—PY Spending Adjust.</p></td>
<td colspan="2"><p>1010.01</p>
<p>$300.00</p></td>
<td><p>1410.01</p>
<p>$300.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO4CR1.3</td>
<td colspan="4"><p>3107.01</p>
<p>$2,425.00</p></td>
<td colspan="4"><p>5700.01</p>
<p>$2,425.00</p></td>
<td colspan="2"><p>AP—AO4CR1</p>
<p>GL—VCH784 Prior Year Accrual</p></td>
<td colspan="2"><p>3107.01</p>
<p>$2,425.00</p></td>
<td><p>5700.01</p>
<p>$2,425.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2"><p>AP—AO4CR1</p>
<p>GL—VCH784 Prior Year Accrual</p>
<p>(This entry created in error due to improper Entry Event setup. Since
both accounts are 4801 and offset each other, no adjusting entry was
necessary).</p></td>
<td colspan="2"><p>4801</p>
<p>$300.00</p></td>
<td><p>4801</p>
<p>$300.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5">AO5.3—Downward Adj. For $3</td>
<td colspan="6">AO5VI3.1</td>
<td colspan="4"><p>4971.01</p>
<p>$3.00</p></td>
<td colspan="4"><p>4450.01</p>
<p>$3.00</p></td>
<td colspan="2"><p>AP—AO5VI3</p>
<p>GL—VCH812 PY Spending Adjust.</p></td>
<td colspan="2"><p>4971</p>
<p>$3.00</p></td>
<td><p>4450</p>
<p>$3.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO5VI3.1</td>
<td colspan="4"><p>2110.01</p>
<p>$3.00</p></td>
<td colspan="4"><p>6100.01</p>
<p>$3.00</p></td>
<td colspan="2"><p>***AP—AO5VI3</p>
<p>GL—VCH812 PY Spending Adjust.</p></td>
<td colspan="2"><p>4610</p>
<p>$3.00</p></td>
<td><p>4901</p>
<p>$3.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO5VI3.2</td>
<td colspan="4"><p>5700.01</p>
<p>$3.00</p></td>
<td colspan="4"><p>3107.01</p>
<p>$3.00</p></td>
<td colspan="2"><p>AP—AO5VI3</p>
<p>GL—VCH812</p>
<p>Prior Year Accrual—Unexpired</p></td>
<td colspan="2"><p>4610</p>
<p>$210.00</p></td>
<td><p>4901</p>
<p>$210.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2"><p>AP—AO5VI3</p>
<p>GL—VCH812</p>
<p>Prior Year Accrual—Unexpired</p></td>
<td colspan="2"><p>6100</p>
<p>$210.00</p></td>
<td><p>2110</p>
<p>$210.00</p></td>
</tr>
<tr class="even">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="5"></td>
<td colspan="4"></td>
<td colspan="2"><p>AP—AO5VI3</p>
<p>GL—VCH812</p>
<p>Prior Year Accrual—Unexpired</p></td>
<td colspan="2"><p>3107</p>
<p>$210.00</p></td>
<td><p>5700</p>
<p>$210.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2"><p>PO—AO5OB1</p>
<p>GL—OBLLIQ809 Obligation Liquid.</p></td>
<td colspan="2"><p>4801</p>
<p>$213.00</p></td>
<td><p>4610</p>
<p>$213.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5">AO5.4—Reverse Downward Adj. For $3 And Upward Adj. For
$2</td>
<td colspan="6">AO5VI4.1</td>
<td colspan="4"><p>4450.01</p>
<p>$3.00</p></td>
<td colspan="4"><p>4971.01</p>
<p>$3.00</p></td>
<td colspan="2"><p>AP—AO5VI3</p>
<p>GL—VCH812 Reverse PY Spending Adjust.</p></td>
<td colspan="2"><p>4450</p>
<p>$3.00</p></td>
<td><p>4971</p>
<p>$3.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO5VI4.1</td>
<td colspan="4"><p>6100.01</p>
<p>$3.00</p></td>
<td colspan="4"><p>2110.01</p>
<p>$3.00</p></td>
<td colspan="2"><p>AP—AO5VI3</p>
<p>GL—VCH812 Reverse PY Spending Adjust</p></td>
<td colspan="2"><p>4901</p>
<p>$3.00</p></td>
<td><p>4610</p>
<p>$3.00</p></td>
</tr>
<tr class="even">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6">AO5VI4.2</td>
<td colspan="5"><p>3107.01</p>
<p>$3.00</p></td>
<td colspan="4"><p>5700.01</p>
<p>$3.00</p></td>
<td colspan="2"><p>AP—AO5VI3</p>
<p>GL—VCH812 Reverse Prior Year Accrual—Unexpired</p></td>
<td colspan="2"><p>4610</p>
<p>$-210.00</p></td>
<td><p>4901</p>
<p>$-210.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2"><p>AP—AO5VI3</p>
<p>GL—VCH812 Reverse Prior Year Accrual—Unexpired</p></td>
<td colspan="2"><p>6100</p>
<p>$-210.00</p></td>
<td><p>2110</p>
<p>$-210.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2"><p>AP—AO5VI3</p>
<p>GL—VCH812 Reverse Prior Year Accrual–Unexpired</p></td>
<td colspan="2"><p>3107</p>
<p>$-210.00</p></td>
<td><p>5700</p>
<p>$-210.00</p></td>
</tr>
<tr class="odd">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6">AO5VI4.4</td>
<td colspan="5"><p>4610.01</p>
<p>$2.00</p></td>
<td colspan="4"><p>4981.01</p>
<p>$2.00</p></td>
<td colspan="2"><p>AP—AO5VI3</p>
<p>GL—VCH816 PY Spending Adjust</p></td>
<td colspan="2"><p>4901</p>
<p>$2.00</p></td>
<td><p>4981</p>
<p>$2.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO5VI4.4</td>
<td colspan="4"><p>6100.01</p>
<p>$2.00</p></td>
<td colspan="4"><p>2110.01</p>
<p>$2.00</p></td>
<td colspan="2"><p>AP—AO5VI3</p>
<p>GL—VCH816 Prior Year Accrual—Unexpired</p></td>
<td colspan="2"><p>4610</p>
<p>$215.00</p></td>
<td><p>4901</p>
<p>$215.00</p></td>
</tr>
<tr class="odd">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6">AO5VI4.5</td>
<td colspan="5"><p>3107.01</p>
<p>$2.00</p></td>
<td colspan="4"><p>5700.01</p>
<p>$2.00</p></td>
<td colspan="2"><p>AP—AO5VI3</p>
<p>GL—VCH816 Prior Year Accrual–Unexpired</p></td>
<td colspan="2"><p>6100</p>
<p>$215.00</p></td>
<td><p>2110</p>
<p>$215.00</p></td>
</tr>
<tr class="even">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="5"></td>
<td colspan="4"></td>
<td colspan="2"><p>AP—AO5VI3</p>
<p>GL—VCH816 Prior Year Accrual–Unexpired</p></td>
<td colspan="2"><p>3107</p>
<p>$215.00</p></td>
<td><p>5700</p>
<p>$215.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5">AO7.2—Downward Adj. For $21</td>
<td colspan="6">AO7CR1.1</td>
<td colspan="4"><p>4972.01</p>
<p>$21.00</p></td>
<td colspan="4"><p>4450.01</p>
<p>$21.00</p></td>
<td colspan="2"><p>AP—AO7CR1</p>
<p>GL—VCH829 PY Spending Adjust.</p></td>
<td colspan="2"><p>4972</p>
<p>$21.00</p></td>
<td><p>4902</p>
<p>$21.00</p></td>
</tr>
<tr class="even">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6">AO7CR1.1</td>
<td colspan="5"><p>1010.01</p>
<p>$21.00</p></td>
<td colspan="4"><p>6100.01</p>
<p>$21.00</p></td>
<td colspan="2"><p>AP—AO7CR1</p>
<p>GL—VCH829 PY Spending Adjust.</p></td>
<td colspan="2"><p>4902</p>
<p>$21.00</p></td>
<td><p>4450</p>
<p>$21.00</p></td>
</tr>
<tr class="odd">
<td></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="5"></td>
<td colspan="3"></td>
<td colspan="4"><p>AP—AO7CR1</p>
<p>GL—VCH829 PY Spending Adjust.</p></td>
<td colspan="2"><p>1010</p>
<p>$21.00</p></td>
<td><p>6100</p>
<p>$21.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2">GL—VCH830 Reclass to 6103 **(see below for further
explanation)</td>
<td colspan="2"><p>4450</p>
<p>$21.00</p></td>
<td><p>4972</p>
<p>$21.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2">GL—VCH830 Reclass to 6103</td>
<td colspan="2"><p>6100</p>
<p>$21.00</p></td>
<td><p>1010</p>
<p>$21.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2">GL—VCH830 Reclass to 6103</td>
<td colspan="2"><p>4972</p>
<p>$21.00</p></td>
<td><p>4450</p>
<p>$21.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2">GL—VCH830 Reclass to 6103</td>
<td colspan="2"><p>1010</p>
<p>$21.00</p></td>
<td><p>6103</p>
<p>$21.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5">AO8.3—Upward Adj. For $100</td>
<td colspan="6">AO8NC2.1</td>
<td colspan="4"><p>4610.01</p>
<p>$100.00</p></td>
<td colspan="4"><p>4882.01</p>
<p>$100.00</p></td>
<td colspan="2"><p>PO—AO8OB1</p>
<p>GL—OBL817 Change Order/Upward Adj. On Obligation</p></td>
<td colspan="2"><p>4610</p>
<p>$100.00</p></td>
<td><p>4881</p>
<p>$100.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2"><p>AP—AO8NC2</p>
<p>GL—VCH823</p></td>
<td colspan="2"><p>4881</p>
<p>$100.00</p></td>
<td><p>4882</p>
<p>$100.00</p></td>
</tr>
<tr class="even">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="5"></td>
<td colspan="4"></td>
<td colspan="2"><p>AP—AO8NC2</p>
<p>GL—VCH823</p></td>
<td colspan="2"><p>4802</p>
<p>$100.00</p></td>
<td><p>4801</p>
<p>$100.00</p></td>
</tr>
<tr class="odd">
<td></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="5"></td>
<td colspan="3"></td>
<td colspan="4"><p>AP—AO8NC2</p>
<p>GL—AP_PMT824 Payment</p></td>
<td colspan="2"><p>4801</p>
<p>$100.00</p></td>
<td><p>4802</p>
<p>$100.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO8NC2.1</td>
<td colspan="4"><p>1450.01</p>
<p>$100.00</p></td>
<td colspan="4"><p>1010.01</p>
<p>$100.00</p></td>
<td colspan="2"><p>AP—AO8NC2</p>
<p>GL—AP_PMT824 Payment</p></td>
<td colspan="2"><p>1450</p>
<p>$100.00</p></td>
<td><p>1010</p>
<p>$100.00</p></td>
</tr>
<tr class="odd">
<td colspan="2"></td>
<td colspan="5">AO9.1—Downward Adj. For $20</td>
<td colspan="6">AO9NC1.1</td>
<td colspan="5"><p>4801.01</p>
<p>$19,980.00</p></td>
<td colspan="4"><p>4901.01</p>
<p>$19,980.00</p></td>
<td colspan="2"><p>AP—AO9NC1</p>
<p>GL—VCH767 PY Spending Adjust</p></td>
<td colspan="2"><p>4610</p>
<p>$20.00</p></td>
<td><p>4801</p>
<p>$20.00</p></td>
</tr>
<tr class="even">
<td></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="5"></td>
<td colspan="3"></td>
<td colspan="4"><p>PO—G22OB0.1</p>
<p>GL—OBLLIQ768</p>
<p>Obligation Liquid.</p></td>
<td colspan="2"><p>4801</p>
<p>$20,000.00</p></td>
<td><p>4610</p>
<p>$20,000.00</p></td>
</tr>
<tr class="odd">
<td></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="5"></td>
<td colspan="3"></td>
<td colspan="4"><p>AP—AO9NC1</p>
<p>GL—VCH767 Prior Year Accrual</p></td>
<td colspan="2"><p>4610</p>
<p>$19,980.00</p></td>
<td><p>4901</p>
<p>$19,980.00</p></td>
</tr>
<tr class="even">
<td></td>
<td colspan="5"></td>
<td colspan="6">AO9NC1.4</td>
<td colspan="5"><p>4871.01</p>
<p>$20.00</p></td>
<td colspan="3"><p>4450.01</p>
<p>$20.00</p></td>
<td colspan="4"><p>AP—AO9NC1</p>
<p>GL—VCH767 PY Spending Adjust</p></td>
<td colspan="2"><p>4871</p>
<p>$20.00</p></td>
<td><p>4450</p>
<p>$20.00</p></td>
</tr>
<tr class="odd">
<td colspan="4"></td>
<td colspan="6">AO9NC1.3</td>
<td colspan="5"><p>4901.01</p>
<p>$19,980.00</p></td>
<td colspan="4"><p>4902.01</p>
<p>$19,980.00</p></td>
<td colspan="4"><p>AP—AO9NC1</p>
<p>GL—AP_PMT766 Payment</p></td>
<td colspan="2"><p>4901</p>
<p>$19,980.00</p></td>
<td colspan="2"><p>4902</p>
<p>$19,980.00</p></td>
</tr>
<tr class="even">
<td colspan="6"></td>
<td colspan="5">AO9NC1.1</td>
<td colspan="6"><p>6100.01</p>
<p>$19,980.00</p></td>
<td colspan="5"><p>2110.01</p>
<p>$19,980.00</p></td>
<td colspan="2"><p>AP—AO9NC1</p>
<p>GL—VCH767 Prior Year Accrual</p></td>
<td colspan="2"><p>6100</p>
<p>$19,980.00</p></td>
<td><p>2110</p>
<p>$19,980.00</p></td>
</tr>
<tr class="odd">
<td colspan="5"></td>
<td colspan="4">AO9NC1.3</td>
<td colspan="7"><p>2110.01</p>
<p>$19,980.00</p></td>
<td colspan="5"><p>1010.01</p>
<p>$19,980.00</p></td>
<td colspan="2"><p>AP—AO9NC1</p>
<p>GL—AP_PMT766 Payment</p></td>
<td colspan="2"><p>2110</p>
<p>$19,980.00</p></td>
<td colspan="2"><p>1010</p>
<p>$19,980.00</p></td>
</tr>
<tr class="even">
<td colspan="5"></td>
<td colspan="4">AO9NC1.2</td>
<td colspan="7"><p>3107.01</p>
<p>$19,980.00</p></td>
<td colspan="5"><p>5700.01</p>
<p>$19,980.00</p></td>
<td colspan="2"><p>AP—AO9NC1</p>
<p>GL—VCH767 Prior Year Accrual</p></td>
<td colspan="2"><p>3107</p>
<p>$19,980.00</p></td>
<td colspan="2"><p>5700</p>
<p>$19,980.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5">AO9.2—Upward Adj. For $25</td>
<td colspan="6">AO9NC2.1</td>
<td colspan="4"><p>4650.01</p>
<p>$25.00</p></td>
<td colspan="4"><p>4982.01</p>
<p>$25.00</p></td>
<td colspan="2"><p>AP—AO9NC2</p>
<p>GL—VCH783 PY Spending Adjust.</p></td>
<td colspan="2"><p>4650</p>
<p>$25.00</p></td>
<td><p>4902</p>
<p>$25.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2"><p>AP—AO9NC2</p>
<p>GL—VCH783 PY Spending Adjust.</p></td>
<td colspan="2"><p>4902</p>
<p>$25.00</p></td>
<td><p>4982</p>
<p>$25.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO9NC2.1</td>
<td colspan="4"><p>6100.01</p>
<p>$25.00</p></td>
<td colspan="4"><p>1010.01</p>
<p>$25.00</p></td>
<td colspan="2"><p>AP—AO9NC2</p>
<p>GL—VCH783 PY Spending Adjust.</p></td>
<td colspan="2"><p>6100</p>
<p>$25.00</p></td>
<td><p>1010</p>
<p>$25.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO9NC2.2</td>
<td colspan="4"><p>3107.01</p>
<p>$25.00</p></td>
<td colspan="4"><p>5700.01</p>
<p>$25.00</p></td>
<td colspan="2"><p>AP—AO9NC2</p>
<p>GL—VCH783 PY Spending Adjust.</p></td>
<td colspan="2"><p>3107</p>
<p>$25.00</p></td>
<td><p>5700</p>
<p>$25.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5">AO10.1—Upward Adj. For $51</td>
<td colspan="6">AO10NC1.2 Obligation Liquid.</td>
<td colspan="4"><p>4801.01</p>
<p>$999.00</p></td>
<td colspan="4"><p>4901.01</p>
<p>$999.00</p></td>
<td colspan="2"><p>PO—FS1OB4</p>
<p>GL—OBLLIQ765</p>
<p>Obligation Liquid.</p></td>
<td colspan="2"><p>4801</p>
<p>$999.00</p></td>
<td><p>4650</p>
<p>$999.00</p></td>
</tr>
<tr class="even">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6"><p>AO10NC1.2</p>
<p>Obligation Liquid.</p></td>
<td colspan="5"><p>6100.01</p>
<p>$999.00</p></td>
<td colspan="4"><p>2110.01</p>
<p>$999.00</p></td>
<td colspan="2"><p>AP—AO10NC1</p>
<p>GL—VCH764</p>
<p>Prior Year Accrual</p></td>
<td colspan="2"><p>4650</p>
<p>$1,050.00</p></td>
<td><p>4901</p>
<p>$1,050.00</p></td>
</tr>
<tr class="odd">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6">AO10NC1.1</td>
<td colspan="5"><p>6100.01</p>
<p>$51.00</p></td>
<td colspan="4"><p>2110.01</p>
<p>$51.00</p></td>
<td colspan="2"><p>AP—AO10NC1</p>
<p>GL—VCH764</p>
<p>Prior Year Accrual</p></td>
<td colspan="2"><p>6100</p>
<p>$1,050.00</p></td>
<td><p>2110</p>
<p>$1,050.00</p></td>
</tr>
<tr class="even">
<td colspan="2"></td>
<td colspan="5"></td>
<td colspan="6">AO10NC1.1</td>
<td colspan="5"><p>4650.01</p>
<p>$51.00</p></td>
<td colspan="4"><p>4981.01</p>
<p>$51.00</p></td>
<td colspan="2"><p>AP—AO10NC1</p>
<p>GL—VCH 764 PY Spending Adjust.</p></td>
<td colspan="2"><p>4901</p>
<p>$51.00</p></td>
<td><p>4981</p>
<p>$51.00</p></td>
</tr>
<tr class="odd">
<td></td>
<td colspan="5"></td>
<td colspan="6">AO10NC1.3</td>
<td colspan="5"><p>3107.01</p>
<p>$1,050.00</p></td>
<td colspan="3"><p>5700.01</p>
<p>$1,050.00</p></td>
<td colspan="4"><p>AP—AO10NC1</p>
<p>GL—VCH764</p>
<p>Prior Year Accrual</p></td>
<td colspan="2"><p>3107</p>
<p>$1,050.00</p></td>
<td><p>5700</p>
<p>$1,050.00</p></td>
</tr>
<tr class="even">
<td colspan="4"></td>
<td colspan="6">AO10NC1.4</td>
<td colspan="5"><p>4901.01</p>
<p>$1,050.00</p></td>
<td colspan="4"><p>4902.01</p>
<p>$1,050.00</p></td>
<td colspan="4"><p>AP—AO10NC1</p>
<p>GL—AP_PMT761</p>
<p>Payment</p></td>
<td colspan="2"><p>4901</p>
<p>$1,050.00</p></td>
<td colspan="2"><p>4902</p>
<p>$1,050.00</p></td>
</tr>
<tr class="odd">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6">AO10NC1.4</td>
<td colspan="4"><p>2110.01</p>
<p>$1,050.00</p></td>
<td colspan="4"><p>1010.01</p>
<p>$1,050.00</p></td>
<td colspan="2"><p>AP—AO10NC1</p>
<p>GL—AP_PMT761</p>
<p>Payment</p></td>
<td colspan="2"><p>2110</p>
<p>$1,050.00</p></td>
<td><p>1010</p>
<p>$1,050.00</p></td>
</tr>
<tr class="even">
<td colspan="3"></td>
<td colspan="5"></td>
<td colspan="6"></td>
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="2"></td>
<td colspan="2"></td>
<td></td>
</tr>
</tbody>
</table>

##### Additional Explanation on Specific Scenarios:

AO1.4

The entries result from 2 PO's that are matched/copied to a single
voucher. Each PO is \$750, but the total invoice is \$1537. JFMIP will
net/consolidate entries when they can (i.e., post the whole \$1537,
despite the fact that it is in effect derived from 3 transactions---PO
#1 for \$750, PO#2 for \$750, and upward adjustment for \$37 (which they
don't break down for us across the 2 PO's). Somewhat arbitrarily, we
allocate the \$37 to the 2 PO's as follows: \$19 of upward to one PO,
and \$18 of upward to the other PO.

To get the upward adjustments, we voucher one of the \$750 PO's for
\$769, and the other for \$768, following our model (i.e., post the
whole amount to 4901, then back-out of 4901 (and post to 4981) the
upward amount as follows:

Voucher:

> 4650/4901 769
>
> 6100/2110 769
>
> 3107/5700 769

Upward kicks in:

> 4901/4981 19

De-Obligation kicks in:

> 4801/4650 750

PeopleSoft does these 3 entries for the other PO as well (substitute
\$768 for \$769).

**AO2.2**

PeopleSoft's posting model allows the user to use the same 'Entry Event'
code to process a Prior Year Accrual and a prior year
transaction/adjustment. The end-user does not need to know to which year
the transaction adjustment relates. The accrual expenditure entry event
step is effective dated so that the system knows when to invoke a
transaction that utilizes funding from 4610 (if it is a current year
transaction) or a transaction that utilizes funding from 4650 (if it is
a prior year transaction.) The way the PeopleSoft model works is that
the prior year accrual transaction is generated based on the entry event
accrual entry event step, then the spending adjustment is generated
based on either the upward or downward adjustment step. In this example,
there is a prior year spending adjustment so the entry is generated in 2
steps:

1\) Post transaction/adjustment

> 4650/4902 \$11
>
> 6100/1010 \$11
>
> 3107/5700 \$11

2\) Post prior year impact

> 4902/4982 \$11

Account 4902 is cleared to 4982 since the adjustment results from prior
year. The net result is the same as the JFMIP entries for AO2.2.

AO7.2---Additional Explanation on the Automatic Reclassification of 6100
to 6103 account for Downward Adjustments.

AO7.2 is an example of a refund against prior year paid delivered order.
The 4972- Downward Adjustments of Prior-Year Paid Expended
Authority---Refunds collected account is used to process this refund.
PeopleSoft assumes that the money that is refunded is not allowed to be
used for future prior year expenditures, so PeopleSoft configured the
system to automatically reclassify the refund so that it is not
available from a funds control perspective. The 6103 account is used to
reclassify the refund from 6100 to 6103 to prevent other users from
using the budget that is made available as a result of the downward
adjustment of prior year paid delivered orders.

PeopleSoft's Commitment Control configuration drives the funds control
rules that are applied when users try to spend money within the Payables
system. Commitment Control budget definitions may be configured to
exclude specific accounts. By excluding the 6103 account in the
commitment control budget definition, the user would not be able to
spend funding that is associated with account 6103. Within each of the
expenditure budget definitions (e.g., APPROP, APPORT, ALLOT, etc.),
account 6103 has been excluded; this means that the recovery of prior
year funding would not increase available budget. A separate budget
definition named 'UNAVAIL' was defined to track only those expenditures
that were posted with account 6103. This would support the Budget
department's sweep of an Agency's recoveries of prior year funding.
PeopleSoft also could have chosen to use the budgetary account, for
example 497X, to also prevent the spending of funds recovered during
prior year funding. This budget setup for recovery of prior year funding
is totally configurable by the agency.

When developing the approach to this scenario, we incorporated our
experience with regard to recoveries of prior year funding. It is our
understanding that OMB provides the authority to reuse this funding via
the SF-132 (line 4A). If the funds are available for use upon recording
the recovery, then the Agency may effectively circumvent OMB's
authority, which gives the Agency the right to Apportion/Allot funds and
thereby use those funds. In this case, no recoveries had been
anticipated, so the use of the actual recovery would need to be
submitted to OMB on line 4A of the SF-132. PeopleSoft's flexible funds
control design gives the Agency the option to have this control and at
the same time support the proper SGL accounting impact.

At USDA and other agencies, the Budget department required that these
recoveries be secured, disallowing obligation of these funds without
Budget's approval. Budget would periodically sweep these unavailable
amounts and redistribute as permitted according to their approved
SF-132.

### Use Negative Debit and Credit Postings for System-Generated Reversals of Allowances for Loss

#### A. Description of Test Execution Variance

The PeopleSoft transaction level reports, such as the Transaction
Register (GLS8501) and the Journal Entry Detail Report (FIN2001) display
data from the general ledger journal line (jrnl_ln) tables. When there
is a reversal in the general ledger, the presentation on these two
reports is to show a negative debit and a negative credit.

JFMIP did not expect to see this type of presentation of negative debits
and negative credits, and requested that a variance be created to
explain the presentation of the data on the reports. PeopleSoft General
Ledger provides the capability to create reversal journals through the
following mechanisms:

-   Automated system-generated reversals that are generated through the
    GL journal template

-   'Copy as reversing journal' general ledger function. A user can copy
    an existing gl journal and mark it as a reversing journal so that
    the system will figure out the reverse of an existing transaction.
    This saves the user time if they want to reverse a transaction that
    has already been posted.

-   Unpost or cancellation journals that are generated from feeder
    systems

When any of the above types of reversal journals are created, the system
creates a copy of the original journal and makes the debit and credit
totals negative.

On transaction level reports derived from the Journal tables, for these
three types of reversal journals, the debits and credits are reflected
with the negative signs. This includes the Transaction Register and
Journal Entry Detail Reports.

PeopleSoft also processed the allowance for loss differently than the
JFMIP had expected for test scenario RD5.2. PeopleSoft interpreted the
original allowance for loss (RD5.1) as a self-reversing general ledger
accrual entry. Each month the allowance for loss is calculated and
posted through the Allocations process. Since the gl journal to record
the allowance for loss is established as a self-reversing journal, it
will automatically reverse in the next period. The journal can
self-reverse at the beginning or end of the next period, configurable by
each Agency. In the next month, when the Allowance for Loss allocation
is executed again, it creates new entries for all the current Allowance
for Loss amount, based on agency criteria, since the last month's
allowance for loss accrual has already been reversed. This allows for an
updated allowance for loss estimate each month.

JFMIP reverses the allowance for loss in Scenario RD5.2, but the
reversal D204R transaction code in the script does not use the same
negative debit and negative credit methodology that PeopleSoft's
automated system generated reversal uses. PeopleSoft approached these
scenarios differently, using a self-reversing accrual and reposting of
all current allowance for loss amounts.

  --------------------------------------------------------------------------------------
  JFMIP's                                  PeopleSoft's                           
  Approach                                 Approach                               
  ---------- --------- ------ ------ ----- -------------- --------- ------ ------ ------
  RD5.2      RD5OT2    1319          350   RD5.2          RD5OT1    6720          -350

                              6720   350                                   1319   -350

                       1369          25                             6720          -25

                              6720   25                                    1369   -25

                                                                                  
  --------------------------------------------------------------------------------------

Also, the system generated reversing GL journals use the same document
number as the document number that is being reversed, so JFMIP will see
the originating allowance for loss document number in their Cycle 12
transaction register for RD5.2.

#### B. Reason for Variance

The reason for this variance is to take advantage of delivered COTS
processing that is provided by PeopleSoft.

#### C. Benefit to the Government

The benefit to the government by using the standard reversal capability,
instead of re-writing delivered logic to flip the debits and credits on
the journal entry screens and reports, is a cost benefit. By using the
delivered journal reversal processing, not only is the government
utilizing COTS functionality, but also it is able to easily discern
reversal entries from regular transaction entries.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

+-------------------+-----------------+--------------------------------+
| Type of Reversal  | Cycle/Scenario  | Scenario corresponds to an     |
|                   |                 | actual JFMIP scenario or       |
|                   |                 | Scenario relates to a          |
|                   |                 | correction processed during    |
|                   |                 | the execution of the JFMIP     |
|                   |                 | Certification test             |
+===================+=================+================================+
| System Generated  | Cycle 12,       | Cycle 12, Scenario RD5.2.      |
| Reversal          | Scenario RD5.2  | Reversal of Allowance for Loss |
|                   |                 | created in Cycle 11, Scenario  |
|                   |                 | RD5.1.                         |
+-------------------+-----------------+--------------------------------+
| Schedule          | Cycle 18,       | Cycle 18, Scenario PP4.2.      |
| Cancellation      | Scenario PP4.2  | Cancellation of payment        |
|                   |                 | schedule created in Scenario   |
|                   |                 | PP4.1.                         |
+-------------------+-----------------+--------------------------------+
| Payment           | Cycle 19,       | Cycle 19, Scenario PP5.4.      |
| Cancellation      | Scenario PP5.4  | Cancellation of voided         |
|                   |                 | Treasury Check.                |
+-------------------+-----------------+--------------------------------+
| System Generated  | Cycle 18,       |   ---------------------------  |
| Reversal          | Scenario PE20.8 |   Cycle 18, Scenario PE20.8.   |
|                   |                 |   Grant Expense Accrual        |
|                   |                 |   Reversal                     |
|                   |                 |                                |
|                   |                 |   ---------------------------  |
+-------------------+-----------------+--------------------------------+
| System Generated  | Cycle 19,       |   ---------------------------  |
| Reversal          | Scenario        |   Cycle 19, Scenario PE20.10.  |
|                   | PE20.10         |   Grant Expense Accrual        |
|                   |                 |   Reversal                     |
|                   |                 |                                |
|                   |                 |   ---------------------------  |
+-------------------+-----------------+--------------------------------+
| Voucher Unpost    | Cycle 5,        | Cycle 5, Scenario PE 1.6.      |
|                   | Scenario PE 1.6 | Unpost of Voucher PE1VI3.      |
|                   |                 | Relates to PSFT-27 TEVR        |
|                   |                 | Variance in Posting of         |
|                   |                 | Payables Adjustments.          |
+-------------------+-----------------+--------------------------------+
| Voucher Unpost    | Cycle 17,       | Cycle 17, Scenario AO5.4.      |
|                   | Scenario AO5.4  | Adjustment to Document Number  |
|                   |                 | AO5VI3. PeopleSoft used the    |
|                   |                 | Voucher Unpost feature for     |
|                   |                 | this scenario. Relates to      |
|                   |                 | PSFT-27 TEVR Variance in       |
|                   |                 | Posting of Payables            |
|                   |                 | Adjustments.                   |
+-------------------+-----------------+--------------------------------+
| Voucher Unpost    | Cycle 17,       | Cycle 17, Scenario PE15.8.     |
|                   | Scenario PE15.8 | Adjustment to Document Number  |
|                   |                 | PE15VI3. PeopleSoft used the   |
|                   |                 | Voucher Unpost feature for     |
|                   |                 | this scenario. Relates to      |
|                   |                 | PSFT-27 TEVR Variance in       |
|                   |                 | Posting of Payables            |
|                   |                 | Adjustments.                   |
+-------------------+-----------------+--------------------------------+
| 'copy as          | Cycle 12,       | Scenario relates to a          |
| reversing         | Scenario AO5.2  | correction processed during    |
| journal'          |                 | the execution of the JFMIP     |
|                   |                 | Certification test             |
+-------------------+-----------------+--------------------------------+
| 'copy as          | Cycle 5,        | Scenario relates to a          |
| reversing         | Scenario RD4.5  | correction processed during    |
| journal'          |                 | the execution of the JFMIP     |
|                   |                 | Certification test             |
+-------------------+-----------------+--------------------------------+
| 'copy as          | Cycle 5,        | Scenario relates to a          |
| reversing         | Scenario RD4.4  | correction processed during    |
| journal'          |                 | the execution of the JFMIP     |
|                   |                 | Certification test             |
+-------------------+-----------------+--------------------------------+
| 'copy as          | Cycle 5,        | Scenario relates to a          |
| reversing         | Scenario RD4.5  | correction processed during    |
| journal'          |                 | the execution of the JFMIP     |
|                   |                 | Certification test             |
+-------------------+-----------------+--------------------------------+
| 'copy as          | Cycle 4,        | Scenario relates to a          |
| reversing         | Scenario RO2.3  | correction processed during    |
| journal'          |                 | the execution of the JFMIP     |
|                   |                 | Certification test             |
+-------------------+-----------------+--------------------------------+
| 'copy as          | Cycle 5,        | Scenario relates to a          |
| reversing         | Scenario RO1.6  | correction processed during    |
| journal'          |                 | the execution of the JFMIP     |
|                   |                 | Certification test             |
+-------------------+-----------------+--------------------------------+
| 'copy as          | Cycle 5,        | Scenario relates to a          |
| reversing         | Scenario RO2.4  | correction processed during    |
| journal'          |                 | the execution of the JFMIP     |
|                   |                 | Certification test             |
+-------------------+-----------------+--------------------------------+
| 'copy as          | Cycle 5,        | Scenario relates to a          |
| reversing         | Scenario RO1.4  | correction processed during    |
| journal'          |                 | the execution of the JFMIP     |
|                   |                 | Certification test             |
+-------------------+-----------------+--------------------------------+
| 'copy as          | Cycle 5,        | Scenario relates to a          |
| reversing         | Scenario RO2.4  | correction processed during    |
| journal'          |                 | the execution of the JFMIP     |
|                   |                 | Certification test             |
+-------------------+-----------------+--------------------------------+
| 'copy as          | Cycle 4,        | Scenario relates to a          |
| reversing         | Scenario G22.6  | correction processed during    |
| journal'          |                 | the execution of the JFMIP     |
|                   |                 | Certification test             |
+-------------------+-----------------+--------------------------------+
| 'copy as          | Cycle 5,        | Scenario relates to a          |
| reversing         | Scenario PP1.2  | correction processed during    |
| journal'          |                 | the execution of the JFMIP     |
|                   |                 | Certification test             |
+-------------------+-----------------+--------------------------------+
|                   |                 |                                |
+-------------------+-----------------+--------------------------------+

## Processing Variances

### Use 'Recurring PO Voucher' Contract Transactions For Lease Installments, Without Automatic Liquidation of the Related Commitment

#### A. Description of Test Execution Variance

The PE11.X business process requires that the recurring lease
installments liquidate the originating commitment for the lease. Per the
script, the lease 'installment' is de-committing, obligating,
de-obligating, and expending.

In PeopleSoft, the expenditure documents do not directly liquidate
commitment documents (vouchers don't liquidate requisitions, vouchers
liquidate PO's, or obligations).

PeopleSoft proposes addressing this requirement with a recurring
transaction in our Contracts module, the 'Recurring PO Voucher'
contract. This contract allows you to setup, auto-generate, and release
a 'PO Voucher' document which will obligate, de-obligate, and expend the
installment amount of the contract. The contract also allows you to
establish a ceiling, or maximum amount, for the releases/installments of
the contract. So, for the PE11 series, the contract will establish a
ceiling of \$28,800 for the releases/installments that can be generated
from the contract. The contract ceiling will have no obligation
associated with it, since the script requires the obligation to occur
during the 'obligate-and-accrue' entry event on the voucher. No
obligation document lines will be created in the controlled budgets in
PeopleSoft since the contract ceiling is not associated with an
obligation. It will 'stage' 9 releases/installments for the monthly
payments (\$3,200), and the installments will be released (processed)
according to the test requirements in PE11.3 and PE11.5.

This primary difference between this approach and the JFMIP script is
the omission of the commitment transaction, and the 'de-commit' with
each installment. Each voucher will post the obligating and expending
transactions similar to the script requirements.

For each step in the PE11.X series, the following variance is proposed:

  -----------------------------------------------------------------------------
  Cycle   Step           Step/Function\             Step/Function\
                         Current                    Proposed
  ------- --------- ---- -------------------------- ---------------------------
  3       PE11.1    1    Create requisition for     Step Omitted
                         lease                      

  3       PE11.2    2    Create Recurring Lease     Create Recurring Lease
                                                    using Recurring PO
                                                    Contract. This type of
                                                    contract 'stages' the
                                                    obligating/expending
                                                    documents (9 of them).
                                                    Later steps will 'release'
                                                    the transactions for
                                                    processing. The contract
                                                    provides document control
                                                    related to releases against
                                                    the contract (i.e.,
                                                    releases cannot exceed the
                                                    contract), but has no
                                                    accounting impact---the
                                                    obligating and expending
                                                    entries will be posted from
                                                    the recurring voucher
                                                    document.

  4       PE11.3    3    Release 1 of lease (For    Release 1 of Recurring PO
                         1/9^th^, de-commits,       Contract. Releases 1^st^
                         obligates, de-obligates    installment of lease
                         and expends)               contract.

  4       PE11.4    4    Treasury notification of   Treasury notification of
                         IPAC                       IPAC

  5       PE11.5    5    Release 2 of lease (For    Release 2 of lease. Repeat
                         1/9^th^, de-commits,       of Step 3 above.
                         obligates, de-obligates,   
                         and expends)               

  5       PE11.6    6    Query on status            Query on status.

  5       PE11.7    7    Suspended IPAC load        As approved under variance
                                                    #13, the IPAC file will be
                                                    loaded but we will not
                                                    attempt to post the
                                                    disbursement.

  5       PE11.8    8    Query on unpaid            Query on unpaid
                         expenditures               expenditures

  5       PE11.9    9    Cancel recurring voucher   Cancel recurring voucher
                                                    contract.

  5       PE11.10   10   Cancel remaining           Step Omitted.
                         commitment                 

  5       PE11.11   11   Access suspended IPAC and  Post IPAC disbursement.
                         post                       

  19      PE18.5         Provide on-line            The Procurement Budgetary
                         information on obligation  Activity Report will not be
                         document lines closed.     updated since there will be
                                                    no obligation document
                                                    lines created. The IPAC
                                                    voucher will process an
                                                    'obligate and accrue'
                                                    transaction which will
                                                    update the controlled
                                                    budgets as an expenditure,
                                                    but it will not update the
                                                    controlled budgets as a
                                                    decrease to an obligation,
                                                    since no obligation was
                                                    created, in accordance with
                                                    the desired non-obligating
                                                    contract ceiling required
                                                    in the PE11 series.
                                                    Therefore there will be no
                                                    rows for PE11AE1 on the
                                                    Procurement Budgetary
                                                    Activity Report.

                                                    
  -----------------------------------------------------------------------------

The accounting impact of these changes is as follows:

  ---------------------------------------------------------------------------------------------------------------------------
  Step        Trans\        DR.\   Cr.\                 Amt    Doc\           Journal\                 DR.\    Cr.\   Amt
              Id            Acct   Acct                        ID             Id                       Acct    Acct   
  ----------- ------------- ------ ------ ------ ------ ------ -------------- ---------- ------------- ------- ------ -------
  JFMIP                                                        PeopleSoft                                             
  Expected                                                     Expected                                               
  Results                                                      Results                                                

  PE11.1      Commitment                                       PE11.1                    Step Omitted                 

                            4610                 3000                                                                 

                                          4700   3000                                                                 

                            4610                 200                                                                  

                                          4700   200                                                                  

  PE11.2      Establish                                        PE11.2                    Establish                    
              Recurring                                                                  Recurring                    
              Lease                                                                      Lease                        

  PE11.3                                                       PE11.3                                                 

  PE11AE1.1                 4700                 3000          PE11AE-1                  Vch Release   4610           3000

                                          4801   3000                                                          4801   3000

  PE11AE1.3                 4801                 3000                                                  4801           3000

                                          4901   3000                                                          4901   3000

                            6100                 3000                                                  6100           3000

                                          2110   3000                                                          2110   3000

  PE11AE1.5                 3107                 3000                                                  3107           3000

                                          5700   3000                                                          5700   3000

  PE11AE1.2                 4700                 200                                                   4610           200

                                          4801   200                                                           4801   200

  PE11AE1.4                 4801                 200                                                   4801           200

                                          4901   200                                                           4901   200

                            6100                 200                                                   6100           200

                                          2110   200                                                           2110   200

  PE11.4      IPAC                                             PE11.4                    IPAC                         
              Processing                                                                 Processing                   

                                                               No variance                                            
                                                               from JFMIP                                             
                                                               script.                                                

  PE11.5      2^nd^                                            PE11.5                    2^nd^                        
              installment                                                                installment                  
              of Recurring                                                                                            
              Lease                                                                                                   

                                                               Repeat of                                              
                                                               Transactions                                           
                                                               and Entries in                                         
                                                               PE11.3                                                 

                                                                                                                      
  ---------------------------------------------------------------------------------------------------------------------------

#### B. Reason for Variance

The variance allows us to achieve the objectives of the government to
create an installment 'obligate and accrue' transaction at the time the
voucher is processed. Each installment will obligate the lease amount,
de-obligate, and setup a voucher for the inbound IPAC disbursement
transaction*.*

#### C. Benefit to the Government

Provides an automated solution to address recurring obligate and accrue
scenarios.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

The changes are reflected in detail in the 'Expected Results' matrix
above.

### Post Purchase Order and Voucher to Accounting Period (AP) 12 Instead of Adjustment AP 13

#### A. Description of Test Execution Variance

PeopleSoft General Ledger is the only module that supports posting to
adjustment periods. PO and Vouchers cannot be posted to Period 13, must
be posted to Period 12. Our current system will allow a current dated
transaction (Obligation or Voucher) to be posted in a prior period while
both periods are in an open status.

The effective date or accounting date will be 9/30/2002 for transactions
that are marked with an effective date of Period 13. In scenario AI1.2,
PeopleSoft used an effective date of 9/30/2002, which translates to
Period 12, not Period 13.

Short Description: PO and VCH Cannot Be Posted to Period 13, Must be
Posted to Period 12.

  --------------------------------------------------------------------------------------------------------------------------------------------------
  Step                     Doc/Trans\   DR.\                Cr.\            Amt   Doc\          Journal\   DR.\             Cr.\      Amt   
                           Id           Acct                Acct                  ID            Id         Acct             Acct            
  ------------- ---------- ------------ --------- --------- ------ -------- ----- ------------- ---------- ------ --------- --------- ----- --------
  JFMIP                                                                           PeopleSoft                                                
  Expected                                                                        Expected                                                  
  Results                                                                         Results                                                   

  AI1.2         AI1OB1.1                4610.01                                   AI1.2         AI1OB1.1          4610.01                   

                                                  4801.01          313.00                                                   4801.01         313.00

  Transaction                                                                     Transaction                                               
  Date 10/14/02                                                                   Date 10/14/02                                             

  Budget and                                                                      Budget and                                                
  Accounting                                                                      Accounting                                                
  Date 09/30/02                                                                   Date 09/30/02                                             

  POSTED IN                                                                       POSTED IN                                                 
  PERIOD 13                                                                       PERIOD 12                                                 

                                                                                                                                            
  --------------------------------------------------------------------------------------------------------------------------------------------------

There is no deviation in accounting entries for these transactions.

#### B. Reason for Variance

The current JFMIP Script requires a Purchase Order and Voucher to be
posted into period 13. Our current system does not allow subsystems
transactions to be posted to period 13 but does have the ability to post
current dated items to be posted in prior periods.

#### C. Benefit to the Government

A transaction received in the current year can be recognized in the
prior year by posted it in the prior year and still maintaining the
current year processing date.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

In JFMIP Script AI1.2 and AO6.3 we are going to post transactions in
period 12 with a transaction date in period 01 instead of posting the
items to period 13 as requested. The system will still give the user a
message that the transaction date has expired but will still allow the
user to process and post the transaction.

### Use Accounting Periods 998 and 999 for Pre-Closing Adjustments and Year-End Closing Entries

#### A. Description of Test Execution Variance

Period 13 = 998 (PreClosing), Period 14 = 999 (Closing)

PeopleSoft provides the capability to define multiple adjustment periods
for each accounting period. However the adjustment periods that are
specifically designated for year-end processing are delivered as period
998 and 999. Period 998 is used for pre-closing adjustments, and Period
999 is used for year-end transactions.

Instead of seeing period 13 and 14, for pre-closing and year-end
transactions; JFMIP will see period 998 and 999, respectively, on all
reports where this information is relevant.

#### B. Reason for Variance

The reason for this variance is to take advantage of delivered COTS
processing that is provided by PeopleSoft.

#### C. Benefit to the Government

The benefit to the government by using the 998 and 999 periods, instead
of re-writing delivered logic to segregate pre-closing and closing
transactions, is a cost benefit. By using the delivered 998 and 999
periods the government is utilizing COTS functionality.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

The scenarios that will utilize 998 and 999 as reporting periods would
fall into the AYX.XX and the RRX.XX business process areas.

In Fiscal Year 2001, since there are no pre-closing entries, the AY0
closing entries are being posted to period 998. For FY 2001 fiscal year
end close, Period 999 was not used. In Fiscal Year 2002, Period 0 is the
period that stores the rolled forward balances. In Fiscal Year 2002, the
year end transactions are being handled in accordance with the Standard
General Ledger, such that the pre-closing entries are being posted to
period 998 and the closing entries are being posted to period 999.

### Post Fiscal Year 2001 Closing Entries at the Budget Object Class Level

#### A. Description of Test Execution Variance

During year-end processing for Cycle 0, PeopleSoft processed AY0.4,
Transaction Reference AY0OT2.3, moving balances in 4610 to 4650, at the
Object Class level. Therefore, the transaction that PeopleSoft created
for this scenario reflects a different set of debits and credits,
although the net results are the same.

JFMIP Expected Results

  --------- ---------- -------- ------- -------- ------ ----------- ------ ---------------
  Step      Doc\       Fund     Org     Object   DR     DR\         CR     CR\
            ID                  Code    Class    Acct   Amt         Acct   Amt

  AY0.4     AY0OT2.3   0100DA   11000            4610   9,999,000   4650   \<9,999,000\>
  --------- ---------- -------- ------- -------- ------ ----------- ------ ---------------

PeopleSoft Expected Results

  ------- ------------ ------------- -------- ------- -------- ------ ----------- ------ ---------------
  Step    Journal ID   Transaction   Fund     Org     Object   DR     DR\         CR     CR\
                       Reference              Code    Class    Acct   Amt         Acct   Amt

  AY0.4   YE00000003   AY0OT2        0100DA   11000            4610   9,999,999   4650   \<9,999,999\>

  AY0.4   YE00000003   AY0OT2        0100DA   11000   2510     4650   999         4610   \<999\>
  ------- ------------ ------------- -------- ------- -------- ------ ----------- ------ ---------------

#### B. Reason for Variance

For Cycle 0 Year-End processing, PeopleSoft processed AY0.4, Transaction
Reference AY0OT2.3, moving balances in 4610 to 4650, at the Object Class
level. Based on guidance provided by JFMIP in Cycle 13, PeopleSoft will
be processing Year-End at the organizational level going forward.

The FY 2002 closing entries were done at all ACE levels except BOC and
by attribute for Trading Partner and Transaction Partner (attributes not
captured by sub-accounts).

#### C. Benefit to the Government

PeopleSoft's Year-End processing is very flexible and user-configurable,
allowing the Government to perform year-end processing at various levels
of their accounting classification structure. Agencies can choose to
process year-end at different levels for each Fund, Organization, etc.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

See Section A, above, for details on the differences in fiscal year end
closing entries.

### System Assigns Payment Schedule Numbers

#### A. Description of Test Execution Variance

The Payment Schedule ID's from the PeopleSoft application will be
different from the expected results of the JFMIP test due to: (1) format
variation, and (2) sequence variation due to miscellaneous data entry
errors.

Each reason is discussed in more detail:

-   Format variation---PeopleSoft uses a different prefix and additional
    digits in numbering the payment schedules. PeopleSoft uses a prefix
    of 'OTH' for vendor payments, and 'TRN' for travel, or
    transportation-related schedules. Also, the numeric sequence can be
    7 digits in length. So, for example, for the first vendor payment
    schedule, PeopleSoft produced a schedule ID of 'OTH0008801'.

-   Data entry mistakes (corrected). If an invalid date, term, or
    payment method was entered (as examples), we would correct the data
    entry mistake, and re-run the payment schedule. However, each time
    we rerun the selection process, the system generates the next
    sequential number for the Payment Schedule.

Also, the Payment Schedule ID's in bulk-formatted payment files
submitted to Treasury for validation will differ from both the JFMIP
schedule numbers and the schedule numbers in the PeopleSoft application.
This is to accommodate Treasury's edit on duplicate schedule/segment
numbers. Since JFMIP schedule numbers used during pre-test validations
cannot be re-used during actual testing, we have incremented these
schedule numbers by 100.

Cycle 19, Scenario PP5.1 tests to validate that a duplicate US Treasury
Schedule number cannot be re-used. PeopleSoft does not allow the re-use
of US Treasury Schedule numbers due to controls that prevent duplicate
schedule numbers, since US Treasury Schedule numbers are autogenerated.

The following Payment Schedules and files were produced, after
correcting any data entry errors, and are mapped to the expected payment
schedule ID's of JFMIP:

  -----------------------------------------------------------------------
  JFMIP\                PeopleSoft\           PeopleSoft payment schedule
  Expected Values       Values                file value (modified to
                                              enable Austin validation)
  --------------------- --------------------- ---------------------------
  Cycle 5                                     

  V-8801                OTH0008801            OTH0008901

  T-7701                TRN0007701            TRN0007801

  V-8802                OTH0008803            OTH0008903

  Cycle 6                                     

  V-8803                OTH0008806            Cycle 6 ECS files did not
                                              require modification for
                                              Austin processing.

  V-8804                OTH0008809            

  T-7702                TRN0007702            

  Cycle 8                                     

  V-8805 (Vendor Check) OTH0008810            

  V-8806 (CTX)          OTH0008811            

  Cycle 18                                    

  V-8807 (Vendor Check) OTH0008812            

  V-8808 (CCD+)         OTH0008813            

  T-7703 (PPD+)         TRN0007703            

  V-8809 (Vendor Check) OTH0008814            

  V-8810 (CCD+)         OTH0008815            

  T-7704 (PPD+)         TRN0007704            

  Cycle 19                                    

  V-8811 (Vendor Check) OTH0008817            

                                              
  -----------------------------------------------------------------------

PP5.1 checks the ability for the Payables system to prevent duplicate
numbering of US Treasury Schedule numbers. PeopleSoft's Payables system
autonumbers the US Treasury Schedules, so there is no way the US
Treasury Schedule numbers could be duplicated.

#### B. Reason for Variance

To provide mapping between schedule ID's and those produced by
PeopleSoft for the test and to accommodate Treasury's edit on the
schedule/segment number field in bulk-formatted payment files.

#### C. Benefit to the Government

Auto numbering of payment schedules prevents duplication.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

Payment schedule numbers will be different than those provided in the
test materials.

### Record Adjustment to Fiscal Year 2001 Beginning Balance in Accounting Period (AP) 998 Instead of AP 0

#### A. Description of Test Execution Variance

##### FACTS II Adjusting Entry

For Cycle 4, Scenario G22.6 JFMIP requests vendors to perform an update
to fiscal year 2002, Accounting Period 00 (Beginning Balances).

In the PeopleSoft Financials applications, users cannot make direct
transaction updates to the Beginning Balance period (0). PeopleSoft's
Beginning Balance period represents calculated balances generated from
the automated Year-End closing and rollover procedures.

To accomplish the JFMIP'S desired affect to the Beginning Balance
period, PeopleSoft performed an entry to Fiscal Year 2001, Accounting
Period 998 and rolled forward the transactions into Fiscal Year 2002,
Accounting Period 0.

#### B. Reason for Variance

JFMIP expects an adjusting entry to Fiscal Year 2002, Accounting Period
0 to meet the FACTSII Edit requirements.

In the PeopleSoft Financials applications, users cannot make direct
transaction updates to the Beginning Balance period (0). PeopleSoft's
Beginning Balance period represents calculated balances generated from
the automated Year-End closing and rollover procedures. PeopleSoft
protects this period from direct posting to ensure that the balances are
an accurate reflection of the ending balances from the previous year.

#### C. Benefit to the Government

PeopleSoft prevents direct postings to the Beginning Balance period
provides benefits to the government by guaranteeing the integrity of the
beginning balance amount, ensuring that ending balances from the
previous year match the beginning balances from the current year.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

The G22.6 Scenarios will be posted to Fiscal Year 2001, Accounting
Period 998 and rolled forward into the Beginning Balance period. They
will be reflected as changes in the beginning balances of the AP 0204
trial balance (as brought forward from AP 0200).

## Reporting Variances

### Report Additional FACTS Attributes on the Transaction Register

#### A. Description of Test Execution Variance

Explanation of the attributes on the transaction register report: JFMIP
will see additional attributes on the transaction register report when
they compare the JFMIP expected results to the PeopleSoft delivered
results.

#### B. Reason for Variance

The reason for this variance between the PeopleSoft transaction register
outputs and the JFMIP output is due to the design of the FACTS1 and
FACTS2 attributes. PeopleSoft has designed the process to collect the 22
FACTS1 and FACTS2 attributes to minimize the user intervention. Some
attributes are related to an appropriation code or Treasury Account
Symbol and can be derived from the appropriation value on a transaction,
thus minimizing the data entry required by the user.

The transaction register is designed to show all attributes associated
with a particular account, as derived from the fund value, regardless of
whether or not FACTS 1 or FACTS 2 requires the attribute for that
account.

#### C. Benefit to the Government

This design approach minimizes the specific attributes that the user
must enter during transaction processing. Currently the only two
attributes that the user enters are the trading partner and the
transaction partner, the other 20 attributes are derived by the account
or appropriation that are associated with the transaction.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

The scenarios that are affected by this variance are the cycle-end
reporting scenarios, RRX.X.

### Report Activity Under GRANT01 and Unfunded Construction Contract CN01 as Extra Level of Detail on Trial Balances due to Use of Project Accounting Classification Element (Chartfield)

#### A. Description of Test Execution Variance

This variance addresses the difference in JFMIP expected results and
PeopleSoft transactions for transactions that reference Unfunded
construction project CN01 and GRANT01. PeopleSoft posted to the General
Ledger the CN01 value in the Project chartfield for all transactions
that referenced the unfunded construction project of CN01. PeopleSoft
posted to the General Ledger the GRANT01 value in the Project chartfield
for all transactions that referenced GRANT01.

This affects any reports that display chartfield detail at the Project
level. JFMIP reports do not include the unfunded project on their
reports. The reports include:

-   FACTSI Trial Balance

-   FACTSII Trial Balance

-   Transaction Register.

The transactions that include the Project value of CN01 within
PeopleSoft are:

  ----------------------- -----------------------------------------------
  Step                    Transaction Reference

  PE23.1                  N/a

  PE23.2                  PE23OB1.1

  PE23.2                  PE23OB1.2

  PE23.3                  PE23NC1.1

  PE23.3                  PE23NC1.5

  PE23.4                  PE23RR1.1

  PE23.4                  PE23RR1.2

  PE23.4                  PE23RR1.4

  PE23.5                  PE23RR2.1

  PE23.5                  PE23RR2.2

  PE23.5                  PE23RR2.3

  PE23.6                  PE23NC2.1

  PE23.6                  PE23NC2.3

  PE24.1                  PE240B1.1

                          
  ----------------------- -----------------------------------------------

The transactions that include the Project value of GRANT01 within
PeopleSoft are:

  ---------------------- ------------------------------------------------
  Step                   Transaction Reference

  PE20.1                 PE20OB1

  PE20.2                 PE20NC2

  PE20.8                 PE20AE5

  PE23.11                PE20AE8

                         
  ---------------------- ------------------------------------------------

The JFMIP data required funds control validation for projects with and
without program codes. When a transaction that did not require a program
code was entered, PSFT assigned a program code of '0' to indicate that
there was no associated program with the project value. This enabled the
funds control checking structure to be met. To accommodate JFMIP's
budget control structure, PeopleSoft needed to establish a budgetary
control structure to support both program and project control,
specifically for Fund 0100DB. Based on our configuration, all
transactions in this Fund require a program code, even if JFMIP did not
specify a value. Where JFMIP did not specify a code, PeopleSoft used
'0'. The 0 program code was used in combination with both CN01 and
GRANT01 project values, since the JFMIP scripts require that the CN01
and the GRANT01 values are used without any program value.

#### B. Reason for Variance

The reason for this variance is transactions that reference unfunded
project CN01 and project GRANT01 were recorded by PeopleSoft through the
use of an accounting classification element field (chartfield) to
identify this activity.

#### C. Benefit to the Government

The benefit to the government is that appropriate reporting is done for
the project activity and that the test script's fund control validation
requirements are met.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

As a result of this variance, the PeopleSoft FACTS trial balances and
the transaction register will have an additional level of reporting for
projects CN01 and GRANT01. Also, in Fund 0100DB, reporting of this
project activity will reflect a program code of '0' where no program
code was assigned by JFMIP.

## Setup Variances

### Use Accounting Classification Element to Control The Spending Limits of BPAS and Contracts

#### A. Description of Test Execution Variance

We plan to utilize budgets to control the spending limits of Blanket
Purchase Agreements and Contracts. We only intend to use budgets to
control spending limit all other controls, dates, accounting impact,
etc. will be handled in our Purchasing and Accounts Payable
applications. Reference the following test steps:

> PE 3.1 Cycle 4 Sort 15 and all subsequent processing steps
>
> PE 6.1 Cycle 7 Sort 9 and all subsequent processing steps

PeopleSoft has several user configurable fields or elements that make up
an organization's chart of accounts. We will utilize one of these fields
for the BPA or Contract. All we will need to capture is the BPA or
Contract and the spending limit or budget amount. Therefore, all sub
ledger transactions will check against that amount to ensure there are
enough funds in place to allow the transaction to proceed. Project was
just one field we thought about using but since it interferes with
processing we will use another element to capture BPA or Contract. In
this way the transactions in the sub ledger may also utilize, project,
fund, object class, etc. when releases are done against the BPA or
Contract

This new proposed chart of account element will be used for the same
purpose across all organizations and funds. It will be used to capture a
BPA or Contract value whenever applicable. It will not be used to
capture any other values.

We will not need to know the fund code as we will be controlling
spending limit just at the BPA or Contract level and will have a
specific element in the chart of accounts to represent a particular BPA
or Contract and then will budget (spending limit) at that level. Again,
PeopleSoft has many elements that make up an organizations chart of
accounts. We will just utilize one of those elements not already
required by JFMIP to establish the BPA or Contract.

In addition, when creating the budget for the BPA or Contract spending
limit there is no requirement to update SGL accounts. Therefore, there
will be no accounting impact for this transaction.

##### Process steps:

-   There will already be an established element within the ACE to
    capture BPA's or Contracts

-   When the BPA or Contract comes in it will be entered in Purchasing
    with start and end dates, vendor information, etc.

-   We would also establish a new value for the BPA or Contract element
    in the ACE

-   We would create a budget for that BPA or Contract element equal to
    the spending limit. This would have no accounting impact.

-   When a release is done against the BPA or Contract the user would
    select the correct BPA or Contract value on the ACE as well as all
    other required ACE elements (e.g., Fund, Object Class, etc.) and our
    budget processor would check the release against the available
    spending limit and would either allow the transaction to pass or
    would provide an error message when this release would exceed the
    limit.

-   When an invoice is entered against a BPA or Contract the user would
    select the correct BPA or Contract value on the ACE as well as all
    other required ACE elements (e.g., Fund, Object Class, etc.) and our
    budget processor would check the invoice against the available
    spending limit and would either allow the transaction to pass or
    would provide an error message when this release would exceed the
    limit.

-   All other edits and validations (e.g., vendor information, start/end
    dates, valid ACE elements, etc.) are done by the Purchasing and
    Accounts Payable Module. For example all other ACE elements (e.g.,
    fund, object class, etc.) will be verified against valid values. The
    transaction will not proceed if these values are invalid

-   Inquiries may be done either in Purchasing or General Ledger to view
    transactional data against the BPA or Contract. The user may search
    by BPA or Contract as well as other criteria.

#### B. Reason for Variance

We would like to have consistent controls for all budgets and spending
limits across our applications. Therefore, for the spending limit
requirement we plan to utilize our budget mechanism to control the
spending limit aspect of the BPA or Contract.

All associated transactions will be recorded under one BPA or Contract
utilizing our Purchasing and Accounts Payable functionality. Therefore,
we can report directly out of Purchasing by BPA or Contract number in
addition we can also report out of GL transactional information by BPA
or Contract.

#### C. Benefit to the Government

By utilizing budgets we will have consistent set up and process
procedures for our customers when implementing controls on budgets and
limits. In addition reporting against a BPA or Contract may be
accomplished in the Purchasing module as well as within the General
Ledger.

By allowing our customers this flexibility they can determine what level
of control they wish to have for the spending limit. It could just be a
warning or it could be a hard error that they could not override.

In addition, by utilizing budgets they will have access to our budget
inquiries to review all transactions against the BPA or Contract and the
ability to drill into the individual detailed transactions.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

The process steps described above will be executed for the test steps
noted below:

> PE 6.1: Steps 2, 3 and 4
>
> PE 6.2: Steps 5 and 7
>
> PE6.3: Steps 5 and 7
>
> PE 6.4: Steps 5 and 7
>
> PE 6.5: Steps 5 and 7
>
> PE 6.6: Step 8
>
> PE 6.7: Steps 5 and 7
>
> PE 6.8: Steps 6 and 7
>
> PE 6.9: Steps 6 and 7
>
> PE 6.10: Step 8
>
> PE 6.11: Step 8

The same rationale is used for PE3.1 and the subsequent transactions and
inquiries.

### Use Subaccounts for FACTS Attributes

#### A. Description of Test Execution Variance

Use of sub accounts, which are accounts that represent posting at a
lower level than the 4 digit SGL account format.

#### B. Reason for Variance

The reason for this variance is to provide the ability to capture one or
many of the 22 FACTS1 and/or FACTS2 attributes required by the US
Treasury through the use of general ledger sub accounts.

#### C. Benefit to the Government

The benefit of the use of sub accounts for capturing the FACTS
attributes is two fold: 1) it allows the capture of the FACTS attributes
and 2) it eliminates the need for the user to individually have to enter
one or many of 20 of the FACTS attributes directly on the originating
transaction. This should streamline data entry, while still providing
the ability to capture the FACTS-related attributes.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

Sub accounts used for FACTS I and II attributes:

+--------+------------------------------------+-------+---------------+
| A      | Account Description                | F     | FACTSII\      |
| ccount |                                    | ACTSI | Attribute     |
|        |                                    | Attr  |               |
|        |                                    | ibute |               |
+========+====================================+=======+===============+
| 1310C1 | Accounts Receivable---Non          | A     |               |
|        | Custodial for FACTSI               |       |               |
|        | Custodial/Noncustodial attribute   |       |               |
+--------+------------------------------------+-------+---------------+
| 1310C2 | Accounts Receivable---Custodial    | S     |               |
|        | for FACTSI Custodial/Noncustodial  |       |               |
|        | attribute                          |       |               |
+--------+------------------------------------+-------+---------------+
| 1319C1 | Allowance for                      | A     |               |
|        | Loss---AR---Noncustodial for       |       |               |
|        | FACTSI attribute                   |       |               |
+--------+------------------------------------+-------+---------------+
| 1319C2 | Allowance for                      | S     |               |
|        | Loss---AR---Custodial for FACTSI   |       |               |
|        | attribute                          |       |               |
+--------+------------------------------------+-------+---------------+
| 4114P1 | Appropriated Trust or Special Fund |       | Authority     |
|        | Receipts---Public Law and          |       | Type = 'P'    |
|        | Authority Type for FACTSII         |       |               |
|        | Attribute                          |       | Public Law =  |
|        |                                    |       | 107-200       |
+--------+------------------------------------+-------+---------------+
| 4114S  | Appropriated Trust or Special Fund |       | Authority     |
|        | Receipts---Public Law and          |       | Type = 'S'    |
|        | Authority Type for FACTSII         |       |               |
|        | Attribute                          |       | Public Law =  |
|        |                                    |       | 107-200       |
+--------+------------------------------------+-------+---------------+
| 4119   | Other Appropriations               |       | Public Law =  |
|        | Realized---Public Law for FACTSII  |       | 106-001       |
|        | Attribute (tied to Fund Code)      |       |               |
|        |                                    |       | Public Law =  |
|        |                                    |       | 107-001       |
|        |                                    |       |               |
|        |                                    |       | Public Law =  |
|        |                                    |       | 107-003       |
+--------+------------------------------------+-------+---------------+
| 4119P1 | Other Appropriations               |       | Public Law =  |
|        | Realized---Public Law for FACTSII  |       | 107-002       |
|        | Attribute (tied to Fund Code)      |       |               |
|        |                                    |       | Public Law =  |
|        |                                    |       | 107-102       |
|        |                                    |       |               |
|        |                                    |       | Public Law =  |
|        |                                    |       | 107-103       |
+--------+------------------------------------+-------+---------------+
| 4119P2 | Other Appropriations               |       | Public Law =  |
|        | Realized---Public Law for FACTSII  |       | 107-103       |
|        | Attribute (tied to Fund Code)      |       |               |
+--------+------------------------------------+-------+---------------+
| 4119P3 | Other Appropriations               |       | Public Law =  |
|        | Realized---Public Law for FACTSII  |       | 107-104       |
|        | Attribute (tied to Fund Code)      |       |               |
+--------+------------------------------------+-------+---------------+
| 4175P1 | No Longer Used                     |       |               |
+--------+------------------------------------+-------+---------------+
| 4175P2 | No Longer Used                     |       |               |
+--------+------------------------------------+-------+---------------+
| 4395P1 | Authority Permanently Not          |       | Public Law =  |
|        | Available---Public Law for FACTSII |       | 107-102       |
|        | Attribute (tied to Fund Code)      |       |               |
+--------+------------------------------------+-------+---------------+
| 4395P2 | Authority Permanently Not          |       | Public Law =  |
|        | Available---Public Law for FACTSII |       | 107-102       |
|        | Attribute (tied to Fund Code)      |       |               |
+--------+------------------------------------+-------+---------------+
| 4450U  | Used in Fiscal Year End Closing.   |       |               |
+--------+------------------------------------+-------+---------------+
| 4510A1 | Apportionments---Available in      |       | Availability  |
|        | Current Period for FACTSII         |       | Time = 'A'    |
|        | Attribute                          |       |               |
+--------+------------------------------------+-------+---------------+
| 4510A2 | Apportionments---Available in      |       | Availability  |
|        | Subsequent Period for FACTSII      |       | Time = 'S'    |
|        | Attribute                          |       |               |
+--------+------------------------------------+-------+---------------+
| 5900C1 | Other Revenue---Non Custodial for  | A     |               |
|        | FACTSI Custodial/Noncustodial      |       |               |
|        | attribute                          |       |               |
+--------+------------------------------------+-------+---------------+
| 5900C2 | Other Revenue---Custodial for      | S     |               |
|        | FACTSI Custodial/Noncustodial      |       |               |
|        | attribute                          |       |               |
+--------+------------------------------------+-------+---------------+
|        |                                    |       |               |
+--------+------------------------------------+-------+---------------+

The list of scenarios that are affected by these sub-accounts is
provided in the cycle end variance to test step crosswalk spreadsheets.

A complete list of all accounts and sub-accounts with their related
attributes is available in the PeopleSoft setup data.

### Configuration for Allotment Withdrawals in Test Steps FM1.24 And FM1.25

#### A. Description of Test Execution Variance

The JFMIP Test Script FM1.24 and FM1.25 requests that PeopleSoft
demonstrate the capability to automatically withdraw allotments budgets.
The Withdrawal process utilizes a standard PeopleSoft process for
decreasing the budget. That same standard process calls a standard Entry
Event posting process and tells it to perform the reverse of an
increase. Therefore, the process reverses whatever configuration (debit
and credit setup) has been established on the Entry Event table. The
Entry Event defines the debit credit pairs that will be posted during a
transaction.

If an agency sets up this table as the SGL views the entry, it would not
achieve the desired result. The Agency, or its integrator, needs to know
that this posting is called from a budget decrease process, and thus
performs a reverse posting.

#### B. Reason for Variance

The reason for this variance is to use the delivered entry event
configuration along with the budget closing process.

#### C. Benefit to the Government

The agency only has to define one transaction code, or entry event, to
create or withdraw an allotment budget.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

None.

### Derivation of Public Law Numbers

#### A. Description of Test Execution Variance

Public Law Derivation---Public Law is derived from ChartField attributes
and validated as part of the FACTS II Validation Edits.

PeopleSoft derives the Public Law for a particular transaction using two
data elements---the Account and Fund. Based on the Account used in a
transaction, during the FACTS II Accumulation process, the application
retrieves the Fund Code Public Law Attribute associated with the
particular Account.

An example is provided below.

An Appropriation transaction (DR 4119/CR 4450) is entered for Fund
10134. As part of the FACTS II Accumulation process, the application
will look for the following Fund Code Attribute for Fund
10134---**XXXXXX-PL**, 4119-PL in this case.

![](media/image3.png){width="5.795833333333333in"
height="2.098611111111111in"}

Based on the configuration shown above, the FACTS II Accumulate process
will retrieve Public Law 107-103.

For Fund Codes that have multiple Public Law attributes, PeopleSoft uses
subaccounts (i.e. 4119P1, 4119P2) to differentiate the transactions.
Entry Events can be setup and named to indicate the proper subaccount or
Public Law.

Below is an example of the Fund Attributes for a Fund Code with multiple
Public Laws.

![](media/image4.png){width="5.993055555555555in" height="2.11875in"}

If an Appropriation transaction is entered with Account 4119, then
Public Law 107-001 will be retrieved. If the transaction is entered
using SubAccount 4119P1, then Public Law 107-103 will be retrieved.
Agencies will only need to use subaccounts when more than one Public Law
exists for a single account for a single fund.

#### B. Reason for Variance

JFMIP expects the Public Law to be entered on funding transactions.
PeopleSoft derives the Public Law values through configuration and edits
them during the FACTS II Validation processing.

#### C. Benefit to the Government

PeopleSoft does not require user input of each Public Law number on a
transaction-by-transaction basis. Agencies can configure this
information to default, based on the Fund and Account values. Since this
value is derived, agencies can easily correct errors through setup.

#### D. Resulting Changes to the Test Materials (list individually by test step number, report name, or other reference)

The FB3.3 scenario was entered using an incorrect entry event.
Therefore, the Public Law was not derived correctly. Instead of
validating the Public Law for this scenario, JFMIP will review the FACTS
II Validation Edit report to ensure that this user error is identified.