Applies to:

Oracle Advanced Supply Chain Planning - Version: 11.5.10 to 12.1

Information in this document applies to any platform.
Manufacturing Transactions processes, procedures
Goal
This document was produced for an Oracle Premier customer that wanted a consolid
ated list of investigative / repair sql addressing manufacturing processes. Th
e idea was to include DEV specific suggestions not published in Metalink (MyOrac
le Support) as well as known solutions in one doc to save time. The commentary
is derived from DEV, myself and Global Support.
The following SQL is meant to assist in debugging transactional issues and in so
me cases repair such transactions. This list is not exhaustive and not meant to
address all transactional errors. In some cases, Oracle development is relucta
nt to publish update SQL statements without having reviewed basic data. The fol
lowing select SQL statements are meant to be used to supply such data to Oracle de
velopment if so required OR enable customers to facilitate the repair on site.
Solution
==========
DISCLAIMER
==========
Of course, Oracle does not endorse the use of the following document UNLESS dire
cted
by Oracle Global Support or Oracle Development.
=====
USAGE
=====
* Always be cautious, taking backups or using TEST instance before implementing
in production.
* Using Find or CTRL F to navigate through this doc is the best way that I have
found to make
make my search easy and fast.
Conclusion
==========
At the end of this document you will find a list of transactions that are pendin
g review
and recommendation. This list is not exhaustive and will change.
QUESTIONS? Contact Jeffery.Goulette@Oracle.com
===============================================
TOPICS COVERED IN THIS DOCUMENT
===============================
FUNCTIONAL USER SQL INVESTIGATION and REPAIR
Best Practices Environment Initiation
DUPLICATE TRANSACTIONS SCRIPT
NEGATIVE BALANCES/AVAILABILITY
SERIAL NUMBERS SCRIPT
INVENTORY LOCATORS SCRIPT
INTERFACE TRIP STOP(ITS) TRANSACTION ERRORS

MONTH END CLOSING as VIEWED FROM THE INVENTORY ACCOUNTING PERIOD->Pending Transa
ctions
- The key steps to resolving pending transactions are
* Typical SQL that can be ran proactively:
Resolution Required Transactions:
UNPROCESSED MATERIAL TRANSACTIONS
PENDING MATERIAL TRANSACTIONS
UNCOSTED MATERIAL TRANSACTIONS EXIST for this PERIOD
PENDING WIP COSTING TRANSACTIONS EXIST in this PERIOD
PENDING RESOURCE TRANSACTIONS
PENDING MOVE TRANSACTIONS for this PERIOD
WIP Month End Uncosted Transactions mtl_material_transactions
RETURN MATERIAL AUTHORIZATIONS
* RECEIVING TRANSACTIONS
Uncosted WSM Transaction
Pending WSM Interface
Workflow PO Processes
SPECIAL CHARACTERS During ITEM IMPORT PROCESSES
- PO INVESTIGATION SQL
- For PO in WF
- PO as related to MTL_SUPPLY
- GENERAL PO INVESTIGATION
- Autocreate Purchase Orders from Requistions WF Investigation
- Currency mismatch in blanket PO
MFG mtl_supply table mismatch
SHIPPING TRANSACTION WF (extent issues)
OM WFt.
Inventory Transaction Interface Internal Sales Orders Stuck
MRP_SALES_ORDER_UPDATES
SALES ORDER DEMAND NOT PROCESSED MRP_RELIEF_INTERFACE
AP Distribution Related Errors Prevent Closing
Sourcing Rules Investigation
END TOPICS COVERED IN THIS DOCUMENT
===================================

Best Practices Environment Initiation

=====================================
set the org context using the following statement.
exec dbms_application_info.set_client_info(&operating_unit_id);
How to find the ORGANIZATION_ID run this script:
select organization_id, organization_code
from org_organization_definitions
where organization_name like xxx% ; ( xxx is organization name )
DUPLICATE TRANSACTIONS SCRIPT
----------------------------These scripts identify duplicates records in the transaction tables:
create or replace view mmt_mti_records_v as
select a.transaction_interface_id,
a.picking_line_id
from mtl_material_transactions b,
mtl_transactions_interface a

where
and
and
and
and
and
and

a.picking_line_id = b.picking_line_id
a.trx_source_line_id = b.trx_source_line_id
a.inventory_item_id = b.inventory_item_id
b.transaction_type_id = a.transaction_type_id
b.transaction_source_type_id in (2,8)
b.transaction_quantity <0
b.picking_line_id is not null;

create or replace view mmtt_mti_records_v as

select a.transaction_interface_id,
a.picking_line_id
from mtl_material_transactions_temp b,
mtl_transactions_interface a
where a.picking_line_id = b.picking_line_id
and
a.trx_source_line_id = b.trx_source_line_id
and
a.inventory_item_id = b.inventory_item_id
and
b.transaction_type_id = a.transaction_type_id
and
b.transaction_source_type_id in (2,8)
and
b.transaction_quantity <0
and
b.picking_line_id is not null ;
create or replace view mmt_mmtt_records_v as
select a.transaction_temp_id,
a.picking_line_id
from mtl_material_transactions b,
mtl_material_transactions_temp a
where a.picking_line_id = b.picking_line_id
and
a.trx_source_line_id = b.trx_source_line_id
and
a.inventory_item_id = b.inventory_item_id
and
b.transaction_type_id = a.transaction_type_id
and
b.transaction_source_type_id in ( 2,8)
and
b.transaction_quantity <0
and
b.picking_line_id is not null;
Now provide the output of the following:
select count(*)
from mmt_mti_records_v;
select count(*)
from mmtt_mti_records_v;
select count(*)
from mmt_mmtt_records_v;

NEGATIVE BALANCES/AVAILABILITY
-----------------------------Please run the following script to check for the correct on hand quantity
for the item. This procedure works on 11i or higher. (The package used
does not exist in 11.0.3 or 10.7)
set serveroutput on
prompt Enter Organization_id
accept org_id
prompt Enter Inventory_item_id
accept item_id
prompt Enter Subinventory Code

accept subinventory
DECLARE
L_api_return_status VARCHAR2(1);
l_qty_oh NUMBER;
l_qty_res_oh NUMBER;
l_qty_res NUMBER;
l_qty_sug NUMBER;
l_qty_att NUMBER;
l_qty_atr NUMBER;
l_msg_count NUMBER;
l_msg_data VARCHAR2(1000);
BEGIN inv_quantity_tree_grp.clear_quantity_cache;
dbms_output.put_line( Transaction Mode );
apps.INV_Quantity_Tree_PUB.Query_Quantities (
p_api_version_number => 1.0,
p_init_msg_lst => apps.fnd_api.g_false,
x_return_status => L_api_return_status,
x_msg_count => l_msg_count,
x_msg_data => l_msg_data,
p_organization_id => &org_id,
p_inventory_item_id => &item_id,
p_tree_mode => apps.INV_Quantity_Tree_PUB.g_transaction_mode,
p_onhand_source => NULL,
p_is_revision_control=> false,
p_is_lot_control => FALSE,
p_is_serial_control => FALSE, p_revision => NULL,
p_lot_number => NULL,
p_subinventory_code => &Subinventory ,
p_locator_id => NULL,
x_qoh => l_qty_oh,
x_rqoh => l_qty_res_oh,
x_qr => l_qty_res,
x_qs => l_qty_sug,
x_att => l_qty_att,
x_atr => l_qty_atr ); dbms_output.put_line( Quantity on hand ||to_char(l_q
ty_oh));
dbms_output.put_line( Quantity res oh ||to_char(l_qty_res_oh));
dbms_output.put_line( Quantity res ||to_char(l_qty_res));
dbms_output.put_line( Quantity sug ||to_char(l_qty_sug));
dbms_output.put_line( Quantity ATT ||to_char(l_qty_att));
dbms_output.put_line( Quantity ATR ||to_char(l_qty_atr));
end; /

SERIAL NUMBERS SCRIPT

--------------------1) To identify Serial Number Information such as status and location:
select substr(msn.serial_number,1,15) "Serial Num",
substr(msn.current_status,1,6) "Status",
substr(decode(msn.group_mark_id,NULL, No Value ,
msn.group_mark_id),1,8) "Mark Id",
substr(decode(msn.line_mark_id,NULL, No Value ,msn.line_mark_id),1,8) "Ln Id
",
substr(decode(
msn.lot_line_mark_id,NULL, No Value ,msn.lot_line_mark_id),1,12) "Lot Mar
k Id",
substr(msn.inventory_item_id,1,9) "Item Id",
substr(msn.current_organization_id,1,9) "Org Id",

substr(msn.current_subinventory_code,1,15) "Current Subinv",

substr(decode(
msn.current_locator_id,NULL, No Loc ,msn.current_locator_id),1,9) "Loc I
d"
from mtl_serial_numbers msn
where serial_number = &Serial_Number ;
2) Run this script to identify serial number transactions history in both tables
:
MTL_MATERIAL_TRANSACTIONS (Transaction Historical) and
MTL_UNIT_TRANSACTIONS (Serialized/Lot Transaction Historical).
select substr(mmt.transaction_id,1,15) "Txn Id",
substr(mut.transaction_id,1,15) "Txn Id2",
substr(mut.serial_number,1,15) "Serial",
substr(mmt.transaction_date,1,15) "Txn Date",
substr(mut.transaction_date,1,15) "Txn Date2",
substr(mmt.inventory_item_id,1,15) "Item Id",
substr(mmt.organization_id,1,10) "Org",
substr(mmt.subinventory_code,1,20) "Subinv",
substr(mmt.transaction_type_id,1,15) "Txn Type",
substr(mmt.transaction_quantity,1,15) "Txn Qty",
substr(mmt.primary_quantity,1,15) "Pri Qty"
from mtl_material_transactions mmt,
mtl_unit_transactions mut
where mmt.transaction_id = mut.transaction_id
and
mut.serial_number = &Serial_number
and
mmt.organization_id = mut.organization_id
and
mmt.inventory_item_id = mut.inventory_item_id;

INVENTORY LOCATORS SCRIPT

------------------------Locators Script: These scripts are used to identify Locator information
before datafixes.
1) Identify locator and item number.
select msl.inventory_item_id ITEM_ID,
msl.organization_id ORG_ID,
msl.secondary_locator LOCATOR_ID,
msl.subinventory_code SUBINVENTORY
FROM mtl_secondary_locators msl,
mtl_item_flexfields mif
WHERE mif.item_number = &item number
AND mif.inventory_item_id = msl.inventory_item_id
AND mif.organization_id = msl.organization_id
AND mif.organization_id = &Org_id;
2) select inventory_location_id LOCATOR_ID,
organization_id ORG_ID,
subinventory_code SUBINVENTORY,
segment1 || + || segment2 || + || segment3 || + || segment4 LOCATOR
FROM mtl_item_locations
WHERE inventory_location_id in (<locator_id>, <locator_id>, )
SCRIPT #3&4, below, have Patchset G considerations:
For Patchset lower than INV G:

3) select substr(create_transaction_id,1,8) "Create Txn Id",

substr(update_transaction_id,1,8) "UpTxn Id",
substr(locator_id,1,8) "Loc Id",
substr(transaction_quantity,1,8) "Txn Qty",
substr(inventory_item_id,1,8) "Item Id",
substr(organization_id,1,8) "Org Id",
substr(subinventory_code,1,15) "Subinv"
from mtl_onhand_quantities
where inventory_item_id = &item_id
and organization_id = &org_id
and subinventory_code = &subinv ;
For Patchset INV G or higher:
4) select substr(create_transaction_id,1,8) "Create Txn Id",
substr(update_transaction_id,1,8) "UpTxn Id",
substr(locator_id,1,8) "Loc Id",
substr(transaction_quantity,1,8) "Txn Qty",
substr(inventory_item_id,1,8) "Item Id",
substr(organization_id,1,8) "Org Id",
substr(subinventory_code,1,15) "Subinv"
from mtl_onhand_quantities_detail
where inventory_item_id = &item_id
and organization_id = &org_id
and subinventory_code = &subinv ;
5) select substr(transaction_id,1,8) "Txn Id",
substr(transaction_type_id,1,8) "Txn Type",
substr(transaction_quantity,1,8) "Txn Qty",
substr(primary_quantity,1,8) "Prim Qty",
substr(inventory_item_id,1,8) "Item Id",
substr(organization_id,1,9) "Org Id",
substr(subinventory_code,1,15) "Subinv",
substr(locator_id,1,9) "Loc Id"
from mtl_material_transactions
where transaction_id = &txn_id <enter transaction id from previous script (3)
>;
6) select substr(transaction_id,1,9) "Txn Id",
substr(inventory_item_id,1,9) "Item Id",
substr(organization_id,1,9) "Org Id",
substr(subinventory_code,1,15) "Subinv",
substr(locator_id,1,9) "Loc Id",
substr(transaction_date,1,12) "Txn Date"
from mtl_unit_transactions where transaction_id = <enter transaction id>;
INTERFACE TRIP STOP(ITS) TRANSACTION ERRORS
------------------------------------------- To obtain detailed information regarding unprocessed Shipping Transaction Navi
gation:
Order Management > Shipping > Interfaces; Run, Single Request "Interface Trip
Stop-SRS program.
Submit the program with parameters below:
Mode: All
- Delivery: get from LOV
- Log Level : 5
The following are the some of the frequent, generic types of data corruption iss
ues

that occur during the month end process.

---------------------------------------------------------------------------------1) Error in ITS LOG : The customer is still getting the following workflow error
:
ORA-20002: 3100: Item OEOL/538957 does not exist. in Package
OE_ORDER_WF_UTIL Procedure Create_LineFork
Error msg: ORA-20002: 3100: Item OEOL/538957 does not exist. in Package
OE_ORDER_WF_UTIL Procedure Create_LineFork .
Cause : The root cause of the failure in trip stop is that, the service(warranty
)
line attached to this Shippable line has been closed (before upgrade) and no WF
information
available. Trip stop is failing to find the WF info for the service line.
Sample Solution :
update oe_order_lines_all
set model_remnant_flag= Y ,
line_set_id=null,
service_reference_line_id=null
where line_Id in (538956,538957,538962,538963);
commit;
exit;
After the above update the ITS has to be rerun so to process the Orderline
further.
2) Error in ITS LOG : InterfaceTripStop: result of INVENTORY interfacing stop_id
413210 =
ERROR: unknown status = InterfaceTripStop: Stopping because of ERROR.
Sample Solution :
UPDATE WSH_DELIVERY_DETAILS
SET transaction_temp_id = null
WHERE delivery_detail_id = 960210322;
Commit;
Subsequently run Interface Trip Stop.
3) Also we might encounter cases where Unprocessed Shipping Transactions
not allowing month end close .The cause here is due to Inventory Interface
flag is N where as the other processes(OM and Receivables interfaces have
gone through correctly. The fix would be to reset the process_flag in
WSH_TRIP_STOPS table so that ITS will pick it up again. If this does not
work then we may need to do Miscellaneous Issue(make sure COGS account is sam
e),
set Inventory Interface flag to Y for the problemmatic line after obtaining
customer approval.
4) To relieve reservations after Order Shipments there is a standard script (i24

71362.sql)
available from patch: <<2471362>>.
5) You can request/search for the script, Cancelorderline1.sql. Use cancel the
order line for
which we need to pass the Order Line Id as the parameter. This script helps
you to cancel
the order line when User wishes to cancel order lines and encounter errors.
6) To discover stuck deliveries:
The navigation to find out the stuck deliveries:
Shipping>Interfaces>Run>Interface Trip Stop - SRS.
In this program there is a parameter for Delivery Id. The LOV for this retri
eves all
deliveries(stuck as well as delivery which has not yet been picked up). As
this program
is running at scheduled intervals it is most likely that only stuck records a
re in the LOV.
User would need to find out whether the Delivery belongs to their sales order
by querying
on the delivery from shipping transactions form.
To get the stuck deliveries in the ITS log, set the OM debug to 5 and run ITS
and the log
will contain all the stuck delivery numbers. However , depending on the natu
re of the problem
reported please check the data from back end before suggesting any scripts.
MONTH END CLOSING as VIEWED FROM THE INVENTORY
ctions
If there are errors, sometimes the transaction
tting it.
Select the lines to be re-submitted. Or go to
ines selected
for re-submission will show up in blue and the
the record
this will re-submit the items.

ACCOUNTING PERIOD->Pending Transa

can be cleared by simply re-submi
the tools menu and select all. L
submit box will be checked. Save

NOTE: LINES WILL NOT BE RE-SUBMITTED UNTIL THE RECORD IS SAVED!

The key steps to resolving pending transactions are:
- Locate the transactions
- Find the error message to determine what is preventing the transactions from p
rocessing.
- Resolve the error
- Resubmit the pending record.
Typical SQL that can be ran proactively:
MTL_MATERIAL_TRANSACTIONS_TEMP
------------------------------ INCTCM is the Transaction Manager for this Table
select count(*) from mtl_material_transactions_temp
where acct_period_id = &acct_period_id;
MTL_MATERIAL_TRANSACTIONS

------------------------- CMCTCM is the Cost Manager for the records to be costed in this table.
- CMCCCM is the Cost Collection Manager for the records to be imported to Projec
t Mfg.
select count(*) from mtl_material_transactions
where costed_flag in ( N , E ) and acct_period_id = &acct_period_id;
MTL_TRANSACTIONS_INTERFACE
-------------------------- INCTCM is the Transaction Manager for this Table.
select count(*) from mtl_transactions_interface
where acct_period_id = &acct_period_id;
WIP_COST_TXN_INTERFACE
---------------------- Resource Cost Worker processes records in this table.
select count(*) from WIP_COST_TXN_INTERFACE
where acct_period_id = &acct_period_id;
WIP_MOVE_TXN_INTERFACE
---------------------- Wip Move Transaction Worker processes records in this table (WICTCM)
select count(*) from WIP_MOVE_TXN_INTERFACE
where acct_period_id = &acct_period_id;
Resolution Required Transactions
-------------------------------- Unprocessed Material indicates that there are unprocessed material transactions
in the MTL_MATERIAL_TRANSACTONS_TEMP table.
- Uncosted Material indicate there are material transactions in the MTL_MATERIAL_
TRANSACTIONS
table with unprocessed accounting entries.
- Pending WIP Costing transactions indicate there are unprocessed resource and ov
erhead
accounting transactions in the
UNPROCESSED MATERIAL TRANSACTIONS
--------------------------------Unprocessed material transactions exist for this period. This message indicates
you have
unprocessed material transactions in the MTL_MATERIAL_TRANSACTIONS_TEMP table. Y
ou are unable
to close the period with this condition. Please see your system administrator. I
nventory considers
entries in this table as part of the quantity movement. Closing the period in t
his situation
is not allowed because the resultant accounting entries would have a transaction
date for a
closed period, and never be picked up by the period close or general ledger tran
sfer process.
- Is the Cost Manager down?
- If the Costed = Error, then the transaction has failed costing
If there are rows, as verified by Pending Transaction screen:
- How to find the WIP_Entity_Id run this script:
select wip_entity_id
from wip_entities
where wip_entity_name = < Wip job or repetitive assembly>

and organization_id=

xxx ; ( xxx is organization id )

select transaction_header_id,
organization_id,
transaction_date,
transaction_mode,
error_code
from mtl_material_transactions_temp
where error_code is not null
order by transaction_date;
Fix the problem for the transaction_header_id with error code specified.
Resubmit the records via the following SQL statement:
Update TL_MATERIAL_TRANSACTIONS_TEMP
Set POCESS_FLAG = Y ,
LOCK_FLAG
= N ,
RANSACTION_MODE = 3,
ERROR_CODE = NULL
where TRANSACTION_HEADER_ID = &TRANSACTION_HEADER_ID ;
If there are Pending Transactions that are stuck in the MTL_MATERIAL_TRANSACTION
S_TEMP table
with transaction_type_id=5 (backflush/wip transactions) with proces_flag =E, the
y need to
be submitted.
------------------------------------------------------------------------------------------To investigate why the Transactions are Failing, run the following SQL Script:
select transaction_source_id,
inventory_item_id,
process_flag,
error_code,
error_explanation,
transaction_source_type_id,
organization_id
from mtl_material_transactions_temp
where process_flag = E
and transaction_source_id= ;
To resubmit the transactions use this script:
Update mtl_material_transactions_temp
set process_flag = Y ,
lock_flag = N ,
transaction_mode= 3,
error_code = NULL,
error_explaination = NULL
where process_flag = E
and transaction_source_id= ;
PENDING MATERIAL TRANSACTIONS
----------------------------- The erred records can be resubmitted via the following SQL statement:
Update MTL_TRANSACTIONS_INTERFACE
Set PROCESS_FLAG = 1,
LOCK_FLAG = 2,
TRANSACTION_MODE = 3,
ERROR_CODE = NULL

Where PROCESS_FLAG = 3;
- The Process transaction interface (short name INCTCM) is the manager that will l
aunch
the Inventory transaction worker (short name INCTCW) to process the transactions
in the
MTL_TRANSACTIONS_INTERFACE table. If the error message in the Transactions Int
erface window
is not clear reviewing the log file of the Inventory transactions Worker may pro
vide more
information that could help in resolving the error.
UNCOSTED MATERIAL TRANSACTIONS EXIST for this PERIOD
---------------------------------------------------- This message indicates you have material transactions in the MTL_MATERIAL_TRAN
SACTIONS
table with no accounting entries (Standard Costing) and no accounting entries
and no costs
(Average Costing). You are unable to close the period with this condition. The
se transactions
are part of your inventory value. Closing the period in this situation is not
allowed because
the resultant accounting entries would have a transaction date for a closed pe
riod, and never
be picked up by the period close or general ledger transfer process. Generall
y these
are Resource transactions which cannot be processed
Return the number of MMT rows with costed_flag =

select count(*) from mtl_material_transactions where costed_flag =

E ;

OR use the following to identify these rows by date:

select count(*),
transaction_date
from mtl_material_transactions
where costed_flag = E
group by transaction_date;
OR use the following:
select count(costed_flag) total,
costed_flag cflag,
substr(error_code,1,40) Code,
substr(error_explanation,1,100) Explan
from mtl_material_transactions
having costed_flag IN ( E , N )
group by costed_flag, error_code, error_explanation;
To Return the number of MMT rows with costed_flag = E
select count(*)
from mtl_material_transactions
where costed_flag = E
and error_explanation is null;

and no error message:

To Determine the number and type of MMT cost errored transactions:

select count(*),
transaction_type_id TxnTyp,
transaction_action_id TxnAct,
transaction_source_type_id TxnSrsTyp
from mtl_material_transactions
where costed_flag = E
and error_explanation is null
group by transaction_type_id, transaction_action_id,
transaction_source_type_id;
At this point check the "Material costs transaction worker".
If unable to locate the worker with the error info you should attempt to
resubmit the rows via SQL Plus as follows:
!FIRST SHUT DOWN THE COST MANAGER!
update mtl_material_transactions
set costed_flag = N ,
transaction_group_id = null
where costed_flag is not null;
commit;
Then locate the latest request for the worker. The correct worker request shoul
d be the
one that completes with warning. This worker will contain the error reason for
each failed
transaction by transaction id #.
Problem 1
--------If the following error message appears in the Material Transaction
Cost Worker:
APP-00001 cannot find message name inv_no_update.
Uncosted material transactions in mtl_material_transactions
table with costed_flag = E.
The transactions are WIP component transactions that do not corresponding
rows in the MTL_MATERIAL_TXN_ALLOCATIONS and/or WIP_PERIOD_BALANCES tables.
If these rows are missing you will need to run one of the following two
scripts depending on the type of job the client using in WIP.
- Discrete Jobs
- Repetitive Jobs

cm276916.sql (check for latest SQL in Metalink)

cm325557.sql (check for latest SQL in Metalink)

The script will recreate the necessary rows in the tables. Then reset flags and
rerun the cost manager. (See Problem 2)
Problem 2
--------The cost manager or cost worker did not finish processing
all the transactions. Use the following sql script to reset
transaction flags. The next time the cost manager runs the stuck rows
will be processed.
update mtl_material_transactions

set costed_flag = N ,
transaction_group_id = NULL
where costed_flag = E or costed_flag = N

PENDING WIP COSTING TRANSACTIONS EXIST in this PERIOD

----------------------------------------------------This message indicates you have unprocessed resource and overhead accounting tra
nsactions in
the WIP_COST_TXN_INTERFACE table. You are unable to close the period with this c
ondition. These
transactions are in your work in process value, and awaiting further processing.
Closing the
period in this situation is not allowed because the resultant accounting entries
would have a
transaction date for a closed period, and never be picked up by the period close
or general ledger
transfer process.
The following updated statement will reset flags for any WIP cost transactions t
hat are stuck
in the WIP Cost Interface.
select transaction_id, request_id, group_id,
process_status , wip_entity_name
from wip_cost_txn_interface
where process_status in ( 1,3) ;
(Process_status= 1 indicates Pending 3 indicates "Error" )
(ie. only uncosted transactions exist in this table)
Update WIP_COST_TXN_INTERFACE
Set GROUP_ID = NULL,
TRANSACTION_ID = NULL,
REQUEST_ID = NULL,
PROCESS_STATUS = 1
Where PROCESS_STATUS = 3;
If you are using Average Costing, then verify that a Transaction has not errored
out in
MTL_MATERIAL_TRANSACTIONS. If a Transaction errored out there, other transaction
s will not
be costed in WIP_COST_TXN_INTERFACE.
If using Average Costing, then All Transactions are processed sequentially. If o
ne transaction errors
out, then no further processing can be done.
PENDING RESOURCE TRANSACTIONS
----------------------------- Navigate Work in Process Responsibility -> Resource Transactions -> Pending Re
source Transactions
NOTE: This form queries the WIP_COST_TXN_INTERFACE table
Records can be updated, deleted, and resubmitted via the form.
- Clearing Pending Resource Transactions in error. For each step, inactivate cos
t manager then
restart after update script:
NOTE: Process_phase = 1 will go through validation again Process_phase = 2 wi

ll simply be processed
Process_phase = 3 is error
update wip_cost_txn_interface
set process_phase = 2,
process_status = 1,
group_id = null
where process_status = 3
and basis_type = 1
(depending on your txn)
and transaction_type = 2; (depending on your txn)
commit;
PENDING MOVE TRANSACTIONS for this PERIOD
----------------------------------------This message indicates you have unprocessed shop floor move transactions in the
WIP_MOVE_TXN_INTERFACE
table. If this condition exists, you will receive a warning but will be able to
close the accounting
period. These transactions are not in your work in process value. However, aft
er you close the period,
these transactions cannot be processed because they have a transaction date for
a closed period.
- Navigate Work in Process Responsibility -> Move Transactions -> Pending Move T
ransactions
* This form queries the WIP_MOVE_TXN_INTERFACE table
* Records can be updated, deleted, and resubmitted via the form.
The following updated statement will reset flags for any WIP move transactions t
hat are stuck in the
WIP Move Interface. wip_move_txn_interface
select count(*)
from wip_move_txn_interface
where process_status = 3 ;
Update WIP_MOVE_TXN_INTERFACE
Set GROUP_ID = NULL,
TRANSACTION_ID = NULL,
PROCESS_STATUS = 1
Where TRANSACTION_ID = &TRANSACTION_ID;
Pending WIP Move Transactions?
-----------------------------Restart the interface managers (Move & Cost Manager).
Launch the Move Transaction Manager even if the TP:WIP Move Transaction Profile
Option =
on-line processing. (Navigation -> Inventory/Setup/Transactions/Interface Manage
rs), use the
"Launch Manager" button under the special option on the tool bar.
WIP Month End Uncosted Transacitons mtl_material_transactions
------------------------------------------------------------When Closing the Inventory Period End, you may receive a message saying that you
cannot close
the Period End because a specified number of Uncosted Transactions exist. This c
an happen when
the Cost Manager job comes down or is taken down during run time, leaving some T
ransactions in an

in between state, with a request_id but costed_flag set to

N .

While in Standard Costing the error message is listed in the log file of the cos
t worker. In Average
Costing the error is detailed in the MMT table itself (error_code, error_explana
tion).
There must be no Uncosted Transactions for the Job in MTL_MATERIAL_TRANSACTIONS
(WHERE COSTED_FLAG IN ( N , E ))
------------------------------------------------------------------------------select request_id, costed_flag, transaction_id,
transaction_group_id, inventory_item_id, transaction_source_id
from mtl_material_transactions
where costed_flag in ( N , E )
and transaction_source_type_id=5
and organization_id = < org. id > ;
IMPORTANT: Ensure that your Cost Manager is NOT running against this Schema.
Create a backup table for the records you are updating (always a good practice);
create table mtl_material_txn_bkup as
(select * from mtl_material_transactions
where costed_flag in ( N , E );
Update the records for re-submission to the Cost Manager.
update mtl_material_transactions
set costed_flag = N ,
request_id = NULL,
transaction_group_id = NULL,
error_code = NULL,
error_explanation = NULL
where costed_flag in ( N , E );
- Re-start the Cost Manager to run against this schema .
RETURN MATERIAL AUTHORIZATIONS
-----------------------------RMA s have been known to create errors. The following update statement will cor
rect t
he transactions:
update mtl_material_transactions_temp
set primary_quantity = transaction_quantity
where transaction_quantity > 0 and process_flag <>

4 ;

Then run the update to reset the flags to reprocess the transactions.
This update statement will reset the flags so that the next time
the Material Transaction manager run it will process the transactions
Note: records with a process flag of 4 are OE transactions and should
not be updated.
update mtl_material_transactions_temp
set process_flag = Y ,
lock_flag = N ,
transaction_mode = 3,
error_code = NULL,

error_explanation = NULL
where process_flag in ( Y , E )
RECEIVING TRANSACTIONS
---------------------The following are used to investigate receiving transactions. Followed by an up
date statement.
select * from rcv_transactions_interface
where source_document_code = RMA ;
select * from po_interface_errors where interface_transaction_id in
(select interface_transaction_id from rcv_transactions_interface
where source_document_code = RMA );
select * from rcv_lots_interface where interface_transaction_id in
(select interface_transaction_id from rcv_transactions_interface
where source_document_code = RMA );
select * from rcv_serials_interface where interface_transaction_id in
(select interface_transaction_id from rcv_transactions_interface
where source_document_code = RMA );
select rsi.*
from rcv_serials_interface rsi,
rcv_transactions_interface rti,
mtl_transaction_lots_temp mtlt,
mtl_serial_numbers_temp mtst
WHERE rti.interface_transaction_id = rsi.interface_transaction_id
AND
mtlt.transaction_temp_id = rti.interface_transaction_id
AND
mtlt.SERIAL_TRANSACTION_TEMP_ID =
mtst.transaction_temp_id
update RCV_TRANSACTIONS_INTERFACE
set PROCESSING_STATUS_CODE= PENDING ,
PROCESSING_MODE_CODE= BATCH ,
TRANSACTION_STATUS_CODE = PENDING
where RECEIPT_SOURCE_CODE = CUSTOMER ;
- Then launch the Receiving Transaction Processor to process the records.
Uncosted WSM Transaction
-----------------------This message indicates you have unprocessed transactions in the WSM_SPLIT_MERGE_
TRANSACTIONS
table. You cannot close the period with this condition. These can be viewed t
hrough the WIP
Lot Transactions form: Shop Floor Manager > Lot Transactions > WIP Lot Transact
ions Clicking
on the Flash Light icon will bring up the find window. Selecting Null in the Transa
ction Type
field will select all WIP Lot Transactions, selecting something other than compl
ete in the Costed
field and the Transaction Dates for the period to query uncosted transactions.
Resubmitting Uncosted WSM transactions
-------------------------------------Running the "WIP Lot transactions Processor" (short name WSMPJUPD) will automati
cally pick up

all the erred and pending transactions

(ie. with status=3 (ERROR) or status=1 (PENDING) in WSM_SPLIT_MERGE_TRANSACTIONS
).
To run the WIP lot transactions processor
----------------------------------------Navigate to the WIP Lot Transactions Processor window. Choose Submit.
Pending WSM Interface
--------------------This message indicates that there were transactions that erred out while running
the Import WIP
lot Txn. Check WSM_INTERFACE_ERRORS to find information on the erred transactio
n.
These will need
to be re-submitted by a technical person at this time.
These will still permit you to close the period, but should be cleaned up before
Pending receiving
transactions for this period. When you use Purchasing, this message indicates y
ou have unprocessed
purchasing transactions in the RCV_TRANSACTIONS_INTERFACE table. These transacti
ons include purchase order receipts and returns for inventory. If this condition
exists, you will receive a warning but
will be able to close the accounting period. These transactions are not in your
receiving value.
NOTE: However, after you close the period, these transactions cannot be processe
d because they have a
transaction date for a closed period.
Script for identifying WSM transactions which are costed = error
---------------------------------------------------------------select wsm.transaction_id,
wsm.reason_id,
wsm.status,
wsm.costed,
wsm.organization_id,
mtl.organization_code
from wsm_split_merge_transactions wsm,
mtl_organizations mtl
where wsm.costed = 3
and wsm.organization_id = mtl.organization_id
Workflow PO Processes
----------------------If you do not have workflow monitor configured, you will need to follow these st
eps to process
the document:
A) Get the item_type and Item_key for the document:
select wf_item_key, wf_item_type, segment1, po_header_id
from po_headers_all
wheresegment1= <po number> ;
B) Run Wfstatus to verify that the document is not stuck for some other reason:
Using SQL*Plus, run
SQL> $FND_TOP/sql/wfstatus.sql <itemtype> <itemkey>

C) Verify that the document is not waiting for the background processor:
SQL> $FND_TOP/sql/wfbkgchk.sql
D) If the wfstatus showed an error, use wfretry to restart the approval:
SQL> $FND_TOP/sql/wfretry.sql <itemtype> <itemkey>
E) If all else fails, use the wf_engine to send the approval through.
SQL> exec wf_engine.startprocess( <itemtype> , <itemkey> );
F) Run wfstatus again to see where the document is.
Another tool that can be
of In Process is
the wfstatus.sql script;
n the directory
$FND_TOP/sql residing on
SQL*Plus using your APPS
ds:

used to diagnosis a document that remains with a status

it comes seeded with the application and can be found i
the database server machine. It is necessary to enter
schema. Once in SQL*Plus, perform the following comman

The wfstatus.sql script requires two values, the wf_item_type and the
wf_item_key. To locate the values please perform the following:
* For Reqs: select wf_item_type, wf_item_key
from po_requisition_headers_all
where segment1 = <insert req number here>
and
org_id = <insert org_id here>;
* For POs: select wf_item_type, wf_item_key
from po_headers_all
where segment1 = <insert PO number here>
and
org_id = <insert org_id here>;
Then, for both document types, perform the following commands. When running
the wfstatus.sql script, you will be prompted for two (2) parameters; the first
value should be
that of wf_item_type returned from the above statement, and the second value sho
uld be that of wf_item_key:
SQL> spool filename.lst
SQL> wfstatus.sql
SQL> spool off
Once the script has completed, the spool file results should be reviewed.
SELECT itemkey, execution_sequence, itemtype, authorization_status, debug_mess
age
FROM po_wf_debug
WHERE itemkey = &item_key and itemtype = &item_type
ORDER BY execution_sequence;
* For buyers who are no longer part of the company:
select substr(segment1,1,15),
substr(item_description,1,18),
quantity "QTY",
need_by_Date,
suggested_buyer_id "Buyer",
preparer_id,
org_id
from po_interface_errors c,
mtl_system_items a,
po_requisitions_interface_all b

where c.interface_transaction_id = b.transaction_id

and a.inventory_item_id = b.item_id
and c.error_message like The suggested buyer is not%
order by 7;
SPECIAL CHARACTERS During ITEM IMPORT PROCESSES
----------------------------------------------- We suggest a variation and customization of the following SQL logic:
update tablename set columnname = replace(columnname, X<list of not okay chara
cters> , X )
where replace(columnname, X<list of not okay characters> , X ) != columnname;
- You would have to do this with X<list of not okay characters> || chr(<#>) ||
chr(<#>)
- The only reason for the where clause is to avoid updates/redo whenever you don
t change the value.
- You have to have the X (or something else to keep) in the SQL because the thir
d parameter can t be null or nothing will be done
PO INVESTIGATION SQL
-------------------1. SELECT po_header_id,
agent_id,
authorization_status,
cancel_flag,
type_lookup_code,
closed_code,
frozen_flag,
user_hold_flag,
revision_num
FROM po_headers_all
WHERE segment1 = &po_num
and org_id = &org_id;
2. SELECT po_line_id,
cancel_flag,
quantity,closed_code
FROM po_lines
WHERE po_header_id = &po_header_id;
3. SELECT cancel_flag,
quantity,
quantity_cancelled,
closed_flag,
closed_code,
closed_date,
quantity_billed
FROM po_line_locations
WHERE po_header_id = &po_header_id;
4. SELECT po_line_id,
line_location_id,
po_distribution_id,
quantity_ordered,
quantity_cancelled,
quantity_delivered,
quantity_billed

FROM po_distributions_all
WHERE po_header_id = &po_header_id;
For PO in WF
-----------Please get us the output of the following sqls:
select wf_item_key from po_requisition_headers
where segment1 in (ENTER YOUR HEADER_IDS HERE);
For each of the wf_item_key, execute the below sql:.
select wias.ACTIVITY_STATUS_CODE
from
WF_ITEM_ACTIVITY_STATUSES_V WIAS,
WF_ITEMS_V WI
where WIAS.ITEM_TYPE = REQAPPRV
and
WIAS.ITEM_KEY = &x_item_key
and
WIAS.ITEM_TYPE = WI.ITEM_TYPE
and
WIAS.ITEM_KEY = WI.ITEM_KEY
and
WIAS.ACTIVITY_NAME= WI.ROOT_ACTIVITY ;
PO as related to MTL_SUPPLY
--------------------------select requisition_header_id
from po_requisition_headers_all
where segment1 in (ENTER YOUR HEADER_IDS HERE);
REQUISITION_HEADER_ID
--------------------202969
select count (*) from mtl_supply
where req_header_id = &req_header_id;
Enter value for req_header_id: 202969
old 2: where req_header_id = &req_header_id
new 2: where req_header_id = 202969
COUNT(*)
---------0
GENERAL PO INVESTIGATION
------------------------- Start of script
set lines 132
SELECT delivery_detail_id, source_line_id,
source_document_type_id,
source_document_id,
source_document_line_id
FROM oe_order_lines_all ol,
wsh_delivery_details wdd
where wdd.source_code = OE
and
wdd.source_line_id = ol.line_id
and
wdd.source_header_id in (51439,45620)
and
wdd.inv_interfaced_flag = P ;

select wdd.delivery_detail_id,
wdd.source_line_id,
pl.requisition_line_id
FROM po_requisition_lines_all pl,
po_req_distributions_all pd,
oe_order_lines_all ol,
wsh_delivery_details wdd
WHERE pl.requisition_line_id = ol.source_document_line_id
AND
pl.requisition_header_id = ol.source_document_id
AND
pl.requisition_line_id = pd.requisition_line_id
and
ol.line_id = wdd.source_line_id
and
ol.source_document_type_id = 10
and
wdd.source_code = OE
and
wdd.source_header_id in (51439,45620)
and
wdd.inv_interfaced_flag = P ;
-- End of script

Autocreate Purchase Orders from Requistions WF Investigation

-----------------------------------------------------------AutoCreate creates PO s from Requisitions, but instead of automatically
approving the PO s, the status remains Incomplete. Cst set the following
attributes:
- Is Automatic Creation Allowed? = Y
- Is Automatic Approval Allowed? = Y
1st) substitute in the requisition number for where you see ##### in
the statement below (for req created to PO)
select requisition_header_id from po_requisition_headers_all where
segment1 = ###### ;
2nd) substitute the requisition_header_id from script 1 where you see
#### in script 2 select item_type, Item_key, root_activity
from wf_items
where item_key like #### || %
and item_type= CREATEPO
and root_activity = OVERALL_AUTOCREATE_PROCESS ;
The results of this script will deliver an item_key and item_type - this
represents the first values that will be used for wfstatus. The output
from this wfstatus represents a text explanation for the Overall Create
Documents Process
3rd) It is now necessary to get the item_type and item_key for the two
sub-processes called during the Overall Create Documents Top Process we know these processes as Verify Req Line Information and Launch
Process to Create/Approve PO or Release . The ##### sign represents a
need for the value wf_item_key obtained from the 2nd script that was run
in step 2.

select item_type, Item_key, root_activity

from wf_items
where parent_item_type= CREATEPO
and parent_item_key = ##### ;
This process will return 2 records. If there is only one record
returned, then there is a breakdown occurring in the Verify Req Line
Information sub-process. Use the Item_key and Item_type from the 3rd
statement to run a wfstatus against the two sub-processes - Verify Req
Line Information as well as Create And Approve Purchase
Order/Release .
Actions for you to take:
1. The wfstatus will then get you the item attributes for the workflow you should confirm for sure that the attibute is set properly in the
CREATEPO workflow to in fact start the approval process.
2. If the approval process is being launched, you would then want to get
the wf_item_key from the po_headers_all for the new PO created - and run
wfstatus against that. See from the wfstatus why it is in fact not
being approved.
Perhaps the PO Approval is being launched and it is the Approval group
setups that are not set properly.
Currency mismatch in blanket PO
------------------------------SELECT default_rate_type
FROM po_system_parameters_all
WHERE org_id = &l_org_id; --Operating unit
SELECT currency_code, rate_type, rate, rate_date
FROM po_headers_all
WHERE po_header_id = &l_header_id;(Blanket PA and the PO)
SELECT fsp.set_of_books_id , glb.currency_code, glc.precision
FROM financials_system_params_all fsp,
gl_sets_of_books glb, gl_currencies glc
WHERE fsp.set_of_books_id = glb.set_of_books_id
AND glb.currency_code = glc.currency_code
AND fsp.org_id = &l_org_id; --Operating unit
select poh.po_header_id, pol.po_line_id, poh.segment1
from po_headers_all poh, po_lines_all pol
where poh.org_id = 84
and poh.segment1 = 97
and poh.po_header_id = pol.po_header_id;
PO_HEADER_ID PO_LINE_ID SEGMENT1
------------ ---------- -------------------8494
9566 97
select aii.invoice_id,
aii.invoice_num,
aii.invoice_amount h_amount,
ail.amount l_amount
from ap_invoices_interface aii, ap_invoice_lines_interface ail
where ail.po_header_id = 8494
and ail.po_line_id = 9566

and aii.invoice_id = ail.invoice_id;

INVOICE_ID INVOICE_NUM
H_AMOUNT L_AMOUNT
---------- --------------------- ---------- ---------3100 ERS-63-1955
9502
9050
select POH.PO_HEADER_ID PO_H_ID,
POL.PO_LINE_ID PO_L_ID,
POLL.LINE_LOCATION_ID L_LOC_ID,
POD.PO_DISTRIBUTION_ID PO_DIS_ID,
POD.RECOVERABLE_TAX,
POD.NONRECOVERABLE_TAX
from PO_HEADERS_ALL POH, PO_LINES_ALL POL,
PO_LINE_LOCATIONS_ALL POLL, PO_DISTRIBUTIONS_ALL POD
where POH.PO_HEADER_ID = POL.PO_HEADER_ID
and POL.PO_LINE_ID = POLL.PO_LINE_ID
and POLL.LINE_LOCATION_ID = POD.LINE_LOCATION_ID
and POH.SEGMENT1 = &segment1
and POH.ORG_ID = 84;
PO_H_ID
PO_L_ID L_LOC_ID PO_DIS_ID RECOVERABLE_TAX NONRECOVERABLE_TAX
---------- ---------- ---------- ---------- --------------- -----------------8655
9727
9089
9157
0
456
* Recoverable_tax and nonrecoverable_tax are already rounded.
MFG mtl_supply table mismatch
------------------------------SELECT requisition_line_id
FROM oe_po_temp opt
MINUS
SELECT missing_req_line_id
FROM corr_account_data;
SHIPPING TRANSACTION WF (extent issues)
----------------------------------------Identify shipment discrepancies
select mmt.shipment_number,mmt.inventory_item_id,
mmt.transaction_quantity qty,
mmt.transaction_action_id,
mmt.transaction_source_type_id,
mmt.organization_id,
rsh.shipment_header_id
from mtl_material_transactions mmt, rcv_shipment_headers rsh
where mmt.shipment_number is not null
and mmt.shipment_number = rsh.shipment_num
and transaction_type_id = 21
and not exists (select 1
from rcv_shipment_lines rsl
where rsh.shipment_header_id = rsl.shipment_header_id
and rsl.source_document_code = INVENTORY
and rsl.from_organization_id is not null
and rsl.to_organization_id is not null
and rsl.quantity_shipped = abs(mmt.transaction_quantity)
and rsl.item_id = mmt.inventory_item_id);

If this errors because of revisions, modify and run sql3

select ms.supply_type_code stcode,ms.supply_source_id,ms.item_id,ms.quantity,
ms.unit_of_measure,ms.to_org_primary_quantity,ms.to_org_primary_uom,
ms.shipment_header_id,ms.shipment_line_id,ms.rcv_transaction_id,
ms.expected_delivery_date,ms.destination_type_code,
ms.from_organization_id,ms.to_organization_id,ms.change_flag,
ms.po_header_id,ms.req_header_id
from mtl_supply ms,rcv_shipment_headers rsh
where ms.supply_type_code = SHIPMENT
and ms.shipment_header_id = rsh.shipment_header_id
and rsh.receipt_source_code = INVENTORY
and not exists (select 1
from rcv_shipment_lines rsl
where rsl.shipment_line_id = ms.shipment_line_id
and rsl.shipment_header_id = ms.shipment_header_id);
SQL3
select shipment_line_id,
last_update_date,
last_updated_by,
creation_date,
created_by,
last_update_login,
shipment_header_id,
from_organization_id,
to_organization_id,
to_subinventory,
request_id,
program_application_id,
program_id,
program_update_date,
unit_of_measure,
to_org_primary_uom,
item_id,
item_revision
from supply_back
where supply_type_code = SHIPMENT
and
shipment_header_id = 1694
and item_id = 10582
and from_organization_id = 87
and quantity = abs(-24 )
and nvl(item_revision, SDSD ) = nvl(null, SDSD );
The following columns can be null because of missing mtl_supply triggers
OR planning manager issues:
-

MRP_TO_ORGANIZATION_ID
MRP_EXPECTED_DELIVERY_DATE
MRP_PRIMARY_QUANTITY
MRP_DESTINATION_TYPE_CODE

Please check whether the POs that are NOT missing from the plan have a value
in the above colums.
The above fields are populated during the MPS relief as part of the planning
manager, if your planning manager is up while creating the PO, the relief occurs

and populates above fields in the mtl_supply.

1) Run the following sql to verify the triggers on mtl_supply:
select status from all_triggers
where trigger_name = MTL_SUPPLY_T ;
2) If this is enabled now ensure that the destination type is INVENTORY, run t
he
following SQL:
Select destination_type_code destination
from mtl_supply
where item_id =
(select inventory_item_id
from mtl_system_items
where segment1 = &youritem
and rowid =
(select min(rowid) from mtl_system_items
where segment1 = &youritem ));
3) Please make sure that the Planning Manager is up and running and let at least
one
cycle of Planning Manager is complete.
4) Check if there are any POs you have created that have NULL in your columns
(as indicated above). If you find any check for records in mrp_relief_interf
ace
with process_status = 4 (which means error) and the error_message column. Ta
ke
corrective action on the records with errors on this table and let these reco
rds
processed (i .e wait for another cycle of Planning Manager)
5) MTL_SUPPLY Mrp_ columns should be populated by now. Use the query for
step 9 below to verify the complete processing of your supply order.
5.1) Check whether You could see these planned orders in the inventory supply/de
mad window.
6) Run the following query:
select substr(po_number,1,10) po_nbr,
substr(DESTINATION_TYPE_CODE,1,10) dtype_code,
PO_REVISION_NUM po_rev,
MRP_EXPECTED_DELIVERY_DATE mrp_exp_deliv_dt,
MRP_PRIMARY_QUANTITY mrp_p_qty,
substr(MRP_PRIMARY_UOM,1,5) mrp_uom,
substr(mrp_destination_type_code,1,10) MRP_DEST_CODE,
MRP_TO_ORGANIZATION_ID mrp_to_org,
MRP_TO_SUBINVENTORY mrp_to_subinv,
ITEM_REVISION item_rev,
EXPECTED_DELIVERY_DATE exp_deliv_dt,
TO_ORGANIZATION_ID to_org_id
from po_po_supply_view
where item_id = (select inventory_item_id
from mtl_system_items
where segment1 = &your_item
and organization_id = po_po_supply_view.organization_id);
7) select organization_id,

inventory_item_id,
compile_designator,
order_type,
substr(po_number,1,15) po,
line_id,
revision
from mrp_item_purchase_orders
where inventory_item_id = (select inventory_item_id
from mtl_system_items
where segment1 = &youritem
and organization_id = mrp_item_purchase_orders.organization_id);
8) Once you ensure that there are no such records

please run the plan

9) IF you still find some missing POs, please create a SR and upload the DAT fil
es and
the plan log files the location of the DAT files can be found at
select file_name from mrp_files where compile_Designator=

&Plan_name

To speed the resolution of your SR it is good practice to recreate the MRP re

sults
while profiles MRP: Trace and MRP: Debug are set to TRUE.
Order Management Workflow and Troubleshooting
--------------------------------------------Please review the output of the following in xsl format:
select a.activity_label,
a.ACTIVITY_BEGIN_DATE,
a.ACTIVITY_END_DATE,
a.ACTIVITY_RESULT_CODE,
a.ACTIVITY_STATUS_CODE,
l.line_id,
l.org_id,
l.orig_sys_document_ref ord_num,
l.flow_status_code
from wf_item_activity_statuses_v a,
oe_order_lines_all l
where l.open_flag = Y
and a.item_type= OEOL
and a.activity_name = FULFILL_LINE
and (a.activity_status_code = ACTIVE or a.activity_end_date is null)
and a.item_key = to_char(l.line_id)
order by l.line_id;
Note that it is normal for the WF to be waiting at fulfill_line or SHIP_LINE. I
f a
line is in shipping process or shipped but not interfaced to OM, the WF will be
at
SHIP_LINE with result notified. If the order line is part of a fulfillment set o
r
invoice option is such that generates only one invoice per delivery the WF will
stay at FULFILL_LINE with result notified.
select
from
where
and

count(*)
oe_order_lines_all oel
oel.open_flag= Y
oel.shipping_interfaced_Flag= Y

and

exists ( select 1
from wsh_delivery_details wsh
where wsh.source_code= OE
and wsh.source_line_id = oel.line_id
and wsh.oe_interfaced_flag= N )
and not exists (select 1
from wf_process_activities wpa,
wf_item_activity_statuses st
where wpa.activity_name= SHIP_LINE
and
st.item_type= OEOL
and
st.activity_status= NOTIFIED
and
st.item_key = to_char(oel.line_id));
This query retrieves the count of problem lines where the order line has been in
terfaced
to Shipping, delivery details are ready for ship confirm/oe interface, but the W
F is not
at Ship Line Notified.
This query can also be used for monitoring the problem lines in future. For cu
stomer s
instant reference, DEV has created a SQL script find_stuck_ship_lines.sql. You
can request
a copy from Oracle Support. To start your investigation you can use the followi
ng to determine
issues with WF:
select
from
where
and
and

and

oel.line_id -- count(*)
oe_order_lines_all oel
oel.open_flag= Y
oel.shipping_interfaced_Flag= Y
exists ( select 1
from wsh_delivery_details wsh
where wsh.source_code= OE
and wsh.source_line_id = oel.line_id
and wsh.released_status= C
and wsh.oe_interfaced_flag= N )
not exists (select 1
from wf_process_activities wpa,
wf_item_activity_statuses st
where wpa.activity_name= SHIP_LINE
and
st.item_type= OEOL
and
st.activity_status= NOTIFIED
and
st.item_key = to_char(oel.line_id))

Inventory Transaction Interface Internal Sales Orders Stuck

------------------------------------------------------------Internal sales order stuck - awaiting shipping. Below is a general select state
ment followed by
two specific types of update statements:
SELECT organization_id,
transaction_interface_id,
transaction_type_id,
transaction_mode,
process_flag,
lock_flag,
error_code,
error_explanation, COUNT(*)

FROM mtl_transactions_interface
WHERE transaction_source_type_id = 8
GROUP BY organization_id, transaction_type_id, transaction_mode,
process_flag, lock_flag, error_code, error_explanation;
1) Transactions with a transaction_type_id of 50 (Subinventory Transfer sourced
by internal order)
are transactions where the transfer_subinventory field is null. Use the foll
owing update script
to provide the transfer_subinventory:
select transfer_subinventory
from mtl_transactions_interface
where transaction_interface_id = &ID_FROM_SQL_ABOVE;
If there is a problem with the subinventory problem use the update statement
below. Where
transfer_subinventory is a valid subinventory in org with org id that matches
your org that has
the error.
update mtl_transactions_interface
set transfer_subinventory = &transfer_subinventory
where transaction_interface_id = &ID_FROM_SQL_ABOVE;
commit;
Now resubmit this transaction and let the transaction manager process the same
.
2) Transactions with transaction_type_id of 54 (Direct xfer between 2 orgs on a
Internal Order)
are transactions where the transfer subinventory is null.
Please update the records with valid subinventory in org with org id that ma
tches your
organization with the errors:
update mtl_transactions_interface
set transfer_subinventory = &transfer_subinventory
where transaction_interface_id in (8410340 ,8410429);
l sql above
commit;

<-verify using genera

MRP_SALES_ORDER_UPDATES
----------------------MRP_Sales_Order_Updates Process_Status Codes
PROCESS STATUS-Description
Action
------------------------------------ -------------------------------------2- Waiting to be Processed
Make sure planning manager is running.
3- In Process
These rows are being processed by the
planning manager.
4- Error
Check ERROR_MESSAGE in the
MRP_SALES_ORDER_UPDATES table.
5- Successful completion.
The following query will reveal ALL open order lines with cooresponding rows stu
ck

in mrp_sales_order_updates with a process_status = 2,3 or 4. These order lines

will
be visible to MRP until reset is committed.
select
substr(oha.order_number,1,8) ord_num,
substr(ola.line_number,1,8) line_num,
substr(msou.request_id,1,10) req_id,
substr(msou.error_message,1,20) err_msg,
substr(msou.new_schedule_date,1,10) new_date,
substr(msou.old_schedule_date,1,10)old_date,
substr(msou.new_schedule_quantity,1,10) new_qty,
substr(msou.old_schedule_quantity,1,10)old_qty,
substr(msou.current_customer_id,1,10) curr_ct_id,
substr(msou.previous_customer_id,1,10) prev_ct_id,
substr(msou.current_bill_id,1,10) curr_bill,
substr(msou.previous_bill_id,1,10) prev_bill,
substr(msou.current_ship_id,1,10) curr_ship,
substr(msou.previous_ship_id,1,10) prev_ship,
substr(msou.current_available_to_mrp,1,10) curr_avail,
substr(msou.previous_available_to_mrp,1,10) prev_avail,
substr(msou.current_demand_class,1,10) curr_dmd,
substr(msou.previous_demand_class,1,10) prev_dmd
from mtl_sales_orders mso,
mtl_demand_omoe mdo,
oe_order_headers_all oha,
oe_order_lines_all ola,
mrp_sales_order_updates msou
where mso.sales_order_id = mdo.demand_source_header_id
and mso.segment1 = oha.order_number
and oha.header_id = ola.header_id
and mdo.demand_source_line = ola.line_id
and mdo.demand_id = msou.sales_order_id
and msou.process_status in (2,3,4)
and ola.open_flag = Y ;
SHUT DOWN THE PLANNING MANAGER
UPDATE mrp_sales_order_updates
SET process_status = 2,
request_id = NULL,
error_message = NULL
WHERE process_status in (2,3,4);
commit;
RESTART the Planning Manager
PARTIAL UPDATE to MRP_SALES_ORDER_UPDATES
----------------------------------------The records in mrp_sales_order_updates were partially updated by the
planning manager, but the process_status never changed from a 2 to a 5.
I believe this problem can happen if the planning manager errors during
tbe compute sales order changes function. In this case, the
following data fix is required:
**The Planning Manager must be on hold or inactive when this script is run!!**
UPDATE mrp_sales_order_updates

SET process_status = 5,
request_id = -1
WHERE
process_status = 2
and error_message is null
and request_id is null
and new_schedule_date = old_schedule_date
and new_schedule_quantity= old_schedule_quantity
and current_customer_id = previous_customer_id
and current_bill_id = previous_bill_id
and current_ship_id = previous_ship_id
and current_available_to_mrp = previous_available_to_mrp
and nvl(current_demand_class,-1) = nvl(previous_demand_class, -1);
commit;
** Restart the Planning Manager
SALES ORDER DEMAND NOT PROCESSED MRP_RELIEF_INTERFACE
----------------------------------------------------Verify that your order relieved the Master Demand Schedule. For a relief to occ
ur, the profile
option, MRP: Consume MDS must be set to Yes, and the relief checkbox to the righ
t of your MDS
Name must also be checked. The following query will reveal if the sales order s
hipment triggered
the creation of a relief entry in MRP_RELIEF_INTERFACE. If your sales order shi
pment did not create
a record in this table, MDS consumption would not have occurred for this shipmen
t:
select
substr(mdo.demand_id,1,10) dmd_id,
substr(ola.line_number,1,4)|| . ||substr(ola.shipment_number,1,4) line_num,
substr(mri.transaction_id,1,10) tran_id,
substr(mri.last_update_date,1,10) ls_update,
substr(mri.new_order_quantity,1,10) relief_qty,
substr(mri.relief_type,1,8) rel_type,
substr(mri.process_status,1,8) proc_stat,
substr(mri.error_message,1,200) error_msg
from
mrp_relief_interface mri,
mtl_sales_orders mso,
mtl_demand_omoe mdo,
oe_order_headers_all oha,
oe_order_lines_all ola
where mso.sales_order_id = mdo.demand_source_header_id
and mri.disposition_id = mdo.demand_id
and mso.segment1 = oha.order_number
and oha.header_id = ola.header_id
and mdo.demand_source_line = ola.line_id
and mdo.demand_source_header_id =
(select sales_order_id
from mtl_sales_orders
where segment1 = &&your_sales_order_number );
If you can see a record in mrp_relief_interface for your sales order shipment, t
hen what
is the process_status? If the process_status is 4, that means that the record h

as errored
in the interface. MDS relief would not have occurred for that record.
Fix the error and run the following update script to reset the record so it can
be
processed by the Planning Manager (Errors in this tableare usually due to
tablespace issues or a Planning Manager Crash):
**Deactivate the Planning Manager before running this script!
update mrp_relief_interface
set process_status = 2,
error_message = NULL,
request_id = NULL
where transaction_id = &transaction_id;
commit;
**Restart the Planning Manager after running this script
AP Distribution Related Errors Prevent Closing
---------------------------------------------You have a cancelled invoice that is preventing the month-end close from complet
ing. The invoice
shows that it is partially posted. The invoice has a rate and period exception.
The rate exception is caused because there is a NULL value for the base_amount
in the
ap_invoice_distributions_all table. The period exception is caused because the
period_date is
in a closed period.
Determine the invoice_id:
SELECT invoice_id
FROM ap_invoices_all
WHERE invoice_num = <invoice number in question> ;
SELECT distribution_line_number, period_name, accounting_date,
base_amount
FROM ap_invoice_distributions_all
WHERE invoice_id = <results from 1 above>;
If this returns row(s) with a base_amount of null and a period_name/accounting_d
ate in a
period that is closed, consider the following updates:
UPDATE ap_invoice_distributions_all
SET base_amount = 0
WHERE invoice_id = <invoice in question>
AND distribution_line_number = <line number(s) from 2 above with null
base amount(s)>;
UPDATE ap_invoice_distributions_all
SET period_ name = < open period >,
accounting_date = < date in open period >
WHERE invoice_id = <invoice in question>
AND distribution_line_number = line number(s) from sql above;

You should then be able to successfully complete the Accounts Payable Transfer
to GL, the Invoice Sweep, and close the period.
SOURCING RULES INVESTIGATION
---------------------------Check for duplicate names by running the following sql:
select autosource_rule_name
from po_autosource_rules group
by autosource_rule_name
having count(*) > 1;
Check for orphaned rows in mrp_sr_assignments
select assignment_set_id, assignment_id, assignment_type, sourcing_rule_id
from mrp_sr_assignments a
where sourcing_rule_type = 1
and not exists (select x from mrp_sourcing_rules b
where a.sourcing_rule_id = b.sourcing_rule_id);