Oracle e-Business Financial

Mahmoud Elemam – blog

  • Administrator:

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 565 other subscribers
  • Mahmoud Elemam

  • Author

  • Calendar

    May 2024
    S S M T W T F
     123
    45678910
    11121314151617
    18192021222324
    25262728293031
  • Blog Stats

    • 608,930 hits

Archive for the ‘Oracle Purchasing’ Category

White Paper on Integration of Payables with Assets, Projects, Purchasing, Property Manager, Grants Accounting, and Inventory

Posted by Mahmoud Elemam on July 18, 2016

White Paper on Integration of Payables with Assets, Projects, Purchasing, Property Manager, Grants Accounting, and Inventory

IntegrationPayables

Posted in Accounts Payables, Asset, General Ledger, Oracle E-Business Applications, Oracle Financial, Oracle Inventory, Oracle Purchasing, Property Manager | Leave a Comment »

Year End Encumbrance Carry-Forward Process

Posted by Mahmoud Elemam on March 28, 2013

Before year-end carry forward of encumbrance followings will be carried out;

  1. Post outstanding encumbrance journal entries in Oracle GL.
  2. Post outstanding budget journal entries in Oracle GL.
  3. Post outstanding actual journal entries in Oracle GL.

For Year-End Carry Forward of encumbrance following tasks will be carried out;

  1. Run “Encumbrance Details Report” in Oracle Purchasing to review Purchase Orders and Purchase Requisitions against encumbrances.
  2. Run Program creates journals.
  3. Post encumbrance journal entries.
  4. Run Encumbrance Trial Balance for audit trail of encumbrance before year-end carry forward in Oracle GL.
  5. Run “Open Encumbrance Balance with Transaction Detail Report” to create an audit trail of encumbrance balances in Oracle GL.
  6. Close the last period of the current fiscal year.
  7. Open the first period of the next fiscal year.
  8. Open the next encumbrance year.
  9. Open the next budget year.
  10. Run “Year-End Carry Forward” with preview option set to YES in Oracle GL.
  11. Review the “Carry Forward Report” showing proposed carry forward accounts and amounts.
  12. Run Year-End Carry Forward with preview option set to NO.
  13. Review the Carry Forward Report with the updated balances.
  14. Run Encumbrance Trial Balance to review the year-end carry forward balances.

Posted in General Ledger, Oracle E-Business Applications, Oracle Financial, Oracle Purchasing | 5 Comments »

How Subledger Accounting Event Classes Map to Inventory, Purchasing, and Cost Management Module Transactions

Posted by Mahmoud Elemam on May 29, 2012

 

In Cost Management module, we have 31 event classes that can be divided into four categories.  The categories are material related, receiving related, work-order related, and write-off related.

Material Related Events

The material related events are based on transactions that can affect one or more of the following: an inventory item’s on-hand quantity, the inventory item’s value, or the inventory item’s item accounting.  The flow from the creation of the material transaction to the Subledger accounting has four steps.  The first step is the creation of the material transactions.  This step can be accomplished by using a form, by running a program or workflow, or by running an API.  In the second step of the flow, the Oracle Inventory module records material transactions in the Material Transaction form.  After the material transaction is recorded, the Cost Manager program performs the third step and calculates the cost and assigns the default accounting.  After the material transactions is costed and is assigned default accounting, the Create Accounting program creates the Subledger accounting entries.

 

Subledger Event Class Transaction Entry Form or Program
Consigned Inventory Ownership Transfer Consigned Transactions
Direct Interorg Receipt Inter-organiztional Transfer
Direct Interorg Shipment Inter-organiztional Transfer
Recipient-side Intransit Interorg Receipt for FOB Receipt Receipt (internal order when the shipping network FOB terms = receipt)
Sender-side Intransit Interorg Receipt for FOB Receipt Receipt (internal order when the shipping network FOB terms = receipt)
Intransit Interorg Shipment for FOB Receipt Shipping  (internal order when the shipping network FOB terms = receipt)
Intransit Interorg Receipt for FOB Shipment Receipt (internal order when the shipping network FOB terms = shipment)
Recipient-side Intransit Interorg Shipment for FOB Shipment Shipping (internal order when the shipping network FOB terms = shipment)
Sender-side Intransit Interorg Shipment for FOB Shipment Shipping (internal order when the shipping network FOB terms = shipment)
Intraorg Transfer Subinventory Transfer
Internal Order to Expense Shipping (internal order when the item is an expense item)
Logical Intercompany Shipping or Receipt when intercompany transfer requires accounting entry but doesn’t require physical movement
WIP Material Lot WIP Material Transactions
Miscellaneous Miscellaneous Transactions
Material Cost Update Average Cost Update, Standard Cost Update
PO Delivery into Inventory Receipt (Receiving into an Asset Subinventory)
Retroactive Price Adjustment Retroactive Price Update on Purchasing Documents
Sales Order Issue Shipping (Ship confirm external 

sales order)

User Defined Inventory Transaction Class Based on transaction setups
WIP Material WIP Material Transactions

Receiving Related Events

The receiving related events are based on transactions that affect the cost of a receipt, the accounting for the accrual of the receipt, and the initial accounting of the receipt from the supplier.

Subledger Event Class Transaction Entry Form or Program
Delivery to Expense Destination Receipt (Receiving into Expense Subinventory)
Landed Cost Adjustment to Delivery TBD – New Module
Landed Cost Adjustment to Receipt TBD – New Module
Period End Accrual Period End Close Process
Receipt into Receiving Inspection Receipt
Retroactive Price Adjustment to Delivery Retroactive Price Update on Purchasing Documents
Retroactive Price Adjustment to Receipt Retroactive Price Update on Purchasing Documents

Work-in-Process Related Events

The work-in-process related events are based on transactions that affect the value of the assembly as it moves through production.

Subledger Event Class Transaction Entry Form or Program
WIP Absorption Move Transactions
Outside Processing Receipt (Outside Processing PO)
WIP Variance Close Discrete Jobs, Period End Close for non-standard jobs
WIP Cost Update Average Cost Update, Standard Cost Update
WIP Lot Completion Transactions

Write-Off Events

The work-in-process related event uses the transactions generated from the Accrual Write-Off process.

Posted in Oracle Cost Management, Oracle E-Business Applications, Oracle Financial, Oracle Inventory, Oracle Purchasing | Tagged: | 1 Comment »

How to Adjust Average Cost with Invoice Price Variances (IPV)

Posted by Mahmoud Elemam on May 29, 2012

 

If you want to get your inventory cost, and ultimately your cost of goods, to reflect the actual cost you paid for your items, then you will want to interface the Invoice Price Variance (IPV) from Oracle Payables to Oracle Inventory/Cost Management.  The ability to perform this update of inventory cost is only for inventory organizations using the average cost costing method.  To understand this process, let’s look at the flow of cost from PO receipt to Transfer of Invoice Variances.  Here’s an overview of each step:

1.       Create and approve a PO

2.       Receive the item

3.       Enter and match an AP invoice (release any holds if necessary)

4.       Generate accounting for the AP invoice

5.       Transfer invoice variances to Inventory

Step 2 in the process (PO receipt) sets the initial average cost.  This cost will be used on all issues or shipments out of inventory.  Remember in average costing, we receive at PO price and issue out at average.

Once steps 3 (enter and match an AP invoice) and 4 (generate accounting) are complete, we are ready to run the Transfer Invoice Variance to Inventory program.  You can run the program from Cost Management for one inventory organization at a time.  This program will sum the difference between the invoice price and the PO price for each item/organization combination and then create an average cost update transaction.  This transaction will have an amount but not a quantity.  This amount is then applied to the remaining inventory on-hand.  So let’s look at a couple of examples and how your average cost will change.

Example 1:

  • PO Price $10
  • Receipt Quantity 100
  • Invoice Price $12
  • On-Hand 100
  • Beginning Average Cost $10
  • Ending Average Cost $12

In this example, we will apply the IPV of $2 to all 100 units in inventory.  So the average cost before the IPV transfer is $10 and the average cost after the IPV transfer is $12.  This would correctly value our inventory at actual cost.

Example 2:

  • PO Price $10
  • Receipt Quantity 100
  • Invoice Price $12
  • On-Hand 10 (sold 90 units)
  • Beginning Average Cost $10
  • Ending Average Cost $30  (($200/10) + $10 = $30

In this example, we will apply the IPV of $2 to remaining 20 units in inventory.  So the average cost before the IPV transfer is $10 and the average cost after the IPV transfer is $30.  This would result in lower margins the next time we sell and ship this item.

Example 3:

  • PO Price $10
  • Receipt Quantity 100
  • Invoice Price $12
  • On-Hand 0 (sold 100 units)
  • Beginning Average Cost $10
  • Ending Average Cost $10

In this example, we wouldn’t apply the IPV of $2 because the on-hand quantity is zero.  So the average cost before the IPV transfer is $10 and the average cost after the IPV transfer would also be $10.

Posted in Accounts Payables, Oracle Cost Management, Oracle E-Business Applications, Oracle Financial, Oracle Inventory, Oracle Purchasing | 9 Comments »

Impact of R12 Design in Procure To Pay Accounting Flow

Posted by Mahmoud Elemam on December 30, 2011

Impact of R12 Design in Procure To Pay Accounting Flow

Basic Changes

Functional design

1. Set Of Books is replaced by the term Ledger.

2. Accounting entries for transactions happening in all the applications such as Purchasing,Cost Management,Payables will go to General Ledger through a common module called “Subledger Accounting (SLA)” which is introduced in R12 and accounting entries can be viewed at SLA menu.

3. Accounting entries can be created manually at SLA level and can be transferred to General Ledger by running the program ‘Transfer to GL’.

4. SLA architecture gives the flexibility to derive the accounts for all transactions when it comes to SLA using Account Derivation Rules to meet various business needs and the accounting entries using those derived accounts can be transferred to General Ledger. Also it gives the flexibility to modify the accounting line types,balance types,conditions based on which the accounting gets generated for all the event classes.

5. SLA has the option to generate the accounting entries for respective subledgers in Draft mode or Final mode. Accounting entries can be created in Draft mode first in SLA which is a rough or draft entry to see whether the journal needs any modification in terms of account code or journal category. These draft entries will not get transferred to GL at any point of time. If any modification is required, it can be done using the features available in SLA and the accounting entries can be created in Final mode once the user feels that the journals do not need any modification. When the entries get created in Final mode in SLA, it will override the entries already created in Draft mode and these final mode entries alone will get transferred to GL.

5. The concept of Secondary Ledger has been introduced so that you can have two different accounting methods set at ledger level, for eg; Accrual basis accounting method for Primary ledger and Cash basis accounting method for Secondary ledger, and the ledgers can have different chart of accounts/currencies/calenders.  Actual and Encumbrance entries in the Procure to Pay cycle can be generated in secondary ledger also along with the entries in Primary ledger.

Technical design

1. The column set_of_books_id has been replaced with ledger_id in GL Tables

2. As a part of Subledger Accounting, new SLA tables XLA_AE_HEADERS, XLA_AE_LINES and XLA_DISTRIBUTION_LINKS have been introduced through which the accounting entries flow to GL.

3. PO details will not available in reference columns(reference_1,reference_2…) in tables GL_JE_LINES and GL_BC_PACKETS. Hence accounting entries in these tables can be retrieved only using SLA tables and GL_IMPORT_REFERENCES table.

4. Receiving Subledger/Inventory subledger/Payables subledger is not directly linked to table GL_JE_LINES,instead it is linked through the subledger tables XLA_AE_HEADERS, XLA_AE_LINES and XLA_DISTRIBUTION_LINKS.

5. XLA_AE_LINES table is mapped to GL_IMPORT_REFERENCES table with the gl_sl_link_id and gl_sl_link_table columns. The linking columns between GL_IMPORT_REFERENCES and GL_JE_LINES tables are je_header_id and je_line_num.

Setting up of Encumbrance

Defining the Subledger Accounting Method (SLAM) :

Navigation:

General Ledger>Set up>Financials>Accounting Set up Manager>Accounting Set ups
Query the ledger and you can find the option for setting up the Subledger Accounting Method

Subledger Accounting Method is having the option of

a) Standard Accrual
b) Encumbrance Accrual
c) Standard Cash
d) Encumbrance Cash

If Encumbrance needs to be enabled, then the Subledger Accounting Method has to be set as  “Encumbrance Accrual” in case of Accrual basis accounting method or “Encumbrance Cash” in case of cash basis accounting method for the ledger.
If Encumbrance is not used, then the Subledger Accounting Method has to be set as “Standard Accrual” or “Standard Cash” for the ledger.

Difference in Behavior between 11i and R12:

1. In 11i, Encumbrance related set ups include enabling the Budgetary control flag for the set of books, defining the Reserve for Encumbrance a/c, enabling the encumbrance for REQ,PO and INVOICE in Financial Options.
Where as in R12, Subledger Accounting Method has to be set for the ledger in addition to other set ups done in 11i. If it is set to “Standard Accrual”, Encumbrance cannot be used for that ledger even though the Encumbrance is enabled for the REQ,PO and INVOICE in Financial Options.

2. In 11i, there is an option to choose different encumbrance types for REQ,PO and INVOICE in Financial options but in R12, Financial options does not have the LOV to choose the encumbrance type. By default, Requisition encumbrance will be “Commitment”, PO encumbrance will be “Obligation” and invoice encumbrance will be “INVOICE”. If any of these 3 encumbrance types is not enabled in GL > Set up > Journal > Encumbrance, then the respective document REQ/PO/Invoice will throw budgetary control exception and will fail funds check.

Generation of Encumbrance Entries

Functional design

On Reserving and Approving the Requisition(PR)/Purchase Order(PO), Encumbrance amount gets reflected in Funds Inquiry screen and the encumbrance entries can be viewed in SLA menu in Purchasing module.

Navigation:
Purchasing>Accounting>SLA:User Main Menu>Accounting events
Query by transaction dates,ledger name and transaction number which is the PR/PO number

Following Accounting entries will be available in the HTML page

Budget a/c DR
Reserve For Encumbrance CR

There is an option to do funds check before taking the RESERVE and APPROVE action on the PR/PO by navigating to Tools > Check funds in Requisitions and Purchase Order forms to see the funds check behavior before approving the PR/PO. This funds check activity will create a draft entry in SLA and once the document is reserved, encumbrance entry will get created in Final mode overriding the draft entry already created for the “Check funds” action. If the funds check fails due to insufficient funds on taking the RESERVE action, entries will get created with Invalid status in SLA.

If Secondary ledger is associated to the primary ledger with the conversion level as ‘Subledger’ and if the secondary ledger is using encumbrance based SLAM, then encumbrance entries will get created in both primary subledger and secondary subledger on doing the RESERVE action on the PO.

The Concurrent Request “Transfer Journal Entries to GL” has to be submitted from Purchasing Responsibility to create the encumbrance entries in GL. On running this request, encumbrance entries created in Final mode alone will get transferred to GL.

Difference in Behavior between 11i and R12:

1. In 11i, encumbrance entries will get transferred to GL by running the concurrent program “Program-Create Journals” from GL responsibility. But in R12, “Transfer Journal Entries to GL” has to be submitted from Purchasing Responsibility to create the encumbrance entries in GL.

2. In 11i, it is not possible to view the encumbrance entries in Purchasing module, where as in R12, the entries can be viewed from SLA menu in Purchasing.

3. In 11i, a credit against the Reserve For Encumbrance a/c (RFE) can be seen only at the time of posting the Encumbrance debit entry in GL. But in R12, RFE a/c gets credited along with the budget a/c debit entry which can be viewed from SLA menu in Purchasing.

Technical design

On reserving and approving the PR/PO, encumbrance entries get generated in table GL_BC_PACKETS with column source_distribution_type as ‘PO_REQ_DISTRIBUTIONS_ALL’ for PR and ‘PO_DISTRIBUTIONS_ALL’ for PO and column source_distribution_id_num_1 as req distribution id for PR and po distribution id for PO.

Encumbrance entries will also get generated in the table PO_BC_DISTRIBUTIONS which has been newly introduced in R12. This table has the columns ‘reference4’ and ‘reference3’ columns where the PO/PR number and distribution id gets populated.
These accounting entries are also populated in the table XLA_AE_LINES. The table XLA_AE_HEADERS will show whether the encumbrance entry is created in Draft mode or Final mode or Invalid mode indicated by the column accounting_entry_status_code and it will also show whether the entry is transferred to GL or not indicated by the column gl_transfer_status_code.

The tables PO_BC_DISTRIBUTIONS and XLA_AE_HEADERS are linked with the column ‘event_id’.
The tables XLA_AE_HEADERS and GL_BC_PACKETS are linked with the column ‘ae_header_id’.
The tables XLA_AE_HEADERS and XLA_AE_LINES are linked with the column ‘ae_header_id’.

Once the entries are populated in GL and those entries are posted, records from the table GL_BC_PACKETS will get deleted but the entries in table PO_BC_DISTRIBUTIONS will remain always.

Difference in Behavior between 11i and R12:

In 11i, Encumbrance entries created in GL_BC_PACKETS will be directly moved to GL_JE_LINES by running the CJE program, whereas in R12, Encumbrance entries gets generated in a new table PO_BC_DISTRIBUTIONS and also in XLA tables in addition to GL_BC_PACKETS.

Receipt Accounting


As mentioned earlier, accounting entries for transactions happening in Receiving subledger and inventory subledger will flow to GL only through SLA which involves a new process called “Create Accounting process”.

Create Accounting process for Online Accruals

When purchase order is set to accrue at receipt, accounting entries get created in Receiving subledger once the receiving transactions are done. Then the Create Accounting process should take place to create journals in SLA accompanied by Transfer to GL process and posting which are optional. Users can choose whether they want the journal import and posting also to happen at the same time when the create accounting process is done or the Transfer to GL/Posting can be done explicitly. But if encumbrance is enabled, it is always preferred to do the Transfer to GL and Posting along with the create accounting process by having the values for parameters ‘Transfer to GL’ and ‘Posting in GL’ as YES while submitting the create accounting program. For more details on this, please refer to Note.728064.1. Another main implication of this model of doing the GL transfer and posting along with create accounting process is that, on failure of Journal Import, the data will be rolled back to SLA tables and hence there will not be any data in GL interface.

This Create Accounting Process involves two concurrent programs Create Accounting-Receiving which can be submitted from Purchasing>View Requests or from Cost Management Responsibility > SLA menu > Create Accounting and Create Accounting-Cost Management which can be submitted from Cost Management Responsibility > SLA menu. “Create Accounting – Receiving” only accounts for Expense destination PO Receipt. “Create Accounting – Cost Management” accounts for all transactions mentioned below.

– Expense destination PO Receipt
– All Inventory transactions including inventory destination POs
– WIP transactions
– Accrual Write Off transactions

Parameters used while submitting the Create Accounting concurrent program:

  • Ledger – Ledger (SOB) name to be given
  • End date – Accounting entries to be created for all receipts  TO DATE
    a) Draft – Draft mode creates the SLA journals as Draft which can be modified. Hence these entries will not get transferred to General Ledger and it will be available only in SLA. Once the entries created in Draft mode are verified and confirmed, Create Accounting program has to be run in Final mode and the entries getting created now will override the draft entries in SLA and will get transferred to General Ledger.
    b) Final – Final mode creates SLA journals which can not be modified and can be transferred to General Ledger.
  • Report – Options available are Detail or Summary
  • Transfer to General Ledger – Yes or No – If the mode is set to Final and the value for this parameter is set to No, then the accounting entries will get created only in SLA table and it will not be available in gl_interface or GL. You need to submit the program “Transfer to Gl” in Cost Management Responsibility > SLA to transfer the entries created in Final mode from SLA to General Ledger.
  • Post in General Ledger – Yes or No

  a) Online Accruals with Expense destination

Functional design

When the PO which is set to accrue at receipt is received and delivered to expense destination, Receipt Accounting happens in Receiving subledger. Then the Create Accounting process has to be submitted to generate the receipt accounting in SLA and GL.
This receipt accounting includes encumbrance reversal entries if the PO is encumbered, otherwise it just includes the actual entries. These entries can be viewed in SLA menu in Cost Management module.

Navigation:
Cost Management,SLA > SLA >SLA: Inquiry > Accounting event
Query by transaction dates and ledger name

Following Accounting entries will be available in the HTML page

AP Accrual a/c CR
Receiving Inspection a/c DR

Charge a/c DR
Receiving Inspection a/c CR

If encumbrance is enabled, encumbrance reversal also can be viewed as follows

Budget a/c CR
Reserve For Encumbrance DR

These entries can also be viewed from Receiving Transaction Summary > View Accounting.

In encumbrance enabled environment, once the receiving process is done, Create Accounting process and posting in GL has to be completed in order to get the encumbrance reversal and actuals to hit the GL funds inquiry simultaneously as the funds availability calculation in Funds Inquiry screen will consider the encumbrance reversal and actuals only when they are posted in GL.

Note: R12 SLA architecture does not have this design initially. This new design is introduced by a patch which is explained in more detail in Note.728064.1 to maintain accurate funds availability for the budget account at any point of time.

Technical design

When purchase order has Accrue on Receipt set to YES, Receiving Transaction Processor generates the accounting entries in RCV_RECEIVING_SUB_LEDGER upon Receipt and Deliver of the PO. Then the Create Accounting process should take place to create SLA journals which will insert records in XLA_AE_HEADERS, XLA_AE_LINES and XLA_DISTRIBUTION_LINKS. These accounting entries will be available in the table XLA_AE_LINES. The event type code in XLA_AE_HEADERS for this Encumbrance Reversal entry is DELIVER_EXPENSE and the event type code in XLA_AE_HEADERS for these actual entries will be RECEIVE for receipt accounting and DELIVER_EXPENSE for delivery accounting.
The tables RCV_RECEIVING_SUB_LEDGER and XLA_DISTRIBUTION_LINKS can be linked using the column source_distribution_id_num_1. The value of rcv_sub_ledger_id has to be given as source_distribution_id_num_1 for the source_distribution_type “RCV_RECEIVING_SUB_LEDGER” in XLA_DISTRIBUTION_LINKS table.

  b) Online Accruals with Inventory destination

Functional design

When the PO is received and delivered to inventory destination, Receipt Accounting happens in Receiving subledger and Deliver Accounting happens in inventory subledger. Then the Create Accounting process has to be submitted to generate the receipt accounting and deliver accounting in SLA and GL. This deliver accounting includes encumbrance reversal entries if the PO is encumbered, otherwise it just includes the actual entries.

View Accounting from Receiving Transaction Summary will show the accounting entries for RECEIVE transaction. To view the actual entries for DELIVER transaction, navigate to Material Distributions form which will show the accounting entries once the deliver transaction is costed. To view these actual entries and Encumbrance Reversal entries in SLA after create accounting process is done, navigate to

Cost Management Resp>SLA>Inquiry>Accounting event
Query by transaction dates and ledger name

Following Accounting entries will be available in the HTML page

AP Accrual a/c CR
Receiving Inspection a/c DR

Material Valuation a/c DR
Receiving Inspection a/c CR

If encumbrance is enabled, encumbrance reversal also can be viewed as follows provided the flag “Reverse encumbrance” is checked in organization parameters > Costing tab.

Budget a/c CR
Reserve For Encumbrance DR

In encumbrance enabled environment, once the receiving process is done, Create Accounting process and posting in GL has to be completed in order to get the encumbrance reversal and actuals to hit the GL funds inquiry simultaneously as the funds availability calculation in Funds Inquiry screen will consider the encumbrance reversal and actuals only when they are posted in GL.

Note: This design related to encumbrance reversal and actuals hitting the funds inquiry after posting is yet to be implemented which will be done soon as this design is restricted only to expense destination POs and not for inventory. As of now, for inventory destination POs, there is a limitation in funds availability calculation where encumbrance reversal hits the funds inquiry at the time of receipt and delivery where as actuals hits the funds inquiry only at the time of posting the actual entries in GL after the create accounting process. Therefore delaying the create accounting process will result in incorrect funds availability. This limitation will be overcome by introducing the same design for inventory destination which is already done for expense POs.

 Technical design

When purchase order has Accrue on Receipt set to YES and destination_type_code is set to Inventory, Receiving Transaction Processor generates the accounting entries in RCV_RECEIVING_SUB_LEDGER upon Receipt and Cost manager generates the accounting entries in MTL_TRANSACTION_ACCOUNTS upon Deliver of the PO. Then the Create Accounting process should take place to create SLA journals which will insert records in XLA_AE_HEADERS, XLA_AE_LINES and XLA_DISTRIBUTION_LINKS. These accounting entries will be available in the table XLA_AE_LINES. The event type code in XLA_AE_HEADERS for this Encumbrance Reversal entry is PO_DEL_INV and the event type code in XLA_AE_HEADERS for these actual entries will be RECEIVE for receipt accounting and PO_DEL_INV for delivery accounting.

The tables MTL_TRANSACTION_ACCOUNTS and XLA_DISTRIBUTION_LINKS can be linked using the column source_distribution_id_num_1. The value of  inv_sub_ledger_id has to be given as source_distribution_id_num_1 for the source_distribution_type “MTL_TRANSACTION_ACCOUNTS”.

Difference in Behavior between 11i and R12:

1. In 11i, Receiving Transaction Processor creates the Receipt Accounting entries in Receiving Subledger as well as in GL_INTERFACE. Journal Import will be done to transfer the entries to GL_JE_LINES where as in R12, Receiving Transaction Processor will create the entries only in Receiving Subledger. Create Accounting Program has to be run to create SLA journals which in turn will trigger the journal import.

2. In 11i, if encumbrance is enabled, encumbrance reversal and actuals will undergo funds check when these entries are populated in gl_interface and GL funds inquiry will reflect the encumbrance reversal and actuals even before posting the entries in GL. But in R12, encumbrance reversal and actuals will hit the GL funds inquiry only when these entries are posted in GL even though funds check happens in SLA itself.

  c) Create Accounting process for Period End Accruals

Functional design

When the PO which is set to accrue at period end is received and delivered to expense destination and Receipt Accruals Period End program is submitted, accounting entries get created in Receiving subledger during period end for the PO shipments which has the received quantity greater than billed quantity. Then the Create Accounting process has to be submitted to generate the receipt accounting in SLA and GL.

This create accounting process is accompanied by Subledger Multiperiod Accounting program which gets spawned automatically to generate the reversal for the accrual entries for the next period in SLA. Depending on the value for  the parameter “Transfer to GL” given while submitting the create accounting program, Journal import will happen and the accrual entries for the current period and next period will get transferred to GL.

Note: Since SLA does the accrual reversal automatically for the next period which gets transferred to GL, Auto Reversal feature available in GL should not be used in R12. Otherwise, it will result in duplication of accrual reversal entries in GL. To get more details on Auto-Reversal feature and its impact on Period end accruals in R12, please refer to Note.873399.1

During this create accounting process, it has to be ensured that the end date given while submitting the Create Accounting program is greater than or equal to the first date of the next period in which accrual reversal is supposed to happen. If the end date of Create Accounting program is less than the first date of the next period, accrual entries for the current period alone will get created in Final mode and will get transferred to GL, where as  the reversal entries will get created in SLA with status as ‘Incomplete’ and it is not eligible to get transferred to GL . To transfer the accrual reversal entries which got created with INCOMPLETE status from SLA to GL, it has to be final accounted in SLA first which can be done by running the program ‘Complete Multiperiod Accounting’ with end date which includes the first date of next period and then it can be transferred to GL. If the GL period is closed for the current period or for the next period, period end accrual entries and reversal entries will get created only in SLA. To transfer these entries to GL, the concurrent request “Transfer Journal entries to GL-Receiving” needs to be submitted after opening the GL period.

This receipt accounting includes encumbrance reversal entries if the PO is encumbered, otherwise it just includes the actual entries. These entries can be viewed in SLA menu in Cost Management module and it cannot be viewed from Receiving Transactions Summary > Tools > View Accounting.

Navigation:
Cost Management>SLA Resp>SLA>Inquiry>Journal entries
Query by transaction dates and ledger name

Following Accounting entries will be available in the HTML page

AP Accrual a/c CR
Charge a/c DR

If encumbrance is enabled, encumbrance reversal also can be viewed as follows

Budget a/c CR
Reserve For Encumbrance DR

for the period in which Receiving is done and for the next period,you can see the reversal entry as

AP Accrual a/c DR
Charge a/c CR

If encumbrance is enabled, encumbrance reversal also can be viewed as follows

Budget a/c DR
Reserve For Encumbrance CR

As mentioned for online accruals with Expense destination, in encumbrance enabled environment, once the receiving process is done, Create Accounting process and posting in GL has to be completed in order to get the encumbrance reversal and actuals to hit the GL funds inquiry simultaneously as the funds availability calculation in Funds Inquiry screen will consider the encumbrance reversal and actuals only when they are posted in GL.

Note: R12 SLA architecture does not have this design initially. This new design is introduced by a patch which is explained in more detail in Note.728064.1 to maintain accurate funds availability for the budget account at any point of time.

Encumbrance will get reversed from the PO once the invoice is validated.Encumbrance on the PO will get converted to Invoice encumbrance. On doing Create Accounting for the invoice, Encumbrance on the invoice will also get reversed. But this invoice encumbrance reversal and Actuals will get reflected in Funds Inquiry screen only when these entries are posted in GL.

Technical design

When Purchase Order has Accrue on Receipt flag set to NO, Receipt Accruals Period End program generates the accounting entries only in RCV_RECEIVING_SUB_LEDGER. Then the Create Accounting process should take place to create SLA journals which will insert records in XLA_AE_HEADERS, XLA_AE_LINES and XLA_DISTRIBUTION_LINKS. These accounting entries will be available in the table XLA_AE_LINES. The event type code in XLA_AE_HEADERS for this Encumbrance Reversal entry is PERIOD_END_ACCRUAL and the event type code in XLA_AE_HEADERS for these actual entries will be RECEIVE for receipt accounting and PERIOD_END_ACCRUAL for delivery accounting.
The tables RCV_RECEIVING_SUB_LEDGER and XLA_DISTRIBUTION_LINKS can be linked using the column source_distribution_id_num_1. The value of rcv_sub_ledger_id has to be given as source_distribution_id_num_1 for the source_distribution_type “RCV_RECEIVING_SUB_LEDGER” in XLA_DISTRIBUTION_LINKS table.

Difference in Behavior between 11i and R12:

1. In 11i, Receipt Accruals Period End program creates the Receipt Accounting entries in Receiving Subledger as well as in GL_INTERFACE. Journal Import will be done to transfer the entries to GL_JE_LINES where as in R12, Receipt Accruals Period End program will create the entries only in Receiving Subledger. Create Accounting Program will create SLA journals and ‘Transfer Journal entries to Gl’ program will move the entries to GL from SLA.

2. In 11i, Accrual entries need to be reversed manually in the next period whereas in R12, reversal of accrual entries for the next period will happen automatically

3. In 11i, if encumbrance is enabled, encumbrance reversal and actuals will undergo funds check when these entries are populated in gl_interface and GL funds inquiry will reflect the encumbrance reversal and actuals even before posting the entries in GL. But in R12, encumbrance reversal and actuals will hit the GL funds inquiry only when these entries are posted in GL even though funds check happens in SLA itself.

Impact of Secondary ledger on Create Accounting process (applicable for both Online accruals and Period end accruals)

If Secondary ledger is associated to the primary ledger with the conversion level as ‘Subledger’ and if the secondary ledger is using Accrual based SLAM (e.g Encumbrance Accrual/Standard Accrual), then encumbrance entries will get created in both primary subledger and secondary subledger on doing the Create Accounting process. On the other hand, if the Secondary ledger associated to the primary ledger is using Cash based SLAM (e.g Encumbrance Cash/Standard Cash) with the conversion level as ‘Subledger’, then the setup mentioned below is mandatory. Otherwise, Create Accounting process will error out or complete with warning and will not generate the receipt accounting entries neither in Primary ledger nor in Secondary ledger.

Setup to be done for Secondary ledger using Cash based SLAM:

1. Go into the responsibility: General Ledger
2. Navigate to MENUPATH > Set up > Financials > Accounting Setup Manager > query for Primary ledger > Update accounting options
3. Go to Secondary ledger > Subledger accounting options > Update > Search for the application Cost management > Update accounting options  > Set Sublegder accounting enabled to NO > Click on Apply
When the Secondary ledger is using Cash basis accounting, Accrual based accounting entries should not get generated for Receiving transactions for the secondary ledger. Hence Create Accounting process should not create accounting entries for the source Cost Management. Therefore it is recommended to do the above mentioned set up of disabling the Subledger Accounting for Cost management application for Secondary ledger.
Impact of Cash basis accounting on Create Accounting process (applicable for both Online accruals and Period end accruals)

When the Primary ledger itself is using Cash basis accounting, Accrual based accounting entries should not get generated for Receiving transactions for the Primary ledger. In such case, it is not required to run the programs ‘Create Accounting-Receiving’ or ‘Create Accounting-Cost Management’ as no accounting entries will be created by these programs.

 Impact of Periodic Average Costing on Create Accounting process (applicable for both Online accruals and Period end accruals) 

R12 SLA design has no impact when Periodic Average Costing (PAC) is used as it follows the same 11i approach. Accounting entries created in PAC will not go to SLA and it will not undergo the create accounting process. Instead it will get transferred to GL via gl_interface from PAC distributions . But the perpetual accounting entries will also happen along with PAC entries where the perpetual accounting will follow the SLA design. But those entries should not get imported from SLA to GL as PAC accounting will be transferred to GL. To restrict the GL import of perpetual accounting entries, “Transfer to GL” option in organization parameters should be set to None for organizations which use PAC so that xla_ae_headers for perpetual accounting will have the gl_transfer_status_code as “NT” and it will not be picked by the journal import process.

Accrual Reconciliation Process

a) Accrual Reconciliation Reports:
After completing  the Receipt transactions and Invoice matching, Create Accounting program has to be run in Final mode along with the  subsequent transfer of entries to General Ledger after which the  Accrual Reconciliation Process has to be started.

“Accrual Reconciliation Load Run” program has to be submitted with transaction date as the parameter which will populate the data in tables CST_RECONCILIATION_SUMMARY, CST_AP_PO_RECONCILIATION and CST_MISC_RECONCILIATION. Now run the Accrual Reconciliation Report for the operating unit and do the reconciliation. There are 3 different types of Accrual Reconciliation Report

1. AP and PO Accrual Reconciliation Report – This report shows the transaction details based on each accrual account for each PO distribution with the Receiving transaction amount and invoice transaction amount with a net balance greater than zero.

Parameters used while submitting the program:

Operating Unit – Select the Operating Unit for the report
Title – Enter your title for the report
Sort by – Parameter to specify how to sort the data at the distribution level – Valid Values – Age in days,Total Balance,Vendor,PO number (default)
Aging Period Days – The number of days by which to group transactions sorted in descending order
Item From and Item To – Range of items to consider for this report
Vendor From and Vendor To – Range of Vendors to consider for this report
Min Outstanding Balance and Max Outstanding Balance – Limits of distribution balance to dispaly
Balancing Segment From and Balancing Segment To – Range of balancing segment to consider for this report

2. Summary Accrual Reconciliation Report – This report shows the total balances for each accrual account without any distribution details and individual transaction amount and also shows whether that summarized accrual balance is related to AP PO transaction or AP no PO transaction or Miscellaneous Inventory transaction.
Parameters used while submitting the program:

Operating Unit – Select the Operating Unit for the report
Title – Enter your title for the report
Balancing Segment From and Balancing Segment To – Range of balancing segment to consider for this report

3. Miscellaneous Accrual Reconciliation Report – This report shows the transaction details based on each accrual account which got hit because of Miscellaneous Inventory transactions and AP NO PO transactions.Accrual amount will be displayed for each transaction along with the source whether it is INV or AP. This report picks data from CST_MISC_RECONCILIATION which gets populated during the load run process.

Parameters used while submitting the program:

Operating Unit – Select the Operating Unit for the report
Title – Enter your title for the report
Sort by – Parameter to specify how to sort the data at the distribution level – Valid Values – Item,Transaction Date (default) , Amount
Date From – Starting date of time period to display for this report
End Date – Ending date of time period to display for this report
Item From and Item To – Range of items to consider for this report
Min Amount and Max Amount – Limits of transaction amount to display
Balancing Segment From and Balancing Segment To – Range of balancing segment to consider for this report

Difference in Behavior between 11i and R12:

1. In 11i, the Accrual Rebuild Reconciliation Report  which was  required  to be run  to populate the accrual reconciliation table is now replaced by “Accrual Reconciliation Load Run” program in R12. The table PO_ACCRUAL_RECONCILE_TEMP_ALL has been replaced by the tables  CST_RECONCILIATION_SUMMARY and  CST_AP_PO_RECONCILIATION in R12.

2. 11i has only one Accrual Reconciliation Report which will show all the transactions for the accrual account irrespective of whether it is Miscellaneous INV transaction or AP NO PO transaction. But in R12 there are 3 different reports, one for AP-PO individual transactions, one for Miscellaneous transactions showing the individual transaction details for source INV and AP and one for showing the summarized accrual balance for all transaction types.

3. 11i has the option of running the Accrual Reconciliation Report with net accrual balance as 0 as well as net accrual balance greater than 0. But in R12, Accrual Reconciliation Report will show only the transactions having net accrual balance greater than zero.

4. In 11i, Accrual Reconciliation Report can be run for a specific data range and accrual balances can be checked for a specific period. But in R12, Accrual Reconciliation Report always shows the ‘as on date’ accrual balance and the report cannot be run for a specific date range.

b) Accrual Write-off Process:
Once the accrual entries for the PO or invoice are shown in Accrual Reconciliation Report, Accrual Write-off can be done using Cost Management or Purchasing responsibility>Accounting>Accrual write offs>AP and PO. This will delete the accrual entry from CST_AP_PO_RECONCILIATION table and populate the write off transaction in CST_WRITE_OFFS table. This write off transaction can also be viewed in the form View Write offs.
Accounting entries have to be created in SLA and GL for these write off transactions by submitting the Create Accounting program.This can be viewed in SLA menu by navigating to Tools > View Accounting in the View Write offs form.

Following Accounting entries will be available in the HTML page for a RECEIVE transaction

Accrual a/c DR
Offset a/c CR

Similarly for an AP PO MATCH transaction

Accrual a/c CR
Offset a/c DR

This Offset a/c will always be the Invoice Price Variance account.

Accounting events for this write off transaction will show the Event status as “Final Accounted” once the Create Accounting program is submitted and the entries are transferred to GL.

Difference in Behavior between 11i and R12:

1. The table PO_ACCRUAL_WRITE_OFFS_ALL has been replaced by the table CST_WRITE_OFFS in R12.

2. In 11i, accounting will not get created for the write off transaction and accrual entry has to be manually adjusted in GL whereas in R12, Create Accounting program will create the accrual entry for the write off transaction in SLA as well as in GL and hence manual adjustment of accrual entry is not required.

Posted in Oracle E-Business Applications, Oracle Financial, Oracle Inventory, Oracle Purchasing | 28 Comments »

Accounting Flow for Purchase Orders, Receipts and Matched Invoices in an Encumbrance Environment

Posted by Mahmoud Elemam on December 30, 2011

Accounting Flow

for

Purchase Orders, Receipts and Matched Invoices in an Encumbrance Environment

An Oracle White Paper

This document details the accounting entries that are expected for purchase orders with Expense or Inventory destinations, receipts and matched invoices. It also considers the two choices of accrual available for Expense items in an encumbrance-enabled environment.

Expense items can be accrued at

a)     Period-end

b)    On Receipt

Inventory Items can ONLY be accrued at

a)     Receipt

This document consists of the following case studies/scenarios.

Accrue on receipt: (APO)

Case 1: Expense Destination/Create, Approve, Reserve/Receive/Invoice

Case 2: Expense Destination/Create, Approve, Reserve/Invoice/Receive

Case 3: Expense Destination/Create, Approve, Reserve/Receive/Invoice at a price greater than PO price

Case 4: Expense Destination/Create, Approve, Reserve/Receive/Invoice at a quantity greater than PO quantity

Case 5: Inventory Destination/ Create, Approve, Reserve/Receive/Invoice

Case 6: Inventory Destination/ Create, Approve, Reserve/Invoice/Receive

Accrue at Period-end: (APE)

Case 1: Create PO /Receive PO /Deliver PO /Invoice/Run the period end program

Case 2: Create PO /Invoice/Receive PO/Deliver PO/Run the period end program

Case 3: Create PO/Receive PO/Deliver PO/Run the period end program/Invoice

Case 4: Create PO/Receive PO/Run the Period end program/Deliver PO/Run the

period end program/Invoice

Case 5: Create PO /Receive PO /Deliver PO /Invoice at a price greater than PO

Price/Run the period end program

Case 6: Create PO /Receive PO /Deliver PO /Invoice at a quantity greater than PO

Quantity/Run the period end Program

The following Pages will explain each case in detail:

LEGEND: AOR= Accrue On Receipt, APE= Accrue at Period-End


AOR-Case 1:

Assumptions:

Accrue on receipt = Y

Destination type = Expense

Item = expense Item

 

  

     Sequence of actions:

  • Create, Approve, Reserve PO
  • Receive and Deliver the PO
  • Invoice Validation after matching
  • Create Accounting for invoice

Action

Accounting entries

Table in which records exist

Flag/nature of entry

1. PO is reserved Budget a/c DR @ PO price (base + NR tax)*

GL_BC_PACKETS

Encumbrance

2. Receive the PO Receiving Inventory a/c DR @ PO price (base + NR tax)++

RRSL/GLI/GL_JE_LINES

Actual

AP Expense accrual a/c CR @ PO price (base+ NR tax) ^^
3. Deliver the PO Expense Charge a/c DR @ PO price (base + NR tax)

RRSL/GLI/GL_JE_LINES

Actual

Receiving Inventory a/c CR @ PO price (base + NR tax)++
Budget a/c CR @ PO price (base + NRtax)*

Encumbrance

4. Invoice Validation REC Tax and NR tax DR @ tax amount++

GL_BC_PACKETS

Encumbrance

5. Create Accounting for Invoice AP Expense accrual a/c DR @ PO price excluding tax and tax DR @ tax rate separately ^^

AP_AE_LINES_ALL

Actual

AP Liability a/c CR @ invoice price
REC Tax and NR tax CR @ tax amount++

AP_ENCUMBRANCE_

LINES_ALL

Encumbrance

Note:

  • The corresponding offsetting records have the same symbol in order to more easily identify which debits and credits offset each other. (^, +, *)
  • PO base price refers to received quantity * unit price in PO Lines.
  • NR tax refers to Non Recoverable Tax calculated for the (received quantity * PO line unit price)
  • REC tax refers to Recoverable Tax calculated for the (received quantity * PO line unit price)
  • RRSL – RCV_RECEIVING_SUB_LEDGER
  • GLI – GL_INTERFACE

AOR-Case 2:


Assumptions:

Accrue on receipt = Y

Destination type = Expense

Item = expense Item

      Sequence of actions:

  • Create, Approve, Reserve PO
  • Invoice Validation after matching
  • Create Accounting for invoice
  • Receive and Deliver the PO

Action

Accounting entries

Table in which records exist

Flag/nature of entry

1. PO is reserved Budget a/c DR @ PO price (base + NR tax) $$

GL_BC_PACKETS

Encumbrance

2. Invoice Validation REC Tax and NR tax DR @ tax amount *

GL_BC_PACKETS

Encumbrance

3. Create Accounting for invoice AP Expense accrual a/c DR @ PO price excluding tax and tax DR @ tax rate separately +++

AP_AE_LINES_ALL

Actual

AP Liability a/c CR @ invoice price
REC Tax and NR tax CR @ tax amount *

AP_ENCUMBRANCE_LINES_ALL

Encumbrance

4. Receive the PO Receiving Inspection a/c DR @ PO price (base + NR tax) ^^^^

RRSL/GLI/GL_JE_

LINES

Actual

AP Expense accrual a/c CR @ PO price (base+ NR tax) +++
5. Deliver the PO Expense Charge a/c DR @ PO price (base + NR tax)

RRSL/GLI/GL_JE_

LINES

Actual

Receiving Inspection a/c CR @ PO price (base + NR tax) ^^^^
Budget a/c CR @ PO price (base + NR tax)  $$

Encumbrance

Note:

  • Corresponding offsetting accounts have same symbols
  •  PO base price refers to received quantity * unit Price in PO lines
  • NR tax refers to Non Recoverable Tax calculated for the (received quantity *PO line unit price)
  • REC tax refers to Recoverable Tax calculated for the (received quantity *PO line unit price)
  • RRSL – RCV_RECEIVING_SUB_LEDGER
  • GLI – GL_INTERFACE

AOR-Case 3:


Assumptions:

Accrue on receipt = Y

Destination type = Expense

Item = expense Item

Sequence of actions:

Create, Approve, Reserve PO

Receive and Deliver PO

Create Invoice at higher unit price than PO

Invoice Validation

Create Accounting

Action

Accounting entries

Table in which records exist

Flag/nature of entry

1. PO is reserved Budget a/c DR @ PO price (base + NR tax) ^^^^

GL_BC_PACKETS

Encumbrance

2. Receive the PO Receiving Inventory a/c DR @ PO price (base + NR tax) $$$

RRSL/GLI/GL_JE_

LINES

Actual

AP Expense accrual a/c CR @ PO price (base+ NR tax) **
3. Deliver the PO Expense Charge a/c DR @ PO price (base + NR tax)

RRSL/GLI/GL_JE_

LINES

Actual

Receiving Inventory a/c CR @ PO price (base + NR tax) $$$
Budget a/c CR @ PO price (base + NR tax) ^^^^

Encumbrance

4. Invoice Validation at higher price REC Tax and NR tax DR @ tax amount #

GL_BC_PACKETS

Encumbrance

IPV a/c DB @ difference in price  &
5. Create Accounting for Invoice AP Expense accrual a/c DR @ PO price excluding tax and tax DR @ tax rate separately **

AP_AE_LINES_ALL

Actual

AP Liability a/c CR @ invoice price
IPV a/c DR @ difference in price
REC Tax and NR tax CR @ tax amount #

AP_ENCUMBRANCE_LINES_ALL

Encumbrance

IPV a/c CR @ difference in price  &

Note:

  • Corresponding offsetting accounts have same symbols
  • PO base price refers to received quantity * unit Price in PO lines
  • NR tax refers to Non Recoverable Tax calculated for the (received quantity * PO line unit price)
  • REC tax refers to Recoverable Tax calculated for the (received quantity * PO line unit price)
  • RRSL – RCV_RECEIVING_SUB_LEDGER
  • GLI – GL_INTERFACE

AOR-Case 4:


Assumptions:

Accrue on receipt = Y

Destination type = Expense

Item = expense Item

     

      Sequence of actions:

  • Create, Approve, Reserve PO
  • Receive and Deliver PO
  • Create Invoice at higher quantity than PO
  • Invoice Validation
  • Create Accounting

Action

Accounting entries

Table in which records exist

Flag/nature of entry

1. PO is reserved Budget a/c DR @ PO price (base + NR tax) &

GL_BC_PACKETS

Encumbrance

2. Receive the PO Receiving Inspection a/c DR @ PO price (base + NR tax) ##

RRSL/GLI/GL_JE_

LINES

Actual

AP Expense accrual a/c CR @ PO price (base+ NR tax) ^^^
3. Deliver the PO Expense Charge a/c DR @ PO price (base + NR tax)

RRSL/GLI/GL_JE_

LINES

Actual

Receiving Inspection a/c CR @ PO price (base + NR tax) ##
Budget a/c CR @ PO price (base+ NR tax) &

Encumbrance

4. Invoice Validation for higher quantity*See additional info below REC Tax and NR tax DR @ tax amount ****

GL_BC_PACKETS

Encumbrance

5. Create Accounting for Invoice AP Expense accrual a/c DR @ invoice price excluding tax and tax DR @ tax rate separately  ^^^

AP_AE_LINES_ALL

Actual

AP Liability a/c CR @ invoice price
REC Tax and NR tax CR @ tax amount ****

AP_ENCUMBRANCE_LINES_ALL

Encumbrance

 

Note:

  • Corresponding offsetting accounts have same symbols
  • PO base price refers to received quantity * unit Price in PO line
  • NR tax refers to Non Recoverable Tax calculated for the (received quantity * PO line unit price)
  • REC tax refers to Recoverable Tax calculated for the (received quantity * PO line unit price)
  • RRSL – RCV_RECEIVING_SUB_LEDGER
  • GLI – GL_INTERFACE
  • No separate accounting entry for Quantity Variation (#4) will be seen here

 

 

 

AOR-Case 5:


Assumptions:

Accrue on receipt = Y

Destination type = Inventory

Item = Inventory Item

      Sequence of actions:

  • Create, Approve, Reserve PO
  • Receive and Deliver the PO
  • Invoice Validation after matching
  • Create Accounting for invoice

Action

Accounting entries

Table in which records exist

Flag/nature of entry

1. PO is reserved Budget a/c DR @ PO price (base + NR tax) #

GL_BC_PACKETS

Encumbrance

2. Receive the PO Receiving Inspection a/c DR @ PO price (base + NR tax)  **

RRSL/GLI/GL_JE_LINES

Actual

AP Inventory accrual a/c CR @ PO price (base+ NR tax)  %%%
3. Deliver the PO Material Valuation a/c DR @ std cost

MTL_TRANSACTION_

ACCOUNTS

Actual (Account line type-1)

Receiving Inspection a/c DR @ PO price (base + NR tax)  **

Actual (Account line type-5)

PPV a/c CR/DR @ difference in price

Actual (Account line type-6)

Budget a/c CR @ PO price (base+ NR tax) #

Encumbrance (Account line type- 15)

4. Invoice Validation REC Tax and NR tax DR @ tax amount $$$$

GL_BC_PACKETS

Encumbrance

5. Create Accounting for Invoice AP Inventory accrual a/c DR @ PO price excluding tax and tax DR @ tax rate separately %%%

AP_AE_LINES_ALL

Actual

AP Liability a/c CR @ invoice price
REC Tax and NR tax CR @ tax amount $$$$

AP_ENCUMBRANCE_

LINES_ALL

Encumbrance

Note:

  • Corresponding offsetting accounts have same symbols
  • PO base price refers to received quantity * unit Price in PO line
  • NR tax refers to Non Recoverable Tax calculated for the (received quantity * PO line unit price)
  • REC tax refers to Recoverable Tax calculated for the (received quantity * PO line unit price)
  • RRSL – RCV_RECEIVING_SUB_LEDGER
  • GLI – GL_INTERFACE

AOR-Case 6:


Assumptions:

Accrue on receipt = Y

Destination type = Inventory

Item = Inventory Item

      Sequence of actions:

  • Create, Approve, Reserve PO
  • Invoice Validation after matching
  • Create Accounting for invoice
  • Receive and Deliver the PO

Action

Accounting entries

Table in which records exist

Flag/nature of entry

1. PO is reserved Budget a/c DR @ PO price (base + NR tax) ####

GL_BC_PACKETS

Encumbrance

2. Invoice Validation REC Tax and NR tax DR @ tax amount*

GL_BC_PACKETS

Encumbrance

3. Create Accounting for invoice AP Inventory accrual a/c DR @ PO price excluding tax and tax DR @ tax rate separately @@@

AP_AE_LINES_ALL

Actual

AP Liability a/c CR @ invoice price
REC Tax and NR tax CR @ tax amount*

AP_ENCUMBRANCE_LINES_ALL

Encumbrance

4. Receive the PO Receiving Inspection a/c DR @ PO price (base + NR tax)  ^^^^

RRSL/GLI/GL_JE_

LINES

Actual

AP Inventory accrual a/c CR @ PO price (base+ NR tax) @@@
5. Deliver the PO Material Valuation a/c DR @ std cost

MTL_TRANSACTION_ACCOUNTS

Actual (Account line type-1)

Receiving Inspection a/c CR @ PO price (base + NR tax)  ^^^^

Actual (Account line type-5)

PPV a/c CR/DR @ difference in price

Actual (Account line type-6)

Budget a/c CR @ PO price (base + NR tax) ####

Encumbrance (Account line type- 15)

Note:

  • Corresponding offsetting accounts have same symbols
  • PO base price refers to received quantity * unit Price in PO line
  • NR tax refers to Non Recoverable Tax calculated for the (received quantity * PO line unit price)
  • REC tax refers to Recoverable Tax calculated for the (received quantity * PO line unit price)
  • RRSL – RCV_RECEIVING_SUB_LEDGER
  • GLI – GL_INTERFACE
Accrue at Period End

APE-Case 1:


Assumptions:

Accrue on receipt = N

Destination type = Expense

Item = expense Item

Purchase Encumbrance type and Invoice    Encumbrance type are different

Sequence of actions:

Create, Approve, Reserve PO

Receive and Deliver the PO

Invoice Validation after matching

Create Accounting for invoice

Run the Period End Program

Action

Accounting entries

Table in which records exist

Flag/nature of entry

1. PO is reserved Budget a/c DR @ PO price (base + NR tax) *

GL_BC_PACKETS

Encumbrance

2. Receive the PO No Accounting Transactions

N/A

N/A

3. Deliver the PO No Accounting Transactions

N/A

N/A

4. Invoice Validation Budget a/c CR @ PO price (base + NR tax) *

GL_BC_PACKETS

Encumbrance

REC Tax and NR tax DR @ tax amount ^^
Budget a/c DR @ invoice price excluding NR tax-INV Enc  &&&
5. Create Accounting for invoice Expense charge a/c DR @ invoice price excluding tax and tax DR @ tax rate separately

AP_AE_LINES_ALL

Actual

AP Liability a/c CR @ invoice price including NR tax
REC Tax and NR tax CR @ tax amount ^^

AP_ENCUMBRANCE_

LINES_ALL

Encumbrance

Budget a/c CR @ invoice price excluding NR tax  &&&
6. Run the Period end program No Accounting Transactions

N/A

N/A

7. Manual Reversal of journal entry Not Required since there are no accrual entries

N/A

N/A

Note:

  • Corresponding offsetting accounts have same symbols
  • PO base price refers to received quantity * unit Price in PO line
  • NR tax refers to Non Recoverable Tax calculated for the (received quantity * po line unit price)
  • REC tax refers to Recoverable Tax calculated for the (received quantity * po line unit price)

APE-Case 2:


Assumptions:

Accrue on receipt = N

Destination type = Expense

Item = expense Item

Purchase Encumbrance type and Invoice Encumbrance type are different

Sequence of actions:

Create, Approve, Reserve PO

Invoice Validation after matching

Create Accounting for invoice

Receive and Deliver the PO

Run the Period end Program

Action

Accounting entries

Table in which records exist

Flag/nature of entry

1.PO is reserved Budget a/c DR @ PO price (base + NR tax)  ####

GL_BC_PACKETS

Encumbrance

2.Invoice Validation Budget a/c CR @ PO price (base + NR tax)  ####

GL_BC_PACKETS

Encumbrance

REC Tax and NR tax DR @ tax amount***
Budget a/c DR @ invoice price excluding NR tax- INV Enc  %%
3.Create Accounting for invoice Expense charge a/c DR @ invoice price excluding tax and tax DR @ tax rate separately

AP_AE_LINES_ALL

Actual

AP Liability a/c CR @ invoice price including NR tax
Budget a/c CR @ invoice price excluding NR tax  %%

AP_ENCUMBRANCE_

LINES_ALL

Encumbrance

REC Tax and NR tax CR @ tax amount***
4.Receive the PO No Accounting Transactions

N/A

N/A

5. Deliver the PO No Accounting Transactions

N/A

N/A

6.Run the Period end program No Accounting Transactions

N/A

N/A

7. Manual Reversal of journal entry Not Required since there are no accrual entries

N/A

N/A

Note:

  • Corresponding offsetting accounts have same symbols.
  • PO base price refers to received quantity * unit Price in PO line
  • NR tax refers to Non Recoverable Tax calculated for the (received quantity * po line unit price)
  • REC tax refers to Recoverable Tax calculated for the (received quantity * po line unit price)

APE-Case 3:


Assumptions:

Accrue on receipt = N

Destination type = Expense

Item = expense Item

Purchase Encumbrance type and Invoice Encumbrance type are different

Sequence of actions:

Create, Approve, Reserve PO

Receive and Deliver the PO

Run the Period End Program

Invoice Validation after matching

Create Accounting for invoice

Action

Accounting entries

Table in which records exist

Flag/nature of entry

1.PO is reserved Budget a/c DR @ PO price (base + NR tax) $

GL_BC_

PACKETS

Encumbrance

2.Receive the PO No Accounting Transactions

N/A

N/A

3.Deliver the PO No Accounting Transactions

N/A

N/A

4.Run the Period end program Expense Charge a/c DR @ PO Price (base + NR tax) #

RRSL/GLI

Actual

AP Expense accrual a/c CR @ PO Price (base + NR tax) &
Budget a/c CR @ PO price (base + NR tax) $

Encumbrance

5.Manual Reversal of journal entry (Both actual and encumbrance) Expense Charge a/c CR @ PO Price (base + NR tax) #

GL_JE_LINES

Actual

AP Expense accrual a/c DR @ PO Price (base + NR tax) &
Budget a/c DR @ PO price (base + NR tax) ++
6.Invoice Validation Budget a/c CR @ PO price (base + NR tax) ++

GL_BC_

PACKETS

Encumbrance

Budget a/c DR @ invoice price excluding NR tax – INV Enc **
REC Tax and NR tax DR @ tax amount ^^
7.Create Accounting for invoice Expense charge a/c DR @ invoice price excluding tax and tax DR @ tax rate separately

AP_AE_LINES_ALL

Actual

AP Liability a/c CR @ invoice price including NR tax
REC Tax and NR tax CR @ tax amount ^^

AP_ENCUMBRANCE_LINES_ALL

Encumbrance

Budget a/c CR @ invoice price excluding NR tax **

Note:

  • Corresponding offsetting accounts have same symbols.
  • PO base price refers to received quantity * unit Price in PO line
  • NR tax refers to Non Recoverable Tax calculated for the (received quantity * po line unit price)
  • REC tax refers to Recoverable Tax calculated for the (received quantity * po line unit price)
  • RRSL – RCV_RECEIVING_SUB_LEDGER
  • GLI – GL_INTERFACE

APE-Case 4:


Assumptions:

Accrue on receipt = N

Destination type = Expense

Purchase Encumbrance type and Invoice Encumbrance type are different

Sequence of Actions:

Create, Approve, Reserve PO/Receive the PO and Run the Period End Program

Deliver the PO and Run the Period End Program

Invoice Validation and Create Accounting


Action

Accounting entries

Table in which records exist

Flag/nature of entry

1.PO is reserved Budget a/c DR @ PO price (base + NR tax)  ^

GL_BC_PACKETS

Encumbrance

2.Receive the PO No Accounting Transactions

N/A

N/A

3.Run the Period end program Expense Charge a/c DR @ PO Price (base + NR tax) +

RRSL/GLI

Actual

AP Expense accrual a/c CR @ PO Price (base + NR tax)  &
Budget a/c CR @ PO price (base + NR tax) ^

Encumbrance

4.Manual Reversal of journal entry (Both actual and encumbrance) Expense Charge a/c CR @ PO Price (base + NR tax) +

GL_JE_LINES

Actual

AP Expense accrual a/c DR @ PO Price (base + NR tax) &
Budget a/c DR @ PO price (base + NR tax) *
5.Deliver the PO No Accounting Transactions

N/A

N/A

5. Deliver the PO No Accounting Transactions

N/A

N/A

6. Run the Period end program Expense Charge a/c DR @ PO Price (base + NR tax) +

RRSL/GLI

Actual

AP Expense accrual a/c CR @ PO Price (base + NR tax) &
Budget a/c CR @ PO price (base + NR tax) *

Encumbrance

7.Manual Reversal of journal entry (Both actual and encumbrance) Expense Charge a/c CR @ PO Price (base + NR tax) +

GL_JE_LINES

Actual

AP Expense accrual a/c DR @ PO Price (base + NR tax) &
Budget a/c DR @ PO price (base + NR tax) #
8.Invoice Validation Budget a/c CR @ PO price (base + NR tax) #

GL_BC_PACKETS

Encumbrance

Budget a/c DR @ invoice price excluding NR tax- INV Enc  /////
REC Tax and NR tax DR @ tax amount \\\\
9.Create Accounting for invoice Expense charge a/c DR @ invoice price excluding tax and tax DR @ tax rate separately

AP_AE_LINES_ALL

Actual

AP Liability a/c CR @ invoice price including NR tax
REC Tax and NR tax CR @ tax amount \\\\

AP_ENCUMBRANCE_

LINES_ALL

Encumbrance

Budget a/c CR @ invoice price excluding NR tax /////

 

APE-Case 5:


Assumptions:

Accrue on receipt = N

Destination type = Expense

Item = expense Item

Purchase Encumbrance type and Invoice Encumbrance type are different

 

Sequence of actions:

Create, Approve, Reserve PO

Receive and Deliver the PO

Create Invoice at higher price than PO

Invoice Validation after matching

Create Accounting for invoice

Run the Period End Program

Action

Accounting entries

Table in which records exist

Flag/nature of entry

1. PO is reserved Budget a/c DR @ PO price (base + NR tax) $$

GL_BC_PACKETS

Encumbrance

2. Receive the PO No Accounting Transactions

N/A

N/A

3. Deliver the PO No Accounting Transactions

N/A

N/A

4. Invoice Validation at higher price Budget a/c CR @ PO price (base + NR tax) $$

GL_BC_PACKETS

Encumbrance

Budget a/c DR @ PO price excluding NR tax  ***
Budget a/c DR @ difference in invoice price ***
REC Tax and NR tax DR @ tax amount &
5. Create Accounting for invoice Expense charge a/c DR @ invoice price excluding tax and tax DR @ tax rate separately

AP_AE_LINES_ALL

Actual

AP Liability a/c CR @ invoice price including NR tax
REC Tax and NR tax CR @ tax amount &

AP_ENCUMBRANCE_LINES_ALL

Encumbrance

Budget a/c CR @ invoice price excluding NR tax
6. Run the Period end program No Accounting Transactions

N/A

N/A

7. Manual Reversal of journal entry Not Required since there are no accrual entries

N/A

N/A

Note:

  • Corresponding offsetting accounts have same symbols.
  • PO base price refers to received quantity * unit Price in PO line
  • NR tax refers to Non Recoverable Tax calculated for the (received quantity * po line unit price)
  • REC tax refers to Recoverable Tax calculated for the (received quantity * po line unit price)

 

APE-Case 6:


Assumptions:

Accrue on receipt = N

Destination type = Expense

Item = expense Item

Purchase Encumbrance type and Invoice Encumbrance type are different

Sequence of actions:

Create, Approve, Reserve PO

Receive and Deliver the PO

Create Invoice at higher quantity than PO

Invoice Validation after matching

Create Accounting for invoice

Run the Period End Program

Action

Accounting entries

Table in which records exist

Flag/nature of entry

1. PO is reserved Budget a/c DR @ PO price (base + NR tax)  ##

GL_BC_PACKETS

Encumbrance

2. Receive the PO No Accounting Transactions

N/A

N/A

3. Deliver the PO No Accounting Transactions

N/A

N/A

4. Invoice Validation at higher quantity Budget a/c CR @ PO price (base + NR tax) ##

GL_BC_PACKETS

Encumbrance

Budget a/c DR @ PO price excluding NR tax $$
Budget a/c DR @ additional invoice price -INV enc $$
REC Tax and NR tax DR @ tax amount  ////
5. Create Accounting for invoice Expense charge a/c DR @ invoice price excluding tax and tax DR @ tax rate separately

AP_AE_LINES_ALL

Actual

AP Liability a/c CR @ invoice price including NR tax
REC Tax and NR tax CR @ tax amount ////

AP_ENCUMBRANCE_LINES_ALL

Encumbrance

Budget a/c CR @ PO price excluding NR tax ^^^^
Budget a/c CR @ additional invoice price with encumbrance line type as QV  ^^^^
6. Run the Period end program No Accounting Transactions

N/A

N/A

7. Manual Reversal of journal entry Not Required since there are no accrual entries

N/A

N/A

Note:

  • Corresponding offsetting accounts have same symbols.
  • PO base price refers to received quantity * unit Price in PO line
  • NR tax refers to Non Recoverable Tax calculated for the (received quantity * po line unit price)
  • REC tax refers to Recoverable Tax calculated for the (received quantity * po line unit price)

Important Notes:

 

1. Accrual entries will be generated /created ONLY when the Received quantity > Billed quantity at the time of running Receipt Accruals-Period end program.

2. Under the cases mentioned above under the Period-end Section, manual reversal of journal entries are not required except for Case 3 and Case 4 since there are NO accrual entries created /generated.

3. For all these cases the account records from receiving will also be inserted into GL_BC_PACKETS, along with the other subledger tables mentioned above. These records in GL_BC_PACKETS can be viewed by querying the  max(packet_id), as there are no REFERENCE fields populated for receiving records.

4. Liability a/c  which is recorded at invoice price will also include the recoverable and non-recoverable tax rates.

Accounting Flow against Purchase Orders, Receipts and Matched Invoices.

Posted in General Ledger, Oracle E-Business Applications, Oracle Financial, Oracle Purchasing | 3 Comments »

How Does the Landed Cost Management Impacts the Accounting Flow in a Procure To Pay Cycle

Posted by Mahmoud Elemam on September 10, 2010

What are the accounting entries in a Procure to Pay cycle when the PO shipment is enabled for Landed Cost Management?

1. Receive the PO with estimated landed cost calculated
– Receiving Inspection a/c DR @ Estimated Landed Cost
– AP Accrual a/c CR @ PO Price inclusive of Non-Recoverable tax
– Landed Cost Absorption a/c CR @ (Estimated Landed cost – PO Price inclusive of Non-Recoverable tax) (This a/c is defined in Receiving options)

  • These accounting entries can be viewed from Receiving Transaction summary > Transactions > Tools > View Accounting
  • These entries get created in rcv_receiving_sub_ledger

2. Deliver the PO to Inventory destination

For Standard Costing organization
– Material Valuation a/c DR @ Std Cost
– Receiving Inspection a/c CR @ Estimated Landed Cost
– Purchase Price Variance a/c DR @ difference between Std Cost and Estimated Landed Cost

For Average Costing organization
– Material Valuation a/c DR @ Estimated Landed Cost
– Receiving Inspection a/c CR @ Estimated Landed Cost

  • These entries can be viewed from Inventory > Material Transactions > Distributions
  • These entries get created in mtl_transaction_accounts

3. Invoice validated and actual landed cost calculated

Once the Actual Landed Cost is calculated, LCM will populate this information in cst_lc_adj_interface with rcv_transaction_id corresponding to the receipt to which the invoice is matched. Then the adjustment entries would get created as given below on running the Landed Cost Adjustment Processor

Landed cost Adjustment – Receiving
– Receiving Inspection a/c DR @ difference between Actual LC and Estimated LC
– Landed Cost Absorption a/c CR @ difference between Actual LC and Estimated LC

Landed cost Adjustment – Delivery (Standard Costing)
– Receiving Inspection a/c CR @  difference between Actual LC and Estimated LC
– Purchase Price Variance a/c DR @ difference between Actual LC and Estimated LC

  • These accounting entries can be viewed from Receiving Transaction summary > Transactions > Tools > View Accounting
  • These entries get created in rcv_receiving_sub_ledger

Landed cost Adjustment – Delivery (Average Costing)
– Receiving Inspection a/c CR @ difference between Actual LC and Estimated LC
– Landed Cost Absorption a/c DR @ difference between Actual LC and Estimated LC

Average Cost Update (Average Costing)
– Material Valuation a/c DR @ difference between Actual LC and Estimated LC
– Landed Cost Absorption a/c CR @ difference between Actual LC and Estimated LC

If this Average cost update happens for updating the item cost with the difference between Actual and Estimated landed cost for an item which has 0 or negative on-hand quantity, then the accounting entries would be as follows:

– Material Valuation a/c DR @ 0
– Landed Cost Absorption a/c CR @ difference between Actual LC and Estimated LC
– Landed Cost Variance a/c DR @ difference between Actual LC and Estimated LC (This a/c is defined inventory > Set up > Organization > Parameters)

  • These entries can be viewed from Inventory > Material Transactions > Distributions
  • These entries get created in mtl_transaction_accounts
  • The link between the Receiving transaction and Average Cost update is done through txn_source_line_id. Rcv_transaction_id of deliver transaction is stamped as txn_source_line_id in mtl_material_transactions for the LCM adjustment transaction which has the transaction type as Average Cost Update.

4. Create accounting for item invoice

– AP Accrual a/c DR @ PO Price
– Tax a/c DR @ tax rate
– Liability a/c CR @ Invoice Price including tax
– LCM:Invoice Price Variance a/c DR @ difference between PO Price and Invoice Price (This IPV a/c is defined in Receiving options)
– LCM:Exchange Rate Variance a/c DR @ difference between receipt exchange rate and Invoice exchange rate (This ERV a/c is defined in Receiving options)

5. Create accounting for charge invoice

– Default Charge a/c DR @ invoice price (This charge a/c is defined in Receiving options)
– Liability a/c CR @ invoice price

6. Perform Return transaction or negative correction after invoice is accounted and actual landed cost is calculated

Return to Vendor /Negative Correction
– Receiving Inspection a/c CR @ Actual Landed Cost
– AP Accrual a/c DR @ PO Price + Non-Recoverable Tax
– Landed Cost Absorption a/c DR (Actual Landed Cost – {PO Price+Non-Recoverable Tax})

  • These accounting entries can be viewed from Receiving Transaction summary > Transactions > Tools > View Accounting
  • These entries get created in rcv_receiving_sub_ledger

Return to Receiving/Negative Correction (Standard Costing)
– Material Valuation a/c CR @ Std Cost
– Receiving Inspection a/c DR @ Actual Landed Cost
– Purchase Price Variance a/c CR @ difference between Std cost and Actual Landed Cost

Return to Receiving/Negative Correction (Average Costing)
– Material Valuation a/c CR @ Actual Landed Cost
– Receiving Inspection a/c DR @ Actual Landed Cost

  • These entries can be viewed from Inventory > Material Transactions > Distributions
  • These entries get created in mtl_transaction_accounts

7. Raise a Debit Note

– AP Accrual a/c CR @ PO Price
– Tax CR @ tax rate
– Liability a/c DR @ Invoice Price including tax
– Invoice Price Variance a/c CR @ difference between PO price and Invoice Price

Note:

1. Estimated and Actual Landed Cost are always inclusive of PO price and Non-Recoverable tax.
2. Landed Cost Absorption account need not be having zero balance at the end of this procure to pay cycle in LCM enabled organization. It will be zero only if default charge a/c defined in Receiving options is same as the landed cost absorption a/c and Actual landed cost is same as the Estimated landed cost.
3. Accounting entries for Expense POs and Shopfloor destination POs has no impact as Landed Cost Management is not applicable for Purchase Orders with Expense and Shopfloor destination.
4. Landed Cost Management has no impact on the Encumbrance Accounting as the PO gets reserved at PO price and it gets reversed at PO price only even though the actual charge account get hit at landed cost.
5. Retroactive Pricing is not supported in LCM enabled organization and hence retroactive price update program will not create the retroactive price adjustment entries in Receiving subledger for the receiving transactions created.


Posted in Accounts Payables, General Ledger, Landed Cost, Oracle E-Business Applications, Oracle Financial, Oracle Inventory, Oracle Purchasing | 5 Comments »

Release 12.1.1 New Features in Oracle Landed Cost Management

Posted by Mahmoud Elemam on September 10, 2010

Overview

Oracle’s Landed Cost Management application is a new product released on EBS r.12.1.
Landed Cost Management enables organizations to gain insight into all of the “real”costs associated with acquiring products including broker, terminal, insurance, and transportation fees as well as duties and taxes. These costs are initially estimated and updated with actual amounts as they become known allocating them to shipments, orders, and products. Cost methods and inventory valuations are accurately maintained providing better visibility into an individual product’s profitability and an organization’s outstanding exposure. This data provides better insight for product forecasting and budgeting and provides clear evidence of the detailed accumulation of expenses for regulatory requirements and reporting.

Features

1. Charge Management
Many of the charges that apply to landed costs can be complicated in their application, maintenance, and ongoing tracking. These charges are received in a variety of formats at different points during a fulfillment process. These points include product creation, sourcing, order creation, shipping, receiving, and invoicing. Organizing and tracking these charges as soon as they are incurred is key to a company fully understanding their outstanding liabilities.

Oracle Landed Cost Management collects an unlimited number of estimated charges and allows users to configure how charges should be applied to a shipment line, a group of lines within a shipment, or an entire shipment. It applies these charges based on weight, volume, quantity, or the value of the items being traded. These charges can be categorized by different cost factors, which will ultimately govern the behavior in how they are included in a total landed cost calculation. Once actual amounts are received, Charge Management records the new value for comparison with the earlier estimates and sends adjustments to backoffice applications.

2. Advanced Pricing for Charge Templates
When organizations try to obtain estimates for a particular charge, they can typically identify standard business rules for when these charges should apply. Oracle’s Landed Cost Management application allows users to enter lists of estimated charges and conditions as to when these charges should apply by using Advanced Pricing. This enables a template of charges to automatically be applied to a receipt. It removes the need for a charge reference spreadsheet or document often found in organizations dealing with complex supply chains and minimizes error prone steps of manually entering charges during a transaction. Once these estimated costs are applied by Advanced Pricing, users have the ability to verify and update them via Oracle Landed
Cost Management’s Charge Management functionality. Ultimately, Oracle Landed Cost Management uses these components to calculate the estimated landed cost.

3. Landed Cost Calculation
Most organizations struggle to find the “real” costs required to take a product to market, to source a product overseas, or to do business with a particular vendor or customer.
Knowing the total actual landed cost of goods provides powerful insight in today’s competitive global markets. When companies use this landed cost information strategically, they can control overall product margin and optimize profitability. Some companies can only estimate this landed cost at best, while others can calculate estimated or actual costs. Often times, this is done in a semi-automated fashion in different places, making it difficult to compare estimates with actuals.
The Oracle Landed Cost Management engine provides the ability to calculate the estimated landed cost based on charges manually assigned and automatically allocated based on the configuration in the charge management repository. It recalculates applicable taxes and can be configured to exclude recoverable tax amounts. It also calculates the actual landed costs by prorating the actual invoices and proportional taxes to obtain the variances between what was estimated and what was charged. Cost components summed in the calculation remain stored at the most granular level for detailed tracking of charge amounts while variances are updated to the appropriate accounts.

4. Product Cost Dashboard
Financial flows do not mirror physical supply chain transactional flows. Landed cost management helps to link these two flows together and provides visibility and traceability from one to the other. With Landed Cost Management’s dashboard pages, companies can see the real time accrual updates for a particular receipt or shipment.
They can validate the accuracy of a supplier’s estimate by comparing estimated and actual costs and can see the percentage of a particular cost component for a particular item. Additionally, users can make use of all the flexible Oracle and E-Business Suite tools in order to meet their own customized reporting requirements.

5. Tax Recovery
Many countries impose high tariffs on items as they pass through the supply chain. This can sometimes reach into the double digits. As a result, tax recoverability becomes extremely important when organizations are making sourcing decisions and automating inbound flows. Oracle Landed Cost Management factors in tax recoverable amounts in the landed cost calculation, so that estimated and actual landed cost calculations do not overstate the true tax costs.

6. Integration to EBS Supply Chain and Backoffice
Almost all organizations struggle to provide their backoffice systems visibility into estimates of accrued liabilities that are then updated with actual amounts when they become known. This is particularly the case when organizations have a large portion of their trade done across borders or have a complex supply chain. Oracle’s Landed Cost Management is integrated with Oracle E-Business Suite’s financial and supply chain applications to provide this visibility and make implementation straightforward. Oracle Landed Cost Management provides the estimated landed cost to E-Business Suite Inventory Receiving, which then automatically forwards it on to E-Business Suite Cost Management module. Once actual costs are obtained and shared with Accounts Payable, variances are effectively communicated to E-Business Suite Cost Management module.

6.1. Procurement Integration
Procurement Information is often the baseline information used to itemize expected shipment or receiving lines on which extended supply chain charges will be applied. Landed Cost Management provides visibility into E-Business Suite Procurement data in order to build expected shipments for charge application and subsequent landed cost estimation calculations. When manually entering expected shipments the reference information provided by Procurement saves time and decreases errors that might occur without automated access to this information. Once available in Landed Cost Management, expected values received from procurement such as quantity and price can be edited for estimated cost calculation purposes. Furthermore, all the necessary data is provided to help arrive at an accurate three way match once an
invoice for a PO line or charge is entered into Accounts Payable.

6.2. Receiving Integration
It is difficult to gain insight into charges associated with the acquisition of items through an extended supply chain. Often, organizations are not aware of them until an invoice is received. Companies need better visibility into these charges. Additionally, many regions require that all expenses be accounted for at an
item/product level upon receipt. In order to comply with these requirements and provide an accurate calculation of product related expenses, these extended costs need to be estimated and applied to an item at the time of receipt.
Oracle’s Landed Cost Management’s integration with EBS Inventory’s Receiving module enables Receiving to view LCM’s estimated shipments and receive against them. It further calls LCM for a total cost estimation calculation for all receipts whether they originate in LCM or in Receiving itself. These estimations are then forwarded to E-Business Suite Cost Management module in order to update inventory valuations and accounting.

6.3. Cost Management Integration
When organizations are able to estimate landed costs, they often do not communicate those estimates to their backoffice system. This is because they lack an automated method to update these estimates with actual values once they are received. This prevents them from fully utilizing the estimated information in their reporting and decision making processes.
After actual values are received and the true landed cost is calculated in Landed Cost Management, any variances between the actual and the estimate are determined.
Those variances are updated to E-Business Suite Cost Management module which in turn updates the proper accounts and valuation.

6.4. Accounts Payable Integration
Few Accounts Payable applications provide a mechanism to apply and match an unlimited number of charges to a particular procured item line or group of lines.
This means that accurate actual landed cost calculations might be difficult to automatically calculate. Additionally, this prevents tying an actual charge back to any record of an earlier estimated landed cost calculation.
Oracle Accounts Payable allows for unlimited numbers of charges to be entered and applied to procured line items and allows line items to be applied and associate to recovered line items. This information is forwarded to Landed Cost Management which in turn calculates the Actual Landed Cost. These values are compared with earlier estimates to determine if a variance should be communicated to Costing and ultimately to the General Ledger.

Posted in Accounts Payables, Landed Cost, Oracle E-Business Applications, Oracle Financial, Oracle Inventory, Oracle Purchasing | 2 Comments »

Some report names and their table names in GL, AP, AR, and PO

Posted by Mahmoud Elemam on April 21, 2010

1) ra_customer_trx_all
customer_trx_id
trx_number (invoice no, debit memo no, credit memo no)
cust_trx_type_id
2) ra_customer_lines_all (details of invoice)
cutomer_trx_id
3) ar_payment_schdules_all
check_id
This table stores all transactions except adjustments and miscellaneous cash
receipts. Oracle Receivables updates this table when activity occurs against an invoice, debit
memo, chargeback, credit memo, on account credit, or receipt.
4) ra_cust_trx_types_all (invoice types)

1) ra_customer_trx_allcustomer_trx_idtrx_number (invoice no, debit memo no, credit memo no)cust_trx_type_id2) ra_customer_lines_all (details of invoice)cutomer_trx_id3) ar_payment_schdules_allcheck_idThis table stores all transactions except adjustments and miscellaneous cashreceipts. Oracle Receivables updates this table when activity occurs against an invoice, debitmemo, chargeback, credit memo, on account credit, or receipt.4) ra_cust_trx_types_all (invoice types)

cust_trx_type_id

5) ra_batches_all

Batch_id

This table stores information about each receipt batch that you create in

Oracle Receivables. Each row includes information about a specific batch such as batch source,

status, batch type, control count, and control amount

6) ra_receivable_application_all

7) ra_adjustments_all

This table stores information about your invoice adjustments. Each row includes general

information about the adjustment you are making such as activity name, amount, accounting

information, reason, and type of adjustment. You need one row for each adjustment you are

making to an invoice.

8) ra_cash_receiots_all

Cash_receipt_id

This table stores one record for each receipt that you enter. Oracle Receivables creates

records concurrently in the AR_CASH_RECEIPT_HISTORY_ALL,

AR_PAYMENT_SCHEDULES_ALL, and AR_RECEIVABLE_APPLICATIONS tables for

invoice–related receipts.

1) ap_invoice_all

invoice_amount, base_amount, payment_status_flag(‘y’ –fully paid

‘n’—unpaid

‘p’ –partially paid)

2) ap_invoice_payments_all

invoice_id,

3) ap_invoice_distibutions_All

amount, base_amount, dist_code_combination_id, line_type_lookup_code

4) ap_payment_schdules

payment_status_flag(“ ‘’’’’”)

5) ap_payment_dustributions_all

6) ap_checks_all

check_id,

AP_CHECKS_ALL stores information about payments issued to suppliers or refunds

received from suppliers. You need one row for each payment you issue to a supplier or refund

received from a supplier. Your Oracle Payables application uses this information to record

payments you make to suppliers or refunds you receive from suppliers.

7) ap_accounting_events_all

8) ap_bank_accounts_all

AP_BANK_ACCOUNTS_ALL contains information about your bank accounts. You

need one row for each bank account you define. Each bank account must be affiliated with one

bank branch. When you initiate an automatic payment batch, enter a manual check, or create a

Quick payment, you can select a bank account that you define in this table.

9) ap_bank_accounts_uses_all

AP_BANK_ACCOUNT_USES_ALL stores information for the internal and external

bank accounts you define in Oracle Payables and Oracle

Receivables applications.

1) po_vendors_all

2) po_vendors_sites_all

3) po_headers_all

po_header_id

4) po_lines_all

po_line_id

5) po_line_locations_All

6) po_distributions_all

po_distribution_id,

1) Gl_code_combinations

GL_CODE_COMBINATIONS stores valid account combinations for each

Accounting Flexfield structure within your Oracle General Ledger application. Associated with

each account are certain codes and flags, including whether the account is enabled, whether detail

posting or detail budgeting is allowed, and others.

2) Gl_je_batches.

GL_JE_BATCHES stores journal entry batches.

3) Gl_je_headers

GL_JE_HEADERS stores journal entries. There is a one–to–many relationship between

journal entry batches and journal entries. Each row in this table includes the associated batch ID,

the journal entry name and description, and other information about the journal entry. This table

corresponds to the Journals window of the Enter Journals form. STATUS is ’U’ for unposted, ’P’

for posted. Other statuses indicate that an error condition was found. A complete list is below.

4) Gl_je_lines.

GL_JE_LINES stores the journal entry lines that you enter in the Enter Journals form.

There is a one–to–many relationship between journal entries and journal entry lines. Each row in

this table stores the associated journal entry header ID, the line number, the associated code

combination ID, and the debits or credits associated with the journal line. STATUS is ’U’ for

unposted or ’P’ for posted

5) Gl_set of books

GL_SETS_OF_BOOKS stores information about the sets of books you define in your

Oracle General Ledger application. Each row includes the set of books name, description,

functional currency, and other information. This table corresponds to the Set of Books form.

6) Gl_periods

GL_PERIODS stores information about the accounting periods you define using the

Accounting Calendar form. Each row includes the start date and end date of the period, the period

type, the fiscal year, the period number, and other information. There is a one–to–many

relationship between a row in the GL_PERIOD_SETS table and rows in this table.

1) OPEN-DEBIT MEMO REPORT?

This report shows all the open-debit memo transactions, based on customer number

and dates.

Columns :- type, customer_no, trx_no, amt_due, remaining.

Parameter :- type, customer, from_date, to_date.

2) GENERATING POSITIVE PAY FILE FOR BANK REPORT?

Basically this report generates a flat file of all the payments in order to send in to

the bank.

3)

 

UPDATE POSITIVEPAY CHECKS REPORT?This report which updates the data into the (AP) account payables system from

the plot file, the file which is sent by bank

4)

 

UPDATE POSITIVEPAY OUT STANDING CHECKS?This report which shows the out standing checks

5) CUSTOMER PAYMENT DETAILS REPORT?

Which shows each customer original amount, amount pay and due amount based

on transaction type (books, pens)

Posted in Oracle E-Business Applications, Oracle Financial, Oracle Purchasing | 5 Comments »

Interview Questions on Oracle Purchasing or Oracle PO

Posted by Mahmoud Elemam on December 12, 2009

ORACLE PURCHASING – PURCHASE ORDERS FREQUENTLY ASKED QUESTIONS
CONTENTS
——–
1. In the Price type quickpick in the Purchase Order Lines zone in enter
Purchase Order form, there is a value called COST PLUS FEE. What is the
COST PLUS FEE price type? How is Purchase Order treating this
price type?
2. What is 2-way, 3-way, 4-way matching? How is this set up?
3. How do you reflect discount from a supplier on a Purchase orders?
4. How do you change the created date on a Purchase Order?
5. What is the sorting order for requisition lines in autocreation of a
Purchase Order?
6. What does the error ‘APP-50022: Oracle Human Resources could not retrieve a
value for User Type profile option’ mean?
7. In the Enter Receipts (RCVRCERC) form and using different responsibilities
produces different values in the action required field. The Purchasing
Responsibility shows Direct and Standard while the Inventory Responsibility
shows just Direct.
Why are the action options for creating receipts different in Inventory
compared Purchasing?
8. How do you purge Cancelled Requisitions?
9. On the requisition form in the source details zone, there is a field
labeled supplier item. Where does this information on the quickpick come
from and how can this information default in?
10. You are entering a requisition and are unable to find the header or line
note fields. Was this replaced in GUI by attachments?
11. When you select the Notifications form to review approvals and click on
approve button for a Requisition waiting for approval, the ‘Reject’ box is
greyed out. How does the approver reject a requisition?
12. What are standard Quotations used for?
13. When do you see the status of a Purchase order as Archived?
14. Where are standard notes in GUI?
15. In Oracle Purchasing, where is the automatic numbering for Purchase Order
defined and maintained?
16. There is a field for the organization code. What is this code?
17. Can the original Purchase Order can be viewed in any way without resorting
to SQL, for a revised Purchase Order?

QUESTIONS & ANSWERS
——————-
1. In the Price type quickpick in the Purchase Order Lines zone in enter
Purchase Order form, there is a value called COST PLUS FEE. What is the
COST PLUS FEE price type? How is Purchase Order treating this
price type?
Answer
——
The functionality for COST PLUS FEE price type is not in Oracle Purchasing at
this point of time. PO does not do anything with this price type.
It is an enhancement request that is being looked at for future releases.
2. What is 2-way, 3-way, 4-way matching? How is this set-up?
Answer
——
2-way matching verifies that Purchase order and invoice information match within your tolerances as follows:
Quantity billed <= Quantity Ordered Invoice price <= Purchase order price (<= sign is used because of tolerances) 3-way matching verifies that the receipt and invoice information match with the quantity tolerances defined: Quantity billed <= Quantity received 4-way matching verifies that acceptance documents and invoice information match within the quantity tolerances defined: Quantity billed <= Quantity accepted. (Acceptance is done at the time of Inspecting goods). Whether a PO shipment has 2-way, 3-way or 4-way matching can be setup in the Shipment Details zone of the Enter PO form (character) Receipt required Inspection required Matching Yes Yes 4-way Yes No 3-way No No 2-way In GUI, Shipments block, alternative region, click on More…this brings up a region with ‘Invoice matching’ column where you can choose 2-way, 3-way or 4- way match. You can find more detailed information about matching in the Oracle Payables Reference Manual (Volume 3) Topical Essay on Integrating your Payables and Purchasing Information. 3. How do you reflect discount from a supplier on a Purchase orders? Answer —— The legal document is the Purchase order not the quote and therefore the purchase order should reflect agreed upon price. Secondly if the discount comes after the PO then AP should handle it when invoicing. If you are using a blanket Purchase order then you can use price breaks. 4. How do you change the created date on a Purchase Order? Answer —— The ‘Created’ date on the Purchase order is not an updateable field, due to it being a legal document once approved. 5. What is the sorting order for requisition lines in autocreation of a Purchase Order? Answer —— Requisition lines first meet search criteria determined by “find” screen, and then are grouped together by item and item category, then by need-by date. After you choose an action, enter any search criteria to narrow the selection of requisition lines. Oracle Purchasing chooses requisition lines from the requisition pool that meet your search criteria. All requisition lines for the same item and item category are grouped together, but they are not necessarily in order alphabetically. Within each grouping of item and item category, requisition lines are ordered by need-by date. 6. What does the error ‘APP-50022: Oracle Human Resources could not retrieve a value for User Type profile option’ mean? Answer —— The profile HR: User Type needs to be set. Set the profile option ‘HR: User Type’ at the Responsibility level. 7. In the Enter Receipts (RCVRCERC) form and using different responsibilities produces different values in the action required field. The Purchasing Responsibility shows Direct and Standard while the Inventory Responsibility shows just Direct. Why are the action options for creating receipts different in Inventory compared Purchasing? Answer —— Set the Profile option RCV: Allow routing override to ‘YES’ at the application level. 8. How do you purge Cancelled Requisitions? Answer —— To purge any Purchase orders or Requisitions: – assign the Payables Purge GUI responsibility to the user – have the user choose that responsibility – then choose Purge from the menu – under the Category field do a List of Values and pick Simple Requisitions for cancelled requisitions The choices are listed. 9. On the requisition form in the source details zone, there is a field labeled supplier item. Where does this information on the quickpick come from and how can this information default in? Answer —— The supplier item field on the requisition can be populated by using either the supplier item catalog or ASL. Take an item from the supplier item catalog that has an associated supplier item, add it to the order pad and then add it to the requisition. After doing this go to the source details zone. The supplier item is defaulted in for that item you choose from the catalog. Navigation: –> Purchasing –> Supplier Item catalog
10. You are entering a requisition and are unable to find the header or line
note fields. Was this replaced in GUI by attachments?
Answer
——
The attachments have replaced notes. The attachments are better because at the
header level, the requisition notes were not coming over to the Purchase Order
whereas the attachment does come over to the Purchase Order.
11. When you select the Notifications form to review approvals and click on
approve button for a Requisition waiting for approval, the ‘Reject’ box is
greyed out. How does the approver reject a requisition?
Answer
——
You cannot reject Requisitions submitted to yourself. You can only reject those
from others.
12. What are standard Quotations used for?
Answer
——
Standard quote is one that you can tie back to a PO. For example, navigate to
RFQ -> Auto create -> enter a PO and reference it back.
13. When do you see the status of a Purchase order as Archived?
Answer
——
You must approve or print a specific purchase order before you can see it in
the history information.
14. Where are standard notes in GUI?
Answer
——
Go to Setup –> Attachments –>Create attachment. Go to Purchase Order and
attach the attachment to the Purchase Order. In GUI, notes are replaced by
attachments.
15. In Oracle Purchasing, where is the automatic numbering for Purchase Order
defined and maintained?
Answer
——
The navigation path for GUI is:
Setup –> Organizations –> Purchasing Options, Numbering alternate region
The navigation path for Character is:
\ Navigate Setup Purchasing Options Purchasing, Numbering options
16. There is a field for the organization code. What is this code?
Answer
——
This code is a short abbreviation for the organization.
17. Can the original Purchase Order can be viewed in any way without resorting
to SQL, for a revised Purchase Order?
Answer
——
The original version of a revised PO cannot be viewed from the PO form or PO
summary form. Information on the original PO can be obtained from the
PO_HEADERS_ARCHIVE and PO_LINES_ARCHIVE tables using the PO_HEADER_ID column as
a common reference using SQL only.

Posted in Interview Questions, Oracle E-Business Applications, Oracle Purchasing | Leave a Comment »