Transaction Dates for Auto Invoices in Receivables:

If there is no value provided for Transaction Date, the Autoinvoice program populates the Transaction date for Auto Invoices based several facors such as Derive Date option enabled or Disabled for Transaction Source, few colums from RA_INTERFACE_LINES_ALL, Invoice rules and Accounting Rules defind or not, and the default value provided in the parameters of Autoinvoice program.

Let us see how Autoinvoice program derives Transaction date based on Derive Date option for Transaction source and populted columns from RA_INTERFACE_LINES_ALL such as GL_DATE, SHIP_DATE_ACTUAL and SALES_ORDER_DATE.

Case 1: If the Derive Date option is enabled for Transaction Source, Autoinvoice program uses the following order to create Transaction Date.
1. GL_DATE
2. SHIP_DATE_ACTUAL
3. SALES_ORDER_DATE
4. DEFAULT_DATE (Provided in parameters of Autoinvoice program, which is mandatory)

Case2: If the Derive Date check box is disabled for Transaction Source, Autoinvoice program uses following order to populated Transaction Date.
1. GL_DATE
2. DEFAULT_DATE (Provided in parameters of Autoinvoice program, which is mandatory)

Invoice Grouping Rules in Receivables R12

Grouping Rules group Revenue and Credit transactions into  Invoices, Credit memos and Debit Memos. Autoinvoice program uses the Grouping Rules to group similar sales orders into a single invoice. We need to assign matching attributes while defining the Grouping Rules. These attributes include mandatory and optional parameters. Mandatory parameters are pre-defined by Oracle, where as optional attributes are optional and can be assigned based on the business requirements. Following is the list of all Mandatory and Optional attributes which can be assigned to the Grouping Rules.

Mandatory Attributes:
AGREEMENT_ID
COMMENTS
CONS_BILLING_NUMBER
CONVERSION_DATE
CONVERSION_RATE
CONVERSION_TYPE
CREDIT_METHOD_FOR_ACCT_RULE
CREDIT_METHOD_FOR_INSTALLMENTS
CURRENCY_CODE
CUSTOMER_BANK_ACCOUNT_ID
CUST_TRX_TYPE_ID
DOCUMENT_NUMBER
DOCUMENT_NUMBER_SEQUENCE_ID
GL_DATE
HEADER_ATTRIBUTE1-15
HEADER_ATTRIBUTE_CATEGORY
HEADER_GDF_ATTRIBUTE1-30
INITIAL_CUSTOMER_TRX_ID
INTERNAL_NOTES
INVOICING_RULE_ID
ORIG_SYSTEM_BILL_ADDRESS_ID
ORIG_SYSTEM_BILL_CONTACT_ID
ORIG_SYSTEM_BILL_CUSTOMER_ID
ORIG_SYSTEM_SOLD_CUSTOMER_ID
ORIG_SYSTEM_BATCH_NAME
PAYMENT_SERVER_ORDER_ID
PAYMENT_SET_ID
PREVIOUS_CUSTOMER_TRX_ID
PRIMARY_SALESREP_ID
PRINTING_OPTION
PURCHASE_ORDER
PURCHASE_ORDER_DATE
PURCHASE_ORDER_REVISION
REASON_CODE
RECEIPT_METHOD_ID
RELATED_CUSTOMER_TRX_ID
SET_OF_BOOKS_ID
TERM_ID
TERRITORY_ID
TRX_DATE
TRX_NUMBER

Optional Attributes:
ACCOUNTING_RULE_DURATION
ACCOUNTING_RULE_ID
ATTRIBUTE1-15
ATTRIBUTE_CATEGORY
INTERFACE_LINE_ATTRIBUTE1-15
INTERFACE_LINE_CONTEXT
INVENTORY_ITEM_ID
REFERENCE_LINE_ID
RULE_START_DATE
SALES_ORDER
SALES_ORDER_DATE
SALES_ORDER_LINE
SALES_ORDER_REVISION
SALES_ORDER_SOURCE
TAX_CODE
TAX_RATE

The following Ship-To fields were mandatory grouping attributes in release 11i, but are optional in release 12 ORIG_SYSTEM_SHIP_CUSTOMER_ID
ORIG_SYSTEM_SHIP_ADDRESS_ID
ORIG_SYSTEM_SHIP_CONTACT_IDThis is because ship to information is now stored at the line level in R12. Therefore a single invoice could have different ship to information for each line.
Autoinvoice program matches all the mandatory parameters and group the transactions into invoices. If all the mandatory parameters are matched for two or more similar transactions, they will fall in a same invoice. If we define any optional attribute, Autoinvoice program matches optional attributes in addition to the mandatory attributes to group the transactions.

For Example: SALES_ORDER is the optional attribute assigned to a grouping rule, there Autoinvoice program matches all mandatory attributes + Sales Order for the transactions. For any two or more transactions, if all the mandatory attributes and Sales Order(optional attribute) are matching, only one invoice will be created for those transactions.

If your Grouping rule doesn't include Sales Order and Ship To fields in Optional attributes, similar sales orders with different ship-to addresses but same bill to will be grouped into one invoice and AR transaction form will not show any value in Ship-To address as it can not determine which ship-to value to be picked from multiple sales orders.

Steps to create a Grouping Rule:

Responsibility: Receivables Manager
Navigation: Setup -> Transactions -> Auto Invoice -> Grouping Rules

Select Line Ordering Rules if you are using any. Optional grouping characteristics are optional. If we are not giving any optional Grouping Characteristics, Autoinvoice will only matches mandatory characteristics. We can assign Optional characteristics for Invoices, Credit Memos and Debit Memos.
 

If  we want to assign optional attributes for all invoices, credit memos and debit memos, First assign optional characteristics for invoice class and the place the cursor on Class Invoices ad use Down Arrow to define  attributes for other classes(Credit Memo and Debit Memo) as well.

Purchasing Overview

Purchasing refers to a business or Organization acquiring goods or services to accomplish the goals of the Organization. The objectives of Purchasing are:

1. Maintain the quality of goods

2. Maintain continuity of supply

3. Maintain the flow of inputs and outputs

4. Avoide duplication and waste

3. Strengthen the competitive position of an Organization.

The Purchasing Process is as follows:

1. The employees raise Requisitions, requesting for required goods or material

2. Concerned authorities Request for Quotations from suppliers

3. Suppliers come with Quotations

4. Analysing the quotations from suppliers and select best quotation

5. Create Purchase Orders, mentioning all the details related to the goods or material and send to the supplier

6. Receiving the goods from suppliers

7. Storage of goods

Oracle Purchasing automates purchasing to make buyers more productive, improves management of your supply base, and adapts to virtually any procurement process. The main functionalities provided by Oracle Purchasing are as follows:

1. Requisitions: Requisition refers to Request for the material. This is the first step in the purchasing process. Requesitions are of two types:

     - Internal :  Internal Requisitions are to be created when you want to source the items internally.  Internal requisitions provide the mechanism for requesting and transferring material from inventory to other inventory or expense locations.This will be converted as Internal Sales Order.

     - Purchase: Purchase requisitions are used when you want to by the items from  a supplier. This will be converted as Purchase Order.


2. Document Approval Process:


Oracle Purchasing uses Workflows to handle requisition and Purchase Order approvals, automatic creation of Purchase Orders and releases, Purchase order changes, notifications and receipt confirmation. The different workflows that Purchasing uses are:


- PO Requisition Approval workflow: This work flow is used for approving requisitions.


- PO Approval workflow: This workflow is used for approving purchase orders.


- Change Order workflow: This workflow is used for controlling which changes to purchase orders require a manual reapproval and which are automatically reapproved; the change order workflow is really a group of workflow processes contained in the PO Approval workflow.


- PO Create Documents workflow: This workflow is used for automatically creating purchase orders and releases.


- PO Account Generator Workflow:  This workflow automatically generates accrual, budget, charge, and variance accounts on purchase orders and releases.


- PO Requisition Account Generator workflow: This workflow automatically generates accrual, budget, charge, and variance accounts on requisitions.


3. RFQ's:
A request for quotation (RFQ) is sent to a supplier to request pricing and other information for an item or items.There are three types of RFQ's that come with Purchasing by default: They are Standard, Bid and Catalog.  


 -Standard RFQ:  Standard RFQ is Used for items you'll need only once or not very often, but not necessarily for a specific, fixed quantity, location, and date. For example, An organization can use Standard RFQ for a special type of equipment, which they need only once or which they don't order very often. A standard quotation includes price breaks at different levels of quantity.


-Bid:  Bid RFQ is Used for a specific, fixed quantity, location, and date. For example, an organization can use a Bid RFQ to order expensive or very large equipment with specific quantity, which has never ordered in the past and may incurs special costs like transportation. Price breaks can not be specified for a Bid RFQ


-Catalog:  Catalog is Used for high-volume items or items for which your supplier sends you information regularly. For example, an organization can use Catalog quotation for office supplies.  Price breaks can be specified for a Catalog quotation at different levels of quantity ordered.


4. Quotations:
A quotation is the supplier's response to the RFQ. Quotations are also 3 types as RFQ's. Standard, Bid and Catalog. Standard, Bid, and Catalog quotations are same as Standard, Bid, and Catalog RFQ's.


5. Quotation Analysis:
Quotation Analysis is used to review and approve general or specific quotation information for an item or a purchasing category. After the Quotation analysis, the best quotation will be selected based on different parameters like Price, quality, delivery time etc.


6. Purchase Orders:
A purchase order (PO) is a commercial document issued by a buyer to a seller, indicating types, quantity, and agreed prices for products or services the seller will provide to the buyer.


Purchase Orders are issued when we request delivery of Goods or Services for specific dates or locations .
Purchasing provides the following purchase order types: Standard Purchase Order, Planned Purchase Order, Blanket Purchase Agreement, and Contract Purchase Agreement.


 - Standard Purchase Order:  Standard purchase orders are generally created for one-time purchase of items. To create standard purchase orders, users should know the details of the goods or services you require, estimated costs, quantities, delivery schedules, and accounting distributions. If you use encumbrance accounting, the purchase order may be encumbered since the required information is known.


- Planned Purchase Orders:  A planned purchase order is a long-term agreement committing to buy items or services from a single source. You must specify tentative delivery schedules and all details for goods or services that you want to buy, including charge account, quantities, and estimated cost.


- Blanket Purchase Agreements: Blanket purchase agreements are to be created when you know the detail of the goods or services you plan to buy from a specific supplier in a period, but you do not yet know the detail of your delivery schedules. You can use blanket purchase agreements to specify negotiated prices for your items before actually purchasing them. Blanket purchase agreements can be created for a single organization or to be shared by different business units of your organization (global agreements). You can encumber funds for a blanket purchase agreement.


- Contract Purchase Agreements:  You create contract purchase agreements with your suppliers to agree on specific terms and conditions without indicating the goods and services that you will be purchasing. You can later issue standard purchase orders referencing your contracts, and you can encumber these purchase orders if you use encumbrance accounting.

<><><><><><>

	Standard PO	Planned PO	Blanket Purchase Agreement	Contract Purchase Agreement
Business Purpose	For one time purchase items eg. Capital equip , Generators etc	For items whose supply date is tentative. The PO is released when material is required by us / sent by supplier against the release.	For Items needed in huge quantity at a discounted price over a period ( eg. components for an Automobile manf co) . The BPA is released when material is required and the supplier sends material against the Release	Purchasing diverse items from a single supplier. A Standard PO is created against a CPA
Goods or Services known	Yes	Yes	Yes	No
Price known	Yes	Yes	Yes	No
Quantity known	Yes	Yes	No	No
Delivery Schedule known	Yes	Tentative	No	No
Terms and Conditions known	Yes	Yes	Yes	Yes

7. AutoCreate:
Purchasing provides automatic creation capabilities for documents. Buyers can quickly create standard purchase orders, planned purchase orders, blanket releases, RFQs, and Oracle Sourcing negotiations from any available standard (not internal) purchase requisition lines.


8. PO Communication:
Purchasing allows you to communicate with concerned people regarding the purchase orders by using notifications, reports, alerts and FYI notifications.


Oracle R12 supports FYI(For Your Information) notifications. So, FYI notifications can be enabled for the viewers to avoid reports and alerts.
When someone gets FYI notification, their approval response is not required.


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.


9. Change Orders:
Purchasing allows you to modify the existing purchase orders or requistions. 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.


10. Receiving:
Receiving allows you to receive the goods or material from suppliers. Receipts are of four types:


- Direct Receipt:
Direct receipt limits receipt of items directly to the final destination; also known as dock to stock receipt. The final destination includes the requester, or the inventory.


In Direct Receipt Goods are received and delivered in one transaction


 - Standard Receipt:
A receipt routing in which shipments are received into a receiving location and then delivered to an interim or final destination in a separate transaction. Standard receipts can be inspected or transferred before delivery.


In Standard Receipt Goods must be received and delivered in separate transactions.


- Inspection Required:
A receipt routing in which shipments are received into a receiving location and then the items should go for inspection before accepting or rejecting the items.




 - Express Receipt:
The express function is a quick method of entering receipts and receiving transactions.


Returns:
Purchasing allows you to perform returns to suppliers or to customers in the Receiving Returns window.


11. Releases:
Purchasing allows you to enter, edit, and approve releases against blanket purchase agreements or planned purchase orders.

Types of Invoices in Oracle Payables

Types of Invoices in AP:

The different types of invoices available in Payables are:

1. Standard Invoices: Standard invoices are the invoices issued by a supplier to the buyer, representing the amount due for the products or services the supplier has provided to the buyer.

Standard invoices can be either matched to a purchase order or not matched.

A standard invoice must be positive amount.

2. Mixed Invoices: Mixed invoices are the invoices which can have either positive or negative amounts and can be matched to both purchase orders and invoices.

For example, if there is a mixed invoice for $-1000, you can either match it to an invoice with $-1000 or to a purchase order with an amount $1000.

3. Credit Memo: Credit memo is an invoice raised by the supplier to the buyer with negative amount. It reduces the supplier balance and reduces the liability.

For example the customer has returned some of the goods that he purchased, the supplier sends a credit memo to the buyer to adjust the balance.

4. Debit Memo: Debit memo is an invoice raised by the customer to supplier with negative amount.

The functionality of Debit Memo is same as Credit Memo. Both are to reduce the liability.

The purpose of Debit Memos is to record a credit for a supplier who does not send you a credit memo.

Unlike in AR, both Credit memo and Debit memo are with negative signs in Payables.

5. Prepayment: Prepayments are the invoices raised to record advance payments to a supplier or employee.

6. Expense Reports: Expense reports are the invoices that represent amount due to an employee for all his business related expenses.

7. Retainage Release Invoices: Retainage release is the act of releasing, or paying, that portion of a payment that was withheld until a substantial portion or all of the service procurement work is completed. The amounts retained during the life of the contract must be released and paid to the supplier or sub-contractor once all or a substantial portion of the work is completed.

Oracle Payables uses the Retainage Release Request to create a type of invoice called Retainage Release. A retainage release invoice has lines, which are copied from the original standard progress invoices, which show an amount left to be released.

Retainage release invoices can only be entered manually in the Invoice Workbench window.


8. Withholding Tax:  After you apply withholding tax to an invoice, you can optionally create invoices to remit withheld tax to the tax authority.
                           
Payables can automatically create withholding tax invoices, or you can perform this
task manually. If you choose to automatically create withholding tax invoices, you must choose whether to do this during Invoice Validation or during payment processing.


9. PO Price Adjustment Invoices:  PO Price Adjustment Invoices are used for recording the difference in price between the original invoice and the new purchase order price.

For example, If a supplier sends an invoice for a change in unit price for an invoice you have matched to a purchase order, PO Price Adjustment Invoices can be used to adjust the invoiced unit price of previously matched purchase order shipments or distributions without adjusting the quantity billed.


PO price adjustment invoices can be matched to both purchase orders and invoices.

10. Quick invoices: Used for quick, high-volume invoice entry for invoices that do not require extensive validation and defaults. After entry, you import these into the Payables system. Validation and defaulting occur during import

Accounting setup in Oracle General Ledger - R12

Accounting setup is used to set up the accounting structure which controls transaction processing across Oracle Financial Applications . With Accounting setup manager we can define and maintain the accounting setup for Legal Entities,

              Ledgers,
              Operating Units,
              Subledger Accounting,
              Intercompany and Intracompany Balancing, and
              Reporting Currencies

Responsibility:   General Ledger

Navigation:       Setup : Financials : Accounting Setup Manager → Accounting Setups

Click on Create Accounting setup to setup the Accounting structure.

There are three steps in Accounting setup process.

1. Assign Legal Entities: 

Here we may create or assign existing LE to the accounting structure. We need not assign legal entity if there is no legal entity context.

If legal entities are involved, we need to define separate accounting setup for each legal entity, which require it's own primary ledger. So ledgers have to be defined for each legal entity separately.

The need for other legal entity depends on Chart of Accounts, calendar, Currency, Accounting Method and Ledger processing options. If a legal entity requires any one of the above attributes to be different, a separate primary ledger is required.

Chart of accounts refers to the number of segments that a Chart of accounts structure consistes of.
Calendar refers to the type of accounting calendar that a legal entity uses. Ex: Monthly or Quarterly Calendar.
Currency refers to the primary currency that a legal entity belongs to.
Accounting Method refers to the subledger accounting methods based on the different accounting standards that a legal entity operates.
Ledger Options refers to the options that control how journals and transactiones are processed for a ledger.
Ex: Journal approval, Suspense account, Average balances, Intracompany balancing option, etc.

If we assign Legal entities to the accounting structure, we must assign specific balancing segment values to legal entities to identify and secure transactions by legal entity.

2. Define Accounting Representations: 

Here we need to define Primary and Secondary ledgers to make the Accounting representation.

Primary Ledgers are mandatory. We need to define the primary ledger for each legal entity and accounting setup.

Secondary ledgers are optional.  Secondary ledgers have to be assigned to the accounting setup or primary ledger to maintain multiple accounting representations for the same legal entity. A secondary ledger can differ in one or more of the following attributes from primary ledger.
Chart of Accounts,
Currency,
Calendar,
Accounting Convention

Secondary ledgers can be maintained at different levels such as:
Subledger level
Journal level
Balance level
Adjustments

In this step we can map the ledgers to  chart of accounts and assign currency, calendar, subledger accounting method and reporting currency.

Reporting currencies have to be assigned when you want diferent currency representation to primary or secondary ledgers.  Reporting currencies must share same chart of accounts,calendar,accounting method and ledger processing options as their source ledger. Reporting currencies can be assigned at different levels.
Subledger level
Journal level
Balance level

We can not use subledger level reporting currencies for secondary ledgers.

3. Save Accounting structure: This step is to review and complete the accounting setup.

Cash Pooling in Cash Management - R12

Cash Pooling Techniques are used by the Organizations to optimize the funds by consolidating bank balances across multiple bank accounts.

Benefits of Cash Pooling Techniques:

- Minimizes the idle funds by consolidating balances
- Helps to decrease external borrowing costs and increase investment returns
- Allows users to group bank accounts into pooling structures to manage funds effectively

Oracle supports following types of cash pools:

1. Self-Initiated Physical Cash Pools:

When Organizations want to monitor individual bank account balances manually and then physically move cash to or from their accounts based on their preferences, Self-Initiated Physical Cash Pools structure can be used.

We can define the rules in pool definitions, to automatically determine when bank account transfers should be made and for what amounts.

2. Bank-Initiated Physical Cash Pools, or Zero Balance Accounts(ZBA’s):

Bank-Initiated Physical Cash Pools are used When Organizations want to sweep all end-of-day balances automatically to or from the main accounts.

This kind of services will leave zero balances at the end of way. That is the reason, Bank-Initiated Physical Cash Pools are often called as Zero Balance Accounts.

3. Notional Cash Pools:

If Organizations want to track the net balances across all accounts along with individual accounts, then Notional Cash Pools will be used.



In 11i, this functionality was available to Oracle Treasury users, but now it is supported by Oracle Cash Management in R12.

Bank model in Cash Management - R12

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.

Major changes in Purchasing/iProcurement - R12

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.

  

How Data Access Sets & Security Rules work together - R12 General Ledger

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.

Major changes in AP - R12

1. Supplier Creation and Maintenance:

In Oracle R12, Suppliers are now part of TCA(Trading Community Architecture), where suppliers are defined as parties and supplier sites as party sites. Each supplier, supplier sites and contact details can be defined globally in TCA level. It means, any changes to supplier/supplier sites/address reflects across Operating Units with out really updating every OU and all the supplier information can be leveraged by multiple Operating Units. Supplier bank information can also be handled at TCA level.

In Release 12, there is a new user interface for suppliers entry and maintenance. When user opens Supplier entry form, Oracle automatically redirects the page to TCA with a jsp form.

Impact of Upgrade:

1. During the upgrade from 11i to R12, TCA party and party sites records are created and updated in TCA for all the existing suppliers and supplier sites.             
2. TCA data model requires country and address information for suppliers, which will be used by E-Business Tax. If there is no country or address information specified to a supplier site, Oracle automatically infer the data based on most frequently used site from the supplier's historical transactions.
3.Oracle Payables reviews the supplier sites and determines duplicates, based on         supplier,address,city,province, state, country, zip and language and creates only one party site for each distinct supplier site address.
4. In 11i the employees are associated with Payables as internal suppliers to create the payments for their expense reports. During migration of data, for internal suppliers, only party will be created in TCA and employee address will not not be migrated to party site and the data remains in HRMS records for data security.
5. As the supplier objects are moved from AP to TCA, the tables related to supplier, supplier site, and supplier address are obsolete in R12 and views are created with the obsoleted table names to link the information from old tables with information in TCA.

Table Changes:

AP_SUPPLIERS, AP_SUPPLIER_SITES_ALL, AP_SUPPLIER_CONTACTS, AP_SUPPLIER_INT_REJECTIONS are the new tables introduced to replace obsoleted tables PO_VENDORS, PO_VENDOR_SITES_ALL, PO_VENDOR_CONTACTS

2. Invoice Entry & Cancellation:

In Oracle R12, there is an additional level of detail called Invoice lines between Invoice Header and invoice distribution to capture the data related to Items, freight, miscellaneous, Tax, Prepayment or withholding tax. An invoice line can have one or more invoice distributions.
                                                                                                                                                               With the introduction of invoice lines, there is lot of significant improvement in the data flow to other modules which are integrated with Payables.
For example: 1. Fixed Assets use the data stored in the Invoice lines fields such as Manufacturer, Model,  Serial Number, Warranty Number, Asset Book and Asset Category to track the assets.
                     2. E-Business tax takes information from the AP invoice lines and creates summary and detail  tax lines in E-Business tax repository.
                     3. Sub ledger Accounting require the invoice distributions should be stored at the maximum level of detail. With additional level in the invoice hierarchy, data flow will be improved to the Sub ledger accounting.

Impact of Upgrade:

During a upgrade one invoice line will be created for every distribution for existing data in 11i.


Cancellation of Invoices:

An invoice line may be discarded on its own or as a part of invoice cancellation. A discarded invoice line will have an amount as 0, marked as discarded and creates a negative respective transaction in the distributions. If a line is discarded as a part of invoice cancellation it will be marked as cancelled.

Recurring Invoice:

In Oracle R12,For Recurring invoices,  invoice definition and line definition are introduced in place of template definition.  In line definition additional information such as Item description, Manufacturer and Model number are included. This will be helpful in smooth data flow to the integrated modules. In addition to Invoice definition and line definition few more tabs are introduced namely Tax, Control and Payment. E-business tax uses the data in Tax ad Payment module uses the data from payment tab on recurring invoices window.

Table Changes:

AP_INVOICE_LINES_ALL              New table introduced to represent the data stored in invoice lines
AP_CHRG_ALLOCATIONS_ALL    Obsolete and now distributions itself represent the allocation of charges


3. Payment Process:

In R12, Oracle Payments is a new module introduced to centralize the payment process into one payment engine, so that multiple applications can leverage the same functionality. In R12 Payables, user can find Payments manager under payment entry, which will re-direct the page to a OAF page. So unlike in 11i, user need to use Payables Payments dashboard to begin the payment process.

Build Payment Batch:

The first step in the payment process is to submit a Payment Process Request(PPR), which replaces Build payment Batch in Release 11i. The Payments Process Request form enable users to set invoice selection criteria. This form consists of various tabs such as Scheduled payment Selection Criteria, Payment Attributes, User Rates, Processing, Validation failure result and additional Information to specify the required criteria for payment processing.

Format Payment Batch:

Payment Process Request will be formatted automatically after submitting the Payment Process Request form. Users can check the status of PPR under Payment Process Request status.

Confirm Payment Batch:

When users click on start action icon, the form takes user to Payment Process Instructions tab, where users can confirm the batch if it is printed correctly, by clicking on 'Record Print Status' button. Here the module name changes from Payables to Payments.


>  There are no different processes  for payment and payment batch in R12. Same screen and process can be used for both .
> If user selects Payee under Scheduled payment Selection Criteria tab in the Payment Process Request  then  single payment will be done for a selected payee. If user leaves it blank, payment will be done to all suppliers.
> All Payment related setups are now moved to Oracle Payments.


4. Create Payment Instructions:

In R12 there are two programs to create payment instructions:

Create Electronic Payment Instructions    for Electronic Payments
Create Printed Payment Instructions        for Check payments

We can run these programs automatically or manually by selecting an option in the Build Payment process.

5. Transmit Payment File to Banks:

As part of R12 , there is a check box in the "Payment System" set up . When enabled the check box " Automatic Transmit of File" - This would transfer the file to bank automatically.

There are few new set ups that needs to be done in the R12.
1. Payment System - External organization ( Internal bank) needs to be set up.
2. Transmission Configuration - This includes the ftp details and how to pull the flat file from a particular location.

6. Banks:

> Bank accounts are moved into TCA architecture which needs to be defined in R12
> Cash Management now owns Banks Set up Definition.
> All the internal bank accounts of 11.5.10, will be migrated into Centralized Bank model automatically during the upgrade.


7. Transfer journal entries to General Ledger:

Users can transfer journal entries to General Ledger in two ways.                                       
1. Run Create Accounting Program with Transfer to GL option as Yes.                          
2. Run Transfer Journal Entries to GL after running Create Accounting Program with Transfer to GL parameter set to NO or after create accounting online in Final mode.

Create Accounting Program:

Payables Accounting Process is obsolete in R12 and is replaced with Create Accounting program. The create accounting program creates sub ledger journal entries by processing eligible accounting events. The Create Accounting program uses application accounting definitions, which are created in Accounting Method Builder(AMB) to create sub ledger journal entries.

The Create Accounting program
1. Creates and validates sub ledger journal entries.
2. Transfers the final journal entries in the current batch run to General Ledger and starts General Ledger Posting Process.
3. Generates Sub ledger Accounting Program Report.

The create Accounting program creates journal entries in three modes.

Draft: Users can create the journal entries in SLA in draft mode and can review and make changes again.

Final: With this option users can create journal entries in SLA which can not be modified again. Here users need to run Transfer Journal Entries to GL to post the subledger journal entries to GL.

Final Post: With this options users can create the journal entries and post to GL with out using Transfer Journal Entries to GL program.

Transfer Journal Entries to GL:

Payables Transfer to General Ledger program is obsolete in R12 and is replaced with Transfer Journal Entries to GL. The Transfer Journal entries to GL program enables users to transfer eligible journal entries to GL, including those from the previous run that have not yet been transferred to GL.

This program is used when the Create Accounting program is run with Transfer to GL parameter set to NO or after create accounting online in Final mode.
                                                                                                                                                                      
8. Invoice Approval Workflow:

Invoice work flow has been enhanced to include line level invoice approval. Based on rules setup for Payables Invoice Approval Transaction Type in AME, the work flow determines if the invoice Header (invoice document) needs approval or invoice lines needs approval or both. If both invoice lines and document need approval, all the lines of the invoice requiring approval must be approved before the invoice document can be approved.                                                                  
                                                                              
The approval  status both at header level as well as line level shows whether the invoice document or invoice lines need approval or not.     

Setup:

> The item class provided in defining rule in AME determines whether this rule effects the invoice document approval or invoice line approval.
> If item class is given as Header, this rule govern the invoice document approval and if given as line item, would govern the invoice line approval. Remaining all setups in AME are same as in 11i.

Changes in Tables: 

In R12, there are 2 history tables for invoice approval.                                                                                               
   1.     AP_APINV_APPROVERS                Stores the line level approval history            
   2.     AP_INV_APRVL_HIST_ALL              Stores both Header and line level history.

Collection Element 'REV' has no LOV in R12 Oracle Quality

In Oracle Quality module, the Quality Element 'Revision' on Enter Quality Results window has no list of values after R12 upgrade, where it was available in 11i. The users who want to capture the 'Revision' for an item on quality plans have no option to select the list of values for Revision. 

According to Oracle, this is expected functionality in R12. The Item revision collection element would be enabled and editable only for a Revision controlled Item. 

The behavior in 11.5.10 was a bug because of which even though the revision field was grayed out, the user could still enter Revision values by invoking the LOV. This was fixed in R12.

The following are the three possible options available to resolve the issue:

Srl#	Option	Remarks
1	Activate “Revision Control Code” for the items in question: All items for which Revision needs to be captured in the Quality Collection Plan’s results, using an LOV, we need to active the Revision Control code for the items in inventory.	The drawback of this option is that all material transactions would mandate the entry of Revision of the item, which makes it very cumbersome for the Inventory and other modules’ users. Hence, may not be a viable option
2	Go with the new functionality suggested by Oracle	This also may not be a good option if users need to capture the Revision of items on QC plans
3	Creation of a new Quality Collection Element that has the capability of accepting Revision of items; In this option, the “Revision Control” code for items need not be activated.	This workaround would enable the users to capture Revision of items during the entry of Quality Results. This option is explained in detail in the subsequent section.

  

Solution for Option 3: Create new collection Element

1. Create a new collection element with SQL Validation statement to populate the LOV. The following screen shot show the details of the new custom collection element to be created

     Navigation:  Quality  Setup  Collection Elements

The “select” statement to fetch the item’s revisions within the LOV is as under: 

  

2.   Identify all the QA Plans that use the standard / seeded QA element “Revision” for all the inventory organizations 

3.   Add the new custom QA element to all the QA Plans (stored in the table QA_PLAN_CHARS) identified in step 2. This could be programmatically done using an open API

4.  Using standard APIs, copy the existing data present in the “Revision” column of QA_RESULTS table into the column of newly added “custom revision” of the same table. Once the change is activated, the data captured under the new “custom revision” column would be stored in one of the custom (user-defined) columns titled CHARACTER1 through CHARACTER100. 

 

5.   Finally, once the copying of the Revision data is completed into the QA_RESULTS table (via Oracle APIs), nullify the data in “Revision” column

 

6.   Modification of Reports: All reports (Oracle Reports / SQL / Discoverer based) that were referring to “Revision” column should now be referring to the custom / user-defined columns defined for the new “custom revision” QA collection element.