Understanding PeopleSoft Interunit and Intraunit Functionality
The PeopleSoft interunit and intraunit functionality includes common setup pages and shared processing to manage interunit and intraunit transactions across its products. You can create a transaction that crosses business units within the same ledger group, and entities, or balancing ChartFields without having to explicitly enter the interunit or intraunit balancing accounting entries. The interunit unit processor creates the interunit and intraunit balancing entries automatically when you have implemented this functionality.
With interunit and intraunit processing, the system uses the minimal number of accounting lines that you must provide and it automatically completes the entire transaction by generating the necessary balancing lines or entries for both the appropriate entities and accounts.
To use centralized interunit and intraunit processing effectively, your accounting environment must be such that you allow cross-entity entries directly to balance sheet, expense or to clearing accounts at some level or levels among the related entities in your organization. Once you establish the necessary accounting protocols to be used in conjunction with interunit and intraunit functionality, minimal input is required from you for the system to complete the cross entity balancing entries necessary when transactions occur between related entities or sets of balanced books.
Partial or minimal interunit and intraunit entries can be unbalanced or cross-entity and are created and processed by many procedures in the various PeopleSoft products.
This topic discusses:
Balancing ChartFields.
Affiliate ChartFields.
Balancing methods.
Anchor entity.
Product interface and system transaction categorization.
Organizational and legal categorization of transactions.
Inter/IntraUnit templates.
Interunit pairs.
Summarization of interunit and intraunit journal lines.
Products using interunit and intraunit processing.
Balancing ChartFields and their relationship to a balanced set of accounts or books is central to interunit and intraunit processing and ChartField Inheritance.
Business unit and the ChartFields that you can designate to represent entities are said to be balancing when you require debit amounts to equal credit amounts for the purpose of maintaining a balanced set of accounts or books for a particular business unit and selected ChartField values. For example, if for a Business Unit, Department and Fund are Balancing ChartFields, then transactions involving values for any of these ChartFields must have debit amounts equal to credit amounts.
You can use Affiliate ChartField values when interunit or intraunit transactions are maintained using the same Account ChartField value among several related entities (such as business units, funds or operating units). For example, each entity within your organization might use account 140000 as the common interunit receivable account and 201000 as the common interunit payable account. However, when using the same accounts for all entities, an Affiliate ChartField value must be assigned to the accounting line or journal line to readily identify the entity with which the receivable or payable is shared.
Affiliate ChartFields cannot be used as standard standalone ChartFields. They must be used in association with another related ChartField. This is because the Affiliate ChartField values are the values of the related ChartField. There is no separate Affiliate ChartField page where you enter Affiliate values as with the stand alone ChartFields, such as Account or Department.
For example, business unit is required as the InterUnit Related ChartField for Affiliate. It provides the values available in the drop down list box for the Affiliate field on the Journal Entry page. PeopleSoft also delivers intraunit affiliate ChartField functionality for the fund and operating unit ChartFields.
While you could assign each entity different accounts to identify entities among the various interunit or intraunit transactions, this probably entail a larger number of interunit or intraunit accounts having to be created and maintained. An advantage in using affiliate ChartFields is that you can have fewer accounts to maintain.
The Balancing Method is a means of ChartField value retrieval to complete partial or out of balance entries and is accomplished by the following methods:
Due To and Due From Balancing
In Due To and Due From Balancing the system generates additional interunit unit receivable and payable journal lines to bring the overall accounting transaction into balance from your partial cross-book interunit unit entry.
For example, assume that you create a cross-entity entry to transfer an asset from one business unit to another. The system generates the interunit receivable entry for the source or Anchor Business Unit and an interunit payable entry for the receiving or Non-Anchor Business Unit to bring the books for each business unit into balance.
There are three Due To and Due From Balancing methods for interunit transactions as follows:
Term |
Definition |
|---|---|
Indirect Method |
The Due To and Due From ChartFields used to balance each business unit in the transaction are retrieved from the affiliated business unit's Inter/IntraUnit Template definition. |
Direct Method |
The Due To and Due From ChartFields used to balance each business unit in the transaction are retrieved from the business unit's own Inter/IntraUnit Template definition. |
Pairs Method |
The Due To and Due From ChartFields used to balance each business unit in the transaction are retrieved from a definition for the pair of business units involved in the transaction. Pairs are defined on the InterUnit Pair Maintenance page. |
Offset Inheritance Balancing
For transactions that include system-generated entries (often as offset entries), the system-generated entries can be defined to inherit ChartField values from the other entries in the transaction (such as the distribution lines you entered) to create an expanded balanced transaction and distribute offsets as needed.
For example, you enter a voucher that records expenses for two different funds. Using Offset Inheritance, the offsetting entries are properly distributed by the system to the appropriate payable accounts for the two funds.
Edit Only Balancing
Even if you have not implemented interunit and intraunit functionality, a journal might not be in balance for reasons other than interunit activity. The Journal Edit process uses the rules that you set up for balancing journals on the Journal Edit Options page to either recycle such journals or do Edit-Only Balancing and provide a suspense account to automatically balance the entry.
Edit-Only Balancing is primarily applicable when a transaction is out of balance due to rounding or an error. It is not applicable to interunit and intraunit processing.
The following information describes an anchor entity and its purpose.
Interunit
Anchor Business Unit typically refers to what is termed the source, sending, initiating, or charging entity. For example, if business unit US001 pays rents for US002 and US003, US001 can be designated as the Anchor Business Unit.
Intraunit
Anchor values for balancing ChartFields serve a similar purpose. For example, within business unit US001, if cash from Fund 100 is used to pay expenses attributable to funds 200 and 300, Fund 100 can be designated the anchor.
Purpose of the Anchor Entity
When transactions involve three or more entities, the anchor designation is essential for determining which entity serves as the central hub for the inter and intraunit balancing entries. The anchor designation also affects the transaction currency in a multicurrency situation for the due to and from lines that are generated by the processor.
Designating an Anchor Entity
In most of the subsystem applications, the anchor entity is determined by the nature of the transaction. For example, for an accounts payable voucher the anchor entity is always the entity to which the supplier liability is recorded. If there are distribution lines that are booked to different business units, these trigger the generation of interunit balancing entries.
In general ledger journal entry, the anchor business unit is the unit entered on the journal header.
Unless you select the IntraUnit Balancing Entries check box on the Detail Ledger Group − Balancing page, inter and intraunit processing does not create IntraUnit balancing entries for balancing ChartFields, such as Fund, even if different fund values appear in the same journal.
The Anchor Business Unit is readily apparent in interunit transactions; however, determining which is the Anchor Fund and how journal lines should be grouped when a transaction involves multiple funds requires additional steps. You can indicate on the journal entry which fund values are Anchors and assign a Group Number to journal lines to assist the inter and intraunit processor in creating the balancing lines.
For General Ledger Allocations, the pool values are used as the anchor values.
PeopleSoft delivers one or more System Transactions for each product primarily to provide the following:
An interface to the Inter/IntraUnit Central Processor for each product or application and its transactions that might require system generated inter and intraunit balancing lines.
Segregation of inter and intraunit payables and receivables by type of System Transaction, such as accounts payable voucher or general ledger journal.
Definition of options that are appropriate only to a particular System Transaction, such as whether to create an AP (accounts payable) Voucher and an AR (accounts receivable) Item for an InterUnit Bill.
The System Transaction provides predefined information about the tables and fields involved in an application transaction and supplies run-time parameters to the Centralized Inter/IntraUnit Processor.
There are some cases where there are multiple System Transaction Codes for a product, even when all of the technical details for the interface to the central processor are the same, such as AP (accounts payable) Vouchers and AP (accounts payable) Payments. This allows you to associate each system transaction with a different user-defined Transaction Code, which is the key to how you set up ChartFields for InterUnit and IntraUnit payable and receivable entries.
Transaction Codes are defined on the Transaction Code page. Each Transaction Code that you define can be mapped to one or more of the System Transactions on the System Transaction Map page, but each System Transaction can have only one Transaction Code for all products with the exception of general ledger. Once mapped, System Transactions determine the Transaction Codes available to a product for further categorization. If your inter and intraunit accounting does not differ across products and transactions you can define a single Transaction Code and map it to all the System Transactions.
Only the General Ledger System Transaction GLJ (general ledger journal) allows the mapping of multiple Transaction Codes so you can create additional subset categorizations for an inter and intraunit transaction. For example, you could create the following Transaction Codes and map them both to the General Ledger System Transaction.
ADVANCES (Intercompany cash advances)
INTEREST (Interest on Intercompany advances)
This enables you to further segregate and categorize interunit transactions within General Ledger by maintaining all advances in a separate category of interunit activity and inter company interest on these advances in another category.
Note: When setting up business units across products, you must include all business units in the same ledger group to use the interunit processor functionality.
PeopleSoft provides functionality to distinguish between Inter Entity and Intra Entity transactions within the interunit category, enabling you to apply the required accounting treatment. However, while there may be different legal entities, all business units in an interunit transaction must share the same ledger group name to generate interunit entries.
The following terms define transactions between and within business units:
Term |
Definition |
|---|---|
InterEntity |
A transaction involving two or more General Ledger business units, when each related business unit represents a separate legal entity. |
IntraEntity |
Transactions involving two or more General Ledger business units, when all business units are part of the same legal entity. |
InterUnit |
Any transactions involving two or more General Ledger business units within the same ledger group. These can be either InterEntity or IntraEntity, depending on how the business units are defined and how they are mapped in the legal entity hierarchy. |
IntraUnit |
A transaction within a single General Ledger business unit that involves more than one value in a lower level Balancing ChartField, such as a Fund or Department. The generic description of intraunit can be substituted with more specific terms, such as inter operating unit, inter department, or inter fund, depending on which ChartField requires balancing within a business unit. |
For intraunit activity, the available Accounting Entry Types on the IntraUnit Template page are intraunit receivable and intraunit payable. Additional Accounting Entry Types are available only for Transaction Codes mapped to specific System Transactions. These include intraunit expense and intraunit revenue for the Billing Invoice System Transaction, and IntraUnit In Transit for the Cost Management InterUnit Transfer System Transaction.
For interunit activity, the available Accounting Entry Types on the InterUnit Template page depend on whether you choose to use the legal entity option for your installation. The following table is an example of possible organizational and legal relationships between several business units:
|
Business Unit |
Belongs to Legal Entity Unit |
|---|---|
|
USLE1 |
USLE1 |
|
USLE2 |
USLE2 |
|
US001 |
US001 |
|
US002 |
USLE1 |
|
US003 |
USLE1 |
|
US004 |
US001 |
|
US005 |
US001 |
|
US006 |
USLE2 |
In this example USLE1 and USLE2 represent two legal entities to which several of the business units belong. Note that US004 and US005 belong to the US001 legal entity.
If you select the Use Legal Entity for InterUnit option on the Installation Options - Overall page, the following selected combinations illustrate possible Accounting Entry Types applicable to various combinations of inter and intraunit transactions for the business units involved:
|
Transactions Between |
Applicable Accounting Entry Types Using Legal Entity |
|---|---|
|
USLE1 and US003 |
IntraEntity Payable and Receivable |
|
US004 and US005 |
IntraEntity Payable and Receivable |
|
US001 and USLE2 |
InterEntity Payable and Receivable |
|
US006 and US003 |
InterEntity Payable and Receivable |
If you do not select the Use Legal Entity for interunit option, the following selected combinations illustrate the possible Accounting Entry Types applicable to various combinations of inter and intraunit transactions for the business units involved:
|
Transactions Between |
Applicable Accounting Entry Types Not Using Legal Entity |
|---|---|
|
USLE1 and US003 |
InterUnit Payable and Receivable |
|
US004 and US005 |
InterUnit Payable and Receivable |
|
US001 and USLE2 |
InterUnit Payable and Receivable |
|
US006 and US003 |
InterUnit Payable and Receivable |
Interunit ChartFields are determined by the InterUnit Template when you use either the Direct or Indirect interunit method.
Intraunit ChartFields are always determined by the IntraUnit Template.
Note: Interunit methods do not apply to intra unit transactions.
You provide the appropriate InterUnit and IntraUnit Template for a business unit in the General Ledger Definition component.
When the interunit method is Direct, the ChartFields for the balancing entries to one business unit are retrieved using its own SetID and InterUnit Template Code.
When the interunit method is Indirect, the ChartFields for the balancing entries to one business unit are retrieved using its own SetID, but the affiliate business unit's template. The prompting on the Business Unit Definition only ensure that the template is defined for the SetID of the business unit being maintained, so you must ensure that the template is defined for each related business unit.
Note: If you use the pairs interunit method, the ChartField values are not determined by the template but are determined by the values that you enter on the InterUnit Pairs page.
Using InterUnit and IntraUnit Templates you associate Transaction Codes with Accounting Entry Types for which you provide ChartField values to complete the partial inter and intraunit entries.
To accommodate different ChartField values across business units, the InterUnit and IntraUnit Template tables are keyed by SetID. The SetID entered for the template is used as the Set Control Value to determine which SetID is used to validate the ChartFields that you enter for the template.
When processing transactions, the general ledger business unit to which the entry is written is used as the Set Control Value to determine the SetID used to access the appropriate InterUnit or IntraUnit Template.
Business units should only share the same inter and intraunit SetID if they also share the same SetIDs for all their ChartFields and their Detail Ledger definitions.
For example, consider the source of receivable accounting entry ChartField values for a transaction from business unit US001 to business unit LE001, when legal entity is not a factor.
|
Balancing Method |
SetID |
Template |
|---|---|---|
|
Direct |
The InterUnit SetID of LE001, the To Unit. |
The InterUnit Template on the Business Unit Definition for LE001, the To Unit. |
|
Indirect |
The InterUnit SetID of LE001, the To Unit. |
The InterUnit Template on the Business Unit Definition for US001, the From Unit. |
Note: The SetID used to retrieve the InterUnit Template is always the SetID of the business unit to which the accounting entry is written. Only the template source differs in that the Direct method retrieves the template from the business unit to which the entries are written but the Indirect method retrieves the template from the affiliate business unit.
You must define ChartFields and other options used for interunit transactions on the InterUnit Pairs page when you choose to use the Pairs Method. The Direct or Indirect Method does not apply to pairs.
An InterUnit Pairs definition is keyed by the from business unit, the to business unit and Transaction Code. For each of these combinations you specify the interunit receivable and interunit payable ChartFields. Separate InterEntity and IntraEntity definitions are not necessary because any given pair of business units can only be one or the other.
All ChartField validation is based on the SetIDs associated with the business units. The business unit used as the Set Control Value for ChartField prompting and validation depends on the Accounting Entry Type. When maintaining interunit pair data, refer to the following table to determine which entry types belong to which business unit.
|
From Business Unit |
To Business Unit |
|---|---|
|
Receivables |
Payable |
|
Revenue (for Billing Invoices) |
Expense (for Billing Invoices) |
|
In Transit (for interunit transfers if the Source is the Ownership Unit |
In Transit (for interunit transfers if the Destination is the Ownership Unit) |
|
Cost of Goods (for interunit transfers) |
Accrued Payables (for interunit transfers) Customer Shipments (for interunit transfers) |
When you want to reduce the number of journal lines generated by interunit or intraunit processing and find that it is not necessary to maintain separate interunit or intraunit balancing, you can choose to use summarization on the Installation Options, Overall page. In addition, you must either not setup affiliates or deselect affiliates for account, fund or operating unit if you want to summarize interunit or intraunit journal lines.
All non-monetary fields on journal lines must be identical to successfully summarize them. Affiliate must not be used, otherwise journal lines cannot be identical and are not summarized by the system. This requirement enables you to selectively use summarization by specifying affiliates in some Ledger Groups but not in others.
You can use interunit with intraunit summarization together and interunit and intraunit journal lines are not combined. If you specify affiliate for business unit, you can summarize by business unit and not by fund or operating unit. Summarization can be selected at installation or at a later date. If selected at a later date, the result is that there will be additional and perhaps unnecessary journal lines.
Note: If you are using the Sybase database, there is a limitation of a maximum of 31 columns in a group by clause. For this reason system-generated lines even if sharing the same ChartField combination, will not be grouped or summarized together into a single journal line; but separate detail lines will be created.
When sequence numbers are assigned to lines generated by the interunit processor for multi-ledger ledger groups, it is normal for gaps to occur in the numbers. The happens because the sequence number calculated for a line is based on the number of lines that precede it, but it also gives secondary ledger lines the same sequence number as their corresponding primary ledger line. For example, if two interunit balancing lines are created for a multibook ledger group containing three ledgers, they are numbered as follows (assuming the first sequence number is 101):
|
Ledger Group |
Ledger |
Sequence Field |
|---|---|---|
|
LEDGRP1 |
LED1 |
101 |
|
LEDGRP1 |
LED2 |
101 |
|
LEDGRP1 |
LED3 |
101 |
|
LEDGRP1 |
LED1 |
104 |
|
LEDGRP1 |
LED2 |
104 |
|
LEDGRP1 |
LED3 |
104 |
The first three lines have the same sequence number (101) because they all represent the same transaction line. The second three lines start with 104 because there are three lines before them (101 + 3 = 104).
If you use a multi-ledger ledger group in your interunit transactions that does not have the Keep Ledgers in Sync check box checked , each line within a transaction (such as, a payable and receivable line) must specify the same ledger name. The ledgers may be defined under different set control values, but the ledger names must be the same for lines within a transaction.
The inter and intraunit processor is automatically called from the general ledger journal edit process and from each process in other products that generates accounting entries and feed transactions to General Ledger, such as PeopleSoft Accounts Payable Voucher Post and Receivables Update. The implementation of Centralized Inter/IntraUnit processing and ChartField Inheritance impacts the following PeopleSoft products:
General Ledger
Payables
Receivables - Deduction Management
Asset Management
Inventory - Cost Management
Billing
Projects
Expenses
Treasury - Cash Management
Contracts
Grants
Refer to documentation for the individual PeopleSoft products for specific information about setting up and using inter and intraunit processing and ChartField Inheritance for a particular product.