If a high risk direct retro is approved by both approver levels at UC Berkeley (if CGA is the 2nd approver level, for example), does it still go to someone at UCPC?
No, when it is approved at the location it goes into ledger directly.
If retroactive pay is issued after a Direct Retro or Funding Change is processed, will the system know?
Position funding for retroactive pay is based on the funding at the time the pay should have been received. If a Direct Retro has previously been completed, the current distribution will not be based on the updated Direct Retro distributions.
The best practice is that any time a Direct Retro is completed, the user should navigate back to the Position-Level funding on Funding Entry Page and make any necessary updates to the funding distribution data. Keeping the Funding Entry Page in sync with processed cost transfers is an optional, location-only business process.
On Direct Retros, if the federal fund is greater than 120 days and we're not changing the fund, rather only the CF1 field, for example, will it be considered high risk?
Definition of high risk Direct Retro:
Violates the 120 Day Rule: Increases the expense on a Federal or Federal Flow-through fund where the transaction is on a payroll transaction for which the original Pay End is prior to [SysDate – 120]
Violates the 90 Day Rule: Increases the expense on a Federal or Federal Flow-through fund where the Fund/Grant End Date is prior to [SysDate – 90].
You can select multiple paychecks at the same time for a single transaction, but you still have to make the adjustment for each one.
Yes. If the parameters for high risk are met, then you will not be able to save the transaction without completing the questionnaire. All high risk Direct Retros have another level of approval (Controller's Office Contracts & Grants).
No, dollar amounts only.
Direct Retros move all associated benefits/fringe with the salary. If a location desires to move fringe only they will need to utilize Benefit Cost Transfer functionality in Path.
Only one Direct Retro transaction can be submitted for the same paycheck. No additional changes can be made until the Commitment Accounting (CA) process runs to process that Direct Retro.
Commitment Accounting (CA) process will run to post fully approved Direct Retros several times per week.
There are reports that will be available to see if there are any suspense items. No system notification will be sent regarding items in suspense.
Transaction errors go to suspense chartstring as follows:
Salary account associated with the employee, fund 69995, a Division level Dept ID code, the CF1 value noted below:
- CF1 = 900000: When a position is created but the position funding is not set up
- CF1 = 900001: When the payroll processing date is past the Funding End Date for the Earnings Distribution (generally applies to Contracts and Grants funds)
- CF1 = 900002: When the provided chartstring was valid at the time of initial entry input, but becomes invalid before payroll processing
The Direct Retro form has a Copy Transaction button that will allow the transaction to be copied, edited, and resubmitted for approval.
The questionnaire is only required for high-risk Direct Retros. The current 120 day/90 days rules for Federal funds/Federal flow-thru funds apply. The questionnaire is not required for other funds.
If you have entered a capped fund and the employee's Total UC Salary value exceeds the salary cap rate, the system prompts you to use the Direct Retro Salary Cap/MCOP Funding Worksheet.
Attributes of the Fund are sourced from Chart of Accounts data coming from Berkeley Financial System (BFS).
Yes. Once Direct Retros are initiated, approved, and processed, they will be available in Berkeley's General Ledger (BFS).
Once the Commitment Accounting (CA) batch has run, processing the transaction, additional updates can be made for the pay period.
Yes. You can move all or part of your existing funding to one or more funding accounts.
You can use a Direct Retro to reallocate the distributed money, and add an effective dated row to your Position Funding to reflect the changes.
If an employee is funded by multiple chartstrings managed by more than one department, who initiates the Direct Retro transaction?
The department that owns the position (rather than the department that owns the funding).
For example, if an employee works primarily for department A and their position is funded by department A and partially by department C, department A would initiate the Direct Retro and enter the chartstrings for both departments A and C. If approval is required from department C, department A can attach approval documentation to the Direct Retro transaction.
No. Direct Retro allows for the redistribution of funding or split funding between multiple funding sources. However, the Earnings Code cannot be changed.
Can someone in Payroll view the transactions that are being approved? What would trigger someone outside the department to review the approvals?
An Ad-Hoc reviewer can be added for reviewing transactions.
Can I view the status of Direct Retro transactions in my department, regardless of whether I am the initiator or not?
The initiator cannot see the list of transactions initiated in the Worklist, however, you can review the status of your Direct Retro transaction by navigating to PeopleSoft Menu > UC Workcenter > Review Retro Distribution. Departments can view transactions by search parameters such as EMPLID, Initiator, etc.
No. In UCPath, you cannot be both the initiator and approver for any transaction.
Yes, you can change the order during your active session by using the Personalize link. However, we encourage users to familiarize themselves with the default order defined by UCPath.
MCOP refers to employees who have more than one earn code. You should use the Direct Retro Salary Cap/MCOP Funding Worksheet to complete your Direct Retro transaction for employees with MCOP.
These are delivered components in PeopleSoft and currently not being used in UCPath.
All pay periods processed by UCPath beginning March 2019 will be available for Direct Retro activity. UCPath payroll data is not purged.
The system will not auto-populate Project Costing (PC) Chartfields.