Understanding Interunit and Intraunit Accounting and ChartField Inheritance

This chapter discusses:

• Interunit and intraunit accounting.

• ChartField inheritance.

• Anchor lines for transactions.

Interunit and Intraunit Accounting

This section provides an overview of interunit and intraunit accounting and discusses:

• Interunit and intraunit setup

• Interunit accounting entries

• Intraunit accounting entries

Interunit and Intraunit Overview

PeopleSoft Receivables creates interunit accounting entries for these transactions:

• Payments made on the payment, draft, and direct debit worksheet or using the Payment Predictor Application Engine process (ARPREDCT), where the payment, draft, or direct debit is processed using a bank account that reflects a general ledger business unit that differs from the item’s general ledger business unit.

• Transactions entered on the maintenance worksheet or created by the Automatic Maintenance Application Engine process (AR_AUTOMNT) to offset items from other general ledger business units.

• Items transferred from one business unit to another, where the general ledger business units are different.

• Direct journal transactions where the deposit is processed using a bank account that reflects a general ledger business unit that differs from the general ledger business unit where revenue is recorded.

The system populates the ChartFields for interunit accounting entries based on the rules that you specify.

Note. If you enable the Use Affiliate option for the Business Unit ChartField for a ledger group, the system populates the Affiliate ChartField with the other business unit involved in the transaction. Otherwise, it leaves the Affiliate ChartField blank.

PeopleSoft Receivables creates intraunit accounting entries for the following transactions, if you enable ChartField balancing for a ledger group on the Ledger Groups - Balancing page, and balancing ChartField values in the transactions differ in any of the distribution lines:

• Transactions on the payment, draft, or direct debit worksheet or transactions created by the Payment Predictor process.

  The system usually creates intraunit accounting entries if the user selects a nonpooled or cash clearing account.

• Transactions on the maintenance worksheet or transactions created by the Automatic Maintenance process, such as refunds and offsetting items with different balanced ChartFields.

• Transactions on the transfer worksheet.

When you generate accounting entries, the Pending Group Generator Application Engine process (AR_PGG_SERV) calls the central processor (IU_PROCESSOR) to create the interunit and intraunit accounting entries.

See Also

Using Interunit and Intraunit Accounting and ChartField Inheritance

Interunit and Intraunit Setup

Setup for interunit and intraunit accounting entries is linked to the business unit definition for general ledger. PeopleSoft Receivables uses the setup for the general ledger business unit associated with each receivables business unit.

Note. If you plan on using discounts and multibook, then you need to have the same ledger group setup for both business units.

PeopleSoft Receivables provides three unique system transaction definitions that define specific rules for receivables transactions:

• Receivables Item (ARIT): Used for all other receivables transactions.

• Receivables Transfer (ARTR): Used for transfers.

• Receivables Direct Journal (ARDJ): Used for direct journal payments.

You should not modify these definitions unless you modify your application. These system transaction definitions are mapped to the system-defined transaction code for general transactions on the System Transaction Map page.

Important! You should also specify the general ledger business unit for customers that you marked as interunit customers on the General Information - Bill To Options page. The system uses the general ledger business unit for the To customer when you transfer items to a new customer to generate the interunit accounting entries.

You must also define distribution codes for maintenance control and assign the default distribution code to each business unit.

Note. Summarization is an installation option for interunit and intraunit distribution lines that do not use Affiliate ChartFields. Using summarization, you can reduce the number of interunit and intraunit distribution lines when segregation of amounts is not required.

Interunit Accounting Entries

This section provides examples of interunit accounting entries for payment, maintenance, and transfer groups. The following accounting entries are shown without summarization.

Interunit Accounting Entries for Payment Groups

The following interunit example could apply to payments, prepayments, on-account transactions, overpayments, underpayments, and deductions. You apply a 980.00 USD payment to a 1,000.00 USD item and create a write-off for the underpayment for 20.00 USD.

This table displays accounting entries for the payment application:

This table displays accounting entries for the underpayment adjustment:

This table displays accounting entries for the write-off. The write-off entries do not require interunit accounting entries:

Interunit Accounting Entries for Maintenance Groups

When you create a maintenance group, you specify the anchor business unit for interunit transactions.

The following is an example of the accounting entries for offsetting items. You offset a 1,000.00 USD debit memo with two credit memos: one for 400.00 USD and one for 600.00 USD. The anchor business unit for the maintenance group is US001:

Interunit Accounting Entries for Transfer Groups

The following example shows the accounting lines that would be generated if you transferred an item from the US001 business unit and customer USA01 to the US003 business unit and customer USA01:

Note. Because the interunit entries balance the transaction no offset entries are necessary.

Intraunit Accounting Entries

This section provides examples of intraunit accounting entries for payment, maintenance, and transfer groups. The following accounting entries are shown without summarization.

Intraunit Accounting Entries for Payment Groups

The following intraunit examples could apply to payments, prepayments, on-account transactions, overpayments, and underpayments.

In the first example, you apply a 1,960.00 USD payment associated with a nonpooled bank account to a 1,960.00 USD item. This table displays the accounting entries:

In the second example, you apply a 1,500.00 USD payment associated with a cash control bank account to a 1,500.00 USD item. This table displays the accounting entries that the system generates when you save the deposit with the payment:

This table displays the accounting entries that the system generates when you apply the payment to the item:

The system generates the intraunit accounting entries for cash control banks by comparing the fund on the Cash line (created when you save the deposit) to the fund on the AR line (created when you apply the payment to the item).

Intraunit Accounting Entries for Maintenance Groups

The first example displays intraunit accounting entries for a refund of a 4,500.00 USD credit memo:

The second example displays the accounting entries for a match of a debit memo to a credit memo with different funds. The debit memo is 1,000.00 USD and the credit memo is –1,000.00 USD:

Note. When you match (offset) multiple funds using the maintenance worksheet or the Automatic Maintenance process, the system creates only one Due To and Due From entry for each fund. There is not a set of entries for each AR line.

Intraunit Accounting Entries for Transfer Groups

The following example shows the accounting lines that would be generated if you transferred an item from the FED01 business unit and customer 1000 to the FED01 business unit and customer 1002:

ChartField Inheritance

PeopleSoft Receivables inherits the ChartField values for receivables transactions. The Pending Group Generator Application Engine process determines the inheritance option for each ChartField and populates each ChartField value based on the inheritance option selected for the ChartField.

This section discusses:

• Inheritance setup

• Inheritance accounting entries

See Also

Using Interunit and Intraunit Accounting and ChartField Inheritance

Inheritance Setup

You must define inheritance rules for the following inheritance groups on the ChartField Inheritance page:

• Billing (AR/BI): Used for all transactions except revaluation.

• Receivables Revaluation (AR Reval): Used for revaluation.

PeopleSoft Receivables uses these rules for all transactions that inherit ChartField values.

Note. ChartField inheritance rules do not apply to PeopleSoft Project Costing ChartFields except the Project ID ChartField.

Options for each ChartField are:

Bank accounts can be associated with a single fund (nonpooled) or group of funds (pooled). A nonpooled bank account must be associated with a fund code, and the inheritance option must be Do not Inherit. When you set up pooled bank accounts, you must define the inheritance rules for the account. The rules that you can select for the Deposit - AR, Control - AR, Draft - AR, and Discount - AR account types are limited based on your selection for the Cash - AR account type.

Note. To set up rules for direct debits, select the DD/AR Draft Cash Control check box, and enter inheritance options for Control - AR account type.

See Also

Bank Account ChartField Inheritance for Education and Government

Inheritance Accounting Entries

When you enter accounting entries online for pending items, you cannot change values for ChartFields that are set to Always Inherit or Inherit within Unit. Also, if you enter additional AR and user-defined (revenue) lines, the system automatically populates the values for ChartFields that are set to Always Inherit or Inherit within Unit. For transactions on payment, draft, maintenance, or transfer worksheets, you can add additional accounting entries only for items that do not reference existing items, such as on-account items and prepayments.

If the values for ChartFields are set to Always Inherit or Inherit within Unit, and you have items with multiple AR accounting lines, the system generates multiple offset lines for all payments, write-offs, maintenance worksheet matching, and so on.

For direct journal payments, the system uses the User-defined line to inherit ChartField values to the Cash line, if the inheritance option for the ChartField associated with the Cash - AR account type is set to Always Inherit or Inherit within Unit for the bank account. If you enter additional User-defined lines, the system automatically populates the ChartField values on the new line. After you create the accounting entries, you cannot change the ChartField values.

For cash control deposit entries, ChartField values are inherited from the cash control line to the cash line, if the inheritance option for the ChartField associated with the Cash - AR account type is set to Always Inherit or Inherit within BU for the bank account.

The following is an example of accounting entries where the inheritance option for the Fund ChartField is set to Always Inherit. The transaction is a payment in full of a 300.00 USD item:

The Fund code on the Cash line is inherited from the Fund code on the AR line, but the Dept ID is different, because it is not set to inherit.

Anchor Lines

The system uses an anchor line for each transaction to generate interunit and intraunit accounting entries and apply inheritance rules. The anchor line for inheritance determines which line is used to obtain ChartField values for ChartFields whose inheritance option is Always Inherit or Inherit within Unit. You select ChartField inheritance options on the Design ChartFields - ChartField Inheritance page. The anchor line varies based on the transaction type.

This table displays the anchor line that the system uses for different transaction types: