Translate

Thursday, October 31, 2013

What Are Concurrent Reports That Should Be Scheduled Periodically

The following requests should be scheduled:

"Purge Concurrent Request and/or Manager Data"
Concurrent Processing Tables and Purge Concurrent Request and/or Manager Data Program (FNDCPPUR)

"Workflow Background Engine"
1Ext/Pub How to Resolve the Most Common Workflow Background Engine Problems

"Purge Obsolete Workflow Runtime Data"
 Ext/Mod How to Purge WFERROR (System Error) Workflow Items?

"Workflow Control Queue Cleanup". Be sure to have that concurent program scheduled to run at regular intervals (6 to 12 hours is recommended).1066117.1
Ext/Pub Oracle Workflow Best Practices Release 12 and Release 11i


The following requests regarding the purge also should be reviewed:

FNDLGPRG - Purge Debug Log and System Alerts (AOL)
Ext/Mod Procedure to Purge FND_LOG_MESSAGES in Oracle Application Release 11i and Release 12?

FNDSCPRG - Purge Signon Audit data (AOL)
What Tables Does the Purge Signon Audit Data Concurrent Program Affect?

MSCATPPURG - Purge ATP Temp Tables
How Often Should the Program Purge ATP Temp Tables be Run?

Wednesday, October 30, 2013

GENERATE COGS RECOGNITION EVENTS NOT COMPLETING


SYMPTOMS


While  running the process "Generate COGS Recognition Events" from the OPM Financial Responsibility it is taking too much time. It is observed that the program is  running for more than 24 hours.



To implement the solution, please execute the following steps:

1. Ensure that you have taken a backup of your system before applying the recommended solution.

2. Run the following scripts in a TEST environment first:


Run the following steps before running the "Generate COGS recognition" which is usually done end of day with less production activities

shrink space for two tables mtl_transactions_interface and cst_revenue_cogs_match_lines.

Steps to shrink:

alter table inv.mtl_transactions_interface DEALLOCATE UNUSED;
alter table inv.mtl_transactions_interface ENABLE ROW MOVEMENT;
alter table inv.mtl_transactions_interface shrink space;
alter table inv.mtl_transactions_interface disable ROW MOVEMENT;

alter table bom.cst_revenue_cogs_match_lines DEALLOCATE UNUSED;
alter table bom.cst_revenue_cogs_match_lines ENABLE ROW MOVEMENT;
alter table bom.cst_revenue_cogs_match_lines shrink space;
alter table bom.cst_revenue_cogs_match_lines disable ROW MOVEMENT;

3. If you are satisfied with the results, issue a commit.

4. If you are satisfied that the issue is resolved, migrate the solution as appropriate to other environments.

Wednesday, October 23, 2013

RMA Receipt Fails with rvptcontrol failed, RVTPT-020: Subroutine rvtoe RmaPushApi() - UORA-06508

Error:

RVTPT-020: Subroutine rvtoe RmaPushApi() - UORA-06508: PL/SQL: could not find program unit being called in Package OE_RMA_RECEIVING Procedure Push_Receiving_info returned error
rvtptcontrol failed
RVTPT-020: Subroutine rvtoe_RmaPushApi() - UUser-Defined Exception in
Package OE_RMA_RECEIVING Procedure Push_Receiving_Info returned error
Cause: Subroutine rvtoe_RmaPushApi() - UUser-Defined Exceptio


CAUSE

Invalid objects in the system.


1. Resolve Invalid Objects that may be causing the problem:

select owner, object_name, object_type from all_objects where status='INVALID' order by owner,
object_name

2. Relink receiving executables:
cd $PO_TOP/bin
$ adrelink force=y ranlib=y "PO RCVOLTM"
$ adrelink force=y ranlib=y "PO RVCTP"

3. Bounce Receiving Transaction Manager:

- $ps -ef | grep RCVOLTM (to see how many processes are running)
-Deactivate Receiving Transaction Manager
(System Administrator > Concurrent > Manager > Administer)
-$ps -ef | grep RCVOLTM (repeat until no processes are running)
-Restart Receiving Transaction Manager

Tuesday, October 22, 2013

Actual Cost Calculation Methods

Actual Cost Calculation Methods

Following are actual cost calculation methods:

Period Weighted Average Cost (PWAC)

This is the strict average cost of the raw material during the period, based on the total estimated receipt (or invoiced) price for the entire inventory quantity. The period weighted average cost is a strict average cost for the period based on Period Total Quantity and Estimated or Final Prices.

PWAC is calculated by dividing -- the sum of the transaction quantity multiplied by price -- by the sum of transaction quantity, as shown in the following illustration:

the picture is described in the document text

Where:

Trans Qty - Receipt Quantities or AP interfaced quantities within the costing period

Price - Receipt estimated prices or AP invoice final prices within the costing period

Period Moving Average Cost (PMAC)

OPM calculates the average cost for the period while moving previous period's cost with last period's inventory balance and cost:

PMAC is calculated by dividing the result of -- the quantity of the prior period inventory balance multiplied by the prior period cost, plus the sum of the transaction quantity multiplied by price -- by the prior period inventory balance plus the sum of transaction quantity, as shown in the following illustration.

Where:

Prior Period Inv Balance - This is the prior period inventory balance captured from the inventory period ending balances.

Prior Period Cost - The prior period actual cost component from the cost component details table.

Trans Qty - Receipt Transaction Quantities or AP Interfaced Quantities within the costing period.

Price - Receipt estimated prices or AP invoice final prices within the costing period.

the picture is described in the document text

Perpetual Weighted Average Cost (PPAC)

The perpetual weighted average cost type computes the average cost for the entered receipts and quantities within the defined boundaries of the cost calendar. The calendar definition may in turn be identical to a fiscal year, or may span multiple fiscal years providing the flexibility of a variety of Perpetual Weighted Average cost methods.

PPAC is calculated by dividing -- the sum of the transaction quantity multiplied by price -- by the sum of transaction quantity, as shown in the following illustration:

the picture is described in the document text

Where:

Trans Qty - Receipt Quantities or AP interfaced quantities from the start of the costing calendar to the end of the current period.

Price - Receipt estimated prices or AP invoice final prices within the costing calendar.

Last Transaction Cost

There are two methods for determining last actual cost of a raw material:

LSTT - This method uses the last transaction within the costing period, regardless of whether the transaction is a receipt or an Accounts Payable invoice.

LSTI - This method uses the last Accounts Payable Invoice transaction within the costing period, even if there are latest receipts with estimated prices. In the absence of AP invoice transactions the latest receipt will be considered for the actual cost.

Last transaction cost adjustments will superseded any other transaction for the actual cost. For both methods, the adjustment unit cost is the actual cost.

Last Transaction (LSST) - OPM uses the last transaction in the costing period as the basis for the raw material cost (if there is no Accounts Payable invoiced cost for the period, the last receipt price is used to cost the raw material).

Last Invoice Transaction (LSTI) - OPM uses the last Accounts Payable invoice transaction in the costing period as the basis for the raw material cost, even if there are raw material receipt transactions that occur later in the period. If there are no Accounts Payable invoiced costs for the period, the last receipt price is then used to cost the raw material. Actual cost adjustments supersede any of the methods used to calculate actual cost - an adjusted cost is the actual cost.

Monday, October 7, 2013

Batch Close Variance

Batch Close Variances can occur in the following situations when using Actual Costing,
  • If the batch was released in one cost period and the debit to WIP is valued at one cost, but the batch was completed in a later cost period when the credit to WIP for the same quantities is valued at a different cost.
    This results in a left over balance WIP due to the cost change and must be cleared out.

  • Batch is released in one period and closed in the next period and has ingredient issues after last product yield and no product yield in next period.

  • When the Ingredient consumptions and product yields are recorded in a period, and in the next period the ingredient, resource, or byproduct consumptions for these batches are updated without any further product yields.
  • Ingredient issued in one period and returned back in next period with cost changes for ingredient across periods.
    - Essentially Ingredient/By-product transactions should be posted prior to product transactions in general, and certainly at least prior to last of product transaction so that such transactions do not contribute to batch close variance.

  • Cost Allocation factors on the Formula are not same as Cost Allocation Factors on the Batch Material details which could happen when using Dynamic Cost Allocation factors (profile option - GMF: Cost Allocation Factor Calculation - set to "Dynamic")
    Any cost allocation factor change made after a Batch is released ( as it happens in case of dynamic cost allocation factors) would require re-layering.
    Re-layering these Batches followed by running the Actual Cost Process, Cost Update and OPM-Preprocessor will eliminate the Batch Close Variances for these Batches.

  • The profile option - 'GMF: Batch Actual Cost Calculation Basis' is set to 'Use Virtual Incremental Backflush Quantities' for a situation where on a Batch all the Ingredients and Resources are not issued out Upfront.
    Virtual Incremental Backflush is essentially designed to address a common situation in process industries where most or all ingredients are issued upfront and there are multiple product yields. 
    Without using the Virtual Incremental Backflush, the first yield would be posted at very high cost and subsequent yields would be posted at zero cost.
    With Virtual Incremental Back flush, costs are apportioned based on the Formula setup even before transactions occur.
    Thus if those transactions do not actually occur prior to batch close, Batch Close Variances would result.

  • Use of Virtual Incremental Backflush with consumption activity and cost changes for ingredients across periods.