COGS in R12

Oracle Application R12 COGS

In Oracle Application R12 COGS process has been changed. Reason for that are aggressive revenue
recognition practices as well as the guidelines from various governing bodies.

Till R11 Cost of goods sold has been recognized as soon as the Order line has shipped, as shown in below
steps

After ship confirm, user run the interface trip stop (ITS).
ITS in turns run the OM Interface and Inventory Interface.
Inventory Interface calls Inventory transaction manager which in turns call COGS WF.
But as per new practices COGS should be recognized along with the revenue.

In R12 used need to define deferred cogs account. These deferred cogs account can be defined at each
inventory org level.

During shipping process Inventory tables will hold the deferred COGS accounts. Only after invoicing has
done in AR, AR will notify the Costing and Costing in turns call the COGS account generator to get the
cogs account .In that way COGS and revenue will be recognized in the same period.

There are few exceptions like how to get the COGS for
1. Ship only line (No Invoice will be created).
To handle above cases Close-line activity of the order line workflow has modified to call the costing API
to get the cogs value
What is the Deferred COGS account in R12
The deferred COGS of goods account is the new feature introduced in Release 12. The basic
fundamental behind the enhancement is that the COGS is now directly matched to the Revenue. The
same was not possible till now.

Prior to this enhancement, the value of goods shipped from inventory were expensed to COGS upon
ship confirm, despite the fact that revenue may not yet have been earned on that shipment. With this
enhancement, the value of goods shipped from inventory will be put in a Deferred COGS account. As
percentages of Revenue are recognized, a matching percentage of the value of goods shipped from
inventory will be moved from the Deferred COGS account to the COGS account, thus synchronizing
the recognition of revenue and COGS in accordance with the recommendations of generally accepted
accounting principles.

The Matching Principle is a fundamental accounting directive that mandates that revenue and its
associated cost of goods sold must be recognized in the same accounting period. This enhancement will
automate the matching of Cost of Goods Sold (COGS) for a sales order line to the revenue that is billed
for that sales order line.

The deferral of COGS applies to sales orders of both non-configurable and configurable items (Pick-To Order and Assemble-To-Order). It applies to sales orders from the customer facing operating units in the
case of drop shipments when the new accounting flow introduced in 11.5.10 is used. And finally, it also
applies to RMAs that references a sales order whose COGS was deferred. Such RMAs will be accounted
using the original sales order cost in such a way that it will maintain the latest known COGS recognition percentage.
To set the deferrred COGS account.
 Inventory --Setup--Organization--Parameters--Other Accounts

A new account is added which is referred as the Deffered COGS accounts.

NEW ACCOUNTING:

Release 12 :

When a Sales order is shipped the following accounting takes place:

Inventory Valuation Account : Credit.
Deferred COGS account : Debit

Once the revenue is recognised, you would need to decide the percentage you wish to recognize the
Revenue. A COGS recognition transaction will be created to reflect a change in the revenue recognition
percentage for a sales order line.

The steps to generate such transactions are as follows:
1. Run the Collect Revenue Recognition Information program. This program will collect the change in
revenue recognition percentage based on AR events within the user specified date range.
2. Run the Generate COGS Recognition Events. This program will create the COGS recognition
transaction for each sales order line where there is a mismatch between the latest revenue recognition
percentage and the current COGS recognition percentage.

Note that users can choose how often they want to create the COGS Recognition Events.

Navigation to run the COGS recognition request :
- Cost > COGS Recognition > Collect Revenue Recognition Information
- Cost > COGS Recognition > Generate COGS Recognition Events
- Cost > View Transactions > Material Transactions


The distribution for the COGS Recognition transaction associated with the Sales Order transaction now
would be as follows:

Deffered COGS : Debit y revenue percentage
COGS : Credit (Actual revenue percentage )

Thus, essentially the recognized COGS balance is to move the value from Deferred COGS to COGS.

This particular COGS recognition transaction actually correspond to a revenue recognition percentage
change.

You can view the transactions as :
Navigation:
- Cost > View Transactions > Material Transactions > Distributions

A new COGS Revenue Matching Report shows the revenue and COGS information of sales order that fall
within the user specified date range by sales order line


SIMPLER TERMS ( Table level details ) :

Once the whole cycle is complete we will have 2 transactions lines in mtl_material_transactions.

1. Sales Order
2. COGS Recognition transaction

Accounting will be in mtl_transaction_accounts and the Subledger accounting tables as follows:

Transaction 1:
Inventory Valuation Account : Credit. (item_cost)
Deferred COGS account : Debit (item_cost)

Transaction 2:
Deffered COGS : Credit (Actual revenue percentage)
COGS : Debit (Actual revenue percentage )


COGS (Cost of Goods Sold) in Oracle E-Business Suite Release 12
Deferred COGS is a new feature introduced in Oracle E-Business Suite Release 12. The basic
fundamentals behind the enhancement are that the COGS are now directly matched to the
Revenue.

Prior to this enhancement, the value of goods shipped from inventory were expensed to COGS
upon ship confirm, despite the fact that revenue may not yet have been earned on that shipment.
With this enhancement, the value of goods shipped from inventory will be put in a Deferred
COGS account. As percentages of Revenue are recognized, a matching percentage of the value
of goods shipped from inventory will be moved from the Deferred COGS account to the COGS
account, thus synchronizing the recognition of revenue and COGS in accordance with the
recommendations of generally accepted accounting principles.

While this helps solve some key accounting issues, there are some key issues one needs to be
aware of:
 
• Currently Deferred COGS accounting cannot be turned off in Oracle EBS Release 12.
• The activity of recording COGS recognition is now a multi-step process
• Run AR Revenue Recognition, and Submit Accounting Processes
• Run a set of concurrent processes in Cost Manager to record Sales Order and revenue
recognition transactions and to create and cost COGS recognition transactions. These
COGS recognition transactions adjust deferred and earned COGS in an amount that
synchronizes the % of earned COGS to earned revenue on Sales Order shipment lines.
• Record Order Management Transactions: records new sales order transaction activity
such as shipments and RMA returns in Oracle Order Management.
• Collect Revenue Recognition Information: determines the percentage of recognized or
earned revenue related to invoiced sales order shipment lines in Oracle Receivables.
• Generate COGS Recognition Events: creates and costs COGS recognition events for
new sales order shipments/returns and changes in revenue recognition and credits for
invoiced sales order shipment lines.
The end result of these activities is a series of COGS Recognition Material Distributions.
However these distributions will not be visible on the Material Transaction screen, unless the
‘Include Logical Transaction’ checkbox is checked.

R12 Order Management: Revenue-COGS Matching Part I
It is a relief to see this much awaited functionality. We heard our accounting departments
complaining about the period mismatches in for our COGS and Revenue accounting for one
order. We ship an order on the last day of the month and COGS gets posted to this month, but if
the invoice is created with next period’s GL date as the current AR period is closed by the time
the order is invoiced. Now all that is changed. Revenue-COGS matching is a standard
functionality now. In simple terms, this means, COGS for an order line will be recognized only if
the revenue is recognized for that line making sure that the revenue and COGS are posted in the
same month.
All of us have spent a lot of time working on COGS accounting workflow to achieve what we
want for our clients/companies. In some cases we even customized Revenue accounting
generation (avoiding auto accounting logic) by using ra_interface, distributions_all table. We had
a handle on accounts generation in this process but not on the actual events of accounting
recognition.
We all know this.
When we ship the order and run the Interface Trip Stops program, inventory gets reduced and
orders get updated to move forward in the workflow to the next activity. Interface Trip Stops
program calls the OE_FLEX_COGS_PUB to generate the COGS account as per design. This
gets passed on to the mtl_material_transactions table in the distribution_account column. When
Cost Manager runs, distribution_account from mtl_material_transactions is picked up to generate
accounting as shown.
                                Cr Inventory Material account $100
                                            Dr COGS Account $100
The role of COGS
workflow is not changed. It is still the same which generates the account of our choice per
workflow design. It still passes the generated account to the mtl_material_transactions table into
the distribution_account column. But what changed in R12 is accounting. In order to match
Revenue with COGS accounting in terms of timing, COGS account cannot be used at the time
shipping. Instead revenue recognition process of the invoice for that order line should generate
COGS accounting.
To achieve this, a new account called Deferred COGS account is introduced at the inventory
organization parameters level. So when the order shipped instead of the above entries the entry
will be
                       Cr Inventory Material account             $100
                                    Dr Deferred COGS Account    $100
When you invoice is this order line, if you have no revenue recognition policies or specialized
accounting rules, revenue should be instantly recognized (upon running revenue recognition
program).
After revenue is recognized, the following programs need to be run to relieve deferred COGS
value and debit actual COGS account.
Record Order Management Transactions: This program collects all the transactions that
belong to transaction types Sales order issue and Logical Sales Order Issue which are not costed
and the order line is invoiceable. The source table is mtl_material_transactions. This program
inserts rows into two tables: cst_cogs_events and cst_revenue_cogs_match_lines. This program
is not necessary to run. When not run, Cost Manager will insert rows into these tables. So from
implementation considerations, this program is not required to be run.
Collect Revenue Recognition Information: This program collects invoice line information of
the order line after the revenue is recognized. The source tables are ra_customer_trx_lines_all
and ra_cust_trx_line_gl_dist_all. It will check the percentage of the revenue recognized (we can
recognize revenue partially for a specific order line based on accounting rule or contingency
rules) and inserts that information into this table: cst_revenue_recognition_lines. Also the table
cst_revenue_cogs_control table is updated with the latest run date with high date of this
parameter, which is used in the next run of the same program.
Generate COGS
Recognition Events: The role of this program is to record a logical material transaction, which
is used to create final COGS entry. This program takes information from the above tables and
creates one logical inventory transaction in mtl_material_transactions with a new transaction
type called COGS Recognition. In the same program these transactions will be costed (not by the
cost manager) creating the following accounting entries. The COGS account in this entry is taken
from the distribution_account in mtl_material_transactions table (which was generated earlier by
COGS workflow).
                                Cr Deferred account                     $100
                                              Dr COGS Account             $100
This is the concept in simple terms. There are different cases (well documented in the Cost
Management User Guide) in this same flow which, I will take one at a time to discuss in the
coming posts.
SQL statements that help understand the data model are below,
SELECT header_id
  FROM oe_order_headers_all
 WHERE order_number = &your_order_number;

SELECT line_id
  FROM oe_order_lines_all
 WHERE header_id = (SELECT header_id
                      FROM oe_order_headers_all
                     WHERE order_number = &your_order_number);

SELECT *
  FROM mtl_material_transactions
 WHERE trx_source_line_id IN (SELECT line_id
                                FROM oe_order_lines_all
                               WHERE header_id = (SELECT header_id
                                                    FROM oe_order_headers_all
                                                   WHERE order_number =
&your_order_number))
       AND transaction_type_id IN (33, 10008);

SELECT *
  FROM mtl_transaction_accounts
 WHERE transaction_id IN (
          SELECT transaction_id
            FROM mtl_material_transactions
           WHERE trx_source_line_id IN (SELECT line_id
                                          FROM oe_order_lines_all
                                         WHERE header_id = (SELECT header_id
                                                              FROM
oe_order_headers_all
                                                             WHERE
order_number = &your_order_number))
             AND transaction_type_id IN (33, 10008));

SELECT *
  FROM cst_revenue_cogs_match_lines
 WHERE cogs_om_line_id IN (SELECT line_id
                             FROM oe_order_lines_all
                            WHERE header_id = (SELECT header_id
                                                 FROM oe_order_headers_all
                                                WHERE order_number =
&your_order_number));

SELECT *
  FROM cst_cogs_events
 WHERE cogs_om_line_id IN (SELECT line_id
                             FROM oe_order_lines_all
                            WHERE header_id = (SELECT header_id
                                                 FROM oe_order_headers_all
                                                WHERE order_number =
&your_order_number));

SELECT *
  FROM cst_revenue_cogs_control;

SELECT *
  FROM ra_customer_trx_lines_all
 WHERE interface_line_context = 'ORDER ENTRY'
   AND interface_line_attribute6 IN (SELECT line_id
                                       FROM oe_order_lines_all
                                      WHERE header_id = (SELECT header_id
                                                           FROM
oe_order_headers_all
                                                          WHERE order_number
= &your_order_number));

SELECT *
  FROM ra_cust_trx_line_gl_dist_all
 WHERE customer_trx_line_id IN (
          SELECT customer_trx_line_id
            FROM ra_customer_trx_lines_all
           WHERE interface_line_context = 'ORDER ENTRY'
             AND interface_line_attribute6 IN (SELECT line_id
                                                 FROM oe_order_lines_all
                                                WHERE header_id = (SELECT
header_id
                                                                     FROM
oe_order_headers_all
                                                                    WHERE
order_number = &your_order_number))
             AND account_set_flag = 'N'
             AND account_class = 'REV');


SELECT *
  FROM cst_revenue_recognition_lines
 WHERE revenue_om_line_id IN (SELECT line_id
                                FROM oe_order_lines_all
                               WHERE header_id = (SELECT header_id
                                                    FROM oe_order_headers_all
                                                   WHERE order_number =
&your_order_number));

SELECT *
  FROM mtl_transaction_accounts
 WHERE transaction_id IN (
          SELECT transaction_id
            FROM mtl_material_transactions
           WHERE trx_source_line_id IN (SELECT line_id
                                          FROM oe_order_lines_all
                                         WHERE header_id = (SELECT header_id
                                                              FROM
oe_order_headers_all
                                                             WHERE
order_number = &your_order_number))
             AND transaction_type_id IN (33, 10008));

Oracle R12.2 new Features

Oracle Projects R12 New Features

Oracle Project Foundation

New Concurrent Process

• ADM: Purge Obsolete Projects Data

Oracle Project Costing

• Federal Budgetary Accounting for Project Expenditures via Subledger Accounting
• Contingency Worker Clearing Projects to allow CWK to charge multiple projects
• Additional Project Information in Oracle Time and Labor (Project Name and Task Name)

Federal Budgetary Accounting for Project Revenue

• Additional journal entries are available in Subledger Accounting for the required Federal Budgetary entries.

Date Effective Funds Consumption

• Project Type option that requires cost and event transaction dates to fall within the agreement start and end dates.
• Transactions are only billed against the agreement if the entire transaction amount can be funded (no partial recognition) for both revenue and invoicing.
• Without enabling this option, revenue generation supports partial billing for transactions.

New Parameters for MGT: Invoice Review

• Project Status
• Project Closed After Date
• Project Range

New Parameters for MGT: Unbilled Receivables Aging

• Project Status
• Project Closed After Date
• Project Range

 Oracle Project Management New Audit Process for Project Performance Reporting Setup

• AUD: Project Performance Reporting Setup

New Parameters for Refresh Project Performance Data Process

• Actual or All Amounts (Plan and Actual)
• Workplan Version
• Financial Plan Version

 Workplan EnhancementsAbility to Delete Published Workplan Versions (except the latest published version, baseline version, and workplan versions included in a program hierarchy) Usability Enhancements

• Update Work Breakdown Structure page is now obsolete.
• View, maintain, and update a workplan structure from the Update Tasks page.
• Where no latest published workplan version exists, the current working version displays on the Update Tasks page when navigating to the Workplan Tasks.
• Indent or outdent multiple workplan tasks in a single step.
• Confirmation, information, and warning messages appear on HTML pages during Apply Latest Progress as well as the Submit Progress processes. Messages include status information during processing and the availability of the latest progress information.

New Public API for Creating, Maintaining, and Deleting Programs New set of public API procedures:

• Designate a project as a program and indicate whether projects linked to the program can belong to multiple programs.
• Create links from a program to one or more projects
• Update links from a program to one or more projects
• Delete links from a program to one or more projects

Budgeting And Forecasting Enhancements Enhanced Automatic Calculation and Derivation Logic

• For plan lines that do not have a specified a quantity, the amount is no longer copied to the quantity field with the rate value set to 1.
• Rate now has a lower precedence than quantity and amount in automatic calculations.  The rate will be re-derived when the quantity, rate and amount are entered at the same time for a plan line.
• When the burden multiplier is overridden by updates to the raw cost or burden cost, subsequent calculations of the burden cost will use the override burden multiplier.  The same is true when the markup percent is updated by changes to plan line components:  the override markup percentage will be used in revenue calculations.

Enhanced Handling of Override Rates on Budget / Forecast Lines

• Override rates for a planning transaction on Edit Budget and Edit Forecast pages.

o   Raw Cost Rateo   Budened Cost Rateo   Bill Rate

• Override rates are applied to all existing and new periodic lines for the planning transaction.
• Average rates fields on these pages are now disabled for entry and are used for display only.

Simplified Addition of Planning Elements and Resources

• New but unbudgeted tasks and resources can be added to a budget or forecast version.
• Add either all new tasks and planning resources or new tasks only to the current plan version.

Self Service Expenditure Inquiry

• Ability to drill into expenditure details from the Financials tab.

Reporting Pack for Generation and Distribution of XML Publisher Reports

• A reporting pack is a set of report templates and recipients by project role.
• The Generate Reporting Pack concurrent program emails the reports generated from the report templates based on pre-defined intervals.
• The report template establishes each report’s layout and content.
• New reports templates are configured using XML Publisher tools.
• New or modified reports can be added to an existing reporting pack or be used to create an entirely new report set.
• Predefined data definition files that contain XML tags for performance measures and project data are provided.

Predefined Reports:

• Project Change Document Report
• Project Committed Cost Report
• Project Cost Detail Report
• Project Cost Labor Report
• Project Cost Summary Report
• Project Earned Value Report
• Project Financial Summary Report
• Project Forecast Summary Report
• Project Revenue At Risk Report

Budget Integration with Federal Budget Execution and/or 3rd Party Budget

• The budget integration workflow supports integration with the Federal Budget Execution module..
• The workflow can be customized to interface budget lines to external budgeting applications.

Microsoft Project 2007 Certification

• Integration with Microsoft Project 2007 is supported.

Project Performance Reporting: Additional MeasuresYTD, QTD and At Completion calculated measures are available on the following pages:

• Performance Overview Period-to-Date
• Summary/Analysis
• Task Summary/Analysis Resource Summary/Analysis

Project Performance Reporting: Inter-Project Revenue / Billing AmountsInter project revenue / billing amounts are available on the following pages:

• Project List View Workplan Cost
• Exception Reporting Performance Overview
• Task Summary/Analysis Resource Summary/Analysis
• Period-to-Date Summary/Analysis

 Supplier Cost DashboardSubcontractor Payment ControlsSupport for Pay when Paid Scenarios

• A new “Pay when Paid” payment term for subcontracts automatically places holds on all subcontractor invoices under that subcontract until the corresponding customer payment is received.
• Subcontract Payment Controls workbench allows project manager to manage the holds, with visibility into both the customer invoices and the related subcontractor invoices.
• Workflow notifications about the receipt of the customer payment allow the project manager to automatically or manually release the subcontract invoice.
• Associations between the customer invoices and the subcontractor invoices may be automatically maintained based on the billing of project expenditures for cost-plus contracts, or may be manually maintained for fixed price contracts.

Payment Controls for Subcontract Deliverables

• Support for the tracking and monitoring of subcontract deliverables that place automatic holds on subcontractor invoices in the case of noncompliance.
• Oracle Procurement Contracts allow a subcontract administrator to specify payment impact controls that will take effect when a subcontract deliverable is not met.
• From the Subcontractor Payment Controls workbench, the project manager can view a checklist of the all the current subcontract deliverables, to assist in evaluating the subcontractor status prior to releasing monthly progress payments.

Oracle Project Resource ManagementResource Search Enhancements

• Resource Search by Email Address
• Resource Search by Person Type
• Streamlined Navigation on Staffing Home

Cross Validation of Project and Assignment Dates

• Requirement start dates are equal to or greater than the project start date and less than the project end date and that finish dates are equal to or less than the project end date but greater than the project start date.
• Assignments cannot be added beyond the project end date.
• A project team role end date cannot be beyond the project end date. If the roles are created before the project end dates are entered, users will receive an error if they later try to enter an end date that is earlier than the end date for existing roles.
• When project transaction dates are moved corresponding assignment dates are validated against the new project dates. If the new project transaction dates fall outside the dates for existing assignments, users are given an option to shift the assignment dates or cancel the date adjustment.

Defaulting of Work Patterns’ From and To Dates

• Work pattern from and to dates will default from the requirement start and end dates.

Improved Exception Handling of Maintain Project Resources Process

• PRC: Maintain Project Resources delivers improved exception handling and notification when it encounters errors while processing employee records.

New Public APIs for Resource ManagementThe new PJR APIs fall into the following four categories:

• Requirement Public APIs
• Assignment Public APIs
• Candidate Public APIs
• Competence Public APIs

Organization Authority: Obsolete Forecast Authority

• Removes the forecast authority functionality from the organization authority form
• Removes existing security data relating to forecast authority.
• Replaces the PJR forecast functionality with the new HTML based forecasting functionality. The new forecasting functionality has its own security mechanism and does not honor the old forecast authority model.
• Improves the performance of security calls to organization authority because the existing security data is being removed.

Oracle Grants AccountingAward Budgeting Enhancements Budget period validations

• Budget periods will not be validated across award budgets when those awards fund a single project.
• Flexibility to establish award budgets based on the actual duration of the award, while not being confined based on the existing budgets already established for the project.

Automatic summarization of project budgets

• With the new budget period validations, automatically summarize to a project budget viewable in Project Status Inquiry.
• Two profile options have been added to identify the budget entry methods that will be used to summarize the project budgets.

Budget Line Sorting Option

• Sort budget lines by Resource name, or by effective dates for budgets with date range periods.  Provides the flexibility to view the budget lines by period or by budgeted resource.

Award Status Inquiry Enhancements View by budget period

• Allows the Find Award Status window to be limited to a single period, range of periods, or inception to date for a particular award.
• Reflects the budget periods entered on the award budget.

GL and PA Date Parameters on Find Expenditure Items window

• GL and PA date parameters have been added to the Find Expenditure Items window.

GL Date Parameters on Find Commitments window

• GL Date parameters have been added to the Find Commitments window.

GL Consolidation

Creating a Capital Asset in Oracle Projects

Create a capital project to collect construction-in-process (CIP) costs you want to place in service and send to Oracle Assets to become fixed assets.
You create an asset in Oracle Projects for each CIP asset you want to place in service. You generate summarized asset lines for each asset, which you can interface to Oracle Assets when the asset is ready to be placed in service. You can copy a capital project and its assets to create a new project.

Create a Capital Project
1. Enter the cost that you want to capitalize either in the Pre-approved expenditure entry or through transaction import or from Payables or other modules.
2. Run the distribute process for the type of cost that you are dealing with. (i.e labor, usage, and miscellaneous cost. )
3. If the item is from Payables, you need to run the ‘PRC: Interface Supplier Costs’ process.
4. Interface Raw Cost and Burden Cost to GL. You may need to run the suitable process from the list below:
PRC: Interface Labor cost to GL
PRC: Interface Total Burdened Cost to GL
PRC: Interface Usage and Miscellaneous Cost to GL
PRC: Interface Supplier Invoice Adjustments to AP(if item is from payables).
5. Define Assets under Projects
6. Assign Assets to a Task/Project in Oracle Projects.
7. Place the Assets in service.
8. Run the ‘PRC: Update Project Summary Amounts‘ to update the Cost buckets.
9. Run the ‘PRC:Generate Asset Lines’ process to generate Asset Lines in PA.
10. Run ‘PRC: Interface Assets’ process to interface Asset Lines to FA.
11. In Fixed Assets post the Asset Lines you have interfaced from PA to FA.
Things you may have to check before generating asset lines:
1. Check all the costs have been cost distributed( You need to run the appropriate cost distribution process
labor, expense, miscellaneous etc depending upon your expenditure type).

2. Check the project type for the project. In the capitalization information, alternate region it indicates whether raw or burden costs are being capitalized. If burden costs are used, then nothing will get picked up unless Distribute total Burden costs has been run.
3. Make sure that the assets have an in-service date and that the report parameter Date Placed In Service Through includes this date.
4. Check the PA Date Through parameter used. Note that this must be at least the last day of the period which includes the PA Date of the cost distribution lines of the expenditure.
If this date is not the last day of a period, the process will select the first date which is a last day of a period prior to the date entered.
Lets say your PA periods are like below:
JAN-13 01-JAN-13 to 31-JAN-13 FEB-13 01-FEB-13 to 28-FEB-13
If you have CDL’s with a PA date of 15-FEB-13, and you enter a PA date through 25-FEB-13, these CDL’s will not be picked up because the process will not actually use the date 25-FEB-13, but rather the first period ending date prior to that date, or 31-JAN-13.
5. Check the project status. In Setup-Projects-Status, make sure that the project’s current status has the Capitalize Assets action allowed.

Earned Value, Schedule Performance Index, CPI(Cost performance Index) formale

Earned Value#

Planned Value The total budgeted cost up to the analysis date.
Earned Value Calculated for the task using the following formula:

Earned Value = Current Budget x Physical Percent Complete

If the physical percent complete rollup method for the workplan is Effort, then earned value is based on effort. Otherwise, earned value is based on cost. Depending on the hysical percent complete rollup method, Oracle Projects uses either the baseline planned effort or cost for the task to determine the Current Budget.
Schedule Performance Index

Calculated for the task using the following formula:

Schedule Performance Index = Earned Value / Planned Value

Cost Performance Index

Calculated for the task using the following formula:

Cost Performance Index = Earned Value / Actual Cost

If the values are null, after running the project performance reporting requests(jobs) looks like Earned value is not getting calculated, cross check the budgets, physical percent complete complete rollup method for the workplan

R12 Tax setups

Step 1: Create the Tax RegimeThe tax regime is the highest/ultimate level that taxes are rolled up to, typically, a specific country. In this step, the Controls and Defaults must be set. The Control section outlines 4 options. Once the tax is made live, the control options cannot be changed.The Defaults section will default as applicable to the tax, status, jurisidiction, and tax rate levels, but they can be changed at each level.Step 2: Create the TaxOne Tax Regime can have multiple taxes defined under it. The tax type, e.g. sales, VAT, use, is determined when the tax is set up. Taxes can be set up by geography type, which allows for taxes at different levels.. For example, in the US, there is can be a tax levied at the State level, one at the County level, and one at the City level.Step 3: Create the Tax StatusThis is used primarily in the UK to define reduced rate, zero rate, etc. taxes. All taxes must have at least one tax status defined, and one of those must have the "Set as Default Status" option checked.Step 4: Create the Tax JurisdictionA tax jurisdiction is a geographic area for which a tax is levied, e.g.Colorado, California, Florida, El Paso County, Los Angeles.There must be at least one Tax Jurisdiction for each Tax Status with the "Set as default Tax Jurisdiction" selected and the "Default Effective Date" supplied.Step 5: Create the Tax RateCreate specific tax rates to be applied for a geography. There must be at least one default tax rate. The tax accounts are also set up in this step.Step 6: Define Tax RulesSet defaults for the following rule types:Place of Supply, Registration, Taxable Basis, Calculate Tax AmountsStep 7: Make the Tax Live for TransactionsReturn back to the Tax created in step 2, and select the Make Tax Available for Transactions option. If it is not available to be checked, the tax is not set up correctly. Any missed setups will need to be completed before this can be setup.