Allocation Methods
Allocating Actual Expenses
The first allocation method of Project Allocation is used to take a specific expense transaction and allocate it to a multiple specific-funding source. The subsystem enables you to create a JL organization key and enter all the attached parts, select codes, and miscellaneous codes from the project allocation screens. In fact, you must not use the general ledger/job ledger screens to enter organization key information or you will receive an error message. The project number and subproject form the primary key. The PAUPPR Project Information and Funding Sources tabs will establish the initial detail for the catalog of project history stored within project allocation. The transactions reside in the encumbrance database from the purchase request or purchase order entries. When the transaction is extracted into AP, it will reside in the open hold database. Once distributed, the transaction will reside in the general ledger and job ledger. The item is available through the standard reports for the encumbrance, accounts payable open hold, general ledger, and the job ledger. This particular approach allows each transaction to be allocated at the time of entry, based on the funding sources, priorities, percentage, and revenue budget amounts entered into PAUPPR, Funding Sources tab.
The catalog of history (maintained in Project Allocation) contains details on the start/end date, budget director, and project director. The information for the transaction percent allocation resides in the Funding Sources screen. The screen displays the secondary key, which is formed by attaching the primary key (project number plus the subproject number) to the funding source.
The items reapportioned by the Project Allocation calculation must be sorted at either the object code or object code group level. These codes, when entered into the first column of the PAUPPR, Funding Sources tab, will trigger the calculation that occurs on the transaction. The split is allocated based on the different funding sources. The decision to choose the calculation to occur at the object code level means one transaction might have multiple transaction postings to allow for the posting splits to the individual secondary keys (project, sub-project and funding source). The decision to choose the calculation to occur at the Object Group level will allow for fewer transaction reallocating.
As stated previously, each "secondary key" is comprised of the project number, subproject number, and the funding source. The secondary key is created from the joining of the project, sub-project, and funding source definitions. During association of a funding source with the primary key, a new JL key will be created. You must be sure your combination of project, sub-project and funding source do not exceed 10 characters. The JL key created from the funding source tab will utilize a naming convention algorithm as follows.
1. PA will first try to concatenate the primary key number and funding source to derive the JL key unless this concatenation will yield a number with a length greater than 10.
2. If the project fund source concatenation yields a number with a length greater than 10, PA will concatenate the rent project number with a sequence character beginning with "A" for each funding source.
3. If the project sequence concatenation yields a number with a length greater than 10, PA will prompt the user as to what the JL key should be and allow the user to input this number.
If object codes are to be placed into one object group that is a consistent item, the object group name can be defaulted on PAUPPR, Funding Sources tab. Any object code that is attached to the designated object group shown in the Funding Sources tab is put through the calculation split shown within the priority, percent, and up to the budget dollar amount shown on the Funding Sources tab.
The Project Allocation screen is maintained as the project progresses. If the priority-one funds are depleted, then the dollars are split to priority-two, etc. The very next transaction related to that project is put through the calculation of the split based on the priority, percent, and/or budget dollar amount. The calculation will always look at the priority-one first to verify funds are available. The transaction, as it is split, is added to the actual total expenses in that group and verified against the expense budget for the group in the GL/JL. If the new dollar amount does not exceed the expense budgeted amount, the transaction will proceed. If the new dollar amount makes the total expense dollar amount exceed the budget amount for all funding sources, PA will post excess to the primary key. The normal warn or block can be implemented through the GL/JL process against the primary or secondary postings. The next check verifies the total funds available in the Funding Sources tab for the funding source. The lack of funds available in priority-one forces the funds to be placed against the priority-two funding source dollar amount budget. The update requires current budget information for each funding source, project director, and the start and end date.
Reporting Prorated Expenses into Budget by Funding Source
This second allocation method allows all transactions to flow into the BusinessPlus core financial subsystems, purchasing and accounts payable, to a single primary key (comprised of project and sub-project number). If the user is not using a reallocation of expenses but wants a recognized revenue budget version, there will not be an addition of the funding source detail to the primary key to create a secondary key. If the funding source part on the primary key has a value other than "not applicable," the PM module will allow you to enter the funding source associated with the project but will not create a new secondary key.
A utility is run which adds up total expenses per project and creates a recognized revenue budget version called Project Funding (PF). The split on the total expenses is based on entry into the Funding Sources tab for the Revenue object codes. The utility then splits the total expenses based on the priority, percentages, and budget amounts. The percentage per priority must add up to 100%. The priority-one funding is spent prior to priority-two, etc. However, if additional budget funds are entered for priority-one, the utility will always look through each priority starting with priority-one first.
The total recognized revenue for the month always matches, dollar for dollar, the actual expenses for the month by project. This is a helpful tool for the implementation of the reimbursed expense billing on Grants.
Departmental Chargebacks
The Project Allocation subsystem evaluates payroll distributions for occurrences of employees working on tasks for projects designated by departments, which are different from the employee's home department. When this occurs, Project Allocation will create the necessary interdepartmental transfer and charge back transactions, as outlined below.
Project Allocation compares the organization part of the G/L account (employee home department) with the organization part of the J/L project account to determine if such transactions are necessary. A J/L report run by project and sorted by G/L account enables management to report on labor source for project tasks. The user is able to use charge back percentages by organization key which are stored in the GL account keys in Miscellaneous Code, field #1:
Miscellaneous Allocations
Pooled cost for projects (for example, seal coating that benefit a subset of projects) can be allocated using the Miscellaneous Allocation screen. From here, you can input the cost pool project number or account number to be allocated and list the projects or account numbers receiving the cost allocation in column format.
The cost will be allocated either by the cost driver input for each project or account number (cost driver column) or by the default cost driver input in the default driver field. The default cost driver field will reference Misc. fields set up for each project at the time of account set up and will echo these cost drivers on the Project Allocation screen. Posting is identified in the Posting Strategy fields. Pooled cost project allocations are calculated using a specialized GL utility. This utility will look to the allocation screen (PAUPMA, Allocations tab) and create a JE batch to be distributed.
Posting options for district project allocations are as follows:
- Distribute costs from a specified account number to individually specified account numbers.
- Distribute costs from specified account number to multiple projects tied to a default task code or object code.
- Distribute total costs of a project to other individually specified account numbers.
- Distribute total costs of a project to multiple projects and use the task/object codes from cost pool project to determine the task/object codes for the new distributed projects.