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.

The Default Project Payroll is available from the Business Analytics Hub (bah.ucsd.edu) under the Payroll Accounting and Reconciliation tab.

Report Demo

You can find the Default Project Payroll Report Demo on the UCSD Budget & Finance YouTube channel, BI & Financial Reporting playlist.

Access

Access has been provisioned to anyone with the Oracle BI Consumer JR role.  Staff who do not have access should request the Oracle role. 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. 

Navigation

  • 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
  • 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.

 

DPP prompt

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. 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.

Do I need to do a UCPath Salary Cost Transfer 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

UCPath Salary Cost Transfer / Direct Retro

Yes

N/A

N/A

UCPath Salary Cost Transfer / Direct Retro

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.

Release Notes & Communications


Date Release Notes & Communications
11/14/2023 Budget & Finance Weekly Digest

Previously, Employee Name and UCPath Project, Task, and Funding Source were only populated for UCPath-source transactions.  We have now extracted those values from the Expenditure Comment for NGN and HSIT transactions where available. As a result, NGN and HSIT transactions will now appear together with the corresponding payroll transactions in all parts of the report. 

On the Oracle + LL Details page, new columns have been added for Position Number and Fund Manager.  The columns have also been reordered to bring employee information together, followed by information about responsible individuals, followed by UCPath chartstring information.

12/12/2023 Budget & Finance Weekly Digest

Changes were made to modernize and standardize the look and feel of the prompt pages across all financial Cognos reports. Specific changes that were made include:

  • Section headers: Prompts are now grouped categorically so that they are always nested under the same section for every report
  • Standardized buttons:
    • Direct links to services, support, and documentation for extra help are now consistently available
    • Reset and finish buttons are now at the top and bottom of every report
  • Standardized prompts: All prompts are now consistent with each other on every report

 

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