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. 

Here you can find various tips and tricks on navigating Cognos 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
• 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.

 

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

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.

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. 

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:

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 Direct Retro or 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.

The UCPath Project is the Default Project OR the task/funding source is missing	The Expenditure Date is between the Task Start and End Dates of the UCPath Project-Task	Action
No	Yes	Oracle Cost Transfer
No	No	UCPath Salary Cost Transfer / Direct Retro
Yes	N/A	UCPath Salary Cost Transfer / Direct Retro

• 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

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.

Date	Release Notes & Communications
3/12/2024 Budget & Finance Weekly Digest	Discontinuation of Direct Retro Processing Automation Tool (DrPat) The Direct Retro Processing Automation Tool (DrPat) has been discontinued due to incompatibility with the new Salary Cost Transfer (SCT) Tool. Users can continue to submit their Direct Retros and SCTs directly into UCPath. While DrPat is no longer being used, staff in Health Sciences can submit Hypercare Transactional Request tickets through ServiceNow for assistance with submitting Direct Retros and Salary Cost Transfers, while staff in Academic Affairs can reach out to their respective Fiscal Tiger Team contact.
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
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.