初步探讨订单确认时的在制品缺陷记录（五）
2012-02-26 18:13:32| 分类：
默认分类
| 标签：
|举报
|字号大中小 订阅
本博文为隐身人原创作品，请勿转载
第九步：完成订单确认之后，使用事务代码CO02，查看刚刚确认完成的生产订单，如下图所示：
我们看到这张订单的系统状态上已经新增了“DEF”标识。这意味着针对该订单已经做过了缺陷记录工作。
第十步：使用事务代码QM10，查看由系统自动生成的质量通知单。首先观察“参照对象”视图，如下图所示：
可以看到，这张通知单对应到我们之前指定的通知单类型，我们可以在这上面看到与之对应的物料号与生产订单号，说明了通知单与生产订单之间的关联关系。特别值得一提的是，在生产订单号的旁边并没有显示出具体的工序号码。这说明该通知单是针对整张生产订单的缺陷记录，而不是具体针对某一道工序的。
接下来我们再查看该通知单的“行项目”视图，如下图所示：
我们看到，之前在做订单确认时所维护的两个缺陷类型行项目（第一个“数量”行项目不属于“缺陷”，因此不记入通知单）已经被忠实地记录在通知单上，每一个缺陷类型行项目都对应了通知单上的一个行项目。我们在该行项目上可以看到缺陷类型代码、缺陷注释、缺陷数量（即“数量”行项目上的确认数量）等数据。这些都是进行生产线绩效评估的必需数据。我们之前提到绩效评估的数据需求时还提到了一项--缺陷责任人。关于这一项，我们并没有在订单确认时予以特别记录。但事实上，维护在订单工序上的工作中心（工位）就已经代表了需要对该缺陷负责的责任方，由此，我们就没有必要再单独记录缺陷责任人了。
在上图中值得一提的是每个缺陷类型行项目上的“缺陷次数”（Number of defects）。此字段同样可用于绩效评估，请注意两个行项目在这项统计数据上的差别：
第一个行项目记录了缺陷数量共三个，但累积的“缺陷次数”只有一次；第二个行项目记录了缺陷数量共两个，而累积的“缺陷次数”也为两次。这就是我们之前在后台配置缺陷记录格式的时候，对每个“数量”行项目的“缺陷次数”累积方式进行了单独定义的结果。在实际应用中，我们应该注意到不同的统计方式所导致评估效果的不同。
评论这张
转发至微博
转发至微博
关闭
玩LOFTER，免费冲印20张照片，人人有奖！
我要抢>
<#--最新日志，群博日志-->
<#--推荐日志-->
<#--引用记录-->
<#--博主推荐-->
<#--随机阅读-->
<#--首页推荐-->
<#--历史上的今天-->
<#--被推荐日志-->
<#--上一篇，下一篇-->
<#-- 热度 -->
<#-- 网易新闻广告 -->
<#--右边模块结构-->
<#--评论模块结构-->
<#--引用模块结构-->
<#--博主发起的投票-->
评论