Cost Allocation
The chapter covers the following topics:
|
Provides an introductory discussion of Cost Allocation and its components. |
||
Cost Allocation allows flexible, user-defined determination of cost or revenue pools and bases to allocate indirect expenses or revenues. Based on the established pools and bases, MARS computes and posts the allocation of costs or revenues to each target entity (Fund, Agency, Organization, Program Budget Unit, Activity, Function, Object/Revenue Source, Job Number, Reporting Category, and Project).
Cost Allocation allows the allocations to be performed for reporting purposes only or for creating journal voucher master documents on the Document Listing (SUSF).
Each allocation operation is identified by a group number and step number that control the sequence of allocations. Each allocation group is a unique and distinct set of allocations. Steps are a series of subsequent, and sometimes dependent, allocations within the same group.
Cost Allocation supports up to 999,999 steps within a group for complex and dependent cost relationships. A single agency may have one or more groups depending on the types of costs and the relationships used to distribute those costs.
The primary functions of this module are to:
- Provide a means for distributing and matching total costs associated with fee-for-service activities.
- Identify the actual total costs associated with the provision of services that are not directly identifiable with a specific entity (Fund, Agency, Organization, Program Budget Unit, Activity, Function etc.).
- Provide the ability to allocate expense and revenue information for budgeting purposes.
Cost Allocation is supported by several offline programs performing the following functions. See Special Features for more detail on these programs:
Cost Allocation Ledger and Master Tables
Cost Allocation maintains the Cost Allocation Detail Ledger. This ledger can also be sorted and summarized.
Cost Allocation consists of the following tables.
The following report is produced by Cost Allocation:
An overview flowchart of Cost Allocation is shown below, and the various processes are identified and explained below:
- Cost Allocation General Ledger Inquiry (CAGL) is created and/or updated by the Build Cost Allocation General Ledger program. This table summarizes the general ledger for the time frame specified by the user on Application Dates (LDAT).
- Object/Revenue Class and Type Inquiry (OBRV) is created by the Build Object/Revenue Class and Type program. This table will be used in the allocation program if pools and/or bases are defined using object/revenue classes or types.
- Lower Level Organizations (LORG) is created by the Build Lower Level Organizations program. This table will be used in the allocation program if pools and/or bases are defined for high level organizations, but allocations will be made to all lower-level organizations as well.
- Agency Class/Agency Association (CLAG) is created by the Build Agency Class/Agency Association program. This table will be used in the allocation program if pools and/or bases are defined using agency classes.
- The Pool/Base Table Expansion program uses the cost allocation user-defined tables and system-generated tables as input and updates the allocation results tables.
- Optionally, Cost Allocation can produce journal vouchers by building the Cost Allocation Detail Ledger from Pool Accumulation (PACC) using the Compute Allocations program. This ledger can be optionally summarized before it is passed to the Generate Journal Voucher program. This ledger can also be used for management reporting.
- The Allocation Ledger Summarization program will summarize the Cost Allocation Detail Ledger within each group/step.
- The Generate Journal Voucher program will create journal vouchers from the Cost Allocation Detail Ledger and update Document Listing (SUSF).
- Figure 136
The following terms are used throughout this chapter:
Allocation Group Control (ALLC) has a Data Integrity option for each accounting distribution element. The main purpose of this option is to determine whether each accounting distribution element used in base record expansion will be determined by the pool or by the base. If the Data Integrity option is set to Pool , the accounting distribution element will be determined by the pool records (for example, if the user wants to allocate all agency values pooled from fund A to the same agencies in fund B, the integrity option for Agency should be set to Pool ). If the Data Integrity option equals Base , the accounting distribution element will be determined by the base records (for example, if the user wants to allocate all fund values to fund B, the Data Integrity option for the Fund element should be set to Base ).
This Data Integrity option also determines whether or not the wild card option can be used on base records. If the Data Integrity option equals Pool , the user may use the wild card option in that field. If the Data Integrity option equals Base , the user may not use the wild card option (that is, since the allocation is base-determined for that accounting distribution element, there must be values in the base record for that element).
Defining Pool and Base Records
Pool/Base Definition Reference (PBDF) defines all pool and base records to be used in the allocation process. Pool records must be entered before base records of a given group/step to default Cost Allocation Distribution Options (CADO) entries created by Allocation Group Control Reference (ALLC). Each record specifies a particular group/step combination, the accounting distribution for the record, an indicator which classifies the record as either a pool or a base, and other information required for the allocation process. Allocation Totals (TOTL) is updated by the system as group/steps are entered on Pool/Base Definition (PBDF). Appropriate error messages are given for any records rejected by the Cost Allocation Table Processor.
Pool/Base Definition (PBDF) is accessed using various key fields and has three purposes:
- It defines the allocation operations; for example, groups and steps in the allocation process, and the sequence of the allocation steps. Each allocation operation must be identified by group and step.
- It defines the accounting attributes used to determine and control the pool and base records (pool records represent the costs or revenues to be allocated; base records define where and how the costs or revenues will be allocated).
- It defines where the emphasis should be placed in allocating costs and revenues.
Defining the Allocation Operation
Each group and each step within a group must be assigned a number and entered on Pool/Base Definition Reference (PBDF). A group is a unique and distinct set of allocations comprised of 1 to 999,999 steps. A step is a series of allocations within the same group, and each step may be dependent on the allocations made in a previous step within that group. Allocations made in one step may be used by subsequent steps, if desired.
Pool/Base Definition Reference (PBDF) identifies the accounting distributions used for determining the pool and base records and the allocation computations. Both types of records are maintained on this window with the primary distinguishing factor being the Record indicator. A pool record is designated by setting the Record indicator to Pool . A pool includes costs or revenues from the identified Fund, Agency, and lower level entities (Organization, Activity, Function, Reporting Category, etc.) to be allocated to the receiving entities. In identifying a pool, either an Object, Object Class, Object Type, Revenue Source, Revenue Class, or Revenue Type must be specified.
The receiving entities of the allocated costs or revenues are called bases and are identified by setting the Record indicator to Base .
The three methods for allocating pooled funds to the receiving base (for example, the target Fund, Agency, and lower level entities) are:
The different base types are identified by the Base Type field on Pool/Base Definition Reference (PBDF). Each base type represents one method of computing and distributing allocated costs or revenues. A group/step can consist of only one type of base record; for example, the Base Type field of the first base record entered in a given group/step combination forces all other base records with that group/step to be defined with the same Base Type . Pool/Base Definition Reference (Variable Method) (PBDA) updates and maintains Pool/Base Definition Reference (PBDF).
The following Base Type methods are entered on Pool/Base Definition Reference (PBFD):
- Fixed Percentage. A fixed percentage base record is identified by setting the Base Type field to Fixed Percentage . The percent entered for the record is used as the allocation base rather than using actual financial information from the base system to force the allocation computations.
- Statistical. A statistical base record is identified by setting the Base Type field to Statistical . Statistical records are like fixed percentage records in that financial data is not needed from the base system to determine the costs to be distributed to the base record accounting distribution. The amount entered in the Statistical Units field represents any type of unit of measure (square feet, weight, etc.) which is used as the allocation base.
- Variable Percentage. Variable percentage base records are identified by setting the Base Type field to Actual . This type of record uses the actual expenses or revenues on an accumulator distribution in determining the allocated costs or revenues to be distributed. The allocated costs or revenues are distributed according to the accounting distributions entered for the base record. This method requires that the base record be entered on Pool Base Definition Reference (Variable Method) (PBDA). Any additions or changes to this table automatically update Pool/Base Definition Reference (PBDF).
Pool/Base Definition Reference (PBDF) has a "wild card" feature that can be used with pool records and base records. A wild card is defined when an asterisk (*) is placed in one or more fields on one of the valid record types. The Fund, Agency, Organization/Sub-Organization, Program Budget Unit, Activity, Function, Object/Revenue/Sub Revenue Source, Job Number, Reporting Category, and Project fields may have wild card indicators.
When one or more fields on a record has a wild card or is left blank, the remaining accounting fields are used in searching Cost Allocation General Ledger Inquiry (CAGL). This table stores all accounting distribution combinations selected from the general ledger.
Every record with wild cards is processed against Cost Allocation General Ledger Inquiry (CAGL) as follows:
- Any field on the Pool or Base Record storing information must match the field on the Cost Allocation General Ledger Inquiry (CAGL) record.
- Any field on the Pool or Base Record that has an asterisk (*) must have a non-blank value in the corresponding field on the Cost Allocation General Ledger Inquiry (CAGL) record.
- A blank field on the Pool or Base Record will match both blank and non-blank values on the Cost Allocation General Ledger Inquiry (CAGL) record. The blank field value will be overwritten with the matched field value.
Therefore, a record on Pool/Base Definition Reference (PBDF) with wild cards or blanks may be expanded into many records that will be stored on Pool Accumulation (PACC) by running the Pool/Base Table Expansion offline program.
A record on Pool/Base Definition Reference (PBDF) may also be defined using an object class or revenue class or type. This record will initially be processed against Object/Revenue Class and Type (OBRV), which stores the budget Object codes and Revenue Source codes organized by Class and Type. Records defined with a class or type will be expanded into detailed Object or Revenue Source codes. The expanded class or type record is processed against Cost Allocation General Ledger Inquiry (CAGL) to verify that the accounting distributions are valid. The same expansion can occur against lower level organizations and agency classes through the use of Lower Level Organizations (LORG) and Agency Class/Agency Association (CLAG).
Including and Excluding Records
When using the wild card feature, some records may be created that should not be included in the allocation process. For example, it may be more reasonable to enter a Pool/Base Definition Reference (PBDF) record with a wild card that may generate many Pool Accumulation Inquiry (PACC) records, and then exclude the records not to be used in the allocation process instead of entering every desired pool/base record individually. The Include/Exclude indicator gives control over what records are included in the allocation process. The Include/Exclude indicator defaults to Include.
Records marked Exclude are used when Pool Accumulation Inquiry (PACC) is built or updated to delete Pool Accumulation Inquiry (PACC) records. Records that are non-active on Pool Accumulation Inquiry (PACC) are not used in the allocation process.
The Offset Codes on Pool/Base Definition Reference (PBDF) are optional. They are used when a record is to be accumulated or distributed using one accounting distribution, but displayed on reports for accounting purposes. For example, the creation of journal vouchers using a different accounting distribution.
When Cost Allocation creates journal vouchers, any Offset Codes entered on the pool or base record will replace the corresponding original values as the journal voucher is created. This allows the user to alter the accounting distribution that is recorded on the journal voucher.
This feature also allows a user to track all incoming costs to a particular reporting category; for example, offsets can be used on Activity, Function, Object/Rev/Sub, Job Number, and Reporting Category for pools and Fund, Agency, Activity, Function, Object/Rev/Sub, Job Number, and Reporting Category for bases, without decreasing the amount, since using offsets would cause the offset reporting category to absorb the amount allocated.
Any Offset Codes must be valid in the respective reference tables (just as the original entries are edited) and the resulting accounting distribution for the journal voucher must have enough funds to perform the allocation or else an error will be issued.
Use of the Percent Field for Pools and Bases
The Percent field on Pool/Base Definition Reference (PBDF) has different implications for pool records than for base records. If a percent is designated on a pool record, then only that percent of the total accumulated costs for that accounting distribution (associated with that pool) will be extracted from Cost Allocation General Ledger Inquiry (CAGL). For example, if the accounting distribution that defines pool 1 accumulates total costs of $1000, and the Percent field is equal to 40, then only $400 will be extracted from Cost Allocation General Ledger Inquiry (CAGL). If no percent value was indicated on the pool record then the entire $1000 would be allocated. The Percent field on a pool record is optional and defaults to 100 percent.
On a base record, the Percent field approximates what percent of the accumulated costs of the corresponding pool record is to be allocated to that base. For example, if the percent for base 1 is equal to 40 and is associated with pool 1, which has $1000 to be allocated, then base 1 will receive at least $400 from pool 1.
The Percent field on a base record is only relevant for fixed percent and statistical base records since variable percent base records receive their allocations in a weighted, proportional manner determined by the prior costs accumulated for their accounting distribution. For more information on performing allocations, See Compute Allocations.
The following sections summarize the steps required to set up Cost Allocation tables and then execute the cost allocation processing programs.
Setting Up Cost Allocation Tables
To set up Cost Allocation tables, take the following steps:
- Execute the Reset Tables program to initialize Pool Accumulation Inquiry (PACC), Cost Allocation General Ledger Inquiry (CAGL), Allocation Totals Inquiry (TOTL), and Cost Allocation Pool Sequence Inquiry (CAPS). The dollar amounts for all records on these tables are set to zero.
- Define which account types are subject to the cost allocation process and how they are to be used. This is performed by entering the appropriate code in the Account Allocation Type field located on Cost Allocation Account Type (CAAT).
- Define the groups that are to be included in the cost allocation process, and the period (periodic, quarterly, or annual) that will be covered by this allocation whether or not to generate journal voucher transactions, and whether to post offset entries. This is performed by entering the appropriate codes in Allocation Group Control Reference (ALLC).
- Define all of the pool and base records that are to be used in the Cost Allocation process, specifying group/step combinations, accounting distributions, and classifying records as pools or bases. This is performed by entering the appropriate codes in Pool/Base Definition Reference (PBDF). Use Pool/Base Definition Reference (Variable Method) (PBDA) for variable allocation base records. The associated pool records are entered on Pool/Base Definition Reference (PBDF).
- Execute the Variable Percent Table Pre-Processor program to create statistical units for variable type base records.
- Execute the Pool/Base Table Pre-Processor to convert the statistical based group/steps into fixed percentage equivalents.
Allocation Totals Inquiry (TOTL) is automatically updated when you update Pool/Base Definition Reference (PBDF). The groups, steps, base types, pool types, and budget/actual allocation indicators are updated. The total percent is calculated for fixed percentage and statistical base records on Pool/Base Definition Reference (PBDF). The backend window that identifies the accounting distribution allocation options is Cost Allocation Distribution Options (CADO).
Once these tables have been loaded, Cost Allocation is ready to run.
Executing the Cost Allocation Process
To execute the cost allocation process, take the following steps:
- Build Cost Allocation General Ledger Inquiry (CAGL) by reading the General Ledger and copying the records which match the account types defined on Cost Allocation Account Type (CAAT) into Cost Allocation General Ledger Inquiry (CAGL). This is done by processing the Build Cost Allocation General Ledger program.
- Build Object/Revenue Class and Type (OBRV) by executing the program that reads Object (OBJT) and Revenue Source (RSRC). Every new object or revenue class or type read from the reference tables is inserted into Object/Revenue Class and Type Inquiry (OBRV). As the classes and types are being inserted into the table, the Object codes or Revenue Source codes associated with them are also inserted into the table.
- Build Lower Level Organizations (LORG) by executing the program that reads Organization (ORG2). Every organization read from the reference table is inserted into Lower Level Organizations (LORG). As the organizations are being inserted into the table, the lower-level organization codes associated with the organizations are also inserted into the table.
- Build Agency Class/Agency Association (CLAG) by executing the program that reads Agency (AGC2). Every agency class read from the reference table is inserted into Agency Class/Agency Association (CLAG). As the agency classes are being inserted into the table, the agency codes associated with the classes are also inserted into the table.
- Build Pool Accumulation Inquiry (PACC) by executing the Pool/Base Table Expansion program. This process uses the pool and base records on Pool/Base Definition Reference (PBDF) and the Accounting codes and Amounts on Cost Allocation General Ledger Inquiry (CAGL). They are used to update the Accumulated Amount and Percent fields on the records in Pool Accumulation Inquiry (PACC). This program also updates the Base Total and Pool Total amount fields on Allocation Totals Inquiry (TOTL).
- Execute the Compute Allocations program to produce the Cost Allocation Detail Ledger which is used for reporting and creating journal voucher documents.
- Execute the Allocation Ledger Summarization program to summarize the Cost Allocation Detail Ledger by combining records with the same accounting codes.
- If applicable, execute the Generate Journal Voucher program to create journal voucher documents to record the results of the allocation process (with the option of having these vouchers reversed out).
The following sections describe each Cost Allocation offline programs. Full details on the commands used to execute these programs can be found in the System Administration Guide .
The Reset Tables program initializes fields on the following tables:
This program must run before Cost Allocation General Ledger Inquiry (CAGL) and Pool Accumulation Inquiry (PACC) are built or updated (for more information, see the System Administration Guide ). If this is not done, dollar amounts will remain in these tables from previous allocations which would cause subsequent executions of Cost Allocation to give incorrect results. Separate parameters allow the user to reset only selected tables or fields from this list if desired.
Build Cost Allocation General Ledger
Two programs exist that must be executed to build or update Cost Allocation General Ledger Inquiry (CAGL) from the general ledger records. The first is an extract program that reads the General Ledger and writes records matching the selection criteria to a file. This file is sorted for input to the second program, Build Cost Allocation General Ledger; this program builds or updates Cost Allocation General Ledger Inquiry (CAGL) with the records in the sorted file.
These two programs must be executed before the Pool/Base Table Expansion program is executed, since the dollar amounts and accounting distribution combinations from Cost Allocation General Ledger Inquiry (CAGL) are needed for the Pool Accumulation Inquiry (PACC). They should also be executed after the Cost Allocation Reset program.
Build Object/Revenue Class and Type
Object/Revenue Class and Type (OBRV) is built or updated by executing the Object/Revenue Class and Type program. This program reads Object (OBJT) and Revenue Source (RSRC) and inserts the object and revenue classes and types along with the codes associated with those classes and types into the table.
This table should be built at the beginning of every allocation process if maintenance has been done on Object (OBJT) or Revenue Source (RSRC). This will ensure that the most current Object Classes, Revenue Classes, Object Types, Revenue Types, Object Codes, and Revenue Source Codes are used in the allocation process. In addition, this program is not dependent on any of the previously executed offline programs and may be run at any time as long as it precedes execution of the Pool/Base Table Expansion program.
Build Lower Level Organizations
Lower Level Organizations (LORG) is built or updated by executing the Build Lower Level Organizations program. This program reads Organization (ORG2) and inserts the organization codes (along with any lower-level organization codes associated with them) into the table.
This table should be built at the beginning of every allocation process if maintenance has been done on Organization (ORG2). This will ensure that the most current Organization hierarchy is used in the allocation process. In addition, this program is not dependent on any of the previously executed offline programs and may be run at any time as long as it precedes execution of the Pool/Base Table Expansion program.
Build Agency Class/Agency Association
Agency Class/Agency Association (CLAG) is built or updated by executing the Build Agency Class/Agency Association program. This program reads Agency (AGC2) and and inserts the agency class along with the agency code into the table.
This table should be built at the beginning of every allocation process if maintenance has been done on Agency (AGC2). This will ensure that the most current Agency hierarchy is used in the allocation process. In addition, this program is not dependent on any of the previously executed offline programs and may be run at any time as long as it precedes execution of the Pool/Base Table Expansion program.
Variable Percent Table Pre-Processor
The Variable Percent Table Pre-Processor sets the Statistical Units field on each actual/variable base record defined on Pool/Base Definition Reference (Variable Method) (PBDA) with the dollar amount associated with the expansion of the accumulator accounting distribution. This total amount from all of the matching records is loaded into the Statistical Units field so that the Pool/Base Table Pre-Processor program can determine the associated percentages that should be used in the actual allocation expansion process.
The Pool/Base Table Pre-Processor converts statistical unit amounts on base records to percentage amounts. The percentage amount for each is set to the share of the total statistical unit amount. For example, base records with statistical unit amounts for four, five, and ten would be converted to 20, 30, and 50 percent. This program also verifies that the total base percentage equals 100 percent.
Two programs are used to update Pool Accumulation Inquiry (PACC) from the records in Pool/Base Definition Reference (PBDF). The first program is an extract program that reads through Pool/Base Definition Reference (PBDF) and writes to a file all records that match the parameter criteria. Only records with a group that has an allocation cycle (found on Allocation Group Control (ALLC)) equal to the Allocation Cycle parameter and a group/step that has an Allocation Type Indicator (found on Allocation Totals (TOTL)) equal to the Allocation Type Indicator parameter will be written to the file. This extract file then becomes the input file to the second program, Build Cost Allocation Pool Accumulation, that actually builds or updates the Pool Accumulation Inquiry (PACC).
This program should be executed only after the user-maintained tables (Cost Allocation General Ledger Inquiry (CAGL), Allocation Totals Inquiry (TOTL), Agency Class/Agency Association (CLAG), Lower Level Organizations (LORG), and Object/Revenue Class and Type Inquiry (OBRV)) have been entered and updated (for example, after the Reset Tables program, Build Cost Allocation General Ledger Table program, Build Object/Revenue Class and Type Table program, Build Lower Level Organizations program, and Build Agency Class/Agency Association have run), and before the Compute Allocations program is run. It makes use of all of Cost Allocation tables and prepares Pool Accumulation Inquiry (PACC) for allocating the costs.
All records on Pool/Base Definition Reference (PBDF) are processed. Groups/steps are processed one at a time and all including records are processed before any excluding records are processed. Pool records with wild cards or blank fields (or base records on variable percentage group/steps) are processed against Cost Allocation General Ledger Inquiry (CAGL) expanding the records into all possible accounting code combinations that exist on the General Ledger table.
The following example illustrates how pool records are written to Pool Accumulation Inquiry (PACC) for a given group/step:
The result of the expansion would appear on Pool Accumulation Inquiry (PACC) as follows:
The first and third records on Cost Allocation General Ledger Inquiry (CAGL) are extracted because the records match the criteria for expansion. The Fund, Agency, and Reporting Category codes match those on Pool/Base Definition Reference (PBDF) and there are non-blank values in the wild card fields.
The fourth record on Cost Allocation General Ledger Inquiry (CAGL) is not extracted because the Activity field is blank. A blank on Cost Allocation General Ledger Inquiry (CAGL) is not considered a valid match for a wild card field; however, a blank in the Function field on the Pool/Base Definition Reference (PBDF) record is a match with both blank and values in the same field on the Cost Allocation General Ledger Inquiry (CAGL) record.
The second record on Cost Allocation General Ledger Inquiry (CAGL) is not extracted because the reporting category does not match the reporting category on Pool/Base Definition Reference (PBDF). All existing codes on Pool/Base Definition Reference (PBDF) must match the codes on a Cost Allocation General Ledger Inquiry (CAGL) record for the record to be extracted.
Object/Revenue Class Expansion
PBDF records that are defined with object or revenue classes are also processed against Cost Allocation General Ledger Inquiry (CAGL). All Object or Revenue Source codes for a class are retrieved from Object/Revenue Class and Type Inquiry (OBRV) and placed in the Object/Revenue/Sub field on the Pool/Base Definition Reference (PBDF) record. The record is then processed against Cost Allocation General Ledger Inquiry (CAGL) to find a match. The following example using two objects defined to the same object class illustrates this technique.
The first and second records from Cost Allocation General Ledger Inquiry (CAGL) are moved to Pool Accumulation Inquiry (PACC). The Object codes associated with the class on Pool/Base Definition Reference (PBDF) are found on Cost Allocation General Ledger Inquiry (CAGL) along with the other accounting codes. The third record on Cost Allocation General Ledger Inquiry (CAGL) is not moved because the Object code does not belong to the object class on the Pool/Base record.
PBDF records that are defined with object or revenue types are also processed against Cost Allocation General Ledger Inquiry (CAGL). All Object or Revenue Source codes for a type are retrieved from Object/Revenue Class and Type Inquiry (OBRV) and placed in the Object/Revenue/Sub field on the Pool/Base Definition Reference (PBDF) record. The record is then processed against Cost Allocation General Ledger Inquiry (CAGL) to find a match. The following example using two objects defined to the same object type illustrates this technique.
The first and second records from Cost Allocation General Ledger Inquiry (CAGL) are moved to Pool Accumulation Inquiry (PACC). The Object codes associated with the type on Pool/Base Definition Reference (PBDF) are found on Cost Allocation General Ledger Inquiry (CAGL) along with the other accounting codes. The third record on Cost Allocation General Ledger Inquiry (CAGL) is not moved because the Object code does not belong to the object type on the Pool/Base record.
Lower Level Organization Expansion
PBDF records that are defined with Include All Lower-Level Organizations selected are also processed against Cost Allocation General Ledger Inquiry (CAGL). All lower-level Organization codes for a specified Organization are retrieved from Lower Level Organizations (LORG) and placed in the Organization field on the Pool/Base Definition Reference (PBDF) record. The record is then processed against Cost Allocation General Ledger Inquiry (CAGL) to find a match. The following example using two lower-level organizations defined to a specified organization illustrates this technique.
The first three records from Cost Allocation General Ledger Inquiry (CAGL) are moved to Pool Accumulation Inquiry (PACC). The lower-level organizations for the Organization specified on Pool/Base Definition Reference (PBDF) are found on Cost Allocation General Ledger Inquiry (CAGL) along with the other accounting codes. The fourth record on Cost Allocation General Ledger Inquiry (CAGL) is not moved because the Organization code is not a valid lower-level Organization for the Organization specified on the Pool/Base record.
PBDF records that are defined with Agency Value is Agency Class selected are also processed against Cost Allocation General Ledger Inquiry (CAGL). All agency codes for a specified Agency Class are retrieved from Agency Class/Agency Association (CLAG) and placed in the Agency field on the Pool/Base Definition Reference (PBDF) record. The record is then processed against Cost Allocation General Ledger Inquiry (CAGL) to find a match. The following example using two agencies defined to an agency class illustrates this technique.
The first three records from Cost Allocation General Ledger Inquiry (CAGL) are moved to Pool Accumulation Inquiry (PACC). The agencies for the agency class specified on Pool/Base Definition Reference (PBDF) are found on Cost Allocation General Ledger Inquiry (CAGL) along with the other accounting codes. The fourth record on Cost Allocation General Ledger Inquiry (CAGL) is not moved because the agency code is not valid for the agency class specified on the Pool/Base record.
Pool records and variable percent base records ( Base Type Actual ) must always be processed against Cost Allocation General Ledger Inquiry (CAGL) because the dollar amount for the accounting distribution combination is needed to calculate the allocated amount for the base records, and pool records, if specified. The pool and base totals on Allocation Totals Inquiry (TOTL) as well as the Accumulated Amount field on Pool Accumulation Inquiry (PACC) are updated with this information.
Base records are processed in this program against pool records to determine if they qualify for pool distributions and to expand any wild cards and blanks on the base records. They are selected and written to Pool Accumulation Inquiry (PACC) to accumulate pooled funds when the values in each accounting distribution field match the fields in the pool records. The match criteria is unique to each field and is defined by the Data Integrity options specified on Cost Allocation Distribution Options (CADO).
If all of the Data Integrity options show that the base record is used to determine whether the fields in the accounting distribution match, the base record will be selected to accumulate funds from every pool record in the group/step. The base record from Pool/Base Definition Reference (PBDF) will be copied to Pool Accumulation Inquiry (PACC) exactly as it appears on Pool/Base Definition Reference (PBDF), except that blank fields on the base record will be overwritten with values from the pool record.
If one or more of the Data Integrity options show that the pool record is used to determine whether a field in the accounting distribution matches, the following criteria will determine whether the base record will be selected to accumulate funds from each pool:
- If the field on the base record stores information, it must match the field of the pool record.
- If the field on the base record has an asterisk (*), it must have a non-blank value in the corresponding field on the pool record.
- A blank field on the base record will match both blank and non-blank values on the pool record. The blank base field value will be overwritten with the matched pool field value.
The entire record will not accumulate funds from a pool record even if one field defined with a pool Data Integrity option is rejected by the pool record. The base record may still accumulate funds from other pool records.
The following tables illustrate pool and base expansion criteria.
The following example illustrates how pool and base records are written to Pool Accumulation Inquiry (PACC) for a given group/step.
The first step is pool expansion. Expanding the pool records against Cost Allocation General Ledger Inquiry (CAGL) will yield the following results:
The first step in the pool base expansion process for fixed percentage or statistical method records is the pool records' expansion against the Cost Allocation General Ledger records.
PACC pool record #1 results from a match between Pool/Base Definition Reference (PBDF) pool record #1 and Cost Allocation General Ledger Inquiry (CAGL) record #1. Pool Accumulation Inquiry (PACC) pool #2 is Pool/Base Definition Reference (PBDF) pool record #2 expanding on Cost Allocation General Ledger Inquiry (CAGL) record #2. Pool Accumulation Inquiry (PACC) pool record #3 is Pool/Base Definition Reference (PBDF) pool record #1 matching Cost Allocation General Ledger Inquiry (CAGL) record #4. Cost Allocation General Ledger Inquiry (CAGL) record #3 is not picked up because its fund 200 does not match Pool/Base Definition Reference (PBDF) pool record #1 and its Agency 350 conflicts with Pool/Base Definition Reference (PBDF) pool record #2 Agency 300.
The Data Integrity options for the included accounting fields are set up as shown in table below.
The next step is base expansion. With the given distribution option values, the base records shown in the table below will result.
The attempt of the Pool/Base Definition Reference (PBDF) base record #2 to expand against Pool Accumulation Inquiry (PACC) pool record #2 demonstrates this process. Even though the funds match, there is a conflict in the Agency, where the pool Agency is equal to 300 and the base Agency is equal to 200. The Data Integrity option on Cost Allocation Distribution Options (CADO) is set to Pool , which indicates that the two fields must match or the base record agency must contain a wildcard entry or spaces. This is not true, so the expansion is rejected.
However, when Pool/Base Definition Reference (PBDF) base record #1 expands against Pool Accumulation Inquiry (PACC) pool record #3, a match is found. Even though the Activity fields do not match, the Activity Data Integrity option on Cost Allocation Distribution Options (CADO) is set to Base so the base record is granted control. The result is a Pool Accumulation Inquiry (PACC) base record with an Activity equal to 5000.
The third step is the allocation of funds from the pool records to the base records. The corresponding dollar amounts for each fixed percentage and statistical base record is recalculated to spread the accumulated amounts from the pools to the base records. The accumulated amounts are spread proportionally among the base records expanded from each pool. The calculation is:
When the base record expansion is completed each pool record will have an associated base percentage that represents the sum of the percentages of the base records which expanded for the pool. These percentages will appear in Cost Allocation Pool Sequence Inquiry (CAPS). The records are keyed by the group number, step number, and the pool-sequence number. They will appear in the following manner:
The accumulated amount for each base record is then computed as well as the percentage each base record composes of the entire allocated amount for Pool Accumulation Inquiry (PACC) base record #1. The following calculation will occur:
Accumulated Amount = $1.00 * 30%/100% = $.30
For base record #2, the following calculation will occur:
Accumulated Amount = $1.00 * 30%/75% =$.40
For base record #3, the following calculation will occur:
Accumulated Amount = $1.00 * 45%/100% = $.45
For base record #4, the following calculation will occur:
Accumulated Amount = $1.00 * 45%/75% = $.60
For base record #5, the following calculation will occur:
Accumulated Amount = $1.00 * 25%/100% = $.25
For base record #6, the following calculation will occur:
Accumulated Amount = $1.00 * 25%/25% = $1.00
If the base record contains a forward reference step, an entry will be added to Pool/Base Forward Reference Step (PBFR) for that base record. These records will be examined by the Pool/Base Definition Reference (PBDF) pool records in the target group/step.
After the allocation process is completed, the remaining amounts on Cost Allocation Pool Sequence Inquiry (CAPS) will be reset to zero. All records being inserted into Pool Accumulation Inquiry (PACC) or into the pool accumulation file will be included in the allocation process.
Pool and base records defined as excluding records on Pool/Base Definition Reference (PBDF) are allowed to have wild cards and are processed in the same way as included records except dollar amounts are not extracted from Cost Allocation General Ledger Inquiry (CAGL). Each excluding record is passed through Pool Accumulation Inquiry (PACC) and, when a match is found, the Pool Accumulation Inquiry (PACC) record is deleted. If the Pool Accumulation Inquiry (PACC) record is a pool, the Pool Total amount on Allocation Totals Inquiry (TOTL) is updated. If the Pool Accumulation Inquiry (PACC) record is a base, the summary base percentage for the pool record from which the base was expanded is adjusted by the percentage on the base record being excluded.
This feature is useful in excluding records from the allocation process that might have been included only because they resulted from expanding a wild card record. All appropriate totals in Allocation Totals Inquiry (TOTL) are adjusted when a record marked excluded is processed.
Pool records which expand through a reference will result as follows:
If the pool has a backward reference entered on the Pool/Base Definition Reference (PBDF) record, the following actions occur:
- All base records on the group/step identified will be traversed sequentially in Pool Accumulation Inquiry (PACC) looking for matches.
- If a match is found, the funds will be allocated to the Pool Accumulation Inquiry (PACC) pool record using the same rules applied to expanding against Cost Allocation General Ledger Inquiry (CAGL).
- The funds extracted from the base record will be moved into the Allocated Amount of that base record, and into the Accumulated Amount of the pool record. If the base record has already been referenced by another pool and there are no funds available the expansion will not occur.
- Each pool record will look on Pool/Base Forward Reference Step Inquiry (PBFR) for forward references to the Pool/Base Definition Reference (PBDF) pool's group/step. If any matches are found, the following actions occur to that base record:
- All base records on the group/step identified will be traversed sequentially in Pool/Base Forward Reference Step Inquiry (PBFR) looking for matches.
- If a match is found the base record responsible for the Pool/Base Forward Reference Step Inquiry (PBFR) entry will be referenced.
- The funds will be allocated to the Pool Accumulation Inquiry (PACC) pool record using the same rules applied to expanding against Cost Allocation General Ledger Inquiry (CAGL).
- The funds extracted from the base record will be moved into the Allocated Amount of that base record, and into the Accumulated Amount of the pool record. If the base record has already been referenced by another pool and there are no funds available the expansion will not occur.
- If the reference is depleted of available funds, the Pool/Base Forward Reference Step Inquiry (PBFR) entry will be deleted. Otherwise the Record Has Been Used in Allocation Process option on the Pool/Base Forward Reference Step Inquiry (PBFR) entry will be selected.
An exception report is printed as a result of executing the expansion program. This report lists information about records processed and/or rejected. The accounting codes for the record along with an appropriate message are printed. The following is a list of possible exceptions:
The following messages may appear on the error report:
If the above messages appear on the error report, the user should view the records on Pool Accumulation Inquiry (PACC). Errors that are found should be corrected on Pool/Base Definition Reference (PBDF) and the expansion offline program should be run again. The allocation process should not continue if messages Not All Base Records Percents Recalculated or Group/Step Sequence Number Not Found appear on the error report. If the process is continued, the records associated with the messages will not have their allocated amounts computed correctly.
The Compute Allocations program computes the allocated amounts for all active base records in Pool Accumulation Inquiry (PACC). Allocated amounts are calculated for offset pool records if the Generate Offset option is selected in Allocation Group Control Reference (ALLC).
This program should only be executed after Pool Accumulation Inquiry (PACC) has been built or updated (and any prerequisite steps) and the user is satisfied with the records in the table and the Exception Report produced from the Pool/Base Expansion program. It also must be run before the Allocation Ledger Summarization program is executed.
The Compute Allocations program uses Pool Accumulation Inquiry (PACC) to create ledger lines (to be used by the Generate Journal Voucher program) from the pool and base records. The Generate Offset option will be selected to ensure the proper accounting distribution is used. If the Generate Journal Voucher option is not selected for a particular group, no journal voucher line entries are produced.
The journal vouchers created will use the entered offset account distribution to post results of the allocation instead of the expanded account distribution.
Allocation Ledger Summarization
The Allocation Ledger Summarization program summarizes the Cost Allocation Detail Ledger created by the Compute Allocations program. It uses the Cost Allocation Detail Ledger as input and summarizes records whose accounting distributions are the same. The amounts are added to produce a total for the summarized ledger record.
This program can only be run after the Compute Allocations program is executed and may be run before the Generate Journal Voucher program is executed.
The Generate Journal Voucher program sequentially reads the Cost Allocation Detail Ledger and creates one journal voucher (JV) for each record or set of records with a unique group and step number, fund, and agency combination.
This is the final program in Cost Allocation, and is essentially the end result of all the preceding programs.