Frequently Asked Questions - General Ledger

The link to funding entry transactions provided in the system-generated emails will, by default, only show you the effective dated rows that are currently active, or future dated. If the funding entry was inserting a retroactive effective date, it will not be visible by default from the email link. You can view all rows associated with this funding entry by selecting the ‘Include History’ button at the bottom of the page. 

We generally recommend searching for the transaction via the Funding Entry page or via the Worklist so you can see all rows in the transaction.

You can copy a denied transaction into a new transaction. Search for the denied transaction via the Funding Entry page. At the top of that denied transaction, there is a ‘Copy to new transaction’ button.

Maybe. Please explore the following job aid: Explainer - Automated Funding Reallocation Process

The Funding Entry page uses 6 decimal places.

The DeptID the system is asking for here is the position/Workforce Administration DeptID, not the GL/Chartfield DeptID. You are only able to enter the DeptID shown in Position Data. If you try to enter a DeptID not given in the Position Data, you will get an error message. If you know the DeptID you entered is the ‘correct’ new DeptID for that position, you need the Workforce Administration transactors to make that update to the position before you can start your Funding Entry transaction.

The initiator will receive a confirmation email notification of their submitted transaction, and another email when the transaction is approved or denied.

A user with the Funding Entry approver role, and with row level security to access the transaction will receive an approval request notification when the transaction is submitted. Approvers can access the transaction via the link provided in the email, but note, the link will only display the effective dates in that position’s funding entry that are currently active. If the entry was a retroactive entry, those rows will not be visible from this email link. We recommend searching for the transaction via the Funding Entry page or via the Worklist to be able to see all rows in the transaction.

Pay Distribution uses six decimals. It looks like this: 1.000000

The Controller's Office would be responsible for these guidelines. Please reference the following job aid for additional guidance: GL: Documentation for Grants & Compliance Checklist

No. 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. The Effective Date you use may also be dependent on the start/end dates of various grants.

Note: Funding Entry records are specific to three values: Position Number, Position DeptID, and Fiscal Year. If the position is reorganized to a new Position DeptID, a new Funding Entry will be required.

Position Pool ID is used by the Work-Study unit in Financial Aid (FASO) to tie a position to an employee’s work study award. 

For more information, refer to the Workstudy Office. Office of Financial Aid & Scholarships.

MCOP stands for “Multiple Components of Pay".

Some positions at UC Berkeley include multiple components of pay (MCOP) and some positions are funded by contracts and grants that have restrictions that impose a salary cap. MCOP Funding Entries ensure these salaries are distributed correctly between capped and supplemental funding sources.

You’ll use the Salary Cap / MCOP Funding Worksheet when:

• Funding includes a capped fund (e.g., NIH, CIRM).
• The position is salaried (not biweekly).
• The position is filled (not vacant).

An academic employee’s position is funded using a capped fund, and their monthly salary exceeds the cap limit for that fund, but there is no available funding source for the over-the-cap earnings. How should the “cap gap” funding be processed?

If there is no funding source for the over-the-cap earnings, the employee’s earnings distribution should be updated in Job Data, distributing the over-the-cap amount to the GAP earn code. This GAP earn code is not paid out, bringing their actual monthly earnings up to, but not exceeding, the cap rate.

On the Funding Entry side, you will still need to use the Salary Cap / MCOP Funding Worksheet. In the funding preview page you will see a N-OTC indicator assigned to the capped fund distribution, and a Y-OTC line with $0.00 distributed to it. When you submit this to the main funding entry page, the Y-OTC row will be removed by the system, along with the N-OTC indicator on the capped fund distribution.

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.

Payroll will go into suspense if:

• No Funding Entry was set up for the position

• The position is no longer in the department for which funding was entered

• Chartstring(s) in the Funding Entryprofile are no longer active

Note: look at Chartfield 1 to understand why payroll went into suspense:

• 900000: FE was not attached to the position

• 900001: chartstring(s) is no longer active

No. Funding Entry approval routes based on the Job Data department, not based on the GL DeptID.

If an employee has earnings on an Earn Code not specified in their Funding Entry (like SAS or STP), the system will use the funding source(s) on the default blank Earn Code row in that Funding Entry. You are able to specify different funding sources for different earn codes in Funding Entry. 

For more information, explore the Job Aid: How to Process a Staff Stipend on a Different Chartstring

• Position Funding was never set up for the position.

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

• A position’s department changed and funding was not set up for the new position/department pair.

Yes. If the funding end date expires, the system will use the suspense account.

Both. The system performs individual chartfield validation, and it also validates the full chartstring.

Note: In Payroll, the system will only validate individual chartfields, not the full chartstring.

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.

It is best practice to backdate to the appropriate Effective Date to ensure any retro pay is paid out correctly.

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 number of distributions that can be entered.

If hours were distributed to the wrong Chartstring (aka Full Accounting Unit / FAU), the department should initiate a Salary Cost Transfer transaction to move the expenses to the correct chartstring(s).

Best practice would be to check the Funding Entry for the position(s) to ensure it is corrected to avoid the same issue for future pay periods or any retro pay.

Yes.  However, a position must be created in UCPath before you can apply funding to it.

UCOP’s web application firewall is flagging and blocking your document or text. If you receive this error, please email UCBUCPath@berkeley.edu, providing the following information: 

• Screenshot of error message, including the Support ID number (located at the bottom of the pop-up)

• A copy of the document you were trying to upload, or a copy of the text added to the text field

• The page you were on when the error message appeared

UCB UCPath Operations team will report this to UCOP IT, who will evaluate the text or document and make adjustments to the firewall settings to allow the text/document.  UCOP IT will inform UCB UCPath Ops that you can try again.  (warning: this might take a few days) 

Image description: This example screenshot includes all the necessary information needed to report this error. Included in this screenshot is the employee’s browser window, with the page they were on when the error message fired (the “Add Employee Relationship” page), the add document popup window, and the error message text:

“UCPathApplicationError

There was an issue with the information you entered.

How to fix it:

• Please double-check your entry and try again

• Avoid using special characters like quotation marks, symbols or backslashes, as they can sometimes cause errors

If you copied and pasted information into the form, hidden characters may have been included. For the best results, try typing the information directly into the form

What happens next:

When you close this message, you'll return to the previous page. Depending on where the error occurred, you might need to re-enter some or all of your information and restart the task. We understand this can be frustrating, and we appreciate your patience.

Need help?

If the issue continues, please reach out to your local helpdesk and provide the following Support ID for faster assistance: 0l3c4f7d-63198-4fg3-01b5-3de4320c3b68”

Please use the chart of accounts validation lookup to verify your chartstring. 

No, when it is approved at the location it goes into ledger directly. 

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.

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]

OR

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.

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

The Direct Retro form has a Copy Transaction button that will allow the transaction to be copied, edited, and resubmitted for approval.

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.

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.

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. 

No. Direct Retro allows for the redistribution of funding or split funding between multiple funding sources. However, the Earnings Code cannot be changed.

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. 

An Ad-Hoc reviewer can be added for reviewing transactions. 

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.

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.

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.