一、解决思路：
由于EBS没有提供历史时间库存表，所以思路就是通过现有量去一步一步地倒推，算出历史时间库存表。
现有量可以采用EBS自带的get_onhand_available_qty函数。
从事务表INV.MTL_MATERIAL_TRANSACTIONS的（TRANSACTION_DATE或者PROGRAM_UPDATE_DATE字段获取，区别稍后说明）中加加减减，一步一步往回推算。
推算用到的函数为SUM()OVER(),以及LAG()OVER()函数。具体用法请自行百度。
二、代码如下：
CREATE OR REPLACE VIEW CUX.CUX_ONHAND_OLD_V ( ORGANIZATION_CODE , INVENTORY_ITEM_ID , SEGMENT1 , ELEMENT_VALUE , SUBINVENTORY_CODE , TRANSACTION_DATE , TRANSACTION_QUANTITY , STOCK_IN , STOCK_OUT , TRANSACTION_UOM , ONHAND_QTY , CURRENT_QTY ) AS WITH T AS ( SELECT SUBINVENTORY_CODE --, REVISION -- , TRANSFER_SUBINVENTORY --, SHIP_TO_LOCATION_ID --, COST_GROUP_ID --, TRANSFER_COST_GROUP_ID --, LPN_ID --, CONTENT_LPN_ID --, TRANSFER_LPN_ID --, TRANSFER_ORGANIZATION_ID --, OWNING_ORGANIZATION_ID --, PLANNING_TP_TYPE -- , OWNING_TP_TYPE --, PLANNING_ORGANIZATION_ID , TRUNC (TRANSACTION_DATE) TRANSACTION_DATE , SUM (TRANSACTION_QUANTITY) TRANSACTION_QUANTITY , SUM ( (case when TO_NUMBER (TRANSACTION_QUANTITY) >= 0 then TRANSACTION_QUANTITY else null end)) stock_in , SUM ( (case when TO_NUMBER (TRANSACTION_QUANTITY) < 0 then -1 * TRANSACTION_QUANTITY else null end)) stock_out , TRANSACTION_UOM --, PRIMARY_QUANTITY , APPS.cux_public_pkg.get_onhand_qty ( p_inventory_item_id => inventory_item_id , p_organization_id => organization_id , p_subinv_code => subinventory_code) onhand_qty --, SECONDARY_TRANSACTION_QUANTITY --, SECONDARY_UOM_CODE --, SHIPMENT_NUMBER --, WAYBILL_AIRBILL --, FREIGHT_CODE --, NUMBER_OF_CONTAINERS --, TRANSACTION_REFERENCE --, COSTED_FLAG -- , OPM_COSTED_FLAG -- , PM_COST_COLLECTED --, PM_COST_COLLECTOR_GROUP_ID --, TRANSACTION_GROUP_ID --, VENDOR_LOT_NUMBER -- , SOURCE_CODE -- , SOURCE_LINE_ID -- , TRANSFER_TRANSACTION_ID --, PARENT_TRANSACTION_ID --, LOGICAL_TRANSACTION --, TRANSACTION_SET_ID -- , RCV_TRANSACTION_ID -- , MOVE_TRANSACTION_ID --, COMPLETION_TRANSACTION_ID --, OPERATION_SEQ_NUM --, SOURCE_PROJECT_ID --, SOURCE_TASK_ID --, PROJECT_ID --, TASK_ID --, TO_PROJECT_ID --, TO_TASK_ID --, EXPENDITURE_TYPE --, PA_EXPENDITURE_ORG_ID --, ERROR_CODE --, ERROR_EXPLANATION --, transaction_source_name --, XFR_OWNING_ORGANIZATION_ID --, TRANSFER_OWNING_TP_TYPE --, ATTRIBUTE_CATEGORY -- , ATTRIBUTE1 -- , ATTRIBUTE2 -- , ATTRIBUTE3 -- , ATTRIBUTE4 -- , ATTRIBUTE5 -- , ATTRIBUTE6 -- , ATTRIBUTE7 -- , ATTRIBUTE8 -- , ATTRIBUTE9 -- , ATTRIBUTE10 -- , ATTRIBUTE11 -- , ATTRIBUTE12 -- , ATTRIBUTE13 -- , ATTRIBUTE14 -- , ATTRIBUTE15 --, LAST_UPDATED_BY -- , CREATION_DATE --, CREATED_BY -- , LAST_UPDATE_LOGIN -- , REQUEST_ID --, PROGRAM_APPLICATION_ID --, PROGRAM_ID --, PROGRAM_UPDATE_DATE -- , LAST_UPDATE_DATE , INVENTORY_ITEM_ID , ORGANIZATION_ID --, LOCATOR_ID -- , REASON_ID -- , TRANSFER_LOCATOR_ID -- , TRANSACTION_TYPE_ID -- , TRANSACTION_ACTION_ID -- , TRANSACTION_SOURCE_TYPE_ID -- , TRANSACTION_SOURCE_ID --, EMPLOYEE_CODE --, DEPARTMENT_ID --, MASTER_SCHEDULE_UPDATE_CODE --, RECEIVING_DOCUMENT --, PICK_STRATEGY_ID --, PICK_RULE_ID --, PUT_AWAY_STRATEGY_ID --, PUT_AWAY_RULE_ID --, ORIGINAL_TRANSACTION_TEMP_ID FROM INV.MTL_MATERIAL_TRANSACTIONS WHERE TRANSACTION_ACTION_ID NOT IN (24, 30) -- and (ORGANIZATION_ID = 86) -- and (INVENTORY_ITEM_ID = 5683) and ( LOGICAL_TRANSACTION = 2 OR LOGICAL_TRANSACTION IS NULL) -- and (subinventory_code = ‘101‘) group by organization_id , inventory_item_id , subinventory_code , TRANSACTION_UOM , TRUNC (TRANSACTION_DATE) ORDER BY TRUNC (TRANSACTION_DATE) DESC), T1 AS (SELECT organization_id , inventory_item_id , SUBINVENTORY_CODE , TRANSACTION_DATE , TRANSACTION_QUANTITY , STOCK_IN , STOCK_OUT , TRANSACTION_UOM , ONHAND_QTY , ( ONHAND_QTY - SUM (TRANSACTION_QUANTITY) over (partition by organization_id , subinventory_code , inventory_item_id , TRANSACTION_UOM order by TRANSACTION_DATE desc)) as current_temp_qty FROM t) SELECT DECODE (organization_id, 85, 101, 86, 102, organization_id) organization_code , inventory_item_id , (SELECT SEGMENT1 FROM inv.mtl_system_items_b where inventory_item_id = t1.inventory_item_id and ORGANIZATION_ID = t1.organization_id) SEGMENT1 , (SELECT ELEMENT_VALUE FROM apps.MTL_DESCR_ELEMENT_VALUES_V where inventory_item_id = t1.inventory_item_id and ELEMENT_SEQUENCE = 20) ELEMENT_VALUE , SUBINVENTORY_CODE , TRANSACTION_DATE , TRANSACTION_QUANTITY , stock_in , stock_out , TRANSACTION_UOM , ONHAND_QTY , LAG (current_temp_qty, 1, ONHAND_QTY) over (partition by organization_id , subinventory_code , inventory_item_id , TRANSACTION_UOM order by TRANSACTION_DATE desc) current_qty FROM t1;
三、验证：TRANSACTION_DATE、PROGRAM_UPDATE_DATE区别
通过报表“事务历史记录汇总”去验证某一天的历史库存。这里的验证是以TRANSACTION＿DATE字段去做验证的。
但这样跑出来的结果，在某一天有可能是负数的。因为有些库存它当天卡在接口上，第二天，甚至过一段时间之后才会从接口上跑过去。
四、优化：
写好后的cux.cux_onhand_v视图，执行时需要30多秒，有点慢。但还是属于可接受范围内。
但在手机执行时是需要传条件过去查询的，最初写的代码如下（5秒执行完毕）：
SELECT onhand.ORGANIZATION_CODE as "组织代码" , onhand.SEGMENT1 as "材料名称" , onhand.ELEMENT_VALUE as "规格型号" , onhand.SUBINVENTORY_CODE as "库" , onhand.PROGRAM_UPDATE_DATE as "日期" , onhand.STOCK_IN as "收入数量" , onhand.STOCK_OUT as "发出数量" , onhand.TRANSACTION_UOM as "单位" , onhand.CURRENT_QTY as "结存数量" FROM cux.cux_onhand_v onhand WHERE onhand.segment1 = ‘102005-000256‘ and onhand.ORGANIZATION_code = 102 and onhand.SUBINVENTORY_CODE = ‘101‘
这样的代码手机执行花了5秒时间，只能算是勉强接受了。先看下执行计划（COST成本花了5409）
这也是因为cux_onhand_v视图访问慢的最主要原因。代码改成如下：
SELECT onhand.ORGANIZATION_CODE as "组织代码" , onhand.SEGMENT1 as "材料名称" , onhand.ELEMENT_VALUE as "规格型号" , onhand.SUBINVENTORY_CODE as "库" , onhand.PROGRAM_UPDATE_DATE as "日期" , onhand.STOCK_IN as "收入数量" , onhand.STOCK_OUT as "发出数量" , onhand.TRANSACTION_UOM as "单位" , onhand.CURRENT_QTY as "结存数量" FROM cux.cux_onhand_v onhand , (SELECT inventory_item_id FROM inv.mtl_system_items_b WHERE organization_id = 84 AND segment1 = ‘102005-000256‘ AND ROWNUM = 1) b WHERE onhand.inventory_item_id = b.inventory_item_id and onhand.ORGANIZATION_code = 102 and onhand.SUBINVENTORY_CODE = ‘101‘
执行计划如下所示：（将谓词inventory_item_id推进入MTL_MATERIAL_TRANSACTIONS表，COST成本从5409立即下降到32）
这样优化后的代码，执行时间由5秒立即下降为1秒，也就是说，手机展示数据所花的时间为。
原文：https://www.cnblogs.com/fjzsl/p/9343087.html