Inventory Replenishment

In any business involved in the sale of goods , the business needs to keep a track of its inventory and replenish the inventory when needed. The business can use different methods to replenish their inventory.

The Inventory replenishment methods provided by Oracle include

1. Min-Max Planning
2. Reorder Point Planning
3. Kanban Replenishment Planning
4. Replenishment Counting

When Placing an order for replenishing the inventory , the business needs to answer certain quetions

1. What should be ordered
2. How much should be ordered
3. When should it be ordered
4. Which planning method should be used to decide the order

Lets see the answer to these questions:

1. What should be ordered : The business needs to decide what products/goods it needs to buy
2. How much should be ordered : When deciding on this the business needs to consider the carrying cost of the goods and the expected demand
3. When should it be ordered: This will be answered by the replenishment method used
4. Which planning method should be used to decide the order : It is decided by the business depending on Oracles offering of each mechanism

Of the replenishment methods listed above , some can be performed at Organization/warehouse level and some at sub-inventory level

Now we will look at the different replenishment methods :

Re-Order Point Planning : is an inventory replenishment mechanism in which the inventory is replenished when the inventory levels fall below a certain pre-defined level. The amount of order placed is equal to EOQ (Economic Order Quantity) . This mechanism is suggested for in-expensive items.

Re-Order Point : Safety stock + Forecasted demand during the lead time , lead time is the time in which the business expects the goods to be delivered

This mechanism can be used in cases of:

• replenishment at Org level is done
• for inexpensive items
• item demand is independent of others

 Min-Max Planning: Min Max Planning is another simple method of inventory planning with the below features

• User  defines the minimum and maximum inventory levels of the item
• Inventory is replenished to the maximum level when the level reaches the minimum level
• Can be applied to any number of items

This mechanism can be used in cases of:: 

• Inventory replenishment is planned at Org or sub-inventory level
• the items do not require strict inventory monitoring

Kanban Replenishment : Kanban Replenishment Planning is a replenishment mechanism which depends on visual cues for inventory replenishment. This mechanism is applicable for items which require shorter lead times,having a constant demand and medium to high production demand

Kanban uses replenishment signals which are easily indicative and visible : in means of color coding scheme, color cards or empty bins.

Depending on the mechanism used once the inventory needs to be replenished as per the signals business will have the replenishment.

The inventory replenishment in Kanban can be on the type of replenishment chosen:

1. Inter Org: In this case an internal requisition is created
2. Intra Org: In this case goods are transferred from one sub-inventory of the warehouse to the other
3. Production : Creation or release of a production job is done
4. Supplier: A purchase requisition is created

Replenishment Counting: Replenishment counting is used for items for which inventory tracking is not maintained. In this mechanism the counters will physically count the inventory on a periodic basis and replenish the inventory as and when required.

  

Inventory Planning and Replenishment

In a business maintaining inventory of goods , the business needs to replenish the stock of the sold goods to maintain the required inventory for normal business operations

The Inventory replenishment is determined by the inventory replenishment method employed by the business

      1.       Min-Max Planning

      2.       Kanban Replenishment Planning

      3.       Replenishment Palnning

      4.       Re-Order Point Planning

The Re-Order of Inventory raises a lot of questions which need to be answered

      1.       What should be ordered

      2.       How much should be ordered

      3.       When should the goods be ordered

      4.       Which planning method to use

How Much to Order : This depends on the relation between the supply and demand and the inventory replenishment lead time.

Inventory Forecasting: Inventory forecasting is the process of extrapolating the expected demand of the goods over an expected number of periods

Inventory Replenishment methods

      1.       Min-Max Planning

      2.       Kanban Replenishment Planning

      3.       Replenishment Planning

      4.       Re-Order Point Planning

Re Order Point Planning

As the name suggests this method of replenishment will replenish the inventory when the inventory level falls below a certain decided point.

The goods ordered are equal to the EOQ (Economic Order Quantity)

This mechanism is recommended for the items which are not very expensive

Re-Order point planning steps

1.       Enter item planning attributes

2.       Forecast item demands

3.       Define safety stock

4.       Run Re-Order point report

Min-Max Planning

The items are planned depending on the user defined Minimum and Maximum quantity.The items are replenished to the Maximum level once it falls below the Minimum Level. It is generally applied to low cost items which do not require strict monitoring

Kanban Planning:

Kanban is a pull replenishment system whose aims is zero stockouts, shorter lead times, and reduced inventory with minimal manual supervision. Instead of waiting for an MRP plan to release materials down the supply chain, with kanban each operation pulls the materials it needs from its source when it needs them, signaling with a replenishment signal or a kanban that it needs to do so.

Kanban

The term kanban refers to a visual replenishment signal such as a card or an empty bin for an item. In a kanban system, each work center has several bins, each containing a certain number of the same item. When a bin becomes empty, the work center starts the process of replenishing the empty bin by sending the replenishment signal, or a kanban. Meanwhile, the work center can continue using the other (stocked) bins.

Types of Kanban Replenishment:

Inter Org: Replenishes by creating Internal Requisition

Intra Org: Triggers Material movement from a subinventory in the same Organization.

Production: Creates or releases a Production Job

Supplier: Creates a Purchase Requisition.

Kanban Elements:

Pull Sequence is a group of information that defines a Kanban location, source information, and planning parameters for an Item.

 Kanban chain is a series of Pull Sequences, which defines the replenishment network. E.g.: Assembly to Stores.

Kanban Cards are created for Item, Subinventory and Locator (optional) and uniquely identified by a Kanban number

 Replenishable Cards can be created automatically through Pull Sequence or manually through „Kanban Cards‟ window.

Replenishment Counting

• Replenishment Counting is a method of ordering Items for non-Tracked Subinventory.

• Non-Tracked subinventories are expense subinventory, for which On-hand balances are not maintained.

• Whenever an Item is moved into Expense Subinventory, the Expense account is charged and the quantity is discarded.

• Items are replenished in Non-Tracked Subinventory by periodically counting the items physically.

Inventory Transactions

Transactions in the inventory are classified depending on the flow

Material Flow:

         1.       Receive Goods

         2.       Move Goods

         3.       Issue Goods

Business Flow:

         1.       WIP à Inventory

         2.       Purchasing à Inventory

         3.       Order Management à Inventory

         4.       Services à Inventory

Different types of Inventory Transactions

         1.       Miscellaneous issue

         2.       Miscellaneous receipt

         3.       Sub inventory transfer

         4.       Inter org transfer

Miscellaneous Issue:

Users can use miscellaneous transactions to issue material from general ledger accounts in your current organization. Items are issued from the inventory without any documentation

Miscellaneous Receipt:

Users can use miscellaneous transactions to receive material to general ledger accounts in your current organization. Items are issued from the inventory without any documentation

Sub Inventory Transfer

Users  use sub inventory transfers to transfer material within your current organization between sub inventories, or between two locators within the same sub inventorys

Inter Org Transfer

Users  use direct inter-organization transfers to move inventory directly from shipping organization to a destination organization

Managing Inventory Receipts

Users can receive both internally and externally sourced shipments and deliver material directly to inventory, the shop floor, and you can deliver to inventory, shop floor, and expense destinations

Types of Inventory Receipts

Direct Shipment:  A direct Shipment enables the users to receive and deliver the goods to the inventory by a single inventory transaction

Standard Receipt: This is a2 step of performing the receipt of goods. The process enables the users to receive the goods in one inventory organization and deliver in another organization

Inspected Receipt: This is a 3 step of performing the receipt of goods. The process enables the users to receive the goods in one inventory organization, inspect the goods and deliver in another organization.

Move Order

A move Order is a document which enables the movement of goods within a single organization. Move Order document keep track of the intra org transfer of the materials. The move order document Is created when a sales order is pick released. The move order document is used by the warehouse personell for performing picking.

There are 3 activities in Move Orders:

Move Order Creation: Creation of the move order documents

Move Order Allocation: Allocation of the goods to the move order

Move Order Transaction: Transfer of the goods within the organization as specified on the move order

Item Definition and Maintenance in Inventory

Item Definition and Maintenance

Items in the business are the goods in which the business deals or which are used for producing the finished goods that the business produces.

Item is a part or service is what the business

       ·         Buys

       ·         Sells

       ·         Plans

       ·         Manufactures

       ·         Stocks

Item definition

When defining an item from oracle the user needs to perform the below steps

       1.       Copy the item or template

       2.       Copy the item attributes

       3.       Assign items to child organizations

       4.       Specify org level item attributes

       5.       Define item costs

Item Master Organization is the logical entity that is used to define the items. Any item defined in the system needs to be defined in the master organization and then assigned to the child organizations

Item Attributes are the characteristics that define the different properties of the item and the operations that can be performed on it. Some of the item attributes are:

        ·         Purchasable

        ·         Orderable

        ·         Transactable

        ·         BOM Allowed etc

These item attributes specify what operations can be performed on the item for e.g.: Web Orderable : this attribute specifies if the item can be ordered by the customer over the web

Item Template: All the items in the business have many attributes which might be the same across different items, thus when defining these items the business user will have to check/set all these attributes to ensure that the attributes are set correctly , this means a lot of manual effort given the number of items to be defined is very large. Thus oracle has given a functionality called item templates. An item template is allows the users to specify a set of attributes which are to be set for the items to be defined in the system, thus when defining an item the user can select an item template and Oracle system will assign all the attributes to the item which are defined in the item template.

Item Status: When an item is defined or for defined items there is an item status. The  item status defines the current status of an item if the item is currently active or inactive.

Item Categories and Category sets

A category is a logical classification of items that have similar characteristics

 A Category set is a distinct grouping scheme and consists of categories

 Users can define an unlimited number of categories and group subsets of your categories into category sets

 A category can belong to multiple category sets

Item Org Assignment: When an item is defined the item is always defined in the item master organization. Once the item is defined in the item master org , it needs to be assigned to the child organization.  Once the item is defined to be transacted in the system it needs to be assigned to the child organizations from where all the business transactions take place

Overview of Oracle Inventory

Overview of Oracle Inventory

Inventory in a business manages all the goods/entities in which the business deals and keeps a track of the goods. In this post we will se a high level overview of the Oracle inventory and in the succeeding posts we will cover the topics in greater detail.

The basic cycle in the Inventory is:

·         Receipt of Goods when it arrives

·         Transfer of goods within the organization

·         Issue the goods when a sale is made

Main Capabilities of Inventory

1.       Defined items

2.       Assign part numbers

3.       Define the inventory organization structure

4.       Material Tracking

5.       Plan material replenishments

6.       Material Issue

7.       Material Receiving

8.       Track material manufacturing

We will have a quick overview of the different functionalities :

1.       Define items: A business involved in the manufacture or sale of products needs to define the items/goods that it will be dealing in. Inventory module of Oracle is responsible for defining the items and its properties

2.       Assign Part Numbers: Once the items are defined they need to be identified  in the system across the other modules too , Inventory will assign the part numbers to the items for by other modules too

3.       Inventory Organization Structure : Depending on the business setup the inventory structure of the business might be defined into Operating units, Inventory Orgs, Sub-inventory , locators etc. This activity is performed by the inventory module of Oracle

4.       Material Tracking: The business needs to keep a track of all the business items ie what is the currently availability in the business for transactions , where is the inventory available in the business for effective business processing. The inventory module keeps a track of all the items a, their availability and locations in the organization

5.       Material Replenishment: The business will need to produce the goods it deals in or the raw materials for continual supply . Inventory module will perform the material requirement planning to effectively plan material replenishment

6.       Material Issue: Once the business sells the goods they need to be issued from the warehouse to be shipped to the customer. The inventory module will handle the issue of goods from the warehouse to be delivered to the customer

Material Issue can be perfumed by the business for a number of reasons:

                    I.            Sale of Goods to customer

                  II.            Internal sale of goods

                III.            Return of defective goods

                IV.            Component Issue

                  V.            Inter Organization Transfers

                VI.            Sub-inventory transfers

              VII.            User defined Issue

7.       Material Receipt: There are instances when the goods will come into the inventory , the inventory module is responsible for keeping a track of all the receiving/goods coming into the inventory

Material Receipt in the inventory can happen for a number of reasons:

                                I.            Purchase Order Receipts

                              II.            Assembly Returns

                            III.            Return Sales Orders

                            IV.            Component Returns

                              V.            User defined return

                            VI.            Inter Organization transfers

Inventory Transfer to GL

As a part of reconciliation with GL the inventory details are transferred to General Ledger. Oracle has provided the users with a standard program: Transfer Transactions to GL which can be used to transfer the inventory information to general ledger.

On running this program all the accounting information in the INV module is transferred to General Ledger. The Program picks up all the records from the table mtl_transaction_accounts having gl_batch_id = -1 for the entered program parameters and transfers them to gl interface.

The Program is generally run as a part of period end process when account reconciliations need to be done.

Like the other modules when the request is run all the accounting information is transferred to GL Interface. Users can subsequently run the Journal Import and Journal Posting Programs to create journals and post them into Ledger.

When submitting the Inventory Transfer to GL Program the user has an option of transferring the information at a summary level or detailed level

Summary: The accounting information of the relevant transactions are summarized and                summary information is transferred, as summary information is being transferred the process is faster and takes less time.

Detail: In case of detail a detailed information is transferred. Detailed accounting records are created for each transaction of Inventory. As the mode since , since detailed transactions are created for individual Inventory transactions the process is more time consuming and thus processing times are higher.

If none is selected, no transfer of accounting information to GL is done for this organization.

The Program is generally run as a part of period closing , however we can perform the general ledger transfer at any time during an open period--not just at period close. The transfer loads summary or detail accounting activity for any open period into the general ledger interface, including both inventory and work in process entries. When more than one period is open, the transfer selects transactions from the first open period up to the entered transfer date, and passes the correct accounting date and financial information into the general ledger interface.

As we have mentioned the Program picks up the relevant records from the table mtl_transaction accounts having a gl_batch_id = -1, When the transactions are passed to the gl_interface it is at this time that the batch is given it’s proper batch number. This is used to overwrite the gl_batch_id and update it.

AP to GL Transfer (Payables Transfer to General Ledger )

Accounts Payable Module in Oracle is concerned with the creation of Payables Invoices, Making payments, bill payments, and expenses and performing other financial activities related to all the expenditures and liabilities of an organization. This is a sub-ledger module in Oracle and all the data recorded in this module need to be transferred into General Ledger so that these are reflected in the financial statements of the organization. Any data which is not transferred to General Ledger will not be reflected in the financial statements. Oracle has provided a standard Program: Payables Transfer to General Ledger to Transfer the Data from AP to GL.

This Program when run in Oracle will transfer all the eligible records from AP to General Ledger. On the Invoices front once the invoices have been created in the system, Validated and Accounted for we run the Payables transfer to General Ledger Program to transfer the invoice details to General Ledger.

When the payable accounting entries are created, then run the program called 'Payables Transfer to GL' Program. Which sends the invoice entries and payable entries to GL  interface .Then submit a request called Journal import to import journal entries to GL

After transferring the data to General Ledger Payables retains the accounting entries, so you can continue to review them in Payables. Also, after you post journal entries in Oracle General Ledger, you can drill down to the related accounting entries or transactions in Payables.

Before Submitting the Payables transfer to General Ledger Program the user needs to ensure that certain prerequisites are met:

1.       The Period of which data is being transferred to general ledger must be open

2.       The Invoices which are to be transferred to General Ledger must be validated and accounted.

Payables Transfer to General Ledger Program takes a number of parameters as input. The values of these parameters determine what activities will be performed by the program.

The Parameters taken in by the Program are discussed below:

1.       Set of Books Name: Specifies the set of books for which the user wishes to transfer the data to general ledger. If you do not define a secondary set of books in the Payables Options window, Payables automatically enters the name of your primary set of books and you cannot change the default. If we have defined a primary and reporting set of books then payables will display Both as the default meaning that an entry will be created for both the set of books , In case the user wishes to perform transfer for a given set of books he needs to change the value manually.

2.       Transfer Reporting books : When transferring the data should the data be posted in the reporting set of books also

3.       Batch Name: When the data is transferred to General Ledger Oracle will create a journal batch for these records. The Batch name specified here will be used when creating a batch in general ledger so that the user can easily identify their payables batch in general ledger. If no batch name is specified General Ledger uses the journal source, request id , the Actual Flag (A, B, or E for actual, budget, or encumbrance), and Group ID to automatically create a name for your journal entry batch . In case the user supplies a batch name this batch name will be appended to the oracle generated batch name.

4.       From Date: Payables will transfer all the eligible records having GL date on or after this date.

5.       To Date: Payables will transfer all the eligible records having GL date on or before this date.

6.       Journal Entry Category: We can select from the LOV

a.       Invoices: This will transfer only the eligible invoices to general ledger

b.      Payments: Payables transfers journal entry information for the payments.

c.       All: Payables will transfer the journal information of both , Invoices and Payments .

7.       Validate Accounts: When transferring the records from Payables to General Ledger if the parameter value is ‘YES’ Oracle will check for the validity of the accounts in general ledger and ensure that these accounts are active in GL , If the user selects a value ‘NO’ , the data will be simply transferred to General Ledger and the account validation will be done In the General Ledger Module later

8.       Transfer to GL Interface: This parameter is used to specify whether we wish to transfer summarized or detailed accounting entry lines. Even if the user chooses summary he still has the option to drill down from General Ledger to individual transactions in Payables.

a.       In Detail: Do not summarize the entries. Transfer one accounting entry for each accounting entry.

b.      Summarize by Accounting Date: Summarize the accounting lines by account and date.

c.       Summarize by Accounting Period: Summarize the accounting lines by account and accounting              period.

9.       Submit Journal Import: This parameter specifies if Oracle should run Journal Import after Transferring data into the GL Interface.

a.       YES : Once the data has been transferred to GL Interface , Oracle will also run the Journal Import to create Journals for the transferred records

b.      NO  : Do not submit the Journal Import , the data will be available in the GL Interface for user reference.

Even After transferring the data to General Ledger the AR module will still retain all the entries that have been transferred and can be used by for future reference.

How to Identify the Invoices that are transferred to GL Interface ?

 Oracle has provided us with 2 columns : GL_SL_LINK_ID and GL_SL_LINK_TABLE

GL_SL_LINK_TABLE: value is APECL for Payables actuals, and APENCL for Payables encumbrances.

GL_SL_LINK_ID: value is a unique, sequential number

User can use this combination to fetch the details of the transaction which has been transferred to GL

Below is list of the reference columns from Oracle site which get populated when the Payables data is transferred to GL Interface.

When you do a transfer in details , these information get populated in GL_Interface.

Purchase Invoices: Records for the Purchase Invoices journal category debit the Expense account (including exchange rate variance and invoice price variance accounting entries), and credit the Liability account.

·         Reference21: supplier name

·         Reference22: invoice ID

·         Reference23: distribution line number

·         Reference25: invoice number

·         Reference26: AP Invoices

·         Reference27: set of books ID

·         Reference30: type of account charged: Liability or Expense

Payments: Records for the Payments journal category debit the Liability account, credit the Cash account, and are charged to the Discount, Realized Gain/Loss, Future Payment, and Rounding accounts.

USER_JE_CATEGORY_NAME: Payments
USER_JE_SOURCE_NAME : Payables

·         Reference21: supplier name

·         Reference22: invoice ID

·         Reference23: check ID

·         Reference24: check number

·         Reference25: Paid invoice number

·         Reference26: AP Payments

·         Reference27: set of books ID

·         Reference28: invoice distribution line number

·         Reference29: invoice payment ID

·         Reference30: account charged: Liability, Cash, Discount, Exchange Gain, Exchange Loss, Future Pay, or Rounding

Reconciled Payments: Records for the Reconciled Payments journal category are charged to the Cash Clearing and Reconciliation Accounting accounts. The Payables Transfer to General Ledger program populates GL Interface reference columns with reconciled payment information as follows:

·         Reference21: supplier name

·         Reference23: check ID

·         Reference24: check number

·         Reference26: AP Reconciled Payments

·         Reference27: set of books ID

·         Reference30: account charged: Cash, Cash Clearing, Charges, Errors, Exchange Gain, Exchange Loss, or Rounding

AP to GL transfer process is required for transferring all the AP data to GL so that financial reports can be prepared for all the expected revenue, receivables for the business.

AR to GL Transfer (General Ledger Transfer Program)

AR to GL Transfer is a process which is concerned with the transfer to data from A to the GL Module.

The General Ledger Transfer Program is a standard spawned program provided by Oracle to transfer the data from AR to GL. The program picks up all the eligible records and transfers them to the gl_interface. All the transactions that have been accounted and are complete, and have not been transferred to GL will be picked up.

When submitting the program to transfer the records to GL form AR user can determine the transactions to be transferred by specifying a General Ledger Date Range when submitting the Interface Program. The user specifies a GL date that Receivables will use to select the transactions for posting.

When you run General Ledger Interface, Receivables transfers transaction data into the GL_INTERFACE table and generates the Posting Execution Report. This report provides the list of transactions make up the entries to the general ledger.

Note: If you are using the Oracle Applications Multiple Reporting Currencies (MRC) feature, you must run the General Ledger Interface program for your primary set of books and each of your reporting set of books

The General Ledger Transfer Program consists of a number of Parameters some of which are discussed below:

Post in Summary:

When the user runs the General Ledger Transfer Program he has the option of choosing a parameter to perform a Summarized or Detailed Transfer

Choose a Posting Detail of Summary or Detail.

This controls how Receivables creates journal entries for your transactions in the interface table.

• If you select Detail(No), then the General Ledger Interface program creates at least one journal entry in the interface table for each transaction in your posting submission.

• If you select Summary(Yes), then the program creates one journal entry for each general ledger account.

Run Journal Import: If the user selects a value = ‘YES’ Oracle will submit the Journal Import process and create Journals for the transferred records. If the user selects the parameter to be ‘NO’ Oracle will not submit the Journal Import Program and the user will be able to see the data in the GL Interface.   

When Submitting the General Ledger Transfer Program Oracle will also check if all the submitted code combinations are valid or not. In case there are any code combinations which are inactive or invalid in GL the Program will report it to the user and process the remaining records.

How to Identify if a record is transferred to GL: Once a transaction has been transferred to General Ledger the user must be abe to identify that the transactions have been transferred to GL. In order to enable the user to find out these details Oracle has specified a field: POSTING_CONTROL_ID in the table : ra_cust_trx_line_gl_dist , If the value of the columns is -3 it means that the record has not been transferred to GL.

RA_CUST_TRX_LINE_GL_DIST_ALL: POSTING_CONTROL_ID NOT NULL Receivables posting batch identifier:

–1 means the record was posted by the old posting program (ARXGLP);

–2 means it was posted from old Release 8 Revenue Accounting;

–3 means it was not posted;

–4 means it was posted by the Release 9 RAPOST program.

How to identify a transaction which has been transferred to General Ledger?

The import puts rows into gl_import references REFERENCE21 to REFERENCE30

If the journal is imported in detail these are added to REFERENCE1 to REFERENCE10 in GL_JE_LINES. In summary mode the references map from there to GL_IMPORT_REFERENCES as there is no 1 to 1 relationship between the lines in gl and there source references.

Below is list from Oracle on which reference fields are populated with what values depending on the transaction category.

If you are customizing it should be note that these are subject to change without warning or notice.

USER_JE_CATEGORY_NAME = Adjustment

Reference21 : POSTING_CONTROL_ID
Reference22 : AR_ADJUSTMENTS.ADJUSTMENT_ID
Reference23 : AR_DISTRIBUTIONS.LINE_ID
Reference24 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference25 : AR_ADJUSTMENTS.ADJUSTMENT_NUMBER
Reference26 : RA_CUST_TRX_TYPES.TYPE
Reference27 : RA_CUSTOMER_TRX.BILL_TO_CUSTOMER_ID
Reference28 : 'ADJ'
Reference29 : 'ADJ_'||AR_DISTRIBUTIONS.SOURCE_TYPE
Reference30 : 'AR_ADJUSTMENTS'

USER_JE_CATEGORY_NAME = Sales Invoice

Reference21 : POSTING_CONTROL_ID
Reference22 : RA_CUSTOMER_TRX.CUSTOMER_TRX_ID
Reference23 : RA_CUST_TRX_LINE_GL_DIST.CUST_TRX_LINE_GL_DIST_ID
Reference24 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference25 : HZ_CUST_ACCOUNTS.ACCOUNT_NUMBER
Reference26 : 'CUSTOMER'
Reference27 : RA_CUSTOMER_TRX.BILL_TO_CUSTOMER_ID
Reference28 : 'INV'
Reference29 : 'INV_'||RA_CUST_TRX_LINE_GL_DIST.ACCOUNT_CLASS
Reference30 : 'RA_CUST_TRX_LINE_GL_DIST'

USER_JE_CATEGORY_NAME = Credit Memo

Reference21 : POSTING_CONTROL_ID
Reference22 : RA_CUSTOMER_TRX.CUSTOMER_TRX_ID
Reference23 : RA_CUST_TRX_LINE_GL_DIST.CUST_TRX_LINE_GL_DIST_ID
Reference24 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference25 : HZ_CUST_ACCOUNTS.ACCOUNT_NUMBER
Reference26 : 'CUSTOMER'
Reference27 : RA_CUSTOMER_TRX.BILL_TO_CUSTOMER_ID
Reference28 : 'CM'
Reference29 : 'CM_'||RA_CUST_TRX_LINE_GL_DIST.ACCOUNT_CLASS
Reference30 : 'RA_CUST_TRX_LINE_GL_DIST'

USER_JE_CATEGORY_NAME = Debit Memo

Reference21 : POSTING_CONTROL_ID
Reference22 : RA_CUSTOMER_TRX.CUSTOMER_TRX_ID
Reference23 : RA_CUST_TRX_LINE_GL_DIST.CUST_TRX_LINE_GL_DIST_ID
Reference24 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference25 : HZ_CUST_ACCOUNTS.ACCOUNT_NUMBER
Reference26 : 'CUSTOMER'
Reference27 : RA_CUSTOMER_TRX.BILL_TO_CUSTOMER_ID
Reference28 : 'DM'
Reference29 : 'DM_'||RA_CUST_TRX_LINE_GL_DIST.ACCOUNT_CLASS
Reference30 : 'RA_CUST_TRX_LINE_GL_DIST'

USER_JE_CATEGORY_NAME = Chargeback

Reference21 : POSTING_CONTROL_ID
Reference22 : RA_CUSTOMER_TRX.CUSTOMER_TRX_ID
Reference23 : RA_CUST_TRX_LINE_GL_DIST.CUST_TRX_LINE_GL_DIST_ID
Reference24 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference25 : HZ_CUST_ACCOUNTS.ACCOUNT_NUMBER
Reference26 : 'CUSTOMER'
Reference27 : RA_CUSTOMER_TRX.BILL_TO_CUSTOMER_ID
Reference28 : 'CB'
Reference29 : 'CB_'||RA_CUST_TRX_LINE_GL_DIST.ACCOUNT_CLASS
Reference30 : 'RA_CUST_TRX_LINE_GL_DIST'

USER_JE_CATEGORY_NAME = Receipts

Receipts Journal
Reference21 : POSTING_CONTROL_ID
Reference22 : AR_CASH_RECEIPTS.CASH_RECEIPT_ID||'C'
||AR_CASH_RECEIPT_HISTORY_ALL.CASH_RECEIPT_HISTORY_ID
Reference23 : AR_DISTRIBUTIONS.LINE_ID
Reference24 : AR_CASH_RECEIPTS.RECEIPT_NUMBER
Reference25 : Null
Reference26 : Null
Reference27 : AR_CASH_RECEIPTS.PAY_FROM_CUSTOMER
Reference28 : 'TRADE'
Reference29 : 'TRADE_'|| AR_DISTRIBUTIONS.SOURCE_TYPE
Reference30 : 'AR_CASH_RECEIPT_HISTORY'

Application Journal
Reference21 : POSTING_CONTROL_ID
Reference22 : AR_CASH_RECEIPTS_ALL.CASH_RECEIPT_ID||'C'
||AR_RECEIVABLE_APPLICATIONS_ALL.RECEIVABLE_APPLICATION_ID
Reference23 : AR_DISTRIBUTIONS.LINE_ID
Reference24 : AR_CASH_RECEIPTS.RECIPT_NUMBER
Reference25 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference26 : RA_CUST_TRX_TYPES.TYPE
Reference27 : AR_CASH_RECEIPTS.PAY_FROM_CUSTOMER
Reference28 : 'TRADE' or 'CCURR'
Reference29 : 'TRADE_' or 'CCURR_'|| AR_DISTRIBUTIONS.SOURCE_TYPE
Reference30 : 'AR_RECEIVABLE_APPLICATIONS'

USER_JE_CATEGORY_NAME = Misc Receipts

Header
Reference21 : POSTING_CONTROL_ID
Reference22 : AR_CASH_RECEIPTS.CASH_RECEIPT_ID
Reference23 : AR_DISTRIBUTIONS.LINE_ID
Reference24 : AR_CASH_RECEIPTS.RECEIPT_NUMBER
Reference25 : AR_CASH_RECEIPT_HISTORY.CASH_RECEIPT_HISTORY_ID
Reference26 : Null
Reference27 : AR_CASH_RECEIPTS.PAY_FROM_CUSTOMER
Reference28 : 'MISC'
Reference29 : 'MISC_' || AR_DISTRIBUTIONS.SOURCE_TYPE
Reference30 : 'AR_CASH_RECEIPT_HISTORY'

Distributions
Reference21 : POSTING_CONTROL_ID
Reference22 : AR_CASH_RECEIPTS_ALL.CASH_RECEIPT_ID
Reference23 : AR_DISTRIBUTIONS_ALL.LINE_ID
Reference24 : AR_CASH_RECEIPTS_ALL.RECEIPT_NUMBER
Reference25 : AR_MISC_CASH_DISTRIBUTIONS_ALL.MISC_CASH_DISTRIBUTION_ID
Reference26 : null
Reference27 : null
Reference28 : 'MISC'
Reference29 : 'MISC_'AR_DISTRIBUTIONS.SOURCE_TYPE
Reference30 : 'AR_MISC_CASH_DISTRIBUTIONS'

USER_JE_CATEGORY_NAME = Credit Memo Application

Reference21 : POSTING_CONTROL_ID
Reference22 : AR_RECEIVABLES_APPLICATIONS.RECEIVABLE_APPLICATION_ID
Reference23 : AR_DISTRIBUTIONS_ALL.LINE_ID
Reference24 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference25 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference26 : RA_CUST_TRX_TYPES.TYPE
Reference27 : RA_CUSTOMER_TRX.BILL_TO_CUSTOMER_ID
Reference28 : 'CMAPP'
Reference29 : 'CMAPP_'||AR_DISTRIBUTIONS.SOURCE_TYPE
Reference30 : 'AR_RECEIVABLE_APPLICATIONS'

USER_JE_CATEGORY_NAME = Bills Receivable

Reference21 : POSTING_CONTROL_ID
Reference22 : AR_TRANSACTION_HISTORY.TRANSACTION_HISTORY_ID
Reference23 : AR_DISTRIBUTIONS.LINE_ID
Reference24 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference25 : AR_TRANSACTION_HISTORY.CUSTOMER_TRX_ID
Reference26 : RA_CUST_TRX_TYPES.TYPE
Reference27 : RA_CUSTOMER_TRX.DRAWEE_ID
Reference28 : 'BR'
Reference29 : 'BR_'||AR_DISTRIBUTIONS.SOURCE_TYPE
Reference30 : 'AR_TRANSACTION_HISTORY'

Upon running the Program the data will be interfaced to the GL Module in the table GL Interface where the user can identify any of the transferred record using the above references.

Even After transferring the data to General Ledger the AR module will still retain all the entries that have been transferred and can be used by for future reference

AR to GL transfer process is required for transferring all the AR data to GL so that financial reports can be prepared for all the expected revenue, receivables for the business.