Using Interunit and Intraunit Accounting and ChartField Inheritance

This chapter provides an overview of PeopleSoft interunit and intraunit functionality and discusses how to:

• Set up interunit and intraunit processing.

• Run the centralized interunit and intraunit processor.

• Use mass maintenance for interunit pairs.

• Use ChartField inheritance.

• Verify interunit, intraunit and ChartField inheritance setup.

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 section 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

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.

Affiliate ChartFields

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.

Balancing Methods

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:

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.

See Also

Configuring ChartFields

Using ChartField Inheritance

Defining and Using ChartFields

Anchor Entity

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.

See Reviewing Sample Parameters Provided at Run Time.

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 vendor 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.

Product Interface and System Transaction Categorization

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 we have provided 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. We have done this so that you are able to associate each system transaction with a different user defined Transaction Code, which is the key to how you setup ChartFields for inter 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.

Organizational and Legal Categorization of Transactions

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 unit 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:

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 depends 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:

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:

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:

Interunit and Intraunit Templates

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 on the General Ledger Definition − Definition page.

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.

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.

Interunit Pairs

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.

See Also

Using Mass Maintenance for Interunit Pairs

Summarization of Interunit and Intraunit Journal Lines

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.

MultiBook Considerations

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):

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.

Products Using Interunit and Intraunit Processing

The inter and intraunit processor is automatically called from the general edger 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.

Setting Up Interunit and Intraunit Processing

To set up interunit and intraunit processing, use the following components:

• Installation Options (INSTALLATION)

• Detail Ledger Group (DETAIL_LEDGER_GROU)

• InterUnit Template (IU_INTER_TMPLT)

• IntraUnit Template (IU_INTRA_TMPLT)

• General Ledger Definition (BUS_UNIT_TBL_GL)

• InterUnit Pair Maintenance (IU_INTER_PR_BASIC)

• InterUnit Transaction Code (IU_TRAN_CD)

• Interunit Transaction Mapping (IU_TRAN_MAP)

This section discusses how to:

• Set Overall Interunit installation options.

• Set balancing options for ledger groups.

• Define transaction codes.

• Map transaction codes to system transactions.

• Provide additional options for billing invoices and interunit transfers.

• Define interunit templates.

• Select entries to insert for the interunit template.

• Define intraunit templates.

• Select entries to insert for the intraunit template.

• Review setup examples using the interunit and intraunit templates.

• Define interunit pairs.

• Define interunit pairs options for interunit billing and interunit transfers.

• Select entries to insert for interunit pairs.

• Specify interunit and intraunit settings for general ledger business units.

Pages Used to Set Up Centralized Interunit and Intraunit Processing

Setting Overall Interunit Installation Options

Access the General Options - Overall page.

InterUnit Method	Select one of three due to and due from balancing methods as your system wide setting. Values are Direct, Indirect, or Pairs.
InterUnit Summarization Option	Summarize: The Summarize option only affects processing if you are not using affiliate ChartFields . Selecting this option will cause the system-generated inter/intraunit offset lines to be summarized together whenever all the fields, except for the amount and line sequence fields, are equal. For example, if business unit A pays expenses for business units B and C, without interunit summarization, two interunit balancing lines are created for business unit A (one for B and one for C). However, with interunit summarization, interunit processing creates only one interunit receivable journal line for business unit A instead of two. If there is additional activity among business units A, B, and C, the interunit processor summarizes the activity to create a minimal number of interunit journal lines while maintaining the overall balance among the business units. No Summarization: Select if you do not wish to summarize system-generated inter/intraunit offset lines or if you are using affiliate ChartFields.
Use Legal Entity for InterUnit	Select the check box if you want to use different ChartFields for interunit balancing entries depending on whether the two general ledger business units involved are part of the same or different legal entities. This field must remain clear (not selected) when the InterUnit Method is Pairs.

Setting Balancing Options for Ledger Groups

Access the Detail Ledger Group - Balancing page.

IntraUnit Balancing Entries	Select and the system automatically generates intraunit balancing entries for transactions that involve multiple values of a balanced ChartField. You cannot select this option unless at least one ChartField is balanced, that is, one Balance check box must be selected that is available. If you do not have this check box selected, or if the journal is not in balance for other reasons, then the journal edit process uses the rules that you set up for balancing journals on the Journal Edit Options page to either recycle or use a suspense account.
Balance	A balanced detail ledger requires that debit amounts equal the credit amounts for business unit, base currency code, book code and adjustment type. To choose additional balancing ChartFields for the ledger group select the check box if it is available for another ChartField. Some ChartFields such as account and alternate account cannot be balancing ChartFields and the check box is unavailable. When you change the value of this check box for a standard or translation ledger group, the system verifies that the new setting is valid for the existing ChartField inheritance groups. See Dealing With ChartField Inheritance Groups Requiring Special Validation with Balanced ChartFields. For balancing ChartFields, the system checks for business units that use the ledger group, as defined on the Ledgers for a Unit page in conjunction with the setIDs that business units use for ledger groups. If a business unit that is tied to the ledger group has a blank inheritance value for the balancing ChartField, you receive a warning.
Use Affiliate	This field is available only if the ChartField has an affiliate associated with it on the Standard or Advanced ChartField Configuration page. Affiliate is used when it is not apparent from the ChartField account value which entities are involved in an interunit or intraunit transaction. For example business unit US001 uses the account ChartField value 114000 to designate interunit receivables from all other related business units. If US001 has elected to Use affiliate and it paid rent for US002 of 200.00 USD and for US003 rent in the amount of 300.00 USD, the interunit and intraunit processor creates two interunit receivables for the books of US001. A debit is created of 200.00 USD to the 114000 account labeled with the affiliate value US002 and it also creates a debit of 300.00 USD in the 114000 account with the affiliate value US003. The standard ChartFields shipped with PeopleSoft products include two intraunit affiliate ChartFields. One is associated with the Fund ChartField and the other with Operating Unit ChartField. You may add additional intraunit affiliate ChartFields and associate the standard ones with other related ChartFields using the Standard or Advanced ChartField Configuration page.
Affiliate ChartField	Displays and is derived from the Standard or Advanced ChartField Configuration page.

See Also

Balancing ChartFields

Choosing Affiliate ChartField Values

Using Standard ChartField Configuration

Defining Transaction Codes

Access the Transaction Code page.

Note. PeopleSoft ships transaction codes and system transaction mapping as sample data only and not as system data. You must define transaction codes according to the level of segregation of interunit and intraunit balances that you require.

Mapping Transaction Codes to System Transactions

Access the System Transaction Map page.

There is one row on the page for each system transaction, based on the PeopleSoft products you have installed. If you have created a new system transaction, for third party transactions for example, it appear here as well. If you insert a row—the System Transaction field is input capable—you can only select a system transaction that allows multiple transaction code instances. The only system transaction that allows multiple transaction codes is general ledger journal. You can only delete a row if it is not the default. This also applies only to general ledger journal.

Note. PeopleSoft ships transaction codes and system transaction mapping as sample data only and not as system data. You must define transaction codes according to the level of segregation of interunit and intraunit balances that you require.

Providing Additional Options for Billing Invoices and Interunit Transfers

Access the Transaction Options page.

The Option link to access the Transaction Options page is present on the System Transaction Map page for the Billing Invoice and InterUnit Transfer System Transactions only. You can define different supporting document requirements for the applicable accounting entry types. If the legal entity distinction is enforced at the installation level you see InterEntity, IntraEntity and IntraUnit but if legal entity is not used you see InterUnit and IntraUnit.

These options govern the creation of supporting documents when the InterUnit Method is Direct or Indirect and ChartField values are derived from the InterUnit or IntraUnit Template. For the Pairs method, these options merely provide defaults when a new interunit pair is defined. You can override any of them for a specific pair of business units.

For the transaction code mapped to the billing invoice system transaction you can choose to print an invoice, generate an accounts receivable open item, generate an AP (accounts payable) voucher, or any combination of the three. The accounts receivable option is available only if Receivables is installed. The accounts payable option is available only if Receivables and Payables are both installed. Both the accounts receivable and accounts payable options are not applicable for intraunit transactions.

For the transaction code mapped to the Cost Mgmt (management) InterUnit Transfer System Transaction you have the option to generate an intercompany bill, and define the ownership unit while the goods are in transit. The intercompany option is available only if Billing is installed, and if it is selected, the ownership unit must be the destination unit.

Defining Interunit Templates

Access the InterUnit Template page.

Transaction Code	Multiple transaction codes can be added to the interunit template and additional settings entered when applicable.
Default Balancing Group	This field is displayed only when one or more account attributes are active, such as book code and balance sheet indicator. When any account attributes are active, the data on this page is only for the default balance group displayed.
Additional Balancing Groups	Click to set up interunit ChartFields for additional Balance Groups for this Transaction Code. This link is available when one or more Account Attributes are active, such as Book Code and Balance Sheet Indicator.
Insert All Applicable Entries	Select this link to insert the Entry types that are applicable for your system settings. Two factors affect which entry types are active. They are the Use Legal Entity option on the Installation page (interunit versus Inter Entity and Intra Entity) and the System Transactions to which the Transaction Code is mapped (Revenue and Expense for Billing Invoice, Cost of Goods, Accrued Payable, Customer Shipments, and In Transit for InterUnit Transfer).
Select Entries to Insert	Click this link to manually select which Entry types are inserted into the page.
Entry Types	The applicable Entry Types for a given Transaction Code depends on to which System Transaction or System Transactions this Transaction Code is linked. The Entry types that are available also vary depending on the Legal Entity option selected. If you do not select the Use Legal Entity for InterUnit option on the Overall Installation options page, the following core Entry types are available: InterUnit Receivable InterUnit Payable If the Use Legal Entity for interunit option is selected, the following core Entry types are available: InterEntity Receivable InterEntity Payable IntraEntity Receivable IntraEntity Payable If the Transaction Code is mapped to the Billing Invoice System Transaction, then interunit or corresponding InterEntity and IntraEntity Revenue and Expense Entry types are also available. If the Transaction Code is mapped to the Cost Mgt (Inventory) InterUnit Transfer System Transaction, then interunit or corresponding InterEntity and IntraEntity Cost of Goods, Accrued Payable, Customer Shipments and In Transit Entry types are also available.
Status	Indicates whether the accounting entry type is Active or Inactive based on the current system settings. For example, you added a row for interunit payable while the Use Legal Entity option is turned off. You then activate the Use Legal Entity option. When you return to this page, you see that the status of the interunit payable entry is now inactive, because you should be defining InterEntity and IntraEntity Payable entries instead.

The following applies to the ChartField grid on this page:

• There can be multiple rows in the grid depending on the product, System Transaction, Transaction Codes and Legal Entity option selected; however, only two rows are displayed in the grid at a time, unless you select the View All option on the grid.

• Account, AltAccount, the configurable ChartFields (except for the Affiliates), DeptID and Project ID are available on the grid.

• Affiliate ChartFields are not available because their values are automatically populated by the Central Inter/IntraUnit Processor.

• The setID for the template is used as the Set Control Value to determine which setID is used to prompt and validate each of the ChartFields in the grid.

• The Account ChartField is required. All other ChartFields are optional. If the ChartField is Balancing, its value on the Due To and Due From balancing entries is automatically inherited from the transaction without regard to the selection on this page.

Selecting Entries to Insert for the Interunit Template

Access the InterUnit Template - Select Entries to Insert page.

Current Settings

Displays all settings that affect the availability of entry types to the transaction code. If account attributes are active, such as book code and balance sheet indicator, the account balancing group is also displayed.

Entry Types

See Also

Defining Intraunit Templates

Defining Intraunit Templates

Access the IntraUnit Template page.

Much of the set up information is the same as for the InterUnit Template. The following are exceptions:

See Also

Defining Interunit Templates

Selecting Entries to Insert for the Intraunit Template

Access the IntraUnit Template - Select Entries to Insert page.

The Current Settings group box displays all settings that affect the availability of entry types to the transaction code. If account attributes are active, such as book code and balance sheet indicator, the account balancing group is also displayed.

In the Entry Types group box all the intraunit Entry Types are available for selection, regardless of their status.

See Also

Defining Intraunit Templates

Reviewing Setup Examples Using the Interunit and Intraunit Templates

The following are three scenarios for setting up the interunit and intraunit template.

Scenario A

The organizational and operational assumptions are:

• You use a corporate chart of accounts for business units ranging from US001 to US050.

• You use unique account values, rather than the affiliate ChartField, to segregate interunit balances by business unit trading partner.

• There is no segregation of interunit balances by the type of transaction.

Installation level options are:

• Interunit balancing method is indirect when unique account values are used to segregate balances by business unit, the method must be either indirect or pairs.

• Do not use legal entity.

Other assumed options are:

• Because all business units share the same corporate chart of accounts, all fifty business units can share the same setID.

• Because there is no segregation by type of transaction, only one transaction code is required and it can be mapped to all system transactions.

• A separate interunit template must be defined for each business unit because each requires a unique account value. On each template, the one transaction code is added, and all applicable entry types are defined for it.

Under scenario A, if there is processing between US008 and US009, when the system generates the balancing entry for US008, it gets the appropriate ChartFields using the setID for US008 and the InterUnit Template for US009 because the interunit balancing method is indirect.

Scenario B

The organizational and operational assumptions are:

• You use a corporate chart of accounts for business units ranging from US001 to US999.

• You want to segregate interunit balances into ten different accounts according to the type of transaction (AP (accounts payable) Voucher, GL (general ledger) Journal, for example).

• You use the affiliate ChartField, rather than unique accounts to segregate balances by business unit trading partner.

Installation level options are:

• Interunit balancing method is direct.

• Do not use legal entity.

Other assumed options are:

• Because all business units share the same corporate chart of accounts, all business units can share the same setID.

• Ten transaction codes are created and are mapped to the appropriate system transactions to segregate transactions in the ten desired categories.

• One interunit template can be used for all business units. On the one template, each of the ten transaction codes is added, and all applicable entry types are defined for each transaction code.

Under scenario B, if there is processing between US008 and US009, when the system generates the balancing entry for US008, it gets the appropriate ChartFields using the setID and the interunit template for US008 because the interunit balancing method is direct.

Scenario C

The organizational and operational assumptions are:

• You use a corporate chart of accounts for business units ranging from US001 to US989 but US990 through US999 share a different chart of accounts.

• You want to segregate interunit balances into ten different accounts according to the type of transaction (AP (accounts payable) Voucher, GL (general ledger) Journal, for example).

• You use the affiliate ChartField, rather than unique accounts, to segregate balances by business unit trading partner.

Installation level options are:

• Interunit balancing method is direct.

• Do not use legal entity.

Other assumed options are:

• Two interunit setIDs are required, one for each chart of accounts.

• Ten transaction codes are created and are mapped to the appropriate system transactions to segregate transactions in the ten desired categories.

• The same interunit template name can be used for all business units, but two interunit template definitions must be maintained, one for each setID. On each of the template definitions, each of the ten transaction codes is added, and all applicable entry types are defined for each transaction code.

Under scenario C, if there is processing between US008 and US009, when the system generates the balancing entry for US008, it gets the appropriate ChartFields using the setID and the interunit template for US008 because the interunit balancing method is direct.

Under scenario C, for example, if there is processing between US989 and US999 when the system is generating the balancing entry for US989, it gets the appropriate ChartFields using the setID and the interunit template for US989 because the interunit balancing method is direct.

Defining Interunit Pairs

Access the InterUnit Pair page.

Interunit pairs are applicable if you choose to use the pairs balancing method. It requires a detailed level of setup because ChartField pairs must be established between all business units that may potentially have related transactions.

Note. If you have a large number of business units you may want to use the InterUnit Pair Mass Maintenance feature rather than this page to maintain your business unit pairs. See the section on Using Mass Maintenance for Interunit Pairs for more information.

See Using Mass Maintenance for Interunit Pairs.

This page displays the Default Balance Group field and the Additional Balance Groups link if one or more account attributes are active.

Defining Interunit Pairs Options for Interunit Billing and Interunit Transfers

Access the InterUnit Pair page.

Click to expand the Inter Unit Billing Options group box and see the following section for explanations of the field values that become available.

Interunit Billing Options

If the transaction code is linked to the billing invoice system transaction, there are additional entry types of interunit revenue and interunit expense. You may also override the default supporting document options, such as:

• Print Invoice

• Generate AR (accounts receivable) Open Item

• Generate AP (accounts payable) Voucher

• AP Unit (accounts payable business unit)

• Vendor (ID)

• Vendor Location

Interunit Transfer Options

If the transaction code is linked to the Cost Management InterUnit Transfer System Transaction, there are additional entry types of InterUnit In Transit, Cost of Sales, and Accrued Payable. You must also establish InterUnit Billing Options, such as:

• Ownership Unit

• InterCompany Processing flag

• BI Unit

• Customer

The default values for these options come from the system transaction map and the GL (general ledger) business unit definition.

The options to Print an Invoice, Generate an AP Voucher and Generate an AR Item default from the options defined for the transaction code, which is mapped to the billing invoice system transaction.

The AP Unit (accounts payable unit ) for the AP Voucher (accounts payable voucher) defaults from the GL Business Unit (general ledger business unit) definition for the To GL Unit field value of the pair. The vendor and location for the AP Voucher default from the GL Business Unit definition for the From GL Unit field value of the pair.

You can override any of these options here for this specific Pair. Changes made later to the System Transaction Map options or the GL Business Unit options do not affect existing interunit pair definitions.

Selecting Entries to Insert for Interunit Pairs

Access the InterUnit Pair - Select Entries to Insert page

Current Settings

Displays all settings that affect the availability of entry types to the transaction code. If account attributes are active, such as book code and balance sheet indicator, the account balancing group is also displayed.

Entry Types

All interunit, interentity and intraentity entry types are available for selection, regardless of their status.

See Also

Using Mass Maintenance for Interunit Pairs

Specifying Interunit and Intraunit Settings for General Ledger Business Units

Access the General Ledger Definition - Inter/IntraUnit page.

InterUnit Template	If the interunit method specified on the installation Overall page is Direct or Indirect, specify an interunit template. Prompting and validation of your selection uses the GL Business Unit as the set control Value. If the interunit method is indirect, the template entered is used by the other GL Business Units involved in the transaction, using their own setID. If this is the case, all business units with which this business unit might have transactions must either share the same interunit setID, or the template must also exist in their interunit setIDs.
IntraUnit Template	The field is required if there is at least one ledger group linked to this business unit that has intraunit balancing entries selected on the Detail Ledger Group − Balancing page. Prompting and validation of your selection uses the GL Business Unit as the set control Value.
Legal Entity Unit	If you select the Use Legal Entity for interunit option on the Installation Overall page, you must establish the legal entity hierarchy among your GL Business Units. Specify the legal entity unit to which the business unit belongs. interunit transactions between business units within the same legal entity unit are treated as IntraEntity. Transactions between business units in different legal entity units are treated as InterEntity. The valid values for the legal entity unit include the business unit being maintained, plus any other business unit that has itself as a legal entity unit
Inheritance Defaults	Used to establish default values for each ChartField to be used in product specific inheritance processing when the inheritance option is Use Unit Default or Inherit Within Unit. It is advisable (but not required) to provide an inheritance default for a ChartField under the following circumstances: The business unit being maintained is linked on the Ledgers for a Unit page with a ledger group for which the ChartField is balanced. A ChartField inheritance group in the setID used by the business unit for ChartField inheritance has Use Unit Default or Inherit Within Unit as the inheritance option for the ChartField.

Interunit Billing Options

The following fields are used when supporting documents are created for an interunit bill, that is, when Generate an AP Voucher is selected on the System Transaction Map Options page. The fields provide default values for interunit pairs, but if these fields are changed they do not affect any existing InterUnit Pair definitions.

If both Billing and Payables are installed the following fields are displayed:

Interunit Transfer Options

The following fields are used when supporting documents are created for an interunit transfer, that is, when Intercompany Processing is selected on the System Transaction Map Options page. The options provide default values for interunit pairs, but if these fields are changed they do not affect any existing interunit pair definitions.

If both Cost Management and Billing are installed, the following fields are displayed:

For example:

• An InterUnit Billing transaction is record in which a billing business unit associated with general ledger business unit JPN01 is billing an interunit customer associated with general ledger business unit US001.

• The System Transaction Map for Billing Invoice has Generate an AP (accounts payable) Voucher selected on the InterUnit Billing Options, so a voucher must be created.

• The voucher is created in US001, so the US001 general ledger business unit definition provides the AP (accounts payable) Business Unit for the voucher.

• The Vendor and Location for the voucher come from the JPN01 general ledger business unit definition.

The supporting document options are independent of the interunit method. Whether you use the Direct or Indirect method, the options are derived from same sources, which are the Transaction Code and the GL Business Unit definitions.

Running the Centralized Interunit and Intraunit Processor

This section provides an overview discusses how to:

• View delivered system transactions.

• Access the system transaction page 1.

• Access the system transaction page 2.

• Review sample parameters provided at run time.

Understanding the Running of the Centralized Processor

In conjunction with centralized setup, PeopleSoft also provides centralized processing for inter and intraunit transactions. The centralized processor’s primary function is the creation of due to and due from balancing entries for transactions that are not yet balanced from either or both an interunit and intraunit perspective.

Typically, a process in an individual PeopleSoft product generates an initial set of accounting entries that are functionally complete, but not yet balanced by business unit or any other balancing ChartField, (this includes all system-generated entries as well as those created by the ChartField Offset Inheritance process). You can also create cross entity online journal entries directly in General ledger.

Running of the Centralized Inter/IntraUnit Process (IU_PROCESSOR) varies from product to product. For example, in General Ledger the inter and intraunit processor is called as a part of the Journal Edit (GL_ JEDIT) process, but in Payables, voucher post (AP_PSTVCHR) and payment post (AP_PSTPYMENT) call the central processor to create inter and intraunit balancing accounting entries.

The central processor evaluates the entries by reading directly from product— specific tables defined by the System Transaction and its interface definition. Additional information, such as the Transaction Code and Anchor ChartField values, are passed to the central processor by these product specific tables.

The central processor determines which ChartFields are to be balanced, whether the transaction is in balance, and if it is not balanced, generates any necessary due to and due from balancing lines. The processor writes balancing lines directly to the accounting entry table for the product or to an interface table as specified by the product interface definition. For feeder applications, the balanced accounting lines are passed back to the application for later journal generation and edit before finally being posted to the General Ledger.

Refer to the documentation on individual products for application specific information about running the centralized inter and intraunit processor.

Pages Used to Process a Centralized Interunit and Intraunit Interface

Viewing Delivered System Transactions

Use the System Transaction component (IU_SYS_TRAN), System Transaction Map component (IU_TRAN_MAP), and Transaction Code component (IU_TRAN_CD) to view pages.

Each PeopleSoft application delivers System Transactions for major types of activities that can be expected to generate inter and intraunit entries. The variety of System Transactions that are provided enables you to segregate your inter and intraunit payable and receivable accounts by type of transaction, for example AP (accounts payable) Voucher, AP (accounts payable) Payment, GL (general ledger) Journal and Expense Sheet.

System Transactions provide information to your system that is necessary to support the interface between various application processes and the common PeopleSoft Centralized Inter/Intra Unit Processor.

Note. System Transactions are delivered and are not to be changed. Any changes to the delivered System Transactions are customizations. You need not access or make changes to the System Transaction pages. They are to be used as delivered. The following is provided for information only or for the use of your MIS personnel or consultants in the event that you intend to implement a customization.

Accessing the System Transaction Page 1

Access the System Transaction page 1.

Note. Do not make changes to any of the system transactions pages unless you intend to implement a customization.

Accessing the System Transaction Page 2

Access the System Transaction Page 2.

Sequence Field

Name of the field on the line record that must be incremented for the new balancing entries created by the processor, if applicable.

Sequence

Leave this field blank if the Sequence Field is blank, or if you want the processor to continue numbering based on the last sequence number used on the original input entries for each document group. Specify a value if you want the inter and intraunit balancing entries to always begin sequencing with a fixed value. Sequence numbers assigned by the processor are typically consecutive. However, for multibook ledger group lines, it is normal to have gaps in the sequence numbers.

InterUnit Balancing Line ID	The name of the field on the line record that identifies the type of entry, if applicable.
InterUnit Payable Value	The value to be populated in the InterUnit Balancing Line ID field for the intraunit (or InterEntity and IntraEntity) payable balancing entries generated by the processor.
InterUnit Receivable Value	The value to be populated in the InterUnit Balancing Line ID field for the intraunit (or InterEntity and IntraEntity) Receivable balancing entries generated by the processor.
IntraUnit Payable Value	The value to be populated in the InterUnit Balancing Line ID field for the intraunit payable balancing entries generated by the processor.
IntraUnit Receivable Value	The value to be populated in the InterUnit Balancing Line ID field for the intraunit (or InterEntity and IntraEntity) receivable balancing entries generated by the processor.
Document Locking Field	Name of the field that is used to logically lock the transaction while it is being processed.
Commit After Lock	Selected to commit the data after updating the Documenting Locking Field.
Where Clause	Static part of the selection criteria. The Where Clause can refer to fields on both the line record and the optional header record. All references to fields from the line record use the record alias LN_A and all fields from the header record use the record alias HDR.
Document Grouping Fields	The list of fields that together define a unique document, such as a general ledger Journal or an accounts payable voucher. If the optional Header Record is used, then the Document Grouping Fields must come from the Header Record. Otherwise, the fields come from the Line Record.
Transaction Grouping Fields	List of fields that identify unique transaction groups within a document. Transaction grouping fields are optional unless you want to use a transaction level status. You do not repeat the Document Grouping fields in this section.

Header/Line Join Fields	If the System Transaction utilizes the optional header record, list the fields that are used to link the header record with its corresponding line record.
Header Status Fields	The field or fields on the header record that carry a status value for the document. You can specify different status values for Valid, Error (for example, setup related errors) or Unbalanced (non-setup related out of balance errors). The Valid value is optional, and the processor performs more efficiently if this value is set in the calling application.
Document Status Fields	The field or fields on the line record that carry a status value for the document. You can specify different status values for Valid, Error (for example, setup related errors) or Unbalanced (non-setup related out of balance errors). All of the accounting entry lines for the document, both the original entries and any balancing entries generated by the processor, are updated with the same status value. The Valid value is optional, and the processor performs more efficiently if this value is set in the calling application.
Transaction Status Fields	The field or fields on the line record that carry a status value for the transaction group within a document. You can specify different status values for Valid, Error (such as setup related errors) or Unbalanced (non-setup related out of balance errors). All of the accounting entry lines for the transaction group, both the original entries and any balancing entries generated by the processor, is updated with the same status value. The Valid value is optional, and the processor performs more efficiently if this value is set in the calling application.
Other Balancing Fields	Additional balancing fields can be specified; however the processor performs more efficiently if these values are set in the calling application.

Other Fields to Populate

List other fields on the line record that are not defined elsewhere on this page, and specify how they are to be formatted on the new inter and intraunit balancing entries created by the processor.

Field Name

The name of the field to be populated. Fields that are not be listed here include any field that is specified elsewhere on the System Transaction, including: GL (general ledger) Business Unit Foreign Currency and Amount Base Currency and Amount Description Accounting Date Rate Type Rate Multiplier and Divisor Sequence Field InterUnit Balancing Line ID Document Locking Field Document Grouping Fields Transaction Grouping Fields Status Fields (both Document and Transaction) ChartFields (those on standard subrecord, plus DeptID and Project ID) Note. Project ID is included in the PCADJ system transaction which is a valid exception. Process Instance Ledger Group Ledger IU Anchor Flag IU System Transaction IU Transaction Code

Note. Currency Effective Date can be specified in the Other Fields to Populate definition as long as it is not the same field as the Accounting Date.

Reviewing Sample Parameters Provided at Run Time

The following section describes the sample parameters that you may select before running the process.

Technical Requirements for calling the Centralized Inter and Intra Unit processor

If you are implementing a customization in which you want to utilize the Centralized Inter/IntraUnit Processor, consider the following requirements.

Calling the Centralized Interunit Processor

The Centralized Inter/IntraUnit processor (IU_PROCESSOR) is an application engine program. In most cases it is called from within another application engine program, such as AP Voucher Post or GL Journal Edit. In some cases it is called directly from PeopleCode using the CallAppEngine built-in function.

When calling the processor, you must first populate the fields on the state record (IU_PROCESS_AET), as described in the following section. If you are calling the processor from another application engine program you must specify the Inter/IntraUnit Processor State Record in the list of state records for your program.

The inter and intraunit processor uses a temporary table (IU_TRAN_TAO) for some of its internal processing. If you call the processor from another application engine program you specify this record in the list of temporary tables for the calling application engine program. In this way, the dedicated instance is allocated at the beginning of the process. Please refer to the PeopleTools Application Engine PeopleBook for additional information about allocating temporary tables.

When control is passed back to your application from the processor, check the value in the processor status field (IU_STATUS) on the state record to determine if the processor encountered any errors during processing.

The InterUnit Processor State Record (IU_PROCESS_AET)

The Inter/IntraUnit Processor State record is used to pass parameters between the calling program and the inter and intraunit processor. In Contains the Following Fields, list in the order that they appear on the record.

Process Instance (PROCESS_INSTANCE)

Process Instance is required on every application engine state record. This field is populated automatically by PeopleSoft tools.

Business Unit (BUSINESS_UNIT)

Insert a general ledger business unit value in this field if you want the inter and intraunit processor to generate balancing entries for just one business unit.

Header (Input) Record (HEADER_RECORD)

The Header Record is used to send related data for unprocessed accounting entries to the inter and intraunit processor for balancing. It may be a SQL Table, SQL View, or a Temporary Table.

Header Update Record (UPDATE_HEADER_REC)

The Header Update Record is used to update the Header Status fields. It may be a SQL Table or a Temporary Table, and in most cases is the same as the Header (Input) Record, unless the Header (Input) Record is a SQL View.

Line (Input) Record (LINE_RECORD)

The Line Record is used to send unprocessed accounting entries to the inter and intraunit processor for balancing. It may be a SQL Table, SQL View, or Temporary Table. It must contain the following fields:

• GL (general ledger) Business Unit.

• Foreign Currency.

• Foreign Amount.

• Accounting Date (may be on line or optional header).

• Rate Type (may be on line or optional header).

• Currency Effective Date (may be on line or optional header; may be the same as the accounting date).

• ChartFields (those on standard subrecord, plus DeptID and Project ID).

• Ledger Group (LEDGER_GROUP).

• Ledger (LEDGER).

• IU Anchor Flag (IU_ANCHOR_FLG).

• IU System Transaction (IU_SYS_TRAN_CD).

• IU Transaction Code (IU_TRAN_CD).

Note. Where a field name is not specified, any field name may be used because it is defined on the system transaction definition.

Line Update Record (UPDATE_LINE_REC)

The Line Update Record is used to update the Document and Transaction Status fields on the original accounting entries. It may be a SQL Table or a Temporary Table, and in most cases is the same as the Line (Input) Record, unless the Line (Input) Record is a SQL View.

Line Insert Record (INSERT_LINE_REC)

The Line Insert Record is the record to which the processor inserts the inter and intraunit balancing entries that it creates. It may be a SQL Table or a Temporary Table, and in most cases is the same as either the Line (Input) Record or the Line Update Record.

You may wish to use a different Line Insert Record if it is necessary for the calling application to perform additional manipulation of the inter and intraunit balancing entries prior to inserting them in the accounting entry table. For example, if the calling application has non-standard rules regarding sequence numbering, it might be better to perform this function after the processor creates the balancing entries, rather than having the processor assign sequence number.

Line Work Record (LINE_WRK_REC)

The Line Work Record is used internally within the Inter/IntraUnit Processor. It may be a SQL Table or a Temporary Table. It should contain all of the same fields as the Line Record, plus the following additional fields (if they are not already on the Line Record):

• Process Instance (PROCESS_INSTANCE).

• InterUnit Line Type (IU_LINE_TYPE).

• If the Account Balance Group option on the System Transaction is selected, then the work record must also contain the Account Balance Group (ACT_BAL_GRP) field.

Note. If there are fields on the Line Insert Record that should always be populated with the PeopleTools default value (the default specified on the record definition, or blank for character fields and zero for numeric fields), then these fields do not have to be included on the Line Work Record. If you do choose to leave the fields off the Line Work Record, then you should not specify them in the Other Fields to Populate section of the System Transaction definition.

Line Work Record #2 (LINE_WRK2_REC)

The Line Work Record #2 is used internally within the Inte/IntraUnit Processor. It may be a SQL Table or a Temporary Table. It should contain all of the same fields as the Line Work Record, plus the following additional fields (if they are not already on the Line Record):

Maximum Sequence Number (MAX_SEQ_NBR)

Error Message Set and Number (MESSAGE_SET_NBR and MESSAGE_NBR)

If the Status returned by the processor is Complete with Errors (IU_STATUS = 1), these fields contain the message set and message number for the appropriate error message.

Inter/IntraUnit Processor Status (IU_STATUS)

The IU Processor Status has the following valid values:

0 - Complete without errors.

1 - Complete with errors.

2 - Incomplete.

We recommend that you set the Status equal to 2 - Incomplete when you populate the state record prior to calling the Inter/IntraUnit Processor. When the processor returns control to the calling program, the status is set to either 0 - Complete without Errors or 1 - Complete with Errors.

Dynamic Where Clause, part 1 (SQL_STMT_254)

The Dynamic Where Clause is used to specify selection criteria that changes each time the processor is called. Selection criteria that is constant or static is typically defined on the System Transaction definition, but can also be included here if desired.

The where clause can refer to fields on both the line record and the optional header record. All references to fields from the line record use the record alias LN_A and all fields from the header record use the record alias HDR.

If the where clause exceeds 254 characters, you can use the field IU_WHERE_SQL below instead of or in addition to this field.

System Transaction Code (IU_SYS_TRAN_CD)

If all of the transactions on your Line (Input) Record are for the same InterUnit System Transaction Code, or if you want to process entries for a System Transaction only, then you specify the System Transaction Code in this field in the state record. This makes the processor run more efficiently.

If your Line (Input) Record contains transactions for more than one System Transaction and you want to process them with one call to the processor, you can leave this field blank.

Dynamic Where Clause, part 2 (IU_WHERE_SQL)

Continuation of the Dynamic Where Clause, as described above. If your where clause exceeds 254 characters, you can use this long character field instead of or in addition to the SQL_STMT_254 field described above.

Specifying Anchor Values for the Inter/IntraUnit Processor

The Inter/IntraUnit Processor looks for the accounting entry line whose InterUnit Anchor (IU_ANCHOR_FLG) is set equal to Y to determine the anchor business unit and anchor values for other balancing ChartFields for each transaction group (or document group if transaction group by fields are not used).

It is important that each transaction group (or document group if transaction group-by fields are not used) has one and only one accounting entry identified as the anchor entry per ledger.

The line marked as the anchor line (IU_ANCHOR_FLG = Y) affect how the due to and due from lines are formatted. For example, assume that you call the interunit and intraunit processor to process the following lines:

Based on the processing of the preceding information, the processor creates the following lines:

However, if you change the original assumption so that the second line and not the first line has the value Y and is the anchor, the due to and from lines created by the processor then appear as follows:

The following example illustrates how the IU_ANCHOR_FLG determines the transaction (foreign) currency and amount of the due to and from lines for a cross currency transaction. The processor rule is that the due to and from lines have the transaction currency and amount of the non-anchor line. For example, assume the processor is run for the following transaction lines:

The following lines are generated by the processor given the previous assumptions:

MultiBook entries and the Inter/IntraUnit Processor

If the calling application supports PeopleSoft MultiBook processing, then the application typically generate accounting entries for both the primary and secondary ledgers prior to calling the processor. In this case, one entry for the primary ledger and all of its corresponding secondary ledger entries are all flagged as anchor entries for each transaction group (or document group if transaction group-by fields are not used).

The following is an example from General Ledger of the type of parameters provided at run-time when calling the Central Inter/IntraUnit Processor:

The JRNL_IU_ANCHOR table with the following fields maintains inter and intraunit anchor values:

The table is also used to identify inter and intraunit journals because non-interunit journals have no entries in this table.

The following fields in the JRNL_HEADER table support calling of the interunit processor:

The following fields on the JRNL_LN table must be populated properly before calling the Iinter and intraunit processor:

Using Mass Maintenance for Interunit Pairs

This section provides an overview and discusses how to:

• Export interunit pairs for mass maintenance.

• Make changes using Excel worksheets.

• Set up your system for import the Excel worksheets.

• Preview your changes and update the database.

Understanding Mass Maintenance for Interunit Pairs

When the sheer number of GL business unit pairs makes it impractical to update interunit pairs online, PeopleSoft provides mass maintenance capabilities using Microsoft Excel worksheets.

Using the Export to Excel feature you can export from one or both of the following InterUnit Pairs tables to Excel worksheets in the .xls file format to do your maintenance:

• IU_INTER_PR_TR contains interunit pairs with billing and transfer options.

• IU_INTER_PR_CF contains associated chartfield values.

  After making your changes, save the worksheets in the CSV (comma delimited) file format. You can then preview the actions to be taken before updating your database tables using the Preview feature.

  When you are ready to update your database, the changes are incorporated directly to the interunit pairs tables using the Application Engine process, IU_PAIRS_MAINT.

  Warning! If a business unit pair has been exported for mass maintenance but not yet imported, no updates should be made to the pair using the online Interunit Pair page . Online updates made after the export are subsequently overwritten when data is imported with the same key values.

Prerequisites

Microsoft Excel 97 or a later version must be installed to use interunit pairs mass maintenance. Excel displays an error message when a worksheet exceeds 64k rows.

Because the Export page is subject to business unit row level security, you must have the appropriate level of security to access interunit pairs for mass maintenance.

Pages Used to Perform Interunit Pairs Mass Maintenance

Exporting Interunit Pairs for Mass Maintenance

Access the InterUnit Pairs Mass Maintenance – Export page.

Using the Business Unit Pairs Selection criteria you can create one or more files that contain the interunit pairs, associated transaction codes, billing options, and transfer options.

For each of the files created by your Business Unit Pairs Selection criteria, you can use the ChartField Selection criteria to optionally create an additional file to maintain the associated ChartField values.

If your exported worksheet is empty this indicates no data met your selection criteria.

Note. Although data values may appear in fields that do not apply to particular transaction codes, these fields should be ignored for those transaction codes. For example, the Print Invoice field should be ignored for the GENERAL transaction code since it is not mapped to the Billing Invoice System Transaction.

Making Changes Using Excel Worksheets

Using the Pairs Maintenance Reports link on the Export page to access the report repository to locate and open the Excel (.xls) worksheet in which you want to make changes. You can manipulate the data using Excel worksheet functionality; however, to delete a row you must enter a Y in the Delete column, located to the far right of the worksheet after the interunit pairs data columns. Do not delete rows loaded from the interunit pairs source tables using the Excel row delete functionality.

Worksheets containing billing and transfer options (from the IU_INTER_PR_TR table) cannot be combined with worksheets containing ChartField values (from the IU_INTER_PR_CF table) . If you select to create a Chartfield value worksheet, each row must have a corresponding row in a billing and transfer options worksheet with the same values for:

• From GL Unit

• To GL Unit

• Transaction Code

The following fields in the billing and transfer options worksheet apply to a Transaction Code only if it is mapped to the Billing Invoice System Transaction:

• Print Invoice

• Generate AR Open Item

• Generate AP Voucher

• AP Unit

• Vendor

• Location

The following fields in the billing and transfer options worksheet apply to a Transaction Code only if it is mapped to the Cost Management InterUnit Transfer System Transaction:

• Ownership Unit

• InterCompany Processing

• BI Unit

• Customer

If values are specified in the fields above for Transaction Codes to which they do not apply, the import process will overwrite these values with either the field default (if one is defined) or blanks.

You can open, work on and save the worksheets in the file repository or copy the file to your local drive to do your changes in the .xls file format.

When you have completed your changes, save the worksheet either in the file repository or on your local drive as a CSV (comma delimited) Excel file.

Your can then either preview or immediately update your database using the Import page.

If further changes need to be made as a result of your preview, open the worksheet in the .xls format, make your changes and save the file in the CSV (comma delimited) format. You can again preview your changes and actions to be taken before updating your database.

Note: Do not modify column headings or insert/delete columns in the worksheet. The Import process requires that this column information remain unchanged.

Setting Up Your System For Importing the Excel Worksheets

Use the File Locations component (FILE_LOC) to setup file locations in conjunction with URL maintenance.

Access the URL Maintenance page.

The interunit pairs text file import process (IU_PR_IMPORT) depends on the following setup.

The storage location of the file attachment is defined by the URL definition IU_PAIRS_IMPORT. By default, it points to a database record. You may want to change the storage location of the file attachment to another location, such as an FTP server. This is optional.

You are required to define an environmental variable, PS_FILEDIR. This variable defines the temporary flat file location on the process scheduler that runs the file import process. If you have a Unix or OS390 process scheduler, you define this in the psconfig.sh file. If you have an NT process scheduler, you define this in the control panel. Refer to the PeopleTools description for GetFile() PeopleCode for additional details, or consult your system administrator.

See Also

Enterprise PeopleTools PeopleBook: PeopleCode Developer's Guide, Understanding File Attachments and PeopleCode

Previewing Your Changes and Updating the Database

Access the InterUnit Paris Mass Maintenance – Import page.

Preview	Select to preview the actions to be taken by the system as the result of your changes before actually updating the interunit pairs tables in your database. Preview loads your worksheets, which you attach in CSV format, to a worktable when you click the Import button. The system inserts an Action column to the right of the Delete column and assigns one of the following Action values to each row based on your changes: Insert – The row does not exist in the original interunit source table and will be inserted. Update – The row exists in the original interunit source table and the values in your worksheet will replace existing values in the source table. Duplicate – One or more rows in your worksheet have the same key values. Duplicate rows are errors and must be resolved before importing to the database. DUMMY TEXT for completeness check. The Action column is for information purposes only. The import process ignores this column. Rows to be deleted are identified by a 'Y' in the Delete column and are not identified in the Action column. When you are ready to update your database, clear the Preview check box prior to selecting the Import button.
Attached Files	Attach worksheets in the CSV (comma delimited) file format. Enter a value or click Add Attachment to find your files. You can add multiple files to be processed in a single Import. Note: If you have already imported a CSV file in a previous run and are re-importing it, you must delete the previous CSV file row from the Import page and insert a new row for the updated file.
Import Text Files	When the Preview check box is not selected and you have attached files in the CSV (comma delimited) format, select this button to update the interunit pairs tables with your changes using the PeopleSoft Application Engine process, IU_PR_IMPORT.
Pairs Maintenance Reports	Click to access the system generated Excel worksheets in the report repository. The process instance is incorporated in the worksheet file name for ready recognition of specific worksheets.
Process Monitor	Access the Process Monitor to see the progress or status of the import process.

The import process (IU_PR_IMPORT) will produce an Excel worksheet as output for each worksheet imported. This worksheet will list up to 5 error messages for each row of data imported. These errors must be corrected before the data can be successfully imported. If no errors are listed for a row and the Preview check box was not checked for the import run, that row successfully updated the database.

The error message 'InterUnit Pairs transaction does not exist' occurs when importing a ChartField value worksheet row for a GL BU pair/Transaction Code that does not exist in the billing and transfer options (header) table nor in a billing and transfer options worksheet being imported.

Using ChartField Inheritance

To use and setup ChartField inheritance, use the ChartField Inheritance component (CF_INHERIT ) and the Detail Ledger Group component (DETAIL_LEDGER_GROU).

This section provides an overview of ChartField Inheritance and discusses how to:

• Specify inheritance options.

• Deal with ChartField inheritance groups requiring special validation with balanced ChartFields.

Understanding ChartField Inheritance

ChartField inheritance, in and of itself, does not generate additional entries to complete a transaction. Instead it drives how the ChartFields are determined for the system-generated entries that are normally created for the transaction. In many cases this is an offset, such as AP (accounts payable) Vouchers, where the user enters the distribution lines and the system generates the vendor liability. Inheritance also applies to other system generated entries that are not offsets, like the VAT entries generated for a GL (general ledger) journal.

Note. Even if you do not want to inherit any ChartField values, you must access the ChartField inheritance page to setup Inheritance Groups for each setID, setting all Inheritance Options to Do Not Inherit.

ChartField Inheritance uses the ChartField Offset Balancing Method to complete transactions by inheriting ChartField values from partial entries, accounting lines or voucher lines to generate complete accounting entries. It is used extensively in education and governmental accounting, and to a lesser extent in commercial accounting.

It enables you to select automatically the source for certain ChartField values to complete partial entries for a given number of system generated accounting entries that are predefined by Inheritance Groups.

Inheritance functionality does not necessarily relate to centralized inter and intraunit processing. This is because it may or may not involve inter or intraunit transactions, and inheritance processing is performed by the individual general ledger feeder systems, such as Receivables and Payables to arrive at offset accounts before any inter and intraunit processing is required.

For example, when posting accounts payable vouchers, you can choose to have the Fund Code on the Vendor Liability entry derived from the Voucher Distribution Line, the GL Business Unit Definition ChartField Defaults, or the Accounting Entry Template.

When you balance on ChartFields other than business unit, and inherit ChartField values onto the system generated offset entries, the transaction often self-balances, making additional intraunit balancing entries unnecessary. For this reason, applications use inheritance functionality before calling the inter and intraunit processor.

The following terms and concepts are important to an understanding of ChartField Inheritance and the examples provided:

Pages Used to Set Up ChartField Inheritance

Specifying Inheritance Options

Access the ChartField Inheritance page.

Inheritance Group	Along with setID, this it is a key field for the table. PeopleSoft delivers the following predefined Inheritance Groups for its various products: Expense Control Accounts Expenses Payroll Offset Expenses VAT Non-Recoverable GL Journal VAT Input Other GL Journal VAT Non-Recoverable GL Journal VAT Output Payables Header-Level Entries Payables Distrib-Level Entries (payables distribution - level entries) Payables VAT Non-Recoverable Promotions Mgmt (management) Accounts Purchasing Control Accounts Purchasing Expense Accounts Purchasing VAT Non-Recoverable Receivables Revaluation Receivables and Billing Treasury VAT Input Other Treasury VAT Non-Recoverable Treasury VAT Output
ChartField	The page is pre-populated with the fully and partially configurable ChartFields other than Account, Alternate Account and the Affiliates. Account and Alternate Account are not available for inheritance and Affiliate values are automatically supplied by the system.
Inheritance Option	The following ChartField Inheritance options apply to all Inheritance Groups: Do Not Inherit– When this option is selected, you can specify a value for the ChartField on the product specific Accounting Entry Template or you can leave the value blank. This option would usually not be selected for a balanced ChartField, unless you select the Intra Unit Balancing Entries check box on the Detail Ledger Group - Balancing page. Use Unit Default– When this option is selected, the ChartField value is the default value that you enter in the Inheritance Defaults for the business unit on the General Ledger Definition − Inter/IntraUnit page. With this option, you do not enter a value for this ChartField on a product specific Accounting Entry Template. Inherit within Unit– If this option is selected, the ChartField value is inherited from one of the other entries on the transaction, but only if the other entry is in the same business unit. Otherwise, the business unit Default is used. You may want to select this option if the ChartField values are not shared across all business nits. With this option you do not enter a value for this ChartField on the product specific Accounting Entry Template page. Always Inherit– If you select this option, the ChartField value is always inherited from one of the other entries that make up the transaction, regardless of whether it is in the same business unit. This option should only be selected if all business units share the same ChartField values; otherwise, the inherited value might be invalid. With this option, you do not enter a value for the ChartField on the product specific Accounting Entry Template or setup page. Some Inheritance Groups have edits that restrict which inheritance options are valid for each ChartField, often based on whether or not the ChartField is balanced. Refer to the next section for details.

Refer to the documentation for ChartField Inheritance for each product for variations in functionality or information specific to that product.

Dealing With ChartField Inheritance Groups Requiring Special Validation with Balanced ChartFields

For some Inheritance Groups, the Inheritance Options are restricted based on whether or not ChartFields are balanced ChartFields. For this reason, the Inheritance Options table shares the same Record Group control as the Ledger Group definition. There may be multiple Ledger Groups defined for a given setID. If any one of these Ledger Groups, having a Ledger Group Type of Standard or Translation, defines a ChartField as balanced, the ChartField is considered balanced for Inheritance Option validation.

This cross-validation occurs when you save the ChartField Inheritance page or the Detail Ledger Group page. If you change a ChartField from balancing to non-balancing or vice versa for a Ledger Group, the system checks whether the change has invalidated any existing ChartField inheritance groups. When you select Inheritance Options for an Inheritance Group, the system checks for balancing ChartFields that make the selected Option invalid.

The specific validation requirements for the individual product Inheritance Groups depends not only on whether balanced or non-balanced ChartFields are involved but in the case of accounts payable on whether the posting method is Summary Control or Detail Offset.

If you receive an error message when saving either the ChartField Inheritance page or the Detail Ledger Group - Inter/IntraUnit page, refer to the following table for correct settings:

Verifying Interunit, Intraunit and ChartField Inheritance Setup

The following section provides an overview and discusses how to select interunit and intraunit setup validation queries and run the audit program.

Understanding Verification of Interunit, Intraunit and ChartField Inheritance Setup

Verifying inter and intraunit setup is very important when first installing your system for inter and intraunit processing and it is also important when any of the following events occur:

• You add new business units.

• You change or restructure your chart of accounts.

• You migrate a subsidiary to your corporate chart of accounts.

• You add or remove Inter/IntraUnit Transaction Codes.

With these and any like events, you typically perform verification to indicate if and where inter and intraunit setup data might be missing. It is advisable to run inter and intraunit setup verification on a periodic basis to catch inadvertent errors as well as after any major maintenance activity.

Using the PeopleSoft Application Engine process (IU_AUDIT), you can identify missing setup data and run queries that download this data to Microsoft Excel worksheets to be printed, sorted or filtered as you choose.

The Application Engine program first validates inter and intraunit setup data and identifies missing setup data. It populates the following audit tables with the results:

The application engine program then runs the queries selected by the user to extract the audit data and writes it to Microsoft Excel worksheets. A separate Excel worksheet is generated by each query and is posted to the Report Repository.

The Run Control page for the application engine program indicates the names of the queries that are available to run.

Setup validation queries lend themselves to use on an adhoc basis. For example, you enter a voucher involving business units US001 and FRAE1 and the post process fails due to missing interunit setup. In this instance you can run the application engine program, select the queries desired to see the data that is set up for each business unit and, if there is any missing data, go to the setup pages and make corrections.

Note. If you are using the InterUnit Pairs Method, you can use the related Inter/IntraUnit Mass Maintenance feature to facilitate correction of audit errors.

Prerequisites

Microsoft Excel 97 or a later version must be installed to verify Inter/IntraUnit and ChartField Inheritance setup. Excel displays an error message when a worksheet exceeds 64,000 rows. If you receive this error message, it is necessary to correct some of the errors listed and rerun the application engine process (IU_AUDIT.)

Page Used to Verify Interunit, Intraunit and ChartField Inheritance Setup

Selecting Interunit and Intraunit Setup Validation Queries and Running the Audit Program

Access the Setup Validation page.

Note. To preclude the same errors being reported multiple times in subsequent audits, we recommend that you begin by running the audits one at a time, in the following order and correct any errors prior to running the next audit:

1. Business Unit Audit—Identify business units that require an InterUnit or IntraUnit Template but do not have them defined. It also lists business unit pairs that are not defined when the interunit balancing method is pairs.

2. Inter/IntraUnit Template Audit—Identify missing InterUnit and IntraUnit Templates, Transaction Codes, Account Balance Groups and Entry Types.

3. ChartField Value Summary Audit—Identify missing setID/ChartField values. Each setID/ChartField value is listed only once.

4. ChartField Value Detail Audit—Identify missing SetID/ChartField values for a combination of Transaction Code, Account Balance Group and Entry Type for the GL BU (general ledger business unit) pair or Inter/IntraUnit Template indicated.

5. ChartField Inheritance Audit—Identify missing ChartField Inheritance Groups and, if also missing, their corresponding SQL Definitions based on installed products.

6. Bank ChartField Inheritance Audit—Identify missing external bank account ChartField inheritance SQL Definitions.

The following provides an understanding the query results.

Query columns that do not apply based on the InterUnit Method selected are blank. For example, the From GL Unit and To GL Unit columns are blank if the InterUnit Method is not Pairs.

InterUnit Pairs Audit Table A

Use this table with the ChartField value audits information in the preceding section.

ChartField Inheritance Audit Table B

Use this table with the ChartField inheritance audit information in the preceding section.