We had a case where customer was using Apps9 ESTIMATES Extension and customer reported erroneous costs on Estimates cost build up.
It was bringing in high labor costs for purchased raw parts… labor costs are only supposed to happen for manufactured parts.
This customer was using configurations and whenever they selected a different sub assembly/compressor (i.e. different from the one they acquired via the RMB Load from template) via edit configurations and recalculated the costs on the estimate, the problem was noticed.
From the SQL point of view, your estimate in error will show up when you run the following SQL (and you can add an “and” condition to include your estimate_id).
In an ideal situation, the following SQL is not supposed to return any rows, but if it does (whether in Apps9 or Apps10), you have a cost build up problem with that estimate.
select Estimate_Node_API.Get_Displaytext(estimate_id, estimate_revision_no, node_id) item_name,
a.* from ESTIMATE_NODE_COST_TAB a
where
cost_element_id in ( 'LABOR', 'LABOUR')
and inventory_part_api.get_type_code(contract,Estimate_Node_API.Get_Displaytext(estimate_id, estimate_revision_no, node_id))
= 'Purchased (raw)'
order by estimate_id desc
This test plan has not been tested on Apps10 yet, but in Apps9 with the customer data/configuration rules setup, it can be easily recreated.
The problem was tracked to Estimate_Component_API.Inherit_Product_Structure__ - the rows from tables ESTIMATE_OPERATION_TAB, ESTIMATE_OPERATION_COST_TAB, ESTIMATE_OPER_COST_DETAIL_TAB were not initialized correctly for the node/dependent sub node(s) in question. That is why the ESTIMATE_NODE_COST_TAB which was dependent on the inputs from the above 3 tables was wrongly calculating/storing estimate costing data.