FAQs for Transactional Users provide answers to questions about processing transactions in UCPath including Position Funding, Direct Retro, Additional Compensation, and more.
The Office of the Chief Financial Officer has also begun a list of frequently asked questions and answers related to UCPath implementation with the general ledger and Cal Answers reporting.
Use the lookup icon to search for an employe by name or employee ID.
A basic overview of leaves that can be recorded include:
- Sick leave
- Family & Medical Leave Act (FMLA)
- California Pregnancy Disability Leave Law (PDLL)
- California Family Rights Act (CFRA)
- Worker’s Compensation
- Jury Duty
- Military, etc and/or any leave the employee is eligible for depending on their type of employment/appointment, or their employment agreement(s).
LAH Original Hours stands for Leave Accrual Hours Original Hours.
SAH Original Hours stands for Sabbatical Accrual Hours Original Hours
FML Original Hours stands for Family Medical Leave Original Hours.
HBE Original Hours stands for Hours Toward Benefit Eligibility Original Hours
HCS Original Hours stands for Hours Toward Career Status Original Hours
Working Hours: Because UCPath does not maintain the employee’s actual work schedule, this field displays 80 hours for biweekly employees. For monthly employees, the number of working days Monday-Friday in the pay period, including holidays, is multiplied by 8. For contract pay employees, the number of contract work days is multiplied by the number of contract daily hours.
Disability leave requires an employee use 20 days of their bank before Paid Disability is activated, is a second leave entry required after those first 20 days are used?
Leaves should be recorded based on a combination of the employee's available sick, PTO and/or vacation balances, and their desire to use them. A second unpaid leave is requested if the employee does not have sick, vacation, PTO to use and/or they have decided they will not use their balances.
Yes. There is a calculation based on Position, date of hire and hours worked.
Because Family & Medical Leave Act (FMLA) is commonly entered after an absence is started, how and where are over/underpayments entered or reflected in this system?
FMLA usage hours should be entered using CalTime by choosing the appropriate usage code such as FMLA sick, FMLA vacation, and FMLA PTO hours. Overpayments will be reconciled by the UCPath Center during payroll processing.
What kind of turn around will UCPC deliver when a Family & Leave Act (FMLA) absence is recorded? How will that affect payroll?
The UCPath Center will follow their SLA (service level agreement) regardless of leave type. Any leaves processed before the payroll cutoff will affect current paycheck.
Who can add retroactive Absence Management entries into UCPath? What documentation is required if the action is retroactive?
An initiator can add retroactive leave. No additional documentation other than the required documentation based on the type of leave is required (e.g., doctors notes, return to work documentation, etc.)
Initiation, Approval, and Maintenance of leave status are all location (campus) based activities. UCPC reviews the leave request and facilitates the update of the job record in the UCPath system based on the information in the Extended Leave Request.
If an employee chooses to go on leave or must go on leave, how is that information entered in UCPath if the available sick and vacation accruals are 0 totals?
In UCPath, the initiator makes a selection of an unpaid leave on the Extended Absence Request form.
After each payroll cycle accruals will be updated in CalTime.
Sabbatical Credits will be available in UCPath as of July 1. UCPath will update accruals ongoing and serve as the system of record. There is system functionality to attach documentation such as sabbatical reports.
Additionally, a warning code will come up to indicate if no sabbatical credits are available.
Employees will have visibility to leave accruals and usage in the Employee Self-Service (ESS) by pay period.
On the Extended Leave Request form, Family & Medical Leave Act (FMLA), CaliforniaPregnancy Disability Leave Law (PDLL), and California Family Rights Act (CFRA) hours and eligibility are captured in addition to the employees available sabbatical, sick, vacation, and PTO balances.
Does the return to work date/end date auto return an employee to their current job, or does it require action?
The return to work date does not automatically return a person to work. The location must also initiate a return to work action in UCPath.
If an employee changes from Intermittent leave to Block leave (e.g., full day or more usage), how will that be processed in UCPath?
A second leave request must be submitted and the usage must be coordinated with the UCPath Center (and possibly manager/ department in order to capture any).
Intermittent leave should be captured by placing an employee on an intermittent leave via the Extended Absence Request form. Positive hours and leave hours should be recorded in CalTime. The interface from CalTime will update UCPath.
Must a return date be entered into the UCPath Absence Management form when the leave is logged, and does it require approval? If the Return date is updated, does that have to be approved too?
Yes, a return to work date is a required field on the Request Extended Absence form. If the return date is updated, approval is required.
No. This process still needs to be monitored at the campus location.
Per UCPC Prudential receives a monthly report from Liberty Mutual that lists employees that have been on disability. Prudential sends a Waiver of Premium packet to the employees on the report. The employees can apply for the waiver when they receive the Waiver of Premium Packet in the mail or they can also choose to apply on the vendor’s website. Once the vendor reviews the Waiver of Premium application, UCPC receives a letter of Approval/Denial.
The employee should reach out to the vendor for updates on their claim or questions with the process
The system does not allow the overlapping of two concurrent leaves of the same leave type and reason. This is a hard restriction. For example, the system does not allow Family & Medical Leave Act (FMLA)/California Family Rights Act (CFRA)/California Pregnancy Disability Leave Law (PDLL) for Employee SHC (Serious Health Condition) leave to be entered for the same duration or if the leave start date and expected return date overlaps.
If a leave is not FMLA-related, then they can concurrently exist with a FMLA leave.
A second leave request must be submitted and the usage must be coordinated with the UCPath Center (and possibly manager/ department in order to capture any necessary revisions to CalTime).
Yes. Also, comments are required if a leave is denied.
No, UCPath will only allow employees to accure hours up to their maximum. The UCPath system decrements usage before it applies accruals.
Only Military caregiver and Family & Medical Leave Act (FMLA). Other historical leaves will not be available (neither will pay history).
Current employees on active leave were converted into the UCPath system. Records of employees who were on leave during conversion (March 2019) should be closely reviewed.
No, percentages must be submitted as positve amounts.
We can request it as a change request but it will need to get approved by all Locations and it will definitely not be done by Go Live.
If an employee is paid using an incorrect chartstring, the payment can be transferred to the appropriate chartstring using a Direct Retro request (also known in current state PPS as a Payroll Expense Transfer).
What kind of notification will indicate that payment is being processed in UCPath (similar to Post Authorization Notifications)?
There are no specific notifications regarding payments being processed in UCPath. However, granted that you have the appropriate UCPath security/permissions, you can review specific employee’s paycheck/payroll data.
No. PAN notifications are sent out from Personnel and Payrolll System (PPS) to notify select individuals that transactions have been processed. PPS will no longer be used, thus PAN notifications will not exist either.
Merit increases should be submitted using PayPath only, not using the additional pay forms. If a retroactive merit increase is submitted, the system will compare the new salary to their current salary and automatically calculate and pay out the amount of retroactive pay that should be generated.
There are three exceptions to this process:
- The system will calculate and pay out amounts for only the earn codes that are eligible for retroactive payments. If the employee has an earn code on their record that is not eligible for retroactive actions AND the amount paid out for that earn code is dependent on the employee’s compensation amount (e.g., a specific percentage of their salary), then the retroactive amount owed to the employee for that specific earn code will not pay out. That amount needs to be manually calculated and paid to the employee by using the one-time additional payment form.
- If the latest effective-dated row for that employee is for an action that conflicts with the retroactive merit increase (e.g., if the employee transferred to a new job or got a promotion), then you must contact UCPath for assistance in processing that transaction.
- If the retroactive date applies to pay periods prior to Go-Live, then the retroactive pay will only be calculated and paid out for the pay periods that exist in UCPath. If the retroactive pay is needed for pay periods prior to Go Live (i.e., that were paid out using PPS), automatic retroactive pay will not be triggered and will have to be paid out manually as a one-time payment.
Yes. Routing to the approver groups will be based on which form it is, the department submitting the request, and the affected employee’s employee class. By default, all forms will only need one approver level, meaning that only one person needs to approve the request in order for it to process.
No. Additional Pay forms will show the same fields, regardless of employee type. However, some select fields may be filtered out based on the amounts input.
How do you enter a By Agreement (BYA/BYN) employee that should receive the same flat dollar amount every pay period?
If the By Agreement employee receives the exact same amount every pay period, then you can submit a Recurring Additional Pay request for that employee, entering the “Pay Period Amount” as the flat dollar amount that the employee should be receiving.
If the by agreement employee does not receive the same amount every pay period, then the request must be submitted via the One-Time Pay Additional form.
Is the Additional Pay amount request for a gross amount or a net amount? Could I choose between the two?
The amount submitted using the Additional Pay forms is the total/gross amount, not including any taxes and deductions that will be subtracted when payroll is processed.
The forms have a Gross-Up checkbox to indicate that the submitted amount should be the net amount that should be paid to the employee; if this checkbox is selected, the employee will receive the submitted amount exactly as their net amount and the department/chartstring will be charged for the additional amounts that would have gotten taken out in taxes/deductions (i.e., the true gross amount needed for the employee to get paid that amount as net).
If UCPath denies the transaction and pushes back to initiator, what is the process if that initiator is no longer an employee? Who is notified to problem solve the reason for denial?
The Approval Administrator (which is a new UCPath-specific role for UC Berkeley) will also be notified that a transaction was denied.
The Recurring Additional Pay form allows for document attachment. However, the One-Time Pay form does not have this functionality. If a document needs to be attached to the request, the one-time payment can be submitted using the Recurring Additional Pay form, with the effective and end dates adjusted to reflect one single pay period.
No, initiators cannot assign a specific approver. Once an initiator submits the request, it will be auto-routed to the appropriate Approver Group based on the Department, the selected form, and the employee class (also known as “appointment type” in current state).
Only one person in that approver group needs to approve for the workflow to move forward. However, the approver can select a specific ad hoc approver from a drop-down menu of approvers who have the appropriate permissions.
Additional Pay is for payments that are in addition to the employee’s base salary (e.g., stipends, bonuses). If the work-study student is owed additional hours that have not been paid to them, then this would not be the appropriate form to use and the hours should be submitted via the Off-Cycle/Final Pay form instead.
If the work-study student is owed additional pay for an action that is separate from their regular hours/salary (e.g., if the student has been given a STAR award), then this would be the appropriate form to use.
When you open an additional pay form, current payroll requests for that employee that have been submitted will be shown to the right of the new submission.
All transactions are kept indefinitely in UCPath.
Yes, some transactions allow cloning, but that is only in the event that the request has been rejected. No cloning functionality exists for the Additional Pay forms. UCOP has not provided a list of transactions that allow copying.
While most earn codes will stay the same, there will be some changes to existing earn codes. We will provide a “mapping” document to map from current-HCM-to-new-UCPath Earn Codes during training as well as a definition of every UCPath earn code and how they should be used. Title codes will be staying the same.
When you open an additional pay form, current payroll requests for that employee that have been submitted will be shown to the right of the new submission, thus allowing the Initiator to check if a specific request has already been submitted. It is up to the Initiators to check current requests and previous paychecks to ensure that they are not submitting a duplicate request; the UCPath Center is not responsible for this action and will process both updates.
What is the difference between processing Additional Pay through the Personnel and Payroll System (PPS) system vs. processing through a department award (DSAS)? Are there guidelines for which to use? How does CSS determine which method to use?
Contact your HR Business Partner for information abour DSAS and what guidelines/criteria are used to determine if they process pay out of PPS or DSAS. If specific payments are paid out of DSAS currently, they will most likely continue to be paid out of DSAS after we go live with UCPath.
There are fields in each Additional Pay form meant to identify the appropriate pay periods that the additional pay should apply to, thus allowing for retroactive submission. Note: You can only submit retroactive payments for earn codes that are eligible for retroactivity.
Additional Pay is defined as pay that is in addition to the employee’s regular base pay. Thus, “out-of-scope” requests for Additional Pay consist of inputting regular hourly and/or salary pay in current or previous pay periods. It also would not be appropriate for “rush”/off-cycle requests as well as final pay.
No. UCPath is the only system of record and payment for HR/Payroll actions that UC Berkeley will be using.
No. Additional Pay requests will be paid out using the employee’s regular on-cycle payroll. In order to “rush” a payment, you will have to fill out the Off-Cycle/Final Pay form in order for the additional pay to be processed during UCOP’s next available payroll run.
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.
Commitment Accounting (CA) process will run to post fully approved Direct Retros several times per week.
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.
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
If a Direct Retro transaction is denied by an approver, do I have to start all over again or can I make a copy of the request?
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 initiatied, 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.
No. Direct Retro allows for the redistribution of funding or split funding between multiple funding sources. However, the Earnings Code cannot be changed.
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.
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 naviagating 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.
No. UCPath will not generate automatic warnings to highlight upcoming leave end dates. However, UCPath will provide reports that identify upcoming leave end dates for a given department or organizational unit.
Yes. Designated employees within each department will have Inquiry access in UCPath to view employee data – including leave information. Additionally, they will be able to access UCPath data through UCPath reports.
Although UCPath will be the online system of record for HR and payroll data transactions, current local systems and paper personnel files will be retained for data that is not migrated to UCPath.
Not necessarily. If the recruitment is for a staff position for an existing vacant position, the same position number can be used. Otherwise a new position number will have to be created.
Yes. Funding is no longer tied to a position. However, a position must be created in UCPath before you can apply funding to it.
What are the timing constraints around direct retros? After we make a direct retro, will we still have to wait until the next accounting period to verify that changes were made correctly?
Departments will no longer have to wait until the end of the month payroll run to see transactions and verify direct retros. Direct retros occur in UCPath as soon as the transaction is submitted and processed in the nightly batch process. Completed direct retros will be fed to the General Ledger.
UC Berkeley will continue to use CalTime and will develop interfaces to UCPath throughout the initial phase of UCPath rollout. These interfaces will pass timekeeping data to UCPath for payroll and leave calculations.
A chartstring will be referred to as “FAU” (Full Accounting Unit) in the new system. If hours were distributed to the wrong FAU (a.k.a. Chartstring), the department should initiate a Direct Retro transaction to move the expenses to the correct FAU(s).
Initiator & Approval Workflow
Te Payroll team would complete this termination template as they do the others. It is largely the same as the other 2, the template type signals additional work downstream for UCPC/RASC.
What is the rounding system for FTE? Will the RA be able to enter distribution percentage down to several decimals?
FTE has six decimals. It looks like this: 1.000000
For employees transferring between departments, does the receiving department initiate the transfer?
Yes, the receiving department should initiate the transfer.
For Merits + TDIs what will the process be? Are we still doing mass salary updates and how will we catch the fall out?
Similar process to current state but it's managed by UCPC. UCB Compensation and APO will work with UCPath Center.
If one approval level is defined, then approve or deny are the only two options. If more than one level of approvals is defined, then pushback is an additional option.
Off-Cycle / Final Pay
In UCPath, Off-Cycle checks will default to the regular method of payment the employee has chosen. If the employee has already signed up for direct deposit, the payment will be directly deposited.
Merit Increases are a data change a department would make in the PayPath template, using Merit Increase as an action reason. UCPath will automatically generate the pay differential and include that retro pay on the next On-Cycle issue. No other form needs to be generated (for example, Additional Pay). However, there are positions with Earn Codes that are not eligible for Merit Increases.*
*If an employee has additional compensation based on a % of salary, and the earn code for that action is not eligible for retroactive pay, then the initiator would have to submit an additional pay request for the difference owed on the ineligible earn code.
Overtime would be recorded in CalTime which will feed payroll at UCPC for payment processing. If an employee’s status (non-exempt) allows OT, the OT will be paid.
Can retro-active hours or flat dollar amounts for a By Agreement (BYA/BYN) employee be processed on an Off-Cycle pay form?
Yes, retro-active hours can be processed for BYA/BYN employees in an Off-Cycle Pay form.
Bonuses should be submitted as a One-Time Pay using the One-Time Pay form and will be paid on their regular pay cycle. Since bonuses are generally paid on cycle, please refer to your department/regions policies for more information about Off-Cycle Pay.
As we transition to UCPath, some earn codes will be changed to meet UCOP guidelines.
CIA will change to “CNB” Coach Non-Base pay.
On the Off-Cycle form, the earn code options available will be defined by the employees’ pay group. As we go live, a job aid will be available that describes and lists earn codes.
All pay should be paid on a regular cycle whenever possible. Off-Cycle pay is often used in sensitive situations. Refer to your department/regions policies for more information.
On the left side of the Off-Cycle form, all current Off-Cycle pay requests, approved, denied, or pending will be available for view.
UCPath Center will provide payroll calendars, which will list the deadlines for Off-Cycle Pay. Requests must be submitted and approved by the listed deadlines in order to be processed. As we go live, UCPath Center calendars will be published.
The Home Campus will pay the employee for all work at all locations. The “home/primary” campus for the employee must be determined. If Berkeley is not the Home Campus and an MLA employee is owed pay, then you must contact the Home Campus on behalf of the employee to schedule the payment.
If Berkeley is the Home Campus, Off Cycle/Final Pay is processed per regular steps.
Can a position’s default chartstring be overridden in special circumstances - i.e. A grant funded employee has a large vacation accrual that must be paid as part of an employee’s Final Pay, but the grant may not be an appropriate funding source.
Yes, a chartstring can be overridden by checking the check box, and a new chartstring can be used.
The process depends on whether or not an employee has been paid for services prior to signing the Oath.
When an employee has been paid for services prior to signing the Oath:
- Submit an Inquiry with the subject "Damage Payment"
- Provide pay period(s) that need to be reversed
- Provide damage payment amount that should be paid (this should be in hourly increments)
- The UCPath Center will reverse the affected pay period(s) and generate the damage payment (DMG) via the off-cycle process. Any accrued vacation will be paid out to the employee.
When an employee has NOT been paid for services prior to signing the Oath:
- Submit a Payroll Request (E-087) for an off-cycle check.
- Provide comments that indicate that this is a Damage Payment (DMG)
- Provide Damage Payment amount to include hours by pay period, vacation, and any legally required benefits
- The UCPath Center will process the Damage Payment.
If an employee leaves on the last day of their pay period, would a Final Pay request need to be entered?
If the employee is leaving at the end of their natural pay period, then a Final Pay request needs to be submitted only if the employee has vacation/accruals that need to be paid out.
A Final pay request must be submitted if the employee has accruals and is owed those accrual hours. In addition, a Final Pay request must be submitted if the termination occurs in the middle of a pay period.
If there are no hours worked and no accruals exist in the current pay period in which the employee terminates, no Final Pay needs to be submitted- the pay will be naturally generated (and no further pay will be issued).
Yes, a chartstring/s can be added (or adjusted as desired) in UCPath for all employees.
Rows listing hours and a corresponding chartstring can be added one at a time.
The default chartstring is automatically applied in all rows; by checking the override box, blank chartstring fields will appear and the desired chartstring can now be entered.
The Off-Cycle pay request will default to charge the employee’s pre-defined positions’ funding/chartstring(s).
If the employee and Job Record are the same, multiple Off-Cycle Requests for pay can be combined into one request. By clicking the + sign, multiple earn codes can be added, with specific beginning and end dates in new rows (as many as are needed). There is no limit to the number of rows that can be added to an instance of an Off-Cycle request.
An Off-Cycle request form must be submitted separately for each job record as needed.
Amounts can be submitted in hours, flat dollar amounts, or percentages, depending on what is appropriate for the employee type and earn code. For example, to submit regular pay (earn code REG) for monthly exempt employees, you can enter a salary % value.
However, the same REG pay for biweekly employees would be entered using hours.
Since there is no Rush Check form, submit the request using the Off-Cycle Pay Form. After that transaction is submitted for approval, submit a separate request to UC Path Center to indicate there’s an Off-Cycle request submitted that is a rush, and needs to be processed.
An Off-Cycle check is any payment that is not paid on the employee’s regular “on-cycle” pay cycle (either monthly or biweekly). This payment can be necessary when employees miss a significant amount of pay (e.g., missed time card, incorrect hours). Though the processing frequency is still being finalized, off-cycle pay will most likely be processed 2-3 times a week, and the employee will be paid with their regular payment method (direct deposit vs. paper check). This process will be different from a “Rush Check."
Person / Job Data and PayPath
Yes, as long as the effective date of the range adjustment is after UCPath go live.
No, you would have to take active steps to generate payment.
The action would be to update the Job as is done in current state.
The list of Action/Reasons viewable during the demonstration in PayPath may have been limited by the type of employee, the tab being viewed (position or job or pay), and the action chosen.
The list viewed was not the full list which will be available in future transactions. More information about action/reason choices will be provided at a later date.
Short Work Break: Can you give an example of a Unit 18 where you would utilize a short work break? Would this not apply for continuing appointments that are only one semester a year?
The scenario envisioned by the team:
Someone is a lecturer in the Spring January 1 to May 31. The department decides they will also teach July 1-August 30. Instead of terminating their position, the process would be to extend the appointment through August (end date August 30) and then put the employee on a Short Work Break from June 1 to June 30.
Users will have view access to Job Data, so historical rows are visible. Forms are just a front end for adding transactions because UCPath is not allowing edit access to parts of the UCPATH system. The custom pay PayPath component brings together the ability to make Position + Job + Pay updates in one place.
Yes. Additional Pay for employees can be added in PayPath or by using the Additional Pay forms.
This business process needs to be defined as there will likely be some similarities because both current and future state use PeopleSoft design and permissions to access records and approve transactions.
The final step of entering information into Human Capital Management (HCM) is a current control in the onboarding process, assuring we have received all necessary paperwork. How do we make sure that the I-9, oath, etc., is done before we begin?
This process is part of the deep dive work the project and Subject Matter Experts (SMEs) will partner to define the business process, ensuring controls.
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.
Benefits follow the employee's salary.
Where can I find guidelines from campus around what documentation should be included/attached on particular transactions?
The Controller's Office would be responsible for these guidelines.
Is legacy HCM accessible for view-only access (for current vacant position information) after go-live?
Legacy HCM will be available through September 2019 for those who already have access. Legacy HCM data can be accessed through Cal Answers reports.
No. Each position requires its own funding. Funding is the same for a single-headcount or a multi-headcount position.
The approver should deny the transaction and the initiator should make the changes and resubmit the transaction for approval.
Yes! Effective Date for position funding must be equal to or later than the Effective Date of the position. The position must be created before you can fund it. Additionally, position funding Effective Date should be prior to the hire Effective Date in order to avoid any pay going into suspense.
Pool ID is used by the Work-Study unit to enter students' Work-Study codes.
Example: The Work-Study codes (e.g. C or G) will go into "pools" (e.g. Work-Study student in "G").
For more information, refer to the Office of Financial Aid & Scholarships.
Multiple Components of Pay. There is a link on the Position Funding page to access the Multiple Components of Pay worksheet to assist you with proper funding.
In rare cases, there may be a situation in Academics where the incumbent’s salary funding is sourced from a capped fund, exceeds over-the-cap (OTC) fund and the OTC default chartstring should not be used. What is the process to handle this scenario?
The earn code, "GAP" should be used for the amount that is over the cap. This step would act as a reversal of the amount above the salary cap.
It will only go to the department’s default chartstring if it’s a new hire, and no one has specified a specific chartstring. However, once funding has been set up, expired funding will go into suspense.
No. The approvals would be routed based on department, not funding.
No. The system will retrieve additional information for the fund code from various fund tables. Some fund attributes are capped/uncapped, annual cap rate. Additionally, the fund code lookup table is sourced from the Fund Attribute table.
The earn code for the additional pay with the chartstring is entered in the Position Funding form. If the additional pay was due to a stipend, the earn code for stipend, “STP,” along with the chartstring would be added in the form.
Are there additional reasons why funding would default to the general fund, other than the expiration date of a current fund?
Yes. A chartstring may be valid at the time of entry in Position Funding, however, it may become invalid prior to Commitment Accounting Actuals/General Ledger batch processing. This instance would result in an edit error being flagged and a default chartstring would be used.
No. The position funding record cannot be copied.
The user is not required to enter the account chartfields.
The system performs individual chartfield validation, but it will also validate the full chartstring.
Yes. However, if the funding end date expires, the system will pull from the suspense account.
Yes, as long as the funding effective date is between the budget begin and end date. You can enter a change in funding with an effective date in the past (e.g. use yesterday’s date) as long as that is a valid date for the position.
The funding effective date should be between budget begin and end date. There is no stated limitation for how far in the future (as long as it’s during the period in which the position is active).
There is no limit to the amount of many distributions that can be entered in the UCPath system. The limits in the current state are driven by PPS (Personnel Payroll System), which will not exist in the future state.
Can an incumbent employee and the replacement (new hire) employee occupy the same Position number during a training overlap period?
When hiring the replacement, use the same Position number. It is not necessary to update the Max Headcount on Position for this transitional overlap if it is for a limited period of time. The Position can be overallocated during the transition period, and will revert back to full once the original incumbent terminates.
June 2019 Update: The information below was most relevant in March, right around Go-Live time. While the information is still available in the Box folder, please keep in mind that the information in the Box folder is good to use, represent the initial conversion, but will will have some duplicate IDs that have since been cleaned up. The more up to date, ongoing source of Legacy/Path IDs in available in Cal Answers using the "Employee Crosswalk" Dashboard.
To facillitate cutover/conversion activities, a mapping file of UCPath Empl ID to PPS Empl ID mapping is available.
A csv file of all converted UCPath Employee ID to PPS Employee ID mapping is available in a file named UCB_PPSID_EMPLID_CUTOVER_327.csv.csv. This file contains all employees converted; these are the final production values, including new values added as of March 27.
Additional files that were used to facilitate Testing efforts during the Testing Phase remain in the UCPath_ID Conversion Box folder for reference.
To gain access to the files, send an email to firstname.lastname@example.org. In the email, please request for access to the UCPath ID conversion folder. This will generate a Service Now incident in which you can use to track progress on the request.
Many applications use LDAP as a means to authenticate to their application systems. While new attributes were added to facilitate testing throughout the various UCPath testing stages, the final Production LDAP attributes, and the expected values in the attributes during the cutover/conversion period are as follows:
|berkeleyEduHCMID||Always populated if there is current or historical HCM Record for the person, including Person Of Interest (POI) and Contingent Worker (CWR) type records|
|berkeleyEduUCPathID||Always populated if there is current or historical UCPath Record for the person, including POI and CWR type records|
Populated with the following data in the order listed:
Multi-Valued; May be populated with legacy UAS IDs and/or ADVCON Ids
UCPath Employee Ids will be added to the employeeNumber attribute in Mid-March for Test-LDAP, and around March 20th for production LDAP. Check the UCPath Cutover Dashboard for PROD-LDAP confirmation.
employeeNumber = HCM Employee Number
berkeleyEduHCMID = HCM Employee Number
berkeleyEduUCPathID Not present
New attributes were added to LDAP to facilitate the various test phases of UCPath:
LDAP Attributes for UCPathIDs in TEST-LDAP
We expect that berkeleyEduUCPathID = berkeleyEduUCPathITID during Integration Testing, and for it switch to berkeleyEduUCPathID = berkeleyEduUCPathUATID during UAT
LDAP Attributes for UCPathIDs in DEV-LDAP
We expect berkeleyEduUCPathID = berkeleyEduUCPathDevID
CALDAP is the database version view of LDAP, and is downstream from LDAP. The attributes in CALDAP mirror those of LDAP except for addition of employeeID.
While new attributes were added to facilitate testing throughout the various UCPath testing stages, the final Production CALDAP attributes, and the expected values in the attributes during the cutover/conversion period are as follows:
CALDAP Production Attributes
- employeenumber = UCPath Employee Number
- HCMID = Legacy HCM Employee Number
- UCPathID = UCPath Employee Number
- employeeID = UCPath if converted, Legacy HCM if not converted
- employeenumber = HCM Employee Number
- HCMID = HCM Employee Number
- UCPathID not present
CALDAP Testing Attributes
Attributes for UCPathIDs in CALDAP_TEST
We expect that UCPathID = UCPathITID during integration testing, and for it switch UCPathID = UCPathUATID during UAT
Attributes for UCPathIDs in CALDAP_DEV
We expect UCPathID = UCPathDevID
CALDAP changes, while in DEV and TEST, will be updated once a day, at 7 am PST.
For additional questions, please contact the Database Team at email@example.com.
During UAT (User Acceptance Testing), the production snapshots used during PPT3 (Payroll Parallel Test) are expected to be in effect during UAT. The snapshot dates are listed below:
- October 23: Legacy PeopleSoft HCM
- October 24: PPS
- November 6: Legacy PeopleSoft HCM
- November 7: PPS
Training Parking Lot
Answers to questions added to the parking lot during training sessions.
Are there any notifications that get sent out to the operator that a retroactive payment will not be paid out or do we have to manually look to see if there are active paychecks?
No, there are no alerts/notifications sent out to tell people that a retroactive payment is or is not triggered. The only notification is if someone at UCPC Payroll thinks an error has occurred and will reach out to the identified individuals to confirm.
How far back is data being migrated from the current systems? Will Staff Retierees be marked as POI?
For Employees: Conversion is only for people terminated within this calendar year, after 1/1/2019. They will have to rely on legacy data in data warehouse and wherever. We are converting only two types of POIs - Academic Pre hire and Staff retiree.
For POIs: For Academic Pre hire, if they also have a EMP or CWR relationship at the time of conversion, we don't convert Academic pre hire, but if there is no active EMP or CWR record that will be converted and Status is POI status is 'A' and End Date is up to 3 years prior to conversion date or greater (If Conversion date is 03/13/19 then any active POI with End Date of 03/13/16 or greater should be converted).
For Staff Retirees: POI End Date up to one month prior to Conversion Date or greater (if Conversion Date is 03/13/19 then any POI 00025 with End Date of 02/13/19 or greater should be converted.
They should be converted regardless regardless of presence/absence of EMP or CWR relationships.
There are no max number of rows, effective dates, or amounts from a system standpoint.
Are there reports to see payroll transactions that are happening for a single employee? For instance, if I have an employee who has two jobs, but I only have security access for one of the jobs, can I see payments that are happening for the other departme
If you have access to the Review Paycheck page for an employee, you can see all of the details that they were paid, including details from other jobs that are not part of your regular visibility. However, beyond usage of the PREPSHUP tables, you will only be able to view recurring additional pay and one-time payments for the departments that you have visibility into.
No, you can program individual hires to be terminated on a specific date.
For this template it goes back to the approver since approvers are able to edit all fields for this template.
Yes, their payroll status will show as "Inactive, Extended Leaves" once the leave has been added to their job data.
What happens when there's a retroactive pay increase and a direct retro needs to be done on the retroactive pay? Can initiators pull up the retro pay?
Yes. The employee's paycheck would include the retroactive pay, an earn code separate from regular earnings would be associated with the retroactive pay. The earn code begins with '9' for retroactive items.
Yes, the system will allow you to leave gender as unknown for the POI template.
No, you have to enter a US address (for the POI template).
Yes. If you do, make sure to add a comment that states you have entered an international phone number.
Does the initiator have to start from scratch to fix a denied position funding transaction? Is there a copy function?
There is a "copy to new transaction" button. However, it isn't for direct retro transactions, only for position funding.
For employees who retieree but who need to have an active record, will the retire template terminate all records? If yes, should we mark them as POI? Is this when the office of retierees steps in?
Yes, UCPC would terminate all the records. If this person is to become an Emeritus, a template would need to be submitted to add that. (Just as today we enter the Emeritus appointment).
If Retirement office needs to process anything, they will do so. That's why coding it as a Retirement is important, so that their processes can be kicked off.
It depends on the employee class. If they are monthly then additional compensation will be distributed in one pay period. If they are biweekly then it will be distributed biweekly.
No, it is only optional if you are using it for some business need of your own and want to run a report on that field. If you enter a Location Use Type, you must enter a Location Use End Date (and visaversa).
Can the template be edited in any way by the initiator or the approved after it was submitted to UCPath?
It cannot be edited unless it is denied by the approver or canceled by UCPC. Approvers also can't edit any fields, they are in a read only role for this template.
You can see all active appointment in all departments and all UCs in the person org summary page.
Yes! All sick and vacation must be entered by day, no matter if they're exempt or not. For exempt employees, however, initiators need to put in full day (8 hours) amounts and cannot use "half day" increments (e.g., taking 4 hours of sick leave).
They will be on seperate job records.
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.
Retro pay change does not affect current position funding.
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].
7 digits, 6 decimal places.
The Department IDs are at level 4,5,6. The department is based on where the position sits.
You would overwrite the chartfields when the chartfields are no longer active during the recovery process. If the overpayment is being recovered from the next available payment, it will go against the current pay cycle and the chartfields will not be able to be changed.
There is no Home Department concept in UCPath, that is a PPS concept.
UCB is supplying a cross-walk table based on the current state Supervisor. The scripts will look up the Supervisor's UCPath position number after conversion and add that as the Reports To on each employee's position.
For conversion, will UCPath take the funding that is programmed in the current HCM from position data or from job data?
Since the conversion is from PPS, and not from HCM, it will come from the distributions in PPS job data.
Approvers can not edit initiator notes, but they can add notes to transactions they are approving for the Extended Leaves of Absence module.
Initiators will receive a notification that their transaction has been approved or denied. Approvers will receive a notification to approve a transaction and may navigate to the transaction using the link in the body of the email and/or using their worklist if they are in UCPath. Additionally, there are available funding reports in Cognos that as a Cognos user one may run for a department.