Basic Install Base setups
1. Item Setup
Is your item set up as IB trackable?
An item needs to be set up as IB trackable in Master and every child inventory org in order to interface the item's transaction to Oracle Installed Base.
Check from form:
INVENTORY (R) > Item > Organization Item > Service Tab > Attribute: Installed Base Trackable
Check using query:
SELECT segment1, organization_id, comms_nl_trackable_flag
FROM mtl_system_items_b
WHERE segment1 = '&your_item_number';
2. Validate Shipment
Does your Order Management shipment go through the inventory interface for a shippable item?
Although your order line is closed, the inventory interface (kicked off from ship confirm trip stop interface) may not complete. Only after the inventory interface
is completed will the transaction be sent to the Installed Base interface.
Check from form
INVENTORY -> Transactions -> Material Transactions
Pick up your shipping organization
Query by Source = Sales Order, Source Id = Sales Order Number
You will see your Order Issue transaction here if your inventory interface is completed.
Profile Options
The Important Profile Options which needs to be set at the site level are
Service: Inventory Validation Organization
CSI: Default Instance Status
Some times when the Item is shipped also instance may not updated in IB,
Please below solution
Every material transaction for an IB trackable item should update install base. IB tracks items throughout their lifecycle - so when they are shipped to customers, but also when received in inventory and transferred around internally. Depending on serial control, the same instance number will be used in the entire lifecycle or it will go through different instance numbers - it depends on whether or not the instance can be identified uniquely.
The processing in IB normally happens through Service Fulfillment Manager (Event Manager) - SFM.
This is defined as a concurrent manager service. When a material transaction (such as shipping) occurs, the inventory code will trigger a 'message' for SFM to process it for IB. This happens on the background, so the core transaction does not have to wait for it to finish updating IB. SFM has processing logic defined for each transaction type - basically calling the IB APIs to process the transaction - and create or update instances accordingly.
Though there may be a lot of other things wrong, here are the basics for you to check first
- First ensure you instance is trackable in all organizations (at least in the master org and the shipping org)
- Then check if SFM is not 'bypassed' (check the Install Base Parameters setup under IB administrator and ensure the 'bypass SFM is NOT checked'
- go into SFM Administrator responsibility, open the queue console and check the number of pending messages for Event Manager - If >0, click on Services and see if the managers are actually running (target = actual processes = 1 (no more - no less)
After each step that should update IB I run this:
select msg_id,msg_code, msg_status, to_char(creation_date,'DD-MON HH24:MI:SS') created,
to_char(last_update_date,'DD-MON HH24:MI:SS')last_update_date,
to_char(sysdate,'DD-MON HH24:MI:SS') sys_date--, body_text
from xnp_msgs
where creation_date > sysdate -.5
order by 4 desc;
--> that would show the message(s) that got submitted to SFM. WHile they are waiting, the status will be 'READY'. Once processed by SFM, they will have status PROCESSED.
misc. receipt will generate a CSIMSRCV message
pick release = CSISUBTR
shipment = CSISOSHP
Once your message is processed, you can run this to see what happened in IB (latest updates will appear on top):
select msg_id,msg_code, msg_status, to_char(creation_date,'DD-MON HH24:MI:SS') created,
to_char(last_update_date,'DD-MON HH24:MI:SS')last_update_date,
to_char(sysdate,'DD-MON HH24:MI:SS') sys_date--, body_text
from xnp_msgs
where creation_date > sysdate -.5
order by 4 desc;
--> that would show the message(s) that got submitted to SFM. WHile they are waiting, the status will be 'READY'. Once processed by SFM, they will have status PROCESSED.
misc. receipt will generate a CSIMSRCV message
pick release = CSISUBTR
shipment = CSISOSHP
Once your message is processed, you can run this to see what happened in IB (latest updates will appear on top):
SELECT csi.owner_party_id,
csi.owner_party_account_id,
csi.instance_number,
csi.inventory_item_id,
mtl.segment1,
csi.SERIAL_NUMBER,
csi.quantity,
csi.inv_master_organization_id,
stat.name,
csi.accounting_class_code,
csi.instance_usage_code,
csi.last_update_date,
inv_subinventory_name,
active_end_date
FROM csi_item_instances csi,
csi_instance_statuses stat,
mtl_system_items_b mtl
WHERE csi.last_update_date > SYSDATE - 1
AND stat.instance_status_id = csi.instance_status_id
AND mtl.inventory_item_id = csi.inventory_item_id
AND mtl.organization_id = csi.last_vld_organization_id
ORDER BY csi.last_update_date DESC;
if this does not return (expected) results, then you can run this to see if there was an IB transaction error - which would mean that SFM did call IB to process the message, but IB encountered an issue while doing so:
select * from csi_txn_errors
where creation_date > sysdate-1;
if there is an error for your transaction (you can identify by e.g. ordernumber - it is in the table as source_header_ref for CSISOSHP transactions)
if this does not return (expected) results, then you can run this to see if there was an IB transaction error - which would mean that SFM did call IB to process the message, but IB encountered an issue while doing so:
select * from csi_txn_errors
where creation_date > sysdate-1;
if there is an error for your transaction (you can identify by e.g. ordernumber - it is in the table as source_header_ref for CSISOSHP transactions)
