Data Access Sets:
Data access sets control, which ledgers can be accessed by different responsibilities. Data access sets can also limit a user from accessing certain balancing segment values or management segment values or grant read–only or read and write access to data in a ledger. 
 
It provides security in 3 levels.
 
1. Full Ledger – Provides access to whole Chart of Accounts. This is required to perform certain operations such as opening and closing periods, creating summary accounts, creating budgets, and performing mass maintenance. Full ledger access provides full read and write access to the ledger and all of its balancing segment values and management segment values.
2. Balancing Segment Value – Provides access to specific balancing segment values
3. Management segment value – Provides access to specific management segment values
 
 – Data Access Sets is mandatory in R12. But defining Data Access Sets is optional. That means if users do not define Data Access Sets, system creates it  with full access automatically when a ledger or ledger set is created.
 
 – Users need to define Data Access Sets, it they want security at balancing segment or management segment value level
 
 – We can assign multiple ledgers or ledger sets to a Data access set, which share the Chart of Accounts and Calender/period type combination.
 
 – To prevent potential errors in processing, we need to make sure at least one responsibility has a data access set assigned with full ledger access.
 
Data Access Sets & Security Rules:

Data Access Sets work with Segment Value Security Rules and Cross–Validation Rules. If we have defined Segment Value Security Rules that prevent certain responsibilities from accessing certain segment values, those rules are combined with data access set security.
For example, if user defined Segment Value Security rules to exclude Balancing Segment Value 01 and then defined data access set security that provides read-only access to values 01–03, the user assigned to this responsibility would not be able to read segment value 01 due to the Segment Value Security rule.
General Ledger Accounting Cycle:
1. Open Period
2. Create/Reverse journal entries
3. Post Journals
4. Review
5. Revaluate/Translate
6. Consolidate
7. Review/correct balances
8. Run reports
9. Close the periods

Integration of General Ledger with other modules:

Oracle General Ledger integrates with other modules. Following is the list of modules along with the details that flow to the General Ledger.
1. Payables sends Invoices, payments, adjustments, realized gain/loss on foreign currency and invoice price variance to GL.

2. Receivables sends invoices, payments, adjustments, debit memos, credit memos, cash, charge backs and realized gain and loss on foreign currency to GL.

3. Assets sends capital and construction in process asset additions, cost adjustments, transfers, retirements, depreciation and reclassifications.

4. Purchasing sends accruals or receipts not invoiced, purchase orders, final closes and cancellations.

5. HRMS sends employee details.

6. Payroll sends salary, deductions and tax information.

7. Inventory sends cycle counts, physical inventory adjustments, receiving transactions, delivery transactions, delivery transactions, intercompany transfers, sales order issue, internal requisitions, sub-inventory transfers and Cost of Goods Sold.

Inter company Transactions are the transactions between two legal entities related to same Organization. Following are the setups need to be defined for Inter company Transactions.

Selling Operating Unit: Vision Japan
Shipping Operating Unit: Vision Operations

Step1: Define Transaction Type
Responsibility: Receivables Manager, Vision Operations
Navigation: Setup → Transactions → Transaction Type
Define New transaction type as shown below.
 
Step2: Assign Document Sequence to new Transaction Type (Defined in Step1) 
Responsibility: General Ledger Manager, Vision Operations
Navigation: Setup : Financials → Sequences → Document → Assign
Assign a document sequence to the transaction type ‘Intercompany’ as shown below.
 
Step3: Define Intercompany Transaction Flow and Intercompany Relations

Responsibility: Inventory Manager, Vision operations

Navigation: Setup → Organizations → Intercompany Transaction Flows
Define Intercompany Transaction flow and Intercompany Relations as shown below.

Mandatory Setups to Check:
1. Make Sure there are no security rules defined when shipping the item from other Operating unit and Auto Accounting rules are defined(for Selling OU) to default the balancing segment values with Table Name as Standard Lines(Which will get the values from Standard line item or Inventory Item used)

Path for Security Rules:
Responsibility: General Ledger Responsibility
Navigation: Setup → Financials → Flexfields → Validation → Security → Define
Path for Auto Accounting:
Responsibility: Receivables Responsibility
Navigation:  Setup Transactions Auto Accounting

2. Make Sure Shipping parameters are defined for both Shipping and Selling operating units.
 

Responsibility: Order Management Responsibility
Navigation: Shipping → Setup → Shipping Parameters
3. Make Sure that the COGS account is assigned to the Transaction Type used for SO in Selling Organization.
Responsibility: Order Management Responsibility
Navigation: Setup-> Transaction Type 

4. Make sure that a value is assigned for System parameter ‘Inventory Item For Freight’

Responsibility: Order Management Responsibility
Navigation: Setup → System Parameters → Values
Intercompany Transaction Process:
1. Create and Book Sales Order:
Responsibility: Vision Japan Order Management Responsibility
Navigation: Orders, Returns → Sales Orders
Create a Sales Order with Vision Operations Shipping Warehouse and book the order as shown below.
 

2. Release the Order and Ship the Item
Responsibility: Vision Operations Order Management Responsibility
Navigation: Shipping → Release Sales Orders → Release Sales Orders
Release and ship the order. Then notice the transaction status as ‘Shipped’ or ‘Interfaced’ on Shipping Transactions form as shown below.
Navigation: Shipping → Transactions
 
3. Run Workflow Background process
Responsibility: Vision Japan Inventory Responsibility
Navigation: Workflow Background Engine
Run Workflow Background Process.
4. Run Auto Invoice Master Program to create Customer Invoice
Responsibility: Vision Japan Receivables Responsibility
Navigation: View → Requests → Auto Invoice Master Program
The invoice created is shown below.
Navigation: Transactions → Transactions
5. Create Intercompany AR Invoice
Responsibility: Vision Operations Inventory Responsibility
Navigation: Reports → Intercompany Invoicing
Run the Program ‘Create Intercompany AR Invoices’ to create Intercompany AR invoice.
6. Import Intercompany AR invoice
Responsibility: Vision Operations Receivables Responsibility
Run Auto Invoice Master Program with parameter Source as ‘Intercompany’. The Intercompany invoice created is shown below.
Navigation: Transactions → Transactions
7. Create Intercompany AP Invoice

Responsibility: Vision Japan Inventory Responsibility

Navigation: Reports → Intercompany Invoicing
Run the Program ‘Create Intercompany AP Invoices’ to create Intercompany AP invoice.
8. Import Intercompany AP invoice
Responsibility: Vision Japan Payables Responsibility
Run Payables Open Interface Program with parameter Source as ‘Intercompany’. The Intercompany AP invoice created is shown below.
Navigation: Invoices → Inquiry → Invoices

Possible Errors while making Intercompany Transactions:
1. Please correct the revenue account assignment 
2. INCIAP – Create Intercompany AP Invoices Terminated By Signal 11 Error
3. Can not retrieve payment term from bill-to site information
4. Returned warning from extra function
Solution: Check Mandatory Setups Section.
1. Requisition Creation:

• In R12 iProcurement, users can see a new button for Managing Approval Routing lists in create requisition page under Approvals stage. The functionality remains the same as in 11i, but users can add/delete approvers and can make changes in the routing sequence in iProcurement itself.

• New country field is required when entering a “one-time” ship to address on create requisitions page.        
          
• Oracle has introduced a new feature for Internal Requisitions and Internal Sales Orders. If preparer makes changes for approved Internal Requisition it will be reflected in Internal Sales Order and vice versa.

Oracle supports this feature only for few particular fields.

For Internal Requisition Oracle supports changes to the following attributes:
1. Quantity
2. Need By Date

If preparer updates any of these values, the changes will be reflected in Internal Sales Order.

Similarly, for Internal Sales Order Oracle supports changes to the following attributes:
1. Order Quantity
2. Request Date
3. Schedule Date
4. Arrival Date

If user updates any of  these values in Internal Sales Order, the requester of Internal Requisition will get notification and quantity and Need by Date in Internal Requisition changes automatically.

• In addition to this, if user cancels the Internal Requisition line, the corresponding line in Internal Sales Order will also be cancelled and vice versa.

• And finally, the urgent flag on the internal requisition line will flow onto the internal sales order line as the shipment priority, based on a profile option.


Set ups required:

To get the new functionality, processing constraints need to be disabled for internal sales orders in Order Management.
1. For ‘Update Ordered Quantity’ – Disable the Condition where Validate Template is “Internal Order”.
2. For ‘Update Requested date’   – Disable the Processing Constraint.

2. iProcurement non-Catalog Request:

• In 11i, for a Non-Catalog Request, when requester describe the purchase, there is a chance that it may not be classified into an existing commodity hierarchy. This increases the misclassification of spend information, contract leakage, lower compliance and internal controls.

• In R12, requester creating Non-Catalog requests will have the option of category being predicted for the purchase being made. After the requester clicks on “Add to Cart” they will be able to view a “suggested best fit” category with a list of categories that could be alternate possibilities.

• With this new feature,  all the unstructured requests will be categorized appropriately to aid the downstream spend analysis.
                                      
• So with the new features organizations can analyze the spending according to the Purchasing Category, which helps to easily identify the categories of items that they purchase.

Set ups required:

This feature takes the category value from Oracle Spend Classification(A new module of the Oracle BI Applications). Oracle Spend Classification is a pre requisite to get use of the new feature. Once we set up Oracle Spend Classification, when user clicks on “Add to Cart” they can see the category list for non-catalog items.

This option is not mandatory.

3. Realms:

In R12 realms are replaced by Content Security Management.

Realms from prior releases are converted to content zones.  The new Content Security model allows administrators a more flexible method to control and adjust iProcurement Content (items) available for requisitioning users. It replaces and enhances functionalities previously provided by Realms, System Profiles, Catalogs, and the Extractor.

4. Communication Process:

Oracle R12 supports FYI notifications. So, FYI notifications can be enabled for the viewers to avoid reports and alerts.

FYI notifications set up has to be done in AME. The Set up process is as follows:

1) The first step is to turn on the FYI Approver capability for the “Purchase Requisition Approval” transaction type. The navigation for this is :

1. Choose “Approvals Management Administrator” responsibility
2. In the upper right Quick Links region choose “Configuration Variables”
3. Enter the Purchase Requisition Approval transaction type and click Go
4. At the “Transaction Type” level set variable “Allow For Your Information Notifications” = Yes
5. Click Apply

2) Now go to the “Approvals Management Business Analyst” responsibility . From here choose the “Purchase Requisition Approval” transaction type and we can modify existing Rules or when we create new Rules,there will be a Category field that is now available, where we can choose “For Your Information”.

For any Rule with this choice, the approvers that are returned are FYI and their approval response is not required. They are only notified with FYI notification.

This feature is available only at the Rule level. So to have FYI notifications and regular response required Approval Notifications send to other approvers, multiple AME Rules have to be created.

In R12, banks are moved into Trading Community Architecture(TCA). Now Cash Management owns the internal bank setup definition.

Benefits of new Bank Account model:
  • There is a central place to define internal bank accounts. So with centralized user interface, users can reduce the number of access points to manage bank accounts
  • With the help of Multi-Org Access Control, we can explicitly grant account access to multiple operating units/functions and users, which improves the visibility and control of bank accounts
  • A single Legal Entity is granted ownership of each internal bank account and One or more Organizations are granted usage rights. So, a single bank statement can be reconciled across multiple Operating Units, which helps to simplify reconciliation process.
  • Reconciliation options can now be defined at the bank account level, which provides more flexibility and control to the reconciliation process.
Bank structure in 11i:

Bank structure in R12:
In R12, Banks are part of TCA and the same bank accounts can be used in Payables, Receivables, Payroll and Treasury.

Impact of Upgrade:
All the internal bank accounts of 11.5.10, will be migrated into Centralized Bank model automatically during the upgrade.

Tables to store the bank information in R12:

The new tables that store bank information are now under Cash Management as follows:

CE_BANK_ACCOUNTS    
                 Contains Legal Entity Level bank account information. Each bank
                                                              account must be affiliated with one bank branch.

CE_BANK_ACCT_USES_ALL           Stores Operating Unit level bank account use information.

CE_PAYMENT_DOCUMENTS  
         Stores payment Documents to be used for Printed type Payments

CE_BANK_BRANCHES_V      
           View: Bank/Branches Info

CE_BANK_ACCT_USES_OU_V 
       View: Internal Bank Account Uses Info

The following tables were obsoleted in R12, in which Bank Data was stored in R11i:

AP_BANK_BRANCHES
AP_BANK_ACCOUNTS_ALL
AP_BANK_ACCOUNTS_USES_ALL


In R12, Internal bank accounts can be created in Cash Management (Setup -> Banks). Where can we define Supplier (or External) bank accounts?

Supplier (or External) bank accounts can be created in Payables, by using Supplier Entry forms.  In the Payables Manager responsibility:

1. Navigate to Suppliers -> Entry.
2. Query or create your supplier.
3. Click on Banking Details and then choose Create.

After creating the bank account, we can assign the bank account to the supplier site.