Processing Allocations

This chapter provides an overview of the PeopleSoft Allocations process (FS_ALLC) and discusses how to:

• Define allocation process steps.

• Define the allocation group.

• Copy, rename, or delete allocation steps.

• Create adjusting entry journals.

• Set up interunit and intraunit allocations.

• Use allocations with PeopleSoft Project Costing.

• Run an allocation request.

• Produce allocation reports.

• View process messages.

• Restart and recover the allocations process.

Understanding the PeopleSoft Allocations Process (FS_ALLC)

Most businesses have some expenses or assets that are held or accumulated in one entity but must be shared by more than one business unit, department, or other entity. Typically, you allocate these balances and statistical quantities across the entities within the organization so that they recognize an appropriate share of the amounts.

Using the PeopleSoft Allocations process, you can define multiple allocation steps or step-down allocations when amounts must be applied according to a hierarchy and in a precise order, which might include allocations to multinational, national, and regional levels for the organization. Step-down allocations are used to determine not only how much general and administrative expense to charge to each business unit and department, but also what portion of that expense to attribute to individual projects or products.

Allocations offers the following advantages:

• Save allocation specifications for such recurring items as rent, utilities, and administrative expenses each time that they are allocated.

• Use time spans (rolling time frames) to automate the determination of accounting periods for the allocations.

• Generate journal entries, edit, and post them to update ledgers from the allocations process or choose to post them later in a separate process.

• Create calculation logs for a complete audit trail.

When you are defining an allocation, first determine the desired end result. For example, the cost of renting an office building might be shared among the departments that are housed in that building. If rent is paid as a single amount and is initially charged to one department, you can allocate the expense to each department in proportion to its share of office space, personnel head count, or any other fixed, percentage, or statistical criteria.

After you determine the purposes of the allocations, gain a working knowledge of the records or tables that are involved and identify which ChartFields are affected.

Note. Carefully consider the types of accounts you propose to use with allocations. Allocation does not support open item accounting. In particular, do not select open item accounts on the Target Tab of the Allocation Step Definition Process.

These are important consideration as you establish the following basic elements of the allocation:

• Allocation type: This is the calculation method for the pool and basis and describes how the basis is used to distribute the pool amounts to the target.

• Pool: The amount or amounts to be allocated.

  This amount can originate from a ledger or table, or you can specify a fixed amount. If it comes from a ledger, allocations uses the ledger definition to determine its table name and other characteristics (such as calendar, multibook, and base currency). If the pool record is a table, specify the table name.

• Basis: Determines how and in what proportion the pool amounts are distributed to the various targets.

• Target: This is the destination where the amounts are allocated.

• Offset: Entries that balance the targets.

  These entries reflect the clearing of pool amounts as they are transferred to the targets or amounts that offset the target.

• Amount fields: Determine the mapping of the amount fields between the pool, basis, and target records.

For example, assume that you want to allocate rent expense that is originally debited against the rent account 640000 to administrative department 14000. The pool is the sum of the amounts that are in the ledger rows for that ChartField combination. The pool is divided among the ChartField values that are specified as the target (the other departments in the company) according to the basis, which in this case is the amount of floor space that each department uses as specified by a statistical account. As the target accounts are debited, the system generates an offset to balance them.

The PeopleSoft Allocations process uses background processing. It is also flexible in that you can update the target and offset tables directly, create and post allocation journals, or create journals that are to be posted later.

Ultimately, an allocation results in updated target and offset ledgers, but the output of the allocation can be to journal entries that you choose to post in allocations or later in a separate process to update the ledgers.

In PeopleSoft applications, you can also allocate among business units (interunit) or within business units (intraunit), such as between funds or departments.

See Also

Setting Up Interunit and Intraunit Allocations

Using TimeSpans

Understanding General Ledger Background Processes

Defining Allocation Process Steps

To define steps in the PeopleSoft Allocations process, use the Define Allocation Step component (ALLOCATIONS).

The following section provides an overview of allocation steps and process group and discusses how to:

• Select the allocation type.

• Define the allocation pool.

• Define the allocation basis.

• Define the allocation target.

• Define the allocation offset.

• Select output options.

• Select rounding options.

• Specify batch records.

• Define amount fields.

Understanding Allocations Steps and Process Group

Depending on its complexity, you can define an allocation by one or more process steps. Multiple steps represent a step-down allocation. These steps together form a process group, with each allocation identified by a unique group ID.

Each allocation step represents a discrete stage in the PeopleSoft Allocations process, which means that the process updates the ledger balances or creates journals at the end of the step. For example, you can perform a rent expense allocation in one step because you update the ledger only once to accomplish this allocation. But for more complex allocations, such as the distribution of administrative expenses across sales departments followed by the allocation of sales expense across products, you need two steps.

This diagram illustrates multiple steps in an allocation processing:

Multiple steps in allocation processing

In this example, the first allocation step distributes administrative expense across the sales departments and then updates the ledger. If the ledger is not updated, the second step draws erroneous data from the ledger because the second step must allocate the newly updated sales expense across products.

Pages Used for Allocation Steps

Selecting the Allocation Type

Access the Type page.

Allocation Type	Select a calculation option to determine the pool amounts that are going to the targets from one of the following allocation types: Copy: Copies pool amounts to the target or offset with possible percentage changes. Spread Evenly: Divides pool amounts equally by the specified basis fields to derive the target amounts. For example, this type can be used to divide the pool equally in thirds among department IDs 0100, 0200, and 0300. Allocate on Fixed Basis: Allocates on a fixed basis and percentage of pro rata allocation. It is based on the fixed allocation percentage that you specify in the % field in the Value/Node scroll area on the Basis page. Prorata with Record Basis: Divides the pool amount among the targets based on amounts that are stored in the basis record. Arithmetic Operation: Defines the allocation calculation as a mathematical operation between the pool and basis.
Extension opcode (extension operation code)	When you select Arithmetic Operation, the extension operation code field becomes active and you can select Add, Subtract, Multiply, or Divide.
Transaction Code	Select the appropriate code when you use interunit and intraunit allocation. See Setting Up Interunit and Intraunit Allocations.

These tables illustrate the results of a simple rent allocation using the same pool of 400 GBP but different allocation types.

The following example illustrates the allocation type of spread evenly:

The following example illustrates the allocation type of fixed basis:

The following example illustrates the allocation type of prorata:

The following example illustrates the allocation type of arithmetic operations of multiplication:

See Also

Defining the Allocation Basis

Setting Up Interunit and Intraunit Allocations

Defining the Allocation Pool

Access the Pool page.

Pool Record Type	Specify one of the following: If you are specifying the pool record for General Ledger, select the Ledger Group and enter the ledger group name. If you are defining the pool record for Project Costing, select Any Table and enter the table name. Note. If you specify the value Any Table in the Pool Record Type field, add any additional fields that might be required to the delivered ALC_GL_P_TAO table. If you want to pool a specific amount, select Fixed Amount. While the pool amount is typically based on amounts from the ledger, you can choose to base it on any fixed amount, such as equipment cost of 40000.00 GBP allocated across departments. Specify the fixed amount on the Amounts Field page. Note. The allocation process does not requires the currency control fields (such as FOREIGN_CURRRNCY and CURRENCY_CD) to be specified in the target and offset definitions when using a fixed pool amount. Foreign Currency: The process defaults the target and offset foreign currency from the base currency of the pool primary ledger or from the base currency of the business unit of the request. If you specify a ledger group for the pool, the process selects the base currency of the primary ledger for the pool ledger group. If the pool ledger group is blank, the process gets the base currency from the business unit of the request. Base Currency: The process defaults the base currency to the base currency of the target and offset business unit. This enables you to set up interunit allocation steps by using a fixed amount and targeting the results to different business units with different base currencies.
Pool factor	Enter a percentage to apply to the pool amount. This option provides the flexibility to allocate a percentage of the pool amount. You can also allocate more than 100 percent of the pool amount.
Time Span	Select to specify a period that is relative to the current period: the fiscal year and accounting period that are to be used to retrieve pool records. Enter a single or multiple period time span to determine the accounting periods that are used for the pool. Relative time spans, such as PER (current period activity), retrieve amounts that are relative to the as of date that you specify on the Allocation Request page. You are not required to specify a value in the Time Span field; if you do, the system retrieves only the pool amounts for the specified fiscal year and accounting periods. If you leave this field blank, the system retrieves all the pool amounts for all fiscal years and accounting periods. If you specify Any Table for the pool record, and the pool record does not have both FISCAL_YEAR and ACCOUNTING_PERIOD fields, you cannot specify a time span value here. If you specify Ledger Group for the Pool Record Type field, the system determines the fiscal year and accounting period by using the calendar that is defined for the ledger group on the Ledgers for a Unit - Definition page. If you specify Any Table for the Pool Record Type , the system determines the fiscal year and accounting period by using the calendar that is defined on the Time Spans page. If you specify a multiple period time span, the system adds together the pool amounts for all periods to get one single pool amount, regardless of the values that you enter in the Basis Time Span, Target Time Span, Basis Span Opt, and Target Span Opt fields. You cannot split pool amounts across periods to match basis or target periods.
Zero Pool Amount Option	Select one of the following options to tell the system how to proceed when the amount of the pool record retrieved is zero: Calculate This Pool: Proceed to calculate the amount when the pool is zero. Select Next Pool: Skip the zero amount pool record and select the next pool record for processing. Stop Processing: Issue an error message to indicate a zero amount pool record is selected, and stop the allocation step due to this error. Calc No Rows as Zero (calculate no rows as zero): If no pool rows are selected based on the time span and selection criteria that is specified in the Pool fields, the allocations process processes these rows as zero pool amounts. For rows that exist in the database, the system processes these rows the same as Calculate This Pool. When you use this option, any selection criteria field that you use for the pool must be explicitly defined. For example, if on the Target/Offset pages one of the fields has a source defined as group by pool and basis, then this field must also be defined in the pool. Before the allocation process selects pool records, it groups them based on how the target and offset fields are specified. The process uses the zero pool amount option logic only if the total amounts of the group of pool records totals zero. If some individual pool amounts are zero but the total amount of the group of the pool records is not zero, the system process this group of pool records.
Field Name	Enter, within the Pool Field group box, the field name that the PeopleSoft Allocations process uses in selecting only certain pool rows from the pool record. If the pool record type is a ledger group, the pool record name is the ledger record name that is defined in the ledger template for the ledger group. The Field Name prompt table lists all fields that are in the pool record. If no pool rows are selected based on the time span and selection criteria that you specify in the Pool Fields group box, the PeopleSoft Allocations process skips this step unless you specify Calc No Rows as Zero in the Zero Pool Amount Option field. You receive the message, “No record row exists for the pool,” and if this is a multiple step group, the system continues processing the next step in the group. In the How Specified group box that follows, specify the appropriate option or select a combination of the three methods that are described to determine how values are to be provided for the field name that you select. If you do not explicitly specify the BUSINESS_UNIT field value, the system uses the business unit that is specified on the Allocation Request page to select pool rows. Note. Use trees whenever possible to reduce future maintenance when the ChartField values change.
Selected Detail Values	Select to activate the first Specify Values/Range of Values/Tree Nodes edit box so that you can list individual pool field values, such as specific departments or accounts.
Selected Tree Nodes	Select to activate the tree information fields for you to specify a tree from which to select nodes. The Level Name field is optional and is used to limit the prompting to the selected level. Use the Set Control Value field to select trees that are not keyed by setID. For example, some Project Costing trees are keyed by business unit. The system uses the value to identify which trees are available in the Tree Name field.
Range of Values	Select to activate the Specify Values/Range of Values/Tree Nodes edit box for you to enter the beginning and ending pool field values. If you leave the fromValue field blank, the system selects all pool field values that are less than or equal to the To field value. You cannot leave the To field blank because the blank value is always the smallest value. You can insert multiple ranges of values.

Note. The PeopleSoft Allocations process excludes period 999.

See Also

Using TimeSpans

Defining the Allocation Basis

Access the Basis page.

How you define the basis depends on the allocation type that you select on the Type page. The allocation type that you select determines much of the Basis page. The following describes what occurs for each allocation type:

• Copy: No basis is required and all fields on the Basis page are unavailable.

• Spread Evenly: The pool amount is divided evenly across the basis field values that are specified in the basis. No basis rows are required to exist in the basis record that is specified. You must still specify a value in the Basis Record Type field so that the system can provide a prompt table listing for the Field Name field in the Basis Fields group box.

  In the How Specified group box, you can use Selected Detail Values, Selected Tree Nodes, or Range of Values fields to specify field values.

  You can specify more than one field name; the system divides the pool amount evenly across all basis field value combinations.

  Suppose that you spread evenly across department IDs 0100 and 0200 and products A, B, and C. In this case, each department ID and product combination (that is, DeptID 0100 and Product A, DeptID 0100 and Product B, and so on) receives 1/6 of the pool amount.

  Note. This is a simplified example of spread evenly allocation type to illustrate how the amounts are distributed across the target. However, depending on the distribute odd cents option, one of the departments might contain the odd cents that are required to offset the allocated amount against the pool. The distribution of the odd cents is covered in the values in the Selecting Rounding Options section.

  See Selecting Rounding Options.

• Allocate on Fixed Basis: This is a variation of pro rata allocation, where the percentage of the prorate is fixed. As withSpread Evenly, no basis rows are required to exist in the basis record that is specified. You must still specify the basis record type so that the system can provide a prompt table listing on the basis field name.

  You can use only the Selected Detail Values field to specify basis field values, and you can specify more than one value in the Field Name field.

  You must also specify the fixed % (percent) for each field value in the Specify Value/Range of Values/Tree Nodes edit box. The total of the percentage for one field does not have to add up to 100 percent, but the system uses the percentages to calculate the actual percent-to-total for each value.

  For example, if you specify 10 percent for DeptID 0100 and 40 percent for DeptID 0200, the system allocates 20 percent of the pool amount to DeptID 0100 and 80 percent to DeptID 0200.

• Prorata with Record Basis: Specify basis fields in the same way that you do the pool. Basis rows are selected from the basis record, and their amounts are used to calculate a percent-to-total to distribute the pool amount to each target.

• Arithmetic Operation: Like Prorata with Record Basis, basis rows are selected from the basis record, and you specify basis in the same way that you do the pool. Target amounts are calculated by performing the mathematical operation between each pool and basis amount.

For example, suppose that the total November rent expense for US004 is 110,000.00 USD, paid through the administrative division. This expense must be divided among six divisions. The basis for the rent expense allocation is the amount of floor space that is occupied each month by each division. Floor space is maintained in statistical account 999903. Department ID is defined using the MFG_DEPARTMENTS tree, the DIVISION tree level, and the USA tree node. The following table indicates how much floor space each division uses:

When the amounts are allocated, each division is debited for its share of the rent expense:

Refer to the Pool page for a description of the remaining fields on the Basis page.

Note. Allocations does not support using summary ledgers in the basis.

See Also

Defining the Allocation Basis

Defining the Allocation Target

Access the Target page.

Target Record Type	Select one of the following: For Journals Records, specify a target ledger group name. The system uses this definition to determine the journal line record name and other characteristics (such as calendar, multibook, and base currency). If the target is Any Table, specify the table name in the edit box that becomes available.
Time Span	Use to specify the output for a single or multiple accounting periods for the target. Relative time spans, such as PER (current period activity), create the target relative to the as of date that is specified on the Allocation Request page. If the Target Record Type value is Journals Records, you must specify the time span value. If the target record is a table that has both FISCAL_YEAR and ACCOUNTING_PERIOD fields, you have the option to specify the time span value. If the target record is a table that does not have both FISCAL_YEAR and ACCOUNTING_PERIOD fields, you cannot specify the time span value. If you do not specify the time span value, the system populates both FISCAL_YEAR and ACCOUNTING_PERIOD with a zero value in the target record.
Basis Span Opt (basis span option)	If you use a multiperiod time span for the basis and target, select one of the following in the Basis Span Optfield: Combine Periods for Basis: Combines the basis amounts for each period that is defined by the time span into one virtual period, producing a single amount. Split Basis by Period: Maps the basis amount for each period one-to-one with the target periods. For this reason, the number of periods that is in the basis and target time span must match. When you select this option, the Target Span Opt field becomes inactive.
Target Span Opt (target span option)	If you select a multiple period time span for the target, you must specify the Target Span Opt field when the basis time span is either a single period or multiple periods (the Basis Span Opt field is Combine Periods for Basis): Repeat Target Each Period: Repeats the entire target amount for each period that is defined in the time span. Divide Target Across Periods: Divides the target amount by the number of periods that are defined in the time span and distributes it equally to each period.
Field Name	If the target record is journals, the target record name is actually the journal line record name that is defined on the ledger template for the ledger group. The Field Name prompt table lists all fields that are in the target record. The system validates the Field Name field value that is entered against the record when you save this allocation step definition. Typically, you include any fields that are required by the target record including all the keys and any fields that affect functionality and those that you might decide are mandatory.
Source	Provides a convenient way to populate the target field values, particularly if the values are from the pool or basis records. You need not reenter them here, just prompt for the appropriate option and choose from the following: Pool: Uses the field values from pool records. Basis: Uses the field values from basis records. Group By: Uses the matched field values from both the pool and basis records. Value: Specifies a fixed value for the target field. You can use this only for character- or date-type fields. You should enter a fixed date in one of these formats: mmddyy, mm/dd/yy, or mm/dd/yyyy. If you select this option, you enter the value in the Value/Mask field. Begin Pd (begin period): Uses the beginning date for the target accounting period. If you use this option, the target time span must be populated. Otherwise, the system cannot populate a date value. End Period: Uses the end date for the target accounting period. If you use this option, the target time span must be populated. Otherwise, the system cannot populate a date value. Req Date (request date): Uses the as of date that is specified on the Allocation Request page. Seq Num (sequence number): Uses the next field sequence number for the target records. The allocations process selects the maximum field sequence number for the specified target criteria and increments the number by one. This option is used if the Target Record Type field value is Any Record.
Field Mapping	If the source is from Pool, Basis, or Group by, you can specify field mapping for those occasions when the field name for the pool or basis record differs from the field name that is in the target record. For example, this could occur if the Product field value for the target record must come from the Project field value of the pool record.
Value/Mask	If you specify a fixed value in the Source field, use this Value/Mask field for character or date-type fields. You can enter a fixed date in one of the following formats: mmddyy, mm/dd/yy, or mm/dd/yyyy.

Defining the Allocation Offset

Access the Offset page.

Offset Record Type

Select Journal Records or Any Table. For journals, specify theOffset Ledger name. The system uses this definition to determine the journal line record name and other characteristics (such as calendar, multibook, and base currency). If the value in the Offset Record Type field is a table, specify the record name in theTable edit box that becomes available. Note. If the allocation step does not require an offset, leave this field blank.

Specify Field Values

Specify the offset field values. The offset fields can be directed to the pool record or a particular target table, but the purpose of the offset is always to prevent double counting.

See Also

Defining the Allocation Target

Selecting Output Options

Access the Output Options page.

Journal Options

Commitment Control

Click the Commitment Control link to access the Commitment Control page.

In the Commitment Control Amount Type field, select from the following options:

Bypassing or Overriding Budget Checking

Click the Commitment Control link to access the Commitment Control page.

Budget Entry Type

The following options apply to commitment control budget journals:

Parent Budget Options

Automatic generation of parent budget impacts revolves around the originating journal. The originating journal is a child level budget, budget adjustment, or transfer budget journal, entered manually or by journal import or allocations, on which parent or multiple parent budget level impacts are generated.

The automatic generation of parent budgets is discussed in the Commitment Control PeopleBook in the chapter dealing with posting of budgets.

See Generating Parent Budgets, Budget Adjustments and Budget Transfers Automatically.

Table Output Option

Currency Conversion

The currency conversion fields are used by the PeopleSoft Allocations process to convert the base currency amount of the target and offset. The process converts the base currency if the base currency of the target and offset is different from the base currency of the pool. When allocating to a table, the business unit of the target and offset must be a General Ledger business unit; otherwise, the process does not convert the base currency amount.

See Also

Processing Journals

Defining Document Sequencing

Selecting Rounding Options

Access the Round Options page.

Round Options	Specify the method to use to round the allocation amount from the following options: Normal:This is the default. The process rounds the allocated amount based on the decimal precision of the currency control value. For example, 104.495 is rounded to 104.50 GBP. Round Down: The process rounds the allocated amount down to the nearest decimal based on the decimal precision of the currency control value. For example, 104.495 is rounded down to 104.49 GBP. Round Up: Rounds the allocated amount up to the nearest decimal based on the decimal precision of the currency control value. For example, 104.495 and 104.494 are both rounded up to 104.50 GBP. Truncate:Truncates the allocated amount after the decimal precision of the currency control value. For example, 104.495 and 104.4949 are truncated to 104.49 GBP.
Distribute Odd Cents	For allocation types of prorata, spread even, and fixed basis, the process balances the target and offset amounts to the pool amount that is allocated. In other words, the process attempts to allocate 100 percent of the pool amount to the target and offset amount, sometimes resulting in odd cents. The Distribute Odd Cents option gives you the flexibility to determine where to distribute odd cents. Because allocation processing is set based rather than row-by-row to improve performance, this option is required for allocation types of prorata, spread even, and fixed basis. First Target Line: This is the default. Odd cents are distributed to the first target line. Specify ChartFields: Define the ChartFields to which the system distributes the odd cents. Last Target Line: Select to distribute odd cents to the last target line. Largest Target: Select to distribute odd cents to the target line with the largest amount. If you are allocating within ChartFields or grouping by ChartFields in the definition, the process distributes odd cents with each group, ChartField value. Note. PeopleSoft recommends that you select the first two options for optimum performance.
Field Name and Field Value	If you select Specify ChartFields as the Distribute Odd Cents option, enter the ChartField combination to which you want to distribute the odd cents. Enter the ChartField in the Field Name field and the ChartField value in the Field Value field. For example, enter ACCOUNT for the field name and 100000 for the field value.

The following examples show how the process rounds the allocation amounts if you select one of the options on this page:

Example 1

The first example shows how the process rounds the allocation amounts if you specify the following options:

The process uses the following formula to calculate the amounts:

Allocated Amount = (Pool Amount (Pool Factor/100)) (Basis Amount/Total Basis).

(1000 (1/6)) = 166.67 rounded:

Example 2

The second example shows how the process rounds the allocation amounts if you specify the following options:

The process uses the following formula to calculate the amounts:

Allocated Amount = (Pool Amount (Pool Factor/100)) (Basis Amount/Total Basis) + .005.

(1000 (1/6)) = 166.67 rounded:

Example 3

The third example shows how the process rounds the allocation amounts if you specify the following options:

The process uses the following formula to calculate the amounts:

Allocated Amount = (Pool Amount (Pool Factor/100)) (Basis Amount/Total Basis) - .005.

(1000 (1/6)) = 166.67 rounded:

See Also

Selecting Rounding Options

Specifying Batch Records

Access the Batch Records page.

Calculation Log	Specify the temporary table (ALC_CLOG_TAO) to the calculation log.
Pool	Specify the temporary table for the pool data. The PeopleSoft Allocations process uses this table to store the temporary data for the pool.
Basis	Specify the temporary table for the basis data. The PeopleSoft Allocations process uses this table to store the temporary data for the basis.
Target Detail	Specify the temporary table for the target detail data. The PeopleSoft Allocations process uses this table to store the temporary data for the target.
Target Summary	Specify the temporary table for the target summary data. The PeopleSoft Allocations process uses this table to store the summarized data for the target and offset.
Offset Detail	Specify the temporary table for the offset detail data. When allocating to a journal, sometimes the process uses a separate temporary table to store the offset data.
Offset Summary	Specify the temporary table for the Offset Summary data. Data is summarized from the target record or journals. When allocating to a journal, sometimes the process uses a separate temporary table to store the offset summary data.
Target Balance	Specify the temporary table for the target balance data. The PeopleSoft Allocations process uses this table to store the target balance lines, which are necessary to balance the target and offset against the pool amount.
Calculation Log Record	Specify to create a calculation log for a complete audit trail for debugging. Select the Create Calculation Log option on the Allocation Request page. You can use the delivered calculation log record, ALLOC_CALC_LOG, for all allocation steps that are processed against the actuals ledger (but not the budgets ledger, which might have ChartFields that are different from the actuals ledger). If the allocation is not processed against the actuals ledger, modify the Calculation Log Record field or create a unique record.
	Click to assign the default temporary tables. The process assigns the temporary tables based on the setup of the pool, basis, target, and offset.

PeopleSoft delivers these standard temporary (TAO) tables:

Use the standard General Ledger TAO tables to allocate ledger (including all ledger, commitment control, projects, and budgets) and journal data.

Use the standard Project Costing TAO tables to allocate projects resource data.

Note. When allocating to a journal, the PeopleSoft Allocations process sometimes uses a separate temporary table for the offset detail and offset summary data in order to optimize the processing performance. The process determines if it must use a separate temporary table at runtime. Even if you specify a different table for the offset detail and summary, the process might not use a separate temporary table to process the offset data. There are no delivered offset detail and summary TAO tables for projects because these tables are not used to allocate to a journal.

PeopleSoft recommends that you use the standard delivered TAO tables.

Note. If you specify the value Any Table in the Pool Record Type field, add any additional fields that might be required to the delivered ALC_GL_P_TAO table.

If you are using your own customized TAO tables, use the delivered TAO tables as a model. Open the delivered TAO table and do a save as to create a TAO table. The following fields are required:

• PROCESS_INSTANCE, LOGICAL_RECORDS, BUSINESS_UNIT, BUSINESS_UNIT_IU.

• ChartField that are applicable to the process, such as Account, DEPTID, and so on.

• Amount Fields and the currency control fields that are applicable to the amounts that are allocated.

  This should also include the calculation log pool and basis amount fields, namely, ALLOC_POOL_AMT, ALLOC_POOL_PBA, ALLOC_POOL_PTR, ALLOC_BASIS_AMT, ALLOC_BASIS_TOT.

• Fields required for interunit processing, IU_TRAN_GRP_NBR, IU_ANCHOR_FLG.

• Fields required for intraunit processing, CF_VALUE1 to CF_VALUE10.

• Field required for base currency conversion, BASE_CURRENCY_POOL, RATE_MULT, RATE_DIV.

• Fields required for time span, ACCOUNTING_PERIOD, FISCAL_YEAR.

• Other fields that are applicable to the setup.

  For example, if you are allocating to a specific ledger, add field LEDGER to the TAO tables.

  Note. To increase performance, the PeopleSoft Allocations process attempts to use a dedicated temporary table for all TAO tables. If you are using your own TAO tables, use dedicated temporary tables that are created in PeopleSoft Application Designer and define the record type as a temporary table. Define the temporary tables in the definition of the PeopleSoft Allocations process (FS_ALLC).

See Also

Defining the Allocation Basis

Understanding General Ledger Background Processes

Defining Amount Fields

Access the Amount Fields page.

Use this page to define the fields in the chosen pool record that store the pool amounts, the fields in the chosen basis record that store the basis amounts, and where the system is to put the calculated amounts in the chosen target and offset records.

You can specify many sets of amount fields to perform allocations. For example, Project Costing can allocate on both resource amount and resource quantity fields in the same allocations. You can allocate pool resource amounts by using the basis resource amount percentage-to-total ratio and the pool resource quantity by using the basis resource quantity percentage-to-total ratio. You can also allocate both the pool resource amount and resource quantity using the basis resource amount percentage-to-total ratio. This page gives you the flexibility to define how the amounts are distributed from the fields in the pool record to the fields in the target and offset record.

General Ledger provides information about the total balances in the base currency and in individual transaction currency balances. Use the posted total amount field to get the total balance in the base currency. You can use the Posted Transaction Amount field to get the individual transaction currency balances. The Posted Transaction Amount (POSTED_TRAN_AMT) and Posted Total Amount (POSTED_TOTAL_AMT) fields exist in the ledger table to store different currency information.

The following simplified example illustrates the totals as recorded in the ledger for three transactions in three currencies: 1000 EUR, 100 USD, and 1000 GBP. Assume that the base currency is USD. Also, assume that 1 EUR is equal to 1.10 USD and that 1 GBP is equal to 1.58 USD. After the three transactions are recorded, the balances in the ledger are as follows:

Note. The Foreign Amount (FOREIGN_AMOUNT) field on the journal line is the transaction currency amount and is ultimately recorded in the posted transaction amount. The Monetary Amount (MONETARY_AMOUNT) field on the journal line is the equivalent of the base currency amount and is recorded in the posted base amount. It is important to keep this relationship between ledger and journal line fields in mind when the target and offset are journal lines.

The following are examples of the setup for the amount fields for various allocation scenarios.

For example, if you are allocating on monetary amounts for General Ledger, the pool record might be Ledger Group ACTUALS and the Target record journals ACTUALS. The allocation fields are:

The actual pool and target records are LEDGER and JRNL_LN, respectively. The currency control fields that are defined in PeopleSoft Application Designer for the POSTED_TOTAL_AMT, POSTED_TRAN_AMT, and POSTED_BASE_AMT fields are the CURRENCY_CD and BASE_CURRENCY fields for the LEDGER record. The currency control fields that are defined in PeopleSoft Application Designer for the FOREIGN_AMOUNT and MONETARY_AMOUNT fields are the FOREIGN_CURRENCY and CURRENCY_CD fields for the JRNL_LN record.

Using these currency control field definitions, allocations automatically determine that the target record’s FOREIGN_CURRENCY field value source is from the pool record’s CURRENCY_CD field value, and the target record’s CURRENCY_CD field value source is from the pool record’s BASE_CURRENCY field value. You need not define the currency field values explicitly for the Target and Offset fields.

These currency control field values also determine the currency precision and rounding feature in the PeopleSoft Allocations process. For example, if the target record FOREIGN_CURRENCY field value is USD, the system rounds the FOREIGN_AMOUNT to the second decimal. If the target record FOREIGN_CURRENCY field value is JPY (Japanese yen), the system rounds the FOREIGN_AMOUNT to the integer.

The PeopleSoft Allocations process uses the target record’s currency control field values to determine the currencies that are for the target and offset records. If you are allocating on fixed pool amounts, there is no pool record; you must specify the target and offset records’ currency field values in the Target and Offset fields. For example, if you are allocating 100.00 USD, you enter 100 in the Fixed Pool Amount field on the Amount page. On the Target and Offset pages, specify the FOREIGN_CURRENCY and CURRENCY_CD fields in the Specify Field Values group box. Set the Source field value on the Target and Offset page to Value.

The following table is an example of the fields that are used when allocating on monetary amounts in PeopleSoft applications:

The following example shows fields used when allocating to statistics amounts in PeopleSoft applications:

If you are multiplying a statistics pool amount (such as, hours) by a basis amount (such as , hourly rate) in PeopleSoft applications to create a monetary amount target, explicitly specify the FOREIGN_CURRENCY and CURRENCY_CD field values for the target and offset record. The amount fields are defined as follows:

If you are creating budgets for next year in PeopleSoft applications and you do not want to carry all foreign currencies in the budget ledger but instead you want to use the consolidated total amounts for all currencies, you can specify the currency code equal to the base currency for your pool. Define the amount fields as follows:

Defining the Allocation Group

To define the allocation group, use the Define Allocation Group component (ALLOC_GROUP).

This section provides an overview of the allocation group and discusses how to put process steps in allocation groups.

Understanding the Allocation Group

You can define multiple allocation steps for step-down allocations across ChartFields. The target for each step can become the next step’s pool or basis. You define an allocation group for these steps and then process the allocation on the group. If a step in the sequence fails, the Continue option determines if processing continues for the next step.

Note. Even if there is only one step in an allocation, you must define an allocation group.

Page Used to Define Allocation Group

Putting Process Steps in Allocation Groups

Access the Allocation Group page.

Use the icons in the upper right corner of the page to copy, rename, or delete the allocation group.

See Also

Defining Allocation Process Steps

Copying, Renaming, or Deleting Allocation Steps

This section provides an overview of copying, renaming, or deleting allocation steps and discusses how to copy, rename, or delete allocation steps.

Understanding Copying, Renaming, or Deleting Allocation Steps

The PeopleSoft Allocations process requires several steps. Chances are that some of the steps in a single allocation—or even steps for a different allocation altogether—can be quite similar. It’s possible to use identical steps in several allocations simply by specifying the step name; there is no limit to the number of times or places that you can use a given step.

Page Used to Copy, Rename, or Delete Steps

Specifying the Parameters for a Copy, Rename, or Delete

Access the Copy / Rename / Delete Allocation Step page.

Action	Select one of the action options: For Copy or Rename, the New Step field is available. Use this field to identify the new step or rename the original one. If you select Delete, the process purges the step definition from the system. If you rename to delete a process step, the process automatically updates the allocation process groups.
Allocation Step	Select the step that you want to manipulate.
Add Step to Allocation Groups	When you copy a step, you can choose one of the following options to add the step to the process group where the process step, used to copy the new step, exists: Add after process step. Add first in group. Add last in group. Do not add in group.

Creating Adjusting Entry Journals

To create adjusting entry journals, use the TimeSpans component (TIME_SPAN).

This section provides an overview of allocations and adjusting entry journals and discusses how to:

• Set up time span definitions specifying absolute period.

• Set up time span definitions specifying relative period.

• Allocate to multiple adjustment periods.

• Specify the Adjusting Entry option.

Understanding Allocations and Adjusting Entry Journals

The PeopleSoft Allocations process supports creating adjusting entry journals, where the accounting period is an adjustment period. Adjustment periods can be defined as absolute period or relative to current period.

Page Used to Create Adjusting Entry Journals

Setting Up TimeSpan Definitions Specifying Absolute Period

Access the TimeSpans page.

TimeSpans page

In this example, the adjustment period is set up for the absolute period of 905.

Setting Up TimeSpan Definitions Specifying Relative Period

In the following example, the adjustment periods are defined relative to the current regular period:

TimeSpan determined relative to current period

The adjustment period is the Start Adjustment Period/End Adjustment Period value that is specified, plus the current regular period. For example, suppose that you are processing allocations in March, then the current period is 03 (monthly calendar) and the adjustment period is 903.

The advantage of defining the adjustment period as relative to the current period is that you need not maintain the adjustment period value in the time span.

Allocating to Multiple Adjustment Periods

Use relative adjustment periods to allocate to multiple adjustment periods. In this example, the TimeSpans page is defined for allocations to create adjusting journal entries for adjustment periods 901 through 912:

TimeSpan for multiple adjustment periods

Specifying the Adjusting Entry Option

Select a time span that uses adjustment period on the allocations Target page.

Specifying the adjustment period time span on the Target page

If the time span that you select on the Target page is not set up to use adjustment periods, the Adjusting Entry options on the allocation Output Option page are not visible.

Selecting adjusting entry on the Output Options page

The PeopleSoft Allocations process uses this option to determine which accounting periods are used with the journals. If the Adjusting Entry option is selected, the PeopleSoft Allocations process creates the journal or journals with the adjustment period or periods that are defined in the target time span. If the option is not selected, allocations creates the journal or journals with the regular accounting period or periods.

Setting Up Interunit and Intraunit Allocations

The PeopleSoft Allocations process creates what are initially unbalanced allocation journal entries between legal entities (interentity), between business units (interunit), and among balancing ChartFields within a particular business unit (intraunit).

The PeopleSoft Allocations process does not create the interunit and intraunit balancing journal lines as a part of the process. The interunit and intraunit balancing transaction lines are created by the Inter/IntraUnit Processor, which is run from journal edit.

In the following example, business unit JP001 is allocating rent expense that is accumulated in its account 640000 in the amount of 1000000 JPY to JP001, JP002, and JP003 on a fixed basis of 50 percent, 20 percent, and 30 percent, respectively.

The following illustrates a simple allocation of this expense across multiple business units:

You create an interunit and intraunit allocation much as you would any other, except that you must select an appropriate transaction code on the Allocation Type page. The PeopleSoft Allocations process populates this value on each journal entry line.

The transaction code is a means to categorize interunit and intraunit transactions. In this instance, we have used the delivered System Transaction for General Ledger journals (GLJ) and the Transaction Code JOURNALS.

If you want to distinguish the allocated interunit and intraunit rent receivables and payables from all others, you can create a transaction code (such as AllocJrnl) and map it to the GLJ System Transaction. You must also create interunit templates and intraunit templates that associate the new transaction code with accounting entry types for which you provide ChartField values that are used by the system to complete the partial interunit and intraunit entries.

The PeopleSoft Allocations process supplies the following information for the journal header:

The PeopleSoft Allocations process creates the following journal line information:

The anchor is the business unit or ChartField value around which the system completes the entry and determines such things as the balancing method and organizes the related journal lines in the same IU group (interunit group).

For intraunit allocation steps, the process always defines a unique IU group for each balancing ChartField value that is defined in the pool. For interunit, the process always uses an IU group number of 1.

The PeopleSoft Allocations process derives the anchor business unit based on the definition setup.

The process first checks to determine if the business unit is defined in the offset as a fixed value. If this condition is the case, the process uses the offset fixed value as the anchor.

If not, the business unit is not in the offset as a fixed value, the process checks if the business unit is defined in the target as a fixed value. If this condition is true, the process uses the target fixed value as the anchor.

If the business unit is not defined in the target or offset as a fixed value, then the process uses the business unit from the pool as the anchor.

Note. If there are multiple pool values, each is processed against the basis in turn. The result is a separate IU group for each pool value and its journal entry lines. Use any of the interunit business units that are defined in the pool when requesting interunit allocations.

At this point, the rent expense is allocated but the journal is not in balance because you have not yet created the due to and due from interunit or intraunit payables and receivables lines. When you run the Inter/IntraUnit Central Processor, it provides the following information or additional lines to balance the journal entry (lines 5 through 8):

See Also

Using Interunit and Intraunit Accounting and ChartField Inheritance

Using Allocations with PeopleSoft Project Costing

There are two basic types of allocations that you can perform in PeopleSoft Project Costing by using the PeopleSoft Allocations process:

• Project-to-project allocations.

• General Ledger to Project Costing allocations.

The PeopleSoft Enterprise Project Costing 8.9 PeopleBook discusses using the PeopleSoft Allocations process in Project Costing and provides an example of a project-to-project allocation step.

See Also

Using Allocations with PeopleSoft Project Costing

Processing Allocations in Project Costing

Running an Allocation Request

This section discusses how to run the allocation request.

Page Used to Run the Allocation Request

Specifying the Allocation Process Request Parameters

Access the Allocation Request page.

Run the request after you define the allocation steps and allocation group.

Note. Calculation logs are cleared using SQL scripts.

See Also

Restarting and Recovering the Allocations Process

Producing Allocations Reports

The allocation reports provide information about the allocation setup and the results of a PeopleSoft Allocations process run.

Pages Used to Produce Allocation Reports

Viewing Process Messages

The run status in the process monitor appears as a warning if allocations generates any error messages for the request. Use the Message Log to view any system-generated messages when you process allocations. The Message Log can also help you to troubleshoot allocations and to audit allocation information.

Restarting and Recovering the Allocations Process

If the system encounters an error while it is processing a request, it sets the request status to error The program then continues with the next request. To rerun the canceled request, you must return to the online request page and initiate the request.

You can use the Message Log page to identify any request marked in error. When you correct the condition that caused the error, mark the request for processing and run the job again.

For allocations, the request specifies the allocation group to be processed and a commit is performed after each allocation step in that group. If the system encounters an error while it is processing a step, two factors determine whether the system continues with subsequent steps:

• The type of error.

• The Continue option on the Allocation Group page.

If the error is a system error, the allocation process aborts. If the error is a data error, the system checks the Step Continue option on the Allocation group definition.

If you select Continue for the step that failed, the system continues processing despite the failure. If you do not select Continue for that step, allocations proceeds with the next group on the request. After you correct the problem that caused the error, you can rerun the process for the same group.

The Start Step check box on the Allocation Request page enables you to specify whether the PeopleSoft Allocations process should restart processing at the step that failed. If you do not select this check box, allocations starts with the first step in the group. The Start Step option is available only if an error occurred during processing.