Default Project Payroll

Access has been provisioned to anyone with DOPE Report access. Staff who do not have access should request UCPath Cognos reports access to Payroll Accounting and Reconciliation. Access failure appears as error "Unable to load requested view. Displaying home view instead."

1. Navigate to bah.ucsd.edu. 
2. Select Budget & Finance. 
3. If using the List View, look for Default Project Payroll in the list or use the search bar at the top right and click the dashboard name  
   • If using the Card View, click the Payroll and Reconciliation tab and click Launch on the Default Project Payroll tile 
4. Use your Active Directory credentials to sign in, if prompted. 

The Cognos and Oracle Tips & Tricks page shares various recommendations on navigating report functionality

• Use these parameters to filter for the data you want to view
• These filters can be used in combination or individually to produce desired results
• Choose which pages of the report you need to conduct your analysis.  

• Focus on a particular Expenditure Date range to speed up the run time. Note that some transactions net to zero across expenditure dates, so selecting particular dates may return different results than running the report without a date filter. In addition, if focusing on 2020 transactions, do not select a range less than May-October 2020.  

• Select a financial unit to examine default project transactions on that financial unit's default project.  Financial unit can be selected at the L2 (VC Area), L3 (School), L4 (Department), or posting level.  Selection of a higher level will filter the lower levels.

• You can also select a specific default project to examine using the Default Project prompt. 

• Selecting an Original Project will identify transactions on default projects that are associated with that project in the Labor Ledger or where that project appears in the Expenditure Comment of the transaction. 

• Selecting a Home Department will identify transactions associated with certain individuals based on their position home department in UCPath. Non-payroll transactions will not be identified.
• Selecting an Employee will identify transactions associated with that individual. These may be payroll transactions or non-payroll transactions where the employee's name appears in the Expenditure Comment.
• In some cases, particularly for payroll in the May-October 2020 period, the report is unable to identify the person associated with payroll transactions.  These rows will not be reported when selecting Home Department or Employee.

 Optimizing Performance

This report can be very slow when running all pages for an entire default project, especially for very large financial units.  There are a few strategies you can use to improve performance.

• Summary pages (Oracle + LL Pivot, Oracle + LL Summary, PPM Only) run faster than detail pages. Run a summary page for the entire default project first to figure out where you want to focus.  We recommend choosing PPM Only as well as either Oracle + LL Pivot or Oracle + LL Summary.  See detailed page descriptions below.
• Use a summary page to determine the date range, original project, or employee you want to focus on, then re-run the report for that specific date range/project/person to get the detail. 
• When selecting an original project, employee name, or home department, the report will run faster if you also select a specific financial unit or default project.
• If your department's practice involves downloading the Detail page for the entire default project monthly or weekly, schedule the report to run in the middle of the night (avoid the 5-8 am window, when new data is being loaded) and email you the results as an Excel file. See the KBA on how to schedule Cognos financial reports for monthly delivery.
• The Oracle with Names page takes about 0.5 seconds per row.  Use this page for targeted troubleshooting only.

Step 1. The report starts by identifying all transactions on department default projects in Oracle. It then performs a series of eliminations to remove transactions that have been fully reversed via PPM cost transfers, as well as entire account codes or expenditure dates that have been resolved. It also removes other non-payroll lines that have been fully reversed.

Step 2. The report takes the remaining list of default project transactions and uses the Original Transaction Reference number (OTR) to identify the project, task, and funding source (PTF) associated with that OTR in the Labor Ledger.  Each OTR only has one PTF in the Labor Ledger. The report also identifies the PTF indicated in the Expenditure Comment on non-payroll transactions.  It performs another series of eliminations across each PTF.  This step of the process uses only PPM dollar amounts.  The PPM Only and Oracle with Names pages use the data from this step.  Extensive testing has shown that there is no difference between Step 2 amounts and Step 1 amounts.

Step 3. With the remaining set of transactions, the report looks for a three-way match between the Oracle transaction and the Labor Ledger transaction using the Original Transaction Reference number, the Account Code, and a match between the Expenditure Item Date in Oracle and the Earnings Period End Date in the Labor Ledger. It uses the match to bring in information about the person paid and the Labor Ledger dollar amount.  If no match can be made, for example due to a mismatch between the Expenditure Item Date and Earnings Period End Date, no person information will be identified for the transaction. 

Step 4. The report calculates a dollar amount for the transaction.  If the Oracle transaction came directly from the Labor Ledger (i.e. a regular payroll, Direct Retro, or Salary Cost Transfer transaction), the dollar amount will come from the Labor Ledger amount for that person, date, and OTR.  If the transaction was from a PPM cost transfer, a manually-created PPM transaction, a transaction that was originally generated in Oracle (such as NGN, HS-TSC, etc), or if no match to the Labor Ledger could be made, the dollar amount will come from the PPM transaction.

Step 5. Using the amounts derived in step 4, the report does a final round of eliminations to remove rows that have been resolved for the person.  The Oracle + LL Pivot, Oracle + LL Summary, Detail, and SCT Prep pages uses the data from this final step.

Oracle + LL Pivot

This page summarizes the amounts resulting from Step 5 (above) by default project, Original PTF, employee name, account code, and expenditure date.  Accounts appear in rows and expenditure item dates appear as columns. 

Oracle + LL Summary

Similar to the Oracle + LL Pivot, but expenditure item dates appear as rows and accounts appear as columns. 

Detail

This page provides detailed transaction information using the data from Step 5 above. It has all of the information you need in order to process corrections.

• Columns in gold show information from Oracle, and columns in blue show information from the UCPath Labor Ledger or information associated with the Labor Ledger project.
• Columns in green have data that sometimes comes from Oracle and sometimes comes from the Labor Ledger. 
• On some rows, columns in turquoise indicate information about the project in the funding entry.  These columns will only be populated when:
  • The transaction posted to the default project in the Labor Ledger due to triggering of the I-370 validation (effective November 2023).
  • The transaction is original payroll, not a Salary Cost Transfer.
  • The transaction is salary, not fringe.
  • The dollar amount was unique for the paycheck.  If two projects in the funding entry resulted in posting to default and the same dollar amount was calculated for both projects, these columns will not show data.
• The Corrective Action column shows 'DR/SCT' or 'PPM Cost Transfer' using the logic outlined in 'Do I need to do a Direct Retro or an Oracle Cost Transfer?' below.  Always perform a DR/SCT when possible.  PPM Cost Transfers should never be used to move payroll transactions except in very specific scenarios.
• Click on the Corrective Action to drill through to the Payroll Transaction Lookup report for further detailed investigation. 
• Rows are highlighted in pink when there are multiple transactions in Oracle for the OTR.  This may indicate that partial PPM cost transfers have been done.  Incorrect amounts may be reported in these situations and further analysis should be done before taking corrective action.  NEVER complete split PPM cost transfers on salary.  

PPM Only

This page summarizes the amounts resulting from Step 2 (above) by default project, Original PTF, account code, and expenditure date.  Accounts appear in rows and expenditure item dates appear as columns.   This page should be used to validate the amounts you see in the pages above and should be considered the source of truth.  There are cases, such as with split PPM cost transfers, where the amounts calculated in Step 4 above are incorrect.  If you see differences in amounts between the PPM Only page and one of the other pages, the amounts on PPM Only are correct, and future investigation is needed for the transactions provided on the Detail page.

Oracle with Names

This page provides a list of transactions resulting from Step 2.  All dollar amounts come from PPM.  An additional table is embedded into each row to provide all of the employee names associated with the OTR in the Labor Ledger.  This additional embedded table causes the page to run very slowly when thousands of rows are requested, so we recommend using this page selectively.  When you see highlighted rows on the Detail page or mismatches between the amounts on the PPM Only page vs another page, use this page to troubleshoot what happened.

SCT Prep

This page is provided for departments that request Salary Cost Transfers to be done by another unit. No dollar amounts are included on this page.  Only information required to prepare a Salary Cost Transfer is included.  Additional blank columns for the TO chartstring and cost transfer justification are provided.

As noted above, the report eliminates transactions that have been fully reversed with an Oracle PPM cost transfer. If an Oracle payroll transaction has been split and partially reversed with an Oracle cost transfer, even if the remaining part of the transaction has been moved off with a Salary Cost Transfer, the report is unable to eliminate the transactions. It will then pull in all of the people associated with that Original Transaction Reference number; it cannot identify which people were moved off with the partial Oracle cost transfer and which were not.

If you see differences between the PPM Only page and the Oracle + LL pivot page, this may be the reason. To help you with this situation, rows where there is more than one Oracle transaction with the same Original Transaction Reference number have been marked in pink on the Detail page.

If you see rows in pink, you must independently verify whether those transactions have already been reversed with an Oracle cost transfer.

If they have, DO NOT additionally process a Direct Retro. The rows will fall off of the report once all other transactions for that Expenditure Date have been corrected.

There are some additional reasons why rows may appear in pink that are unrelated to partial Oracle cost transfers:

• The same payroll transaction may have erroneously posted twice in Oracle.  Even after these duplications have been corrected, the transactions will appear in pink on the Detail tab.
• Summer salary benefit corrections that posted only in Oracle use the same Original Transaction Reference number as the original salary transaction.  These rows will also appear in pink.
• Manually-created correction transactions use the same OTR as the original salary transaction. These rows will also appear in pink.

The report performs a three-way match between Oracle and Labor Ledger using Original Transaction Reference number, Account Code, and Expenditure Date/Earnings Period End Date.  If it is unable to make a match using all three data points, it will return the dollar amount from the Oracle transaction, but all fields related to the employee. 

In the first few months after the launch of UCPath and Oracle, there were some errors in the integration between the two systems that caused Oracle transactions to post with a different Expenditure Date than the Labor Ledger Earnings Period End Date, preventing this three-way match. 

For these rows, use the Oracle with Names page to identify the people associated with the transaction and determine whether the transaction offsets another transaction for the same person.  If it does, do not process any additional correction for either transaction, as they have already been corrected.

Summer salary benefit corrections posted only in Oracle using the benefits Account Code (508000) but the Original Transaction Reference number from the original salary transaction.  This situation also prevents the three-way match. 

Most commonly, negative amounts appear on the report when salary has been moved off of the default project with an Oracle cost transfer.  If the Original Transaction Reference number contains ‘PT’, this is most likely the situation.

To verify, take the following steps:

Option A:

1. Navigate to the Oracle + LL Summary tab.
2. Click on the Expenditure Item Date for the row with the negative amount.  This will take you to the Payroll Transaction Lookup Report for that person and earnings date.
3. Review the rows with the account code associated with the negative amount.  If the cost was transferred off twice, you will see rows for the Salary Cost Transfer as well as rows where the Transferred From and Adjusted Transaction Number columns are populated, indicating a PPM cost transfer of the payroll cost. Refer to the Payroll Transaction Lookup Blink page for an example.

Option B:

1. Run the DOPES report for the Employee Name and Earnings Period End Date of the PT transaction in question. If funding was split between many projects, it can also be helpful to include the UCPath project number in the search.
2. Identify the Original Transaction Reference number for the original payroll transaction.  This transaction will have the earliest Pay Period End Date, be on a salary account code, and have an Original Transaction Reference number containing PJ.
3. Click on the Original Transaction Reference number for the original payroll transaction to see Oracle financial transactions with that Original Transaction Reference number on the Transaction Details report.
4. If the original payroll transaction was moved via cost transfer, you will see at least three rows: the original transaction, the reversal transaction, and the new transaction.  If you only see one row, there was no cost transfer.

To correct these, another Oracle cost transfer will need to be processed to reverse the duplicative cost transfer.

There are other less common scenarios as well:

• There may be situations where a salary reduction was processed and posted to the default project.  These negative amounts will have a ‘PJ’ in the Original Transaction Reference number.  You can process Direct Retros for these as with any other salary transaction.
• In some cases, due to problems with the integration between UCPath and Oracle, transactions posted with the wrong expenditure date (see 'Why do I see payroll rows with no Labor Ledger information?' above).  In these cases the report may not be able to match a payroll transaction with the Direct Retro transaction moving it off the default and both rows still appear on the report.  Use the Oracle + LL Pivot tab to identify amounts that net to zero, typically in the May-September 2020 timeframe.  These amounts can be disregarded.
• Some Direct Retros caused a credit to post to the default project even though the original payroll charge was not on the default.  Follow the steps outlined above to determine where the original payroll charge posted in Oracle.  These cases need to be corrected with an Oracle cost transfer.

• How to Determine What Corrective Action to Take to Clean Up Defaulted Payroll
• How to Find the Payroll-Related PPM Transactions for an Oracle PPM Cost Transfer
• How to Perform a Payroll-Related PPM Cost Transfer