This chapter covers the following topics:
In Release 12, the major improvements to the Financials Common Modules include the new Advanced Global Intercompany System and the changes to the Receivables and Payables netting functionality.
Oracle Advanced Global Intercompany System (AGIS) is a new module within the Oracle E-Business Suite that allows companies to streamline intercompany processing and facilitates the reconciliation of intercompany transactions. It replaces the Global Intercompany System (GIS) feature provided by General Ledger in Release 11i.
All setup and transaction data are moved to a new data model. All Oracle Forms in the Global Information System are replaced by browser-based, user-interface pages in the Advanced Global Intercompany System.
Following sections describe the way in which existing data in GIS system in Release 11i is migrated to Release 12.
All GIS Subsidiaries are upgraded into intercompany organizations. If the Subsidiary is deactivated, during the upgrade, an active party in Trading Community Architecture (TCA) with a classification that is end dated is created. The reason for this is that the end date of the classification can be changed from the Intercompany User Interface (UI) but a party must be reactivated from the TCA UI. A relationship between TCA Intercompany Party and the legal entity to which it belongs is created.
The user must consider if the automatic upgrade of subsidiaries to intercompany organizations makes sense in their situation. It depends on what the subsidiaries represent in their GIS system. For instance, if subsidiaries represent legal entities, then the user should not create new parties. Rather, they should query relevant legal entities and classify them as intercompany organizations. However, if the subsidiaries represent concepts that do not exist in the user’s setup, then they should be re-created as new parties. It is likely that in many cases, users will be using some existing parties to process intercompany transactions and will need to classify these as intercompany organizations, rather than create new ones.
Upgrade from GIS converts subsidiaries into intercompany organizations, one for one. Security grants are created for the users based on the subsidiaries assigned to the responsibilities that each user was assigned. A user may be given access to many different intercompany organizations regardless of the responsibility used to log in.
The GIS transaction types are upgraded to the new intercompany system transaction types. When GIS transaction types are upgraded, the Allow Invoicing option is set to Not Required. In order to take advantage of the new invoicing feature in AGIS, you should manually select the Allow Invoicing check box for transaction types where invoicing is required.
In Release 11i, the Intercompany accounts balancing rules are created against a Balancing Segment Values (BSV), for account that has to be debited and the Due From/Due to would be processed as per the rule. These Intercompany accounts are upgraded as Intracompany Balancing Rules in the Release 12, AGIS system. In Release 12, the account listed is the debit account for the debit BSV and credit Account for the credit BSV.
For examples, the Release 11i setup shown below:
| Company | Due From | Due To |
| 01 | 01-4100 | 01-2100 |
| 02 | 02-4200 | 02-2200 |
| All Other | 01-4000 | 01-2000 |
Will be upgraded to:
| Rule # (for reference only) | DR BSV | CR BSV | Debit Account | Credit Account |
| 1 | 01 | All Other | 01-4000 | 01-2100 |
| 2 | All Other | 01 | 01-4100 | 01-2000 |
| 3 | 02 | All Other | 02-4000 | 02-2000 |
| 4 | All Other | 02 | 02-4200 | 02-2200 |
| 5 | 01 | 02 | 02-4200 | 02-2000 |
| 6 | 02 | 01 | 02-4100 | 01-2200 |
| 7 | All Other | All Other | 01-4000 | 01-2000 |
Or the Release 11i setup shown below:
| Company | Due From | Due To |
| 01 | 01-4100 | 01-2100 |
| 02 | 02-4200 | 02-2200 |
| 03 | 03-5100 | 03-9999 |
| All Other | 01-4000 | 01-2000 |
Will be upgraded to:
Cross-Entity Balancing
| DR BSV | CR BSV | Debit Account | Credit Account |
| 01 | 02 | 01-4100 | 02-2200 |
| 01 | 03 | 01-4100 | 03-9999 |
| 01 | All Other | 01-4100 | 01-2000 |
| 02 | 01 | 02-4200 | 01-2100 |
| 02 | 03 | 02-4200 | 03-9999 |
| 02 | All Other | 02-4200 | 01-2000 |
| 03 | 01 | 03-5100 | 01-2100 |
| 03 | 02 | 03-5100 | 02-2200 |
| 03 | All Other | 03-5100 | 01-2000 |
| All Other | All Other | 01-4000 | 01-2000 |
Auto Accounting rules defined in Release 11i GIS are not upgraded to Release 12. These rules need to be defined in Subledger Accounting (SLA) Transaction Account Builder feature.
In Release 11i, GIS transaction consists of transaction header and transaction lines. In Release 12, AGIS transactions are grouped into batches. Outbound batch can contain one or more transactions, and the transactions can be for different receivers. All GIS new and completed transactions are upgraded along with the Global Descriptive Flexfield details. For each GIS transaction, an AGIS transaction batch is created.
Release 11i GIS profile options are obsolete in Release 12 and are not upgraded. All options are available in the AGIS System Options page.
In Release 11i, Oracle Financials has three netting solutions:
Single Third-Party in Oracle Public Sector Financials International.
Contra Charging in Oracle Financials for Europe.
Receivables and Payables Netting in Oracle U.S. Federal Financials.
Oracle's Financial Common Module introduces a new Payables and Receivables Netting solution intended to consolidate and improve the functionality to create one total-netting solution built into the standard applications.
Only setup from Contra Charging in Oracle Financials for Europe, and Receivables and Payables Netting in Oracle U.S. Federal Financials are upgraded. The following sections describe the way in which setup related to the netting features in Release 11i are migrated to Release 12.
The existing Customer and Supplier relationships are preserved and new entities known as Netting Agreements are created during the upgrade. Default values (or naming schemes) are used to populate any incomplete information. Users can change these defaults after the upgrade as and when required. For example, the priority level of the netting parties is set to 1. The netting agreement name is generated from the customer identifier and name. During the upgrade, the suppliers and customers having the same name and VAT registration identifiers become candidates for trading partners in a netting agreement.
When netting agreements are created by the upgrade process, all receivables transaction types of invoice, credit memo, debit memo, and charge back are included in the netting agreements so that transactions of each of these types can be considered for netting. Similarly, Payables invoice types of credit, debit, standard, and mixed are included in the netting agreement so that invoices of each of these types can be considered for netting.