Lets take an example. Suppose you are running a small grocery shop, so the typical operation as a shop owner is you basically buy groceries from some big seller and stock it in your shop. Now people come to your shop for day-to-day needs and buy stuff from your shop at a slightly higher price than what you originally bought and stocked it in your shop.
Occasionally you may not be carrying items or run out of stock that people ask for so you make a note of it and promise the person to come back tomorrow and they will get their item. So far so good, now lets name some entities before we proceed and things get complicated. The big seller from whom you buy stock is called as Vendor, the people who come to your shop to buy things are known as customers, the stock in your shop is known as inventory.

So far we have identified few entities that play an active role in your day-to-day operations. As time goes by, your business expands and now you take orders over the phone and provide service to deliver the items to your customers, so you hire people to help you out in maintaining the inventory, do the delivery part and all the necessary stuff to keep the business running smoothly. The people you hire are known as employees.
So in this small shop, you typically manage the bookkeeping activities by hand using a notepad or something similar. Now imagine the same setup on a larger scale where you have more than 10,000 customers, have more than 1000 vendors, have more than 1000 employees and have a huge warehouse to maintain your inventory. Do you think you can manage all that information using pen and paper? Absolutely no way! Your business will come to a sudden stop sign.
To facilitate big businesses, companies like Oracle Corporation have created huge software known in the category of ERP (Enterprise Resource Planning) as Oracle Applications. Now coming to think of it, Oracle Apps is not one huge software, instead it is a collection of software known as modules that are integrated and talk to each other.
Now what is meant by integrated? First let us identify the modules by entities. For e.g Purchasing and Account Payables deal with the vendors since you typically purchase from vendors and eventually have to pay the dues. Oracle Purchasing handles all the requisitions and purchase orders to the vendors whereas Oracle Accounts Payables handles all the payments to the vendors.
Similarly Oracle Inventory deals with the items you maintain in stock, warehouse etc. Dealing with customers is handled collectively with the help of Oracle Receivables and Oracle Order Management. Order Management helps you collect all the information that your customer is ordering over the phone or webstore etc whereas Receivables help you collect the money for the orders that are delivered to the customers.
Now who maintains the paychecks, benefits of the 1000 employees? right! it is managed by Oracle Human Resources. So you get the idea by now that for each logical function there is a separate module that helps to execute and maintain that function.
So all the individual functions are being taken care but how do I know if I am making profit or loss? That’s where integration comes into play. There is another module known as Oracle General Ledger. This module receives information from all the different transaction modules and summarizes them in order to help you create profit and loss statements, reports for paying Taxes etc.
Just to simplify the explanation, when you pay your employees that payment is reported back to General Ledgers as cost i.e money going out, when you purchase inventory items the information is transferred to GL as money going out, and so is the case when you pay your vendors. Similarly when you receive items in your inventory it is transferred to GL as money coming in, when your customer sends payment it is transferred to GL as money coming in. So all the different transaction modules report to GL (General Ledger) as either money going in or money going out, the net result will tell you if you are making a profit or loss.
All the equipment, shops, warehouses, computers can be termed as Assets and they are managed by Oracle Fixed Assets. Initially Oracle Applications started as bunch of modules and as time passed by they added new modules for different and new functions growing out of the need for today’s internet world.
So if you come across a module that you are trying to learn and work on, first try to understand what business need is it trying to fulfill and then try to understand what the immediate modules that it interacts with. For e.g lets say you come across Oracle Cost Management module, you will learn that it helps to maintain the costs of items in your inventory and the immediate modules that it interacts with are Oracle Inventory (ofcourse), Oracle Bills of Material, Order Management and so on..
(Source: http://www.appsbi.com/what-is-oracle-apps-erp)
The migration of transactions & journals from legacy to oracle is the most difficult part of data migration. You should migrate all the GL balance for the current year periods, all the last year periods and the ending balance of ‘Y-2’ to oracle. You need to do a proper reconciliation of GL balances after migration of open AP/AR invoices to the current period.
AP Open Invoice
The charge and tax amounts of the open AP invoices already exist in the legacy system. You need to make sure that you don’t account them again in oracle.
Accounting entries in Legacy
Charge A/C Dr
Tax  A/C Dr                            Supplier Liability A/C Cr
Instead of the liability account use a clearing account(Liability) while transferring the journals to oracle GL. Make the below changes while transferring these journals to oracle GL
Charge A/C Dr
Tax  A/C Dr                           
Migration Clearing A/C (Liability) Cr
When you transfer the AP invoice from legacy to oracle. Use the above migration clearing account as charge/tax/freight A/C
Accounts created in oracle AP
Migration Clearing A/C (charge)
Migration Clearing A/C(tax)                       Supplier Liability A/C Cr
Transfer these accounts from AP to Oracle GL. After posting all these journals in the current period the YTD balance of migration clearing A/C should be zero.
AR Open Invoice
Similar to AP open invoice in AR invoice we use a clearing account (ASSET) instead of the receivable A/C in legacy. The revenue and tax amounts of the open AR invoices exist in the legacy system. You need to make sure that you don’t account them again in oracle.
Accounting entries in Legacy
Receivable A/C Dr
                                    Revenue A/C Cr                           
                                    Tax A/C Cr            
              
Make the below changes while transferring these journals to oracle GL
Migration Clearing A/C (Asset) Dr
                                                             Revenue A/C Cr                           
                                                              Tax A/C Cr     
      
When you transfer the AR invoice from legacy to oracle. Use the above migration clearing account as revenue/tax/freight A/C (use transaction type in auto accounting and put the clearing accounts in transaction type)
Accounts created in oracle AR
Receivable A/C Dr
                                    Migration Clearing A/C (Revenue) Cr                           
                                     Migration Clearing A/C (Tax) Cr            

Transfer these accounts from AR to Oracle GL. After posting all these journals in the current period the YTD balance of migration clearing A/C should be zero.
Fixed Assets
Transfer all the assets from legacy to oracle with Accumulated depreciation till the current period. Oracle ‘ll not create any depreciation for previous period. System ‘ll create below journal entries when you close & transfer the journals for the first asset period
Addition Journals
Addition Cost A/C Dr.
                                  Addition Cost Clearing A/C  Cr.
All these assets are present in legacy GL and transferred as a part of GL migration. You need to reverse all these journals in current period
Depreciation Journals
System‘ll create the depreciation journals for the current period.
All the past period depreciation & acc. Depreciation amounts are transferred through GL migration.
Oracle Puchasing:
1. Requisitions Open Interface
2. Purchasing Documents Open Interface
3. Cancel PO APIs
4. Receiving Open Interface
Oracle Inventory:
1. Open Transaction Interface
2.1 Customer Item Interface
2.2 Open Item Interface
2.3 Cycle Count Open Interface
3.1 Open Replenishment Interface
3.2 Reservations Open Interface
3.3 Move Orders Open Interface
OM:
1.    Order Import
2.    Process Order API
3.    RLM Open Interfaces
Actions, APIs, and Parameters: Descriptions of the APIs used for various functions and the API parameters.
Application Parameter Initialization: Description of the application parameter initialization call.
Trip API: Create and update trip records and perform actions on trips.
Stop API: Create and update stop records and perform actions on stops.
Deliveries API: Create and update trip stop records and perform actions on trip stops.
Delivery Details API: Assign and unassign delivery details to and from deliveries, split a delivery detail, update a delivery detail with new
information, and create trips and deliveries for multiple delivery lines.
Container API: Create container records, update container records, autopack containers, perform actions on containers.
Freight Cost APIs: Create freight cost records, update freight cost records, validate freight cost types, delete freight cost records.
Tables
OE_ORDER_HEADERS_ALL
OE_ORDER_LINES_ALL
WSH_DELIVERY_DETAILS
OE_ORDER_HOLDS_ALL
OE_PRICE_ADJUSTMENTS
OE_TRANSACTION_TYPES_ALL
OE_DROP_SHIP_SOURCES
OE_SETS
OE_SYSTEM_PARAMETSR
MTL_DEMANDS
MTL_RESRVATIONS
Inventory
Open Transaction Interface
Oracle Inventory provides an open interface for you to load transactions from external applications and feeder systems. These transactions could include sales order shipment transactions from an Order Management system other than Oracle Order Management, or they could be simple material issues, receipts, or transfers loaded from data collection devices. The following transaction types are supported by this interface:
• Inventory issues and receipts (including user-defined transaction types)
• Subinventory transfers
• Direct interorganization transfers
• Intransit shipments
• WIP component issues and returns
• WIP assembly completions and returns
• Sales order shipments
• Inventory average cost updates
• LPN Pack
• Unpack
• Split Transactions
• Inventory Lot Split/ Merge/ Translate Transactions
This interface is also used as an integration point with Oracle Order Management for shipment transactions. Oracle Order Management’s Inventory Interface program populates the interface tables with transactions submitted through the Confirm
Shipments window.
You must write the load program that inserts a single row for each transaction into the MTL_TRANSACTIONS_INTERFACE table. For material movement of items that are under lot or serial control, you must also insert rows into MTL_TRANSACTION_LOTS_INTERFACE and MTL_SERIAL_NUMBERS_INTERFACE respectively. If you insert WIP
assembly/completion transactions that complete or return job assemblies, you must also insert rows into the CST_COMP_SNAP_ INTERFACE table if the organization referenced uses average costing. The system uses this information to calculate completion cost.
There are two modes you can use to process your transactions through the interface. In the first processing mode, you populate the interface table only. Then the Transaction Manager polls the interface table asynchronously looking for transactions to process, groups the transaction rows, and launches a Transaction Worker to process each group.
In the second processing mode, you insert the rows in the interface table and call a Transaction Worker directly, passing the group identifier of the interfaced transactions as a parameter so that the worker can recognize which subset of transactions to process.
The Transaction Worker calls the Transaction Validator, which validates the row, updates the error code and explanation if a validation or processing error occurs, and derives or defaults any additional columns. Next, the Transaction Processor records the transaction details in the transaction history table along with relevant current cost information. All material movement transactions update inventory perpetual balances for the issue, receipt, or transfer locations. Once the transaction has been successfully processed, the corresponding row is deleted from the interface table. Finally, the transaction is costed by the transaction cost processor, which runs periodically, picking up all transactions from the history table that have not yet been marked as costed.
Open Replenishment Interface
Oracle Inventory provides an open interface for you to easily load replenishment requests from external systems such as a barcode application. Such requests may be in the form of stock-take counts or requisition requests for subinventories in which you do not track quantities.
Cycle Count Entries Interface
You can import cycle count entries from an external system into Oracle Inventory using the Cycle Count Entries Interface. This interface validates all data that you import into Oracle Inventory. It also performs foreign key validation and checks for attribute inter-dependencies, acceptable values, and value ranges. The interface ensures that the imported cycle count entries contain the same detail as items entered manually using the Cycle Count Entries window. Errors detected during validation are written to the Cycle Count Interface Errors table.
Kanban Application Program Interface
The Kanban API is a public API that allows you to update the supply status of kanban cards. To accomplish this task, you use the public procedure update_card_supply_status
Item Open Interface
You can import items from any source into Oracle Inventory and Oracle Engineering using the Item Open Interface. With this interface, you can convert inventory items from another inventory system, migrate assembly and component items from a legacy manufacturing system, convert purchased items from a custom purchasing system, and import new items from a product data management package. The Item Open Interface validates your data, ensuring that your imported items contain the same item detail as items that you enter manually in the Master Item window.
You can also import item category assignments. This can be done simultaneously with a process of importing items, or as a separate task of importing item category assignments only. For this purpose, the Inventory menu contains the Import submenu with the Import Items and Import Item Category Assignments menu entries.
Receiving Open Interface
You use the Receiving Open Interface to process and validate receipt data that comes from sources other than the Receipts window in Oracle Purchasing. These sources include:
• Receipt information from other Oracle applications or legacy systems
• Brocades and other receiving information from scanners and radio frequency devices
• Advance Shipment Notices (ASNs) from suppliers
The Receiving Open Interface maintains the integrity of the new data as well as the receipt data that resides in Oracle Purchasing.
The Receiving Open Interface does not support:
• Movement statistics
• Dynamic locators

BOM
Bills of Materials Open Interfaces
WIP
Open Move Transaction Interface
You can load Move transaction information into the Open Move Transaction Interface from a variety of sources, including external data collection devices such as bar code readers, automated test equipment, cell controllers, and other manufacturing execution systems. You then use the interface to load these transactions into Oracle Work in Process. All transactions are validated and invalid transactions are marked, so that you can correct and resubmit them.
Open Resource Transaction Interface
You can use external data collection devices such as bar code readers, payroll systems, and time card entry forms to collect resource and overhead transaction data, then load the data into the Open Resource Transaction Interface for Oracle Work in Process to process.
Work Order Interface
The Work Order Interface enables you to import Discrete job and Repetitive schedule header information, and Discrete job operations, material, resource, and scheduling information from any source, using a single process.
You can import:
• Planned orders for new Discrete jobs,
• Discrete job operations, components, resources, resource usage, and scheduling details
• Update and reschedule recommendations for existing Discrete jobs
• Suggested Repetitive schedules Work in Process then uses this information to automatically create new Discrete jobs
and pending Repetitive Schedules, or to update existing Discrete jobs.
MRP
Open Forecast Interface
You can import forecasts from any source using the Open Forecast Interface table. Oracle Master Scheduling/MRP automatically validates and implements imported forecasts as new forecasts in Oracle Master Scheduling/MRP.
Cost Management
Periodic Cost Open Interface
The Oracle Periodic Cost Open Interface provides an open interface for you to easily load periodic item costs from external applications or legacy systems and migrate them into the Oracle Cost Management Application. This interface should only be used to bring in periodic costs for the first opened periodic period. It cannot be used for subsequent periods. Costs in subsequent periods are calculated by the system.
Cost Import Interface
The Oracle Cost Import Interface enables you to import costs for items from legacy systems, and import new cost information for existing items. Importing resource costs and resource overhead rates is also supported. You will also be able to replace existing cost information with the new cost information. However, updating of existing costs is not supported. Importing costs into frozen cost type is also not supported. The item costs will have to be imported into another cost type and then the cost update may be run to update the frozen cost type
OM
Order Import
Pricing Open interface
Pick release