Understanding Oracle's 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.

  • Migrate allocation configuration data from one database to another.

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.

Migrating Allocation Configuration Data

For efficiency when implementing Allocations, you can create and test your allocations in a development or test database and use the Data Migration Workbench to migrate your Allocation Steps, Groups, and Requests from one database to another, and ultimately to the production database.

For more information, see Using the Data Migration Workbench for PeopleSoft Allocations