报表练习题：销售订单打印
一、此练习的目的在于帮助同学们掌握：
1.1、如何从界面查数据来源（表或视图）
1.2、如何从界面查“界面字段对应的数据库字段”
1.3、初步掌握EBs标准Form代码的分析方法
1.4、进一步巩固基础报表开发能力
二、说明：
2.1、此练习的功能设计文档 参考doc/Md060/ 下的文档：
2.2、此练习的技术设计文档 参考doc/Md070/ 下的文档：
2.3、此练习的参考代码 参考doc/program/ 下的文档：
警告：参考代码是有问题的，直接照搬照抄是不行的，只有在弄懂了销售订单的表结构关系以后才能正确的更正并完成报表开发。
三、提示：
3.1、附件中提供的rdf中的ＳＱＬ语句可能存在问题 ：
比如：
3.1.1 附件中rdf中的SQL语句的where条件对session的语言环境有依赖，这是不对的。(比如以状态的中文名称作为条件就是不对的，如果用户切换到英文环境就完蛋了，应该以一个跟语言环境无关的状态代码作为条件）
况且where 条件中使用函数（没有建函数索引）将严重影响性能，因此就错的更离谱了。
3.1.2 原来的 sql语句是针对特定项目环境的，我能练习是针对Demo环境的，需要自己弄清楚销售订单的表结构和数据逻辑关系后加以修改。
四、常见问题：
4.1 如何从销售订单的界面查找到销售订单的数据源？
答：一般说到数据源即指： View->synonym->Table
针对销售订单：
销售订单的导航路径在：operations/welcome登录 Nav: Order Management Super User, Vision Operations (USA)-》Ordders,Return -》销售订单
查询：客户名称= ABC Corporation Asia 的订单
查历史记录可看到界面对应的View , 对View进行分析可获得其来源表信息;
所以销售订单对应的视图就是：OE_ORDER_HEADERS_V
在PLSQL Developer中打开该视图的定义，在定义中最主要的一张表一般就是主表
对销售订单头而言：oe_order_headers 看上去就是主表，但实际上，它是个同义词：
该同义词指向：ONT.OE_ORDER_HEADERS_ALL
对我们开发人员来说，在R12版本中我们客户化的程序中一般也是要使用同意词，而不是同义词指向的最终表，原因是R12的VPD策略一般都是建立在同义词上，而不是最终的表上，请看：
我们写的程序在访问数据时理应受VPD控制，所以我能对数据源的追踪也是追到同意词即可；
同理：光标停到订单行上，查看历史记录可看到订单行对应的View, 对View进行分析可获得其来源表信息.
4.2 报表中的参数：订单类型参数需要用LOV输入，如何实现？
答：订单类型的定义在
Nav:Order Management Super User, Vision Operations (USA)-》Setup-》事务处理类型-》定义
OE_transaction_types_V 的定义如下：
可见该视图主要来源是OE_TRANSACTION_TYPES_VL, 对VL进一步分析可见其最终来源于TL和同意词，因此到VL可不在往下追了，直接使用VL作为值列表的数据来源不会造成多余的查询而导致性能浪费；
在销售订单头的数据源里面，保存的是订单类型的ID， 也就是对应OE_TRANSACTION_TYPES_VL.TRANSACTION_TYPE_ID , 界面上的订单类型名称也就对应OE_TRANSACTION_TYPES_VL.name ; 所以，对于销售订单类型的值列表而言可以把SQL写成：
select TRANSACTION_TYPE_ID,name from OE_TRANSACTION_TYPES_VL; 考虑到要对OU进行屏蔽，再加一个条件：
select TRANSACTION_TYPE_ID,name from OE_TRANSACTION_TYPES_VL where org_id =fnd_profile.value(‘ORG_ID’)
可把值集定义成如下样子：
Nav：Application Developer->应用产品->验证->请求集：
编辑信息：
值集定义好以后，再把该值集赋给参数即可：
在并发程序的参数定义界面：
提交并发程序时可能出现订单类型值列表没有值的情况：
详细资料：
此现象的原因分析：
因为VL视图来源于：OE_TRANSACTION_TYPES_TL T, OE_TRANSACTION_TYPES_SYN B ，其中OE_TRANSACTION_TYPES_SYN 上面是有VPD策略的：
倘若在Form中访问VL，肯定是没有问题的，因为用户登录后，上下文环境已经存在了；但对于并发程序而言，并发程序的参数值列表是通过fdlfch(）来获取的，该程序是个C写的编译后的二进制文件，我们估计它获取上下文的逻辑与form不太一致；
我们猜测：它需要并发程序必须定义业务模式后才能正确获取到用户登录上下文：
因此需要定义并发程序的业务模式：
Nav：系统管理->并发->程序
点击 更新 按钮，一定要选择一个业务模式，然后保存；
这样再次提交报表时，参数就可以选到了：
4.3 报表中的参数：订单状态需要用LOV输入，如何实现？
答：报表参数使用LOV输入，只需要给参数定义一个值集即可，这个在上文已经讲过，对订单状态而言，关键是找到订单状态的内部Code 和 外部名称的Mapping定义来源：
光标停到状态字段，选择 帮助-》诊断-》检查 ，可知道界面上的状态对应哪个block的哪个item，一般来说，item名称与数据表中的字段一致。
如果不一致，需要打开form源代码分析，这个例子中界面上看到的Status这个字段，在View里面不存在，所以要对form进行分析，知道status的具体来源， 首先要知道当前Form的名称，这可以通过帮助->关于oracle Applications 找到：
这里的表单路径中的，OEXOEORD.fmx就是编译后的form名称，其源代码对应于OEXOEORD.fmb , 源代码一般存在于$AU_TOP/forms/US 和 $AU_TOP/forms/ZHS目录下，我们这下载中文版的Form源代码就应该从
$AU_TOP/forms/ZHS中找：
下载下来，打开时提示：此Form引用了很多其他Form， 则其他Form 也需要下载：
此例中可能需要下载的被引用的Form包括：
打开后，找到order块，打开post-query Trigger， 里面有代码OE_ORDERS.Post_Query
查找，OE_ORDERS ,可知这个Api 在OEXOEHDR 这个pll 中；
打开： OEXOEHDR 这个pll
在导航对象查找：OE_ORDERS
打开 OE_ORDERS， 找到Post-query() , Ctrl+F 在编辑器中查找 “STATUS” , 可以找到这么一段代码：
IF Name_In(l_orders_block||'.flow_status_code') IS NOT NULL THEN
x_lookup_value:=null;
l_count:=0;
l_count:=OE_Cache_Values.IS_Value_In_Cache(
p_code =>Name_In(l_orders_block||'.flow_status_code'),
p_rg_name =>'FLOWSTATUS_CACHE',
x_value => x_lookup_value
);
IF l_count <>0 AND x_lookup_value IS NOT NULL THEN
Copy(x_lookup_value,l_orders_block||'.status');
ELSE
p_header_rec.flow_status_code := Name_In(l_orders_block||'.flow_status_code');
END IF;
END IF;
从代码可知： Block 上的status 字段是根据flow_status_code 而显示出来的，所以该字段实际对应数据库表中的Flow_status_code 字段；
而且，从代码我们基本猜测到：flow_status_code 的 Code 和名称的mapping关系是在record Gruop FLOWSTATUS_CACHE 中，如果我们找到FLOWSTATUS_CACHE这个record group的定义，自然就知道其SQL来源了，因此我能查找对象FLOWSTATUS_CACHE：
可惜我们没找到，因为form中不存在FLOWSTATUS_CACHE 这个记录组的定义，既然如此，那么这个记录组有可能是在程序中动态的populate出来的，因此PLSQL检索FLOWSTATUS_CACHE ：
共找到两处代码：另外一处指向 write_value_in_cache, 是向FLOWSTATUS_CACHE记录组中写内容，看来这个记录组不是从sql语句populate出来的；那么我们要最终是谁从哪里把数据读出来，然后写进去的
我们在所有代码中查找：write_value_in_cache， 我们发现数据来源于x_header_val_rec.status
于是我们在继续全代码搜索：x_header_val_rec.status
我们发现是由：Oe_Oe_Form_Header.POPULATE_CONTROL_FIELDS 获取的：
在对象中搜索：Oe_Oe_Form_Header
什么也没有搜索到，说明这不是一个Form Pll 的package ,而是一个数据库package ,因此转到PLSQL Developer中查看其定义：
从PLsQL 程序中我们可以看到Flow_status的Code和名称的Mapping定义是在Fnd_lookup_Values表中，因此状态的值列表Sql语句我们可以写成：
SELECT lookup_code,meaning
FROM FND_LOOKUP_VALUES LV
WHERE LANGUAGE = userenv('LANG')
and VIEW_APPLICATION_ID = 660
and lookup_type='FLOW_STATUS'
定义值集并赋个报表参数的步骤此处就省略了。
4.4 如何知道销售订单在挑库过程中涉及的表与表之间的关系
答： 每次挑库都会有个挑库单报表，可以通过这个来追踪订单行与发运、库存表之间的关系
首先我们看清楚并发程序的名称：
然后我们切换到 Application Developer责任 ，
查找并发程序定义和可执行定义：
确定要到WHS模块下去找rdf 文件：
使用Report Builder 打开这个文件，查看SQL：
从SQL的From和Where 条件可以看到订单行表与各表之间的关系：
如果你不知道这里面有些表是干什么用的，可以查询Oracle 的在线TRM 表信息文档，比如，你想知道wsh_delivery_details 表是干什么的，可以登录：
EBS.R12表结构文档路径：
http://etrm.oracle.com/pls/etrm/etrm_search.search
查询这张表：
可以得到这张表的详细信息：
如果你想知道挑库单号是来自哪张表的哪个字段：可以看报表的布局，然后点挑库单号对应的框，可以追溯到其在数据模型中的字段名：
回过头来，做一张订单
挑库：
查看挑库报表： 生成了类型=挑库通知的 物料搬运单（3905075）、交货（3773389）
这个物料搬运单可以在库存模块的物料搬运单界面找到： 其对应的视图就是MTL_TXN_REQUES_LINES_V
而交货号可以在发运模块的发运事务处理界面找到
然后做延交发运（由于某种原因，当前没有商品可发运，所以就延迟交货，意味着本次交货作废）
已延交
进一步发放已延交的部分：
重新生成性的物料搬运单和交货号
重新针对新的交货，进行发运事务处理：
我们可以看到交货号是新的的交货号，但是详细信息字段还是一样的。
全部发运掉：
通过对挑库单报表的SQL和这些表、视图进行分析，可以知道：
1）交货号=wsh_new_deliveries.delivery_id=wsh_delivery_assignments_v.delivery_id
2) 详细信息的这个字段=wsh_delivery_details.delivery_detail_id
3) wsh_delivery_details 与 订单行oe_order_lines_all是一对一关系，通过
wsh_delivery_details.source_line_id =oe_order_lines_all.line_id 关联；
4）wsh_delivery_details 与 wsh_delivery_assignments_v 是一对一关系，而wsh_delivery_assignments_v 与 wsh_new_deliveries 是一对多关系，因为在发运延交的情况下，wsh_new_deliveries 就会有多条记录。
5）物料搬运单行与 wsh_delivery_details 表是通过这个关联的 mtrl.line_id = wdd.move_order_line_id
6）物料搬运单行 与 物料事务处理临时表 是一对一关系 ，关联条件是： wpsv.move_order_line_id = mtrl.line_id
7）挑库报表完成后如果显示成功挑库，就意味着已经生成了两条库存事务处理，可以根据挑库单号查询出来，比如：