Multi Org

In Release 11i, a user assigned to an Operating Unit (OU) would process data from the products deployed in that OU. To process data for another OU, a user would log out of the first and into the second. The data generated in that OU would be accounted for according to rules generated by various product accounting engines, and posted to general ledger in ways appropriate for the different products, some generating part of the detail at different times in the process. General Ledger sets of books (Sob) were self-contained, reflecting the balances of the entity to which you'd assigned the Sob, and managed by users assigned to the Sob.

In Release 12.0, by contrast, users can be assigned to multiple operating units, and are supported by processes and transactions that can span operating units. Their data is book-kept according to rules stored in a single accounting engine,and the accounting is stored in subledger tables that are standard across all products. Complete accounting is maintained for every appropriate event, and all subledger entries are fully balanced and detailed. A single, common posting engine summarizes to your required level of detail, and posts to General Ledger.Sets of Books are replaced by the accounting entity's 'ledger' for data, and its 'Ledger Set' for processing, from reporting, opening and closing, through allocations. Ledgers can be combined into ledger sets, and GL users are assigned to the ledger sets. User access to multiple operating units is called 'Multi-Org Access Control',(MOAC).

Multi-Org Access Control
(Changed functionality)

Multi-Org Access Control enables companies that have implemented a Shared Services operating model to efficiently process business transactions by allowing them to access, process, and report on data for an unlimited number of operating units within a single applications responsibility. This increases the productivity of Shared Service Centers, as users and processes no longer have to switch applications responsibilities when processing transactions for multiple operating units at a time. Data security and access privileges are still maintained using security profiles that now support a list of operating units.

Multi-Org Security Profile Preferences
(Changed functionality)

A Multi-Org Security Profile defines the list of operating units to which a user has access. If a user typically uses a subset of the operating units in his security profile, he may set up Preferences to limit the operating units available to him during transaction processing. The user can also set a default 'operating unit' to minimize manual data entry when an operating unit context is required.

Enhanced Multi-Org Reporting
(Changed functionality)

Consistent with the Multi-Org Access Control feature, users are able to run reports using two levels:

• Ledger : The report runs for all operating units within a ledger to which the user has access
• OU : The report runs for a selected operating unit that belongs to the user's security profile.

Multi-Org Integration with Accounting Setup Manager
(New functionality)

The Accounting Setup Manager is a central location to define your accountingrelated setup across all financial applications. Here, you can define your legal entities and their accounting context, which includes the ledgers that will contain the accounting data for each legal entity. Multi-Org is integrated into the Accounting Setup Manager such that users can define operating units and their relationship to ledgers. For each operating unit, users can also select a legal entity to provide a default legal context during transaction processing. This centralizes your setup and makes it easier to inquire on and maintain relationships between ledgers, legal entities, and operating units.

GL Accounting Setup- Simultaneous Accounting for Multiple Reporting Requirements
(New functionality)

Companies that are global in nature and that have operations in different localities often have multiple reporting requirements. These companies and their subsidiaries often need to satisfy the accounting and reporting requirements for each country as well as those of the parent company. This involves performing accounting in accordance with accounting principles and standards of multiple countries and in different currencies, charts of accounts, and/or calendars. The reporting requirements can also be statutory in nature, and one subsidiary may even need to satisfy multiple sets of statutory requirements. Oracle General Ledger simplifies the simultaneous management of the accounting for all of these different reporting requirements in this latest release. You are able to define your legal entities and the setup needed to address each accounting and reporting requirement using the Accounting Setup Manager. New enhancements and integration with Subledger Accounting enable Oracle General Ledger to perform accounting for all reporting requirements of a legal entity simultaneously.

Centralized Accounting Setup
(New feature)

The Accounting Setup Manager is a central location to define your accounting-related setup across all financial applications. Here you can define your legal entities and their accounting context, which includes the ledgers* that contain the accounting data for each legal entity. If a legal entity has multiple reporting requirements, you can include additional reporting currencies or ledgers in the accounting context to satisfy the additional requirements.

Enhanced Reporting Currency Functionality
(Changed functionality)

Multiple Reporting Currencies functionality is enhanced to support all journal sources. Reporting sets of books are now simply reporting currencies. Every journal that is posted in the primary currency of a ledger can be automatically converted into one or more reporting currencies. This conversion can be performed by Subledger Accounting, to convert all subledger journal entries, or by General Ledger, to convert more summarized General Ledger journals. You can choose to convert any journal sources and categories.

Simultaneous Data Access to Multiple Legal Entities and Ledgers
(New feature)

Can access multiple legal entities and ledgers when you log into Oracle General Ledger using a single responsibility. This improves processing efficiency by reducing the need to switch between responsibilities when trying to access data for different ledgers or legal entities.

Simultaneous Opening and Closing of Periods for Multiple Ledgers
(New feature)

The Open and Close Periods Programs have multiple enhancements. You are able to run any of the Open and Close Periods Programs from the Concurrent Manager. This allows you to take advantage of scheduling and request set capabilities for greater processing efficiency. Also, if you manage multiple ledgers, you can open or close periods for multiple ledgers simultaneously. You can even keep the status of periods across multiple ledgers in synch with new programs that ensure a specific period is Open or Closed for all of the ledgers you manage.

Cross-Ledger and Foreign Currency Allocations
(New feature)

You are able to allocate financial data from one or more ledgers to a different target ledger. This enables you to perform cross-ledger allocations, which is useful for purposes such as allocating corporate or regional expenses to local subsidiaries when each entity has its own ledger. This is possible even if the target ledger is in a different currency than the source ledger(s) because you can create allocations in foreign currencies. Foreign currency allocations are also useful within a single ledger if you need to allocate amounts to a currency that is different from the primary currency of a ledger.

Simultaneous Currency Translation of Multiple Ledgers
(New functionality)

If business manages multiple ledgers; you can run the Translation program for multiple ledgers simultaneously.

FND_MESSAGE.CLEAR	Clears the message stack of all the messages
FND_MESSAGE.DEBUG	Immediately displays the string passed to it as input parameter
FND_MESSAGE.ERASE	Clears the oracle Forms status line
FND_MESSAGE.ERROR	Displays an error message in an Oracle Forms modal window or a concurrent program log file. (Example: "Invalid value entered."). It takes its message from the stack, displays the message, and then clears all the messages from the message stack
FND_MESSAGE.GET	Retrieves a translated and token–substituted message from the message stack and then clears that message from the message stack. This could be used for getting a translated message for a forms built–in or other function. Assumes you have already called FND_MESSAGE.SET_NAME and, if necessary, FND_MESSAGE.SET_TOKEN. It returns up to 2000 bytes of message
FND_MESSAGE.HINT	Displays a message in the Oracle Forms status line. It takes its message from the stack, displays the message, and then clears that message from the message stack. The user may still need to acknowledge the message if another message immediately comes onto the message line
FND_MESSAGE.QUESTION	Displays a message and up to three buttons in an Oracle Forms modal window. (Example: "Please choose one of the following actions: ") It takes its message from the stack, and clears that message. After the user selects a button, It returns the number of the button selected. For each button, you must define or use an existing message in Message Dictionary (under the Oracle Application Object Library application) that contains the text of the button. This routine looks for your button name message in the Oracle Application Object Library messages, so when you define your message, you must associate it with Oracle Application Object Library (the "FND" application) instead of your application
FND_MESSAGE.RETRIEVE	Retrieves a message from the database server, translates and substitutes tokens, and sets the message on the message stack
FND_MESSAGE.SET_NAME	Retrieves your message from Message Dictionary and sets it on the message stack. You call it once for each message you use in your client–side PL/SQL procedure. You must call this procedure before you call FND_MESSAGE.SET_TOKEN
FND_MESSAGE.SET_STRING	Takes an input string and sets it directly on the message stack. The string does not need to be defined in the Messages window. These strings may be hard coded into the form and are not translated like messages defined in Message Dictionary
FND_MESSAGE.SET_TOKEN	Substitutes a message token with a value you specify. You call FND_MESSAGE.SET_TOKEN once for each token/value pair in a message. The optional translate parameter can be set to TRUE to indicate that the value should be translated before substitution. (The value should be translated if it is, itself, a Message Dictionary message name.)
FND_MESSAGE.SHOW	Displays an informational message in an Oracle Forms modal window or a concurrent program log file. (Example: "To complete this function, please enter the following... "). It takes its message from the stack, displays the message, and then clears only that message from the message stack
FND_MESSAGE.WARN	Displays a warning message in an Oracle Forms modal window and allows the user to either accept or cancel the current operation. (Example: "Do you wish to proceed with the current operation?") FND_MESSAGE.WARN returns TRUE if the user accepts the message (that is, clicks OK), or FALSE if the user cancels. It takes its message from the stack, displays the message, and clears that message from the message stack

 

Oracle Version 1, 1978

 Written in Assembly Language
 Ran under PDP-11 under RSX in 128K of Memory
 Implementation separates oracle code and user code.

Oracle Version 2, 1979

 The first SQL Relational Database Management system that was commercially released.
 Written in PDP-11 Assembly Language
 Ran on VAX/VMS in Compatibility mode

Oracle Version 3.1980

 Written in C, Portable Source Code
 Retained Split Architecture
 Introduced the concept of Atomic SQL Execution and transactions (Commit & Rollback)

Oracle Version 4, 1984

 Introduced Read Consistency.
 Portable to many platforms
 Interoperability between PC and Server

Oracle Version 5, 1986

 True Client Server –Distributed Processing
 VAX –Cluster Support
 Version 5.1- Distributed Queries

Oracle Version 6, 1989

 Major Kernel Rewritten
 OLTP Performance enhancements (save points)
 Online Backup and Recovery
 Row level Locking
 PL\SQL in the database
 Parallel Servers (VAX Clusters, nCube)

Oracle Version 7, 1993

 Stored Procedures and Triggers
 Shared SQL, Parallel Execution
 Declarative Referential Integrity
 Advanced Replication 

Oracle Version 8, 1997

 Object Relation Extensions in the Database
 From Client Server to Three tier Architecture
 Partitioning Option

Oracle Version 8i, 1999

 Java in the database (JVM and SQLJ)
 Partitioning Enhancements
 Data Warehousing Enhancements
 XML Support
 Summary Management
 Oracle Internet Directory (LDAP)
 Ported to Linux

Oracle Version 9i, 2001

 Real Application Clusters, with cache fusion– Scalability on inexpensive clustered hardware
 Automatic segment-space management
 Internet security enhancements
 Integrated business intelligence functionality
 Data Guard (standby databases)
 Oracle managed files
 Globalization support (Unicode, time zones, locales)

Oracle Version 10g, 2003

 Primary goal: Build a self-managing database that requires minimal human intervention.
 Reduction in administration cost without
 Compromising high availability, scalability, and security.
 Minimal performance impact
 Effective for all configurations and workloads

Oracle Version 11g, 2007

 Flashback data Archive
 Advanced Compression
 Real Application Testing
 Automatic Storage Management 

In R12 Accounts Payables, that there is no more supplier form. The Suppliers have gone to self-service now. This is not the only change in the supplier. The suppliers objects have moved from AP product to TCA (Trading Community Architecture) DataModel. Due to this, even the underlying tables have changed. Supplier information is no more stored in PO_VENDORS Table now.

3 new tables have been introduced.

• AP_SUPPLIERS

• AP_SUPPLIER_SITES_ALL

• AP_SUPPLIER_CONTACTS

But don't panic as your customizations can still work as there are views created with names of PO_VENDORS, PO_VENDOR_SITES_ALL and PO_VENDOR_CONTACTS for backward compatibility.

Being a part of the TCA, these tables are closely linked to the hz tables. Here is the list of few imp HZ Tables that are affected when a new supplier is added.

TABLE NAME	DESCRIPTION
HZ_PARTIES	Master table along with AP_SUPPLIERS instead of PO_VENDORS
HZ_PARTY_SITES	Master table for supplier sites along with AP_SUPPLIER_SITES_ALL instead of PO_VENDORS_SITES_ALL
HZ_LOCATIONS	Contains the party sites information
HZ_PARTY_USG_ASSIGNMENTS	Stores party usages
HZ_ORGANIZATION_PROFILES	Captures additional Supplier information, e.g. credit scoring details of Supplier or the Number of Employees working in Supplier Organization
IBY_EXTERNAL_PAYEES_ALL	Captures Payment related details of the Supplier
POS_SUPPLIER_MAPPINGS	It holds the mapping between the AP_SUPPLIERS.VENDOR_ID and HZ_PARTIES.PARTY_ID

This is useful in cases whereby two vendors effectively belong the same HZ_Party Record.

See the diagram below for Supplier/Sites Mappings to TCA Objects.

So whenever a supplier is added in R12, an entry is made in all these tables. Functionally also, creating the supplier is different from 11i. Here are the steps to create a new supplier.

1. Hit the CREATE SUPPLIER button

2. Enter a unique supplier name (Organization Name) along with other optional other information like Alias, Tax Registration Number, D-U-N-S number.

3. If the Supplier Number Entry option in the Payables System Setup window is set to Automatic, Payables automatically enters a Supplier Number for you. If this option is set to Manual, you must enter a unique Supplier Number.

4. Click Apply. The system creates the supplier record and accesses the Suppliers: Quick Update page.

5. To create Supplier Sites, you will have to create the locations for that supplier. For that, click on the "Address Book" Button.

6. On the Address Book page, click the Create button.

7. Fill all the address details and address purpose. i.e. Purchasing, Payment or RFQ Only.

8. You can add as many locations as you wish.

9. When created, you can manage the addresses for other information.

<< Click to view the image in large size >>

10. The system only displays sites that are in your MOAC profile

11. The address status indicates whether the supplier has provided any updates for the address. Using iSupplier Portal's Supplier Profile Management tools, suppliers can enter address book information online, creating any number of new addresses, modifying the details for existing addresses, and indicating how each address is used.

12. Suppliers can also inactivate addresses that are obsolete. Buyer administrators need to approve any changes in order to update the master supplier details.

13. Address statuses include:

• New. A supplier has created a new address.

• Change Pending. A supplier has changed the address details. Click the Update icon to review the changes that have been made. The page displays the original address details and the changes, indicated by a blue dot. Buyer administrators can approve or make additional modifications to the changes before approving or rejecting the change. If the supplier has indicated that the address should be removed, there is a status change from Active to Inactive.

• Current. There are no pending updates for the address.

14. Since suppliers are stored in TCA, the address details for the supplier may be used by other Oracle products so be careful if removing supplier addresses. If the address is inactivated, the system no longer associates it to any contacts, and any bank account assignments to the address are inactivated. Methods to inactivate addresses include:

• You can click the Remove button on the Address Book page. This sets the address status to inactive and sets the Inactive Date for every site that is associated with the address in all operating units to today's date.

• You can update the address and set its status to Inactive. This changes the address status and does not inactivate any of the sites that are using the address.

• You can use the Manage Sites page to manually update the Inactive Date for each site.

Oracle Inventory is core module of entire Oracle e-business suite, this module shares the information with almost every other module. Oracle Inventory let you define the Items and it is backbone of all inventory transactions.

Functionality provided by Oracle Inventory

Item Master

Item setup is critical part of Oracle ERP implementation. Item setup is required to place purchase orders, receive & transact inventory, to enter sales orders, ship goods/services to customer. Items are first setup in master inventory organization and same can enabled in every other inventory organization where it needs to transact. Item attributes are different flags that determine the characteristics of items. Item attributes determine whether item is procured item, saleable item, service item etc.

Inventory transactions

Inventory holds the onhand quantities and transactions that can cause onhand changes. Transactions originated from other modules (Shipping - customer shipments, Purchasing - Receiving goods into stock etc) are finally transferred to Inventory. Every transaction is associated with a transaction type, source, Item, quantity, unit of measure and additional attributes. Oracle provides many seeded transaction types and you can add custom transaction types as needed for accurate reporting.

Examples of Inventory transactions

       Subinventory transfers

       Miscellaneous issue/receive

       Account Alias issue/receive

       Move order issue

       Sales order shipment

Serial & Lot control Its provides detail tracking of onhand and related inventory transactions. Lot number and serial number are critical requirements in a regulated environment like pharmacuetical, food processing industries. In case of any recalls lot/serial control provides tracing the current location of goods.

Inventory Planning

Oracle Inventory planning provides good planning methodoligies for indirect item purchases, MRO kinds of items while MRP (Material Requirements Planning) as planning method is still preferred for direct material. MRP functionality is delivered through Oracle MRP/SCP module. Widely known inventory planning methods are Reorder planning & Min-max planning, lets understand little bit more about these methods.

Reorder Point Planning (ROP) ROP uses Supply (onhand + expected receipts) and safety stock information to plan the re-order quantity. When supply falls below safestock a replenishment order is created considering the lead time and economic order quantity.

Min-Max Planning This planning method is bit different from ROP, The replenishment order is created when onhands falls below the minimum level set at the item.

Periodic Inventory verification methods

It is very important to have systematic onhand match with actual physical onhands for data accuracy and efficient planning purpose. Oracle Inventory provides two onhands verification and rconcialiation methods called Physcial Inventory and Cycle counting.

Physical Inventory It is an activity where 100% of onhand is physically verified and reconciled with system onhand. Typically this is done once a year or twice based on business needs. When physical inventory in progress typically all other operations will be on hold. Any differences in physical and systematic onhands are adjusted and approved in system and matched with physical onhand quantity.

Cycle counting It is a periodic counting process instead of onetime process like physical inventory. In cycle couting items are classified into ABC classes (high, medium, low value items). High value items are verified more frequent than low low value items. System generates the schedule of items that need to be counted and verified.