Skip to main content

System Status: 

Default Project Payroll

The Default Project Payroll report provides payroll details for transactions on a department default project that need to be corrected, as well as information about non-payroll transactions. It provides the information you need to complete Direct Retros or complete a DrPat file for processing by your VC area.

Overview

Access the Report through the Business Analytics Hub

Access to this report is provisioned to users who have access to the DOPES report. To request access to this report and the DOPES report, submit a UCPath Cognos Reports Access Request. Request access to the Payroll Accounting and Reconciliation group of reports.

  1. Navigate to bah.ucsd.edu.
  2. Select Budget & Finance.
  3. Click the Financial Accountability tab.
  4. Click Launch from the Default Project Payroll tile.
Use your Active Directory credentials to sign in, if prompted.

Prompts

  • Use the dropdown menus on the prompt page to select an Entity (VC area), Division, and/or Department.
  • Selecting an Entity or Division will narrow the choices for the lower-level dropdowns.
  • Search directly for a department by clicking the dropdown and typing the name of the department. The selection will jump to the correct place in the list.
  • Don't see your department in the list?  Congratulations! You have no default project transactions needing correction.

How does the report work?

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. It also removes other non-payroll lines that have been fully reversed. It then takes the remaining list of transactions and pulls in information from the UCPath Labor Ledger about the person and Labor Ledger chartstring.

It 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. After this matching is done, the report performs a second round of eliminations to remove transactions that have been corrected via Direct Retro. What remains should be only transactions still requiring correction.

How do I use the different tabs?

It is critically important that you analyze the data in the entire report before processing Direct Retros based on the information in the report. Failing to do so could lead you to process unnecessary Direct Retros or generate errors that themselves need to be corrected later. Read the entirety of the instructions in this document before proceeding.

The Oracle + LL pivot tab provides a summarized view of the final output of the report.  It shows amounts from the Labor Ledger by Account Code, Employee Name, and Expenditure Date.  You may see salary amounts with no associated name. To understand how to deal with these, see ‘Why do I see payroll rows with no Labor Ledger information?’ below.

The Oracle Pivot tab provides a summarized view in the same layout as the Oracle + LL pivot tab, but uses data from Oracle only, before transactions have been matched with Labor Ledger information.  Compare totals by account code between the Oracle + LL pivot tab and the Oracle Pivot tab. If the amounts are the same, the amounts on the Oracle + LL pivot tab can be trusted. If you notice differences, compare the amounts by Expenditure Date to understand where the differences come from.

If the amounts for a given Expenditure Date match between the two tabs, the amounts for that Expenditure Date can be trusted. Each value on the Oracle Pivot tab is a link to a drillthrough report that provides more detailed information about the Oracle transactions behind the number. To understand further why there might be differences, see ‘Why do I see transactions I’ve already moved off?’ below.

The Oracle + LL Summary tab provides the same information as the Oracle + LL Pivot tab, but with Expenditure Dates in rows and Account Codes in columns. This allows you to see all transactions for a person on a single row, and is provided as an alternative way for you to view the data.

The Oracle + LL Detail tab provides detailed transaction information using the same query as the Oracle + LL pivot tab. 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. Use the information in the Detail tab to complete Direct Retros or Oracle cost transfers, or download the report to Excel and copy/paste the last seven columns into a DrPat template. When performing Direct Retros, only salary (usually account codes 500000 and 501000) needs to be moved and the remaining associated charges will move with the salary. See 'Do I need to do a Direct Retro or an Oracle Cost Transfer?' below to determine the correct course of action using the data in this tab.

Why do I see transactions I’ve already moved off (rows in red)?

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 Direct Retro, 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 Oracle Pivot tab and the Oracle + LL pivot tab, 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 red on the Oracle + LL Detail tab.

If you see rows in red, 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 red 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 red on the Oracle + LL 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 red.
  • The drillthrough from the Oracle Pivot tab is helpful in investigating these situations.

Why do I see payroll rows with no Labor Ledger information?

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 Labor Ledger fields will be blank. 

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, search for the Original Transaction Reference number in the DOPES report to identify the associated person.  Check to see 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. 

Why do I see negative amounts?

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

To verify, take the following steps:

  1. Run the DOPES report for the Employee Name and Earnings Period End Date of the PT transaction in question. 
  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. Run the Project Costs Detail Report on the Business Analytics Hub for the Original Transaction Reference number for the original payroll transaction.  Expand the date range to include all dates.
  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.

Do I need to do a Direct Retro or an Oracle Cost Transfer?

The UCPath Project and Task is the Default Project

The UCPath Project and Task is where the payroll should be in Oracle as well

The Task End Date is after the Expenditure Date

Action

No

Yes

N/A

Oracle Cost Transfer

No

N/A

Yes

Oracle Cost Transfer

No

No

No

Direct Retro

Yes

N/A

N/A

Direct Retro

Additional Useful Job Aids

Demo

View a live demo of the report on the Budget & Finance YouTube channel

Find answers, request services, or get help from our team at the UC San Diego Services & Support portal.