惯例闲话：分享 朱龙春老师的一篇随笔《只是做点ERP，没必要跳楼吧 。 多大的事呢，生命面前，一切都是个P》的感想，故事大致是这样，客户不断提需求，技术出身的愣头青项目经理扛不住项目成本压力，一气之下跳楼自杀。
感触良多，8年前闲人做乙方项目经理时，也遇到过类似窘境，被客户各种超SOW之外加码，公司配备的开发资源严重不足，很多时候必须自己亲自下场干模块和开发，那1年每天工作时间超16小时以上，压力可想而知。项目结束后，离职休息了2个月，那是闲人这些年职业生涯中刻骨铭心的炼狱项目，但是总算扛过来了，之后无论遇到多难的项目，都不是个事，有种涅槃重生般的感觉。闲人非常认同朱龙春老师的这句点评——生命面前，一切都是个P。
敬畏生命，没有过不去的坎。这里的敬畏生命，倒不是生命受到威胁而妥协的意思，而是看清自己的边界线，有多少能力干多少活，每一个中年男人背后，都是一个家庭，保持健康心态，是对家庭的负责。
闲话到此为止，今天聊聊BOM虚拟件应用中遇到的问题
虚拟件的问题
首先看问题，近期财务用户找闲人反馈，在CK11N标准成本发布的时候总是提示错误，刚开始闲人不以为然，发布标准错误无非就是信息记录、KP26作业价格、BOM问题，把问题怼回去让他们自己去看ISSUE LOG处理。
但是再次发截图过来时，发现问题并不简单了，“溢出:900100000000020400 物料清单的级别1存在超过 99 个虚拟装配件”。于是，开始跟踪问题。
用CK11N跑一下标准成本估算，果然报错了，而且是系统级错误。普通的方法显然不能解决。
原因追溯
此类问题，建议搭建先打开英文版界面，把报错的英文复制下来，然后在BING搜索，有条件的当然第一优先级去SAP官方网站去找notes。这是一个重要的方法，可以帮助你高效的找问题答案。
把这段话消息 More than 99 phantom assemblies at one BOM level放进去搜索，很快就有针对性的处理记录
打开notes 3146281，找到问题的根源——一个产品的多级BOM展开，过程中虚拟件个数被这AUFWG，BAUWG2个字段控制，显然2位数字最大是99，这就解释了问题的根本原因。
下面看SAP给出的解决办法，概括下：
方法1：更改BOM结构，把虚件改成实件，减少虚件数量，SAP推荐方法
方法2：更改AUFWG，BAUWG字段的数据元素的长度，有风险，可能会产生不可预知的结果，SAP不推荐。
由于用户反馈要着急生产，闲人和关键用户商议了一下，决定临时先用方法1。改了其中25个虚拟件的主数据属性，改为实件
然后CK11N发布标准成本继续走后续业务。
但是这毕竟是临时方法，BOM发布来源PLM，PLM源头不会改变物料的属性。
这种业务场景在项目制造场景很常见，越是行业特点鲜明的企业，虚拟件越普遍，零散加工件图纸多，但是流转时间较短，如果都采用实件管理，工单、报工、入库、消耗等环节将增加数倍的人力物力，所以这种场景下虚改实显然是临时权宜之计。
所以结论，虚拟件超过99个，是一些行业的常态，要彻底解决必然要冒险用第二种方法。
处理过程
1、改长度很简单，直接SE11对数据元素的域属性长度改为4就可以
2、激活过程才是重点。PLMZ工艺路线物料分配表、RESB预留表都是2张巨大的表，激活过程出现错误，
需要用SE14对表做一次转换调整
然后再次激活
这个过程的建议：
1、反复测试。主要测试环节，CK11N、CA01、CA02、CO01、CO02、CO11N等工单管理全过程，直至程序编译完成且没有问题
2、正式机传输要找一个晚上时间，用户不操作的窗口期进行。RESB 400W，PLMZ 300W+的数据量，生产机传输完成约2个小时
目前这个问题和几个朋友交流，也遇到相同的问题，测试过程还算顺利，没有大的异常，所以初步判定，这个改动是可行的。
回顾
有一个有趣的疑问，虚拟件个数的字段要控制在99个？可以假设一个很大的产品，下面有几十万甚至上百万的组件，如果做在一张工单里，那么单张工单的组件数量会巨大，RESB的RSPOS的位数是4位最多支持9999个，所以，基本可以判定，这个是用来控制单张工单中预留组件数量的。问题分析到这里，各位是否可以联想到很多大型装备制造企业，用工单来管理生产过程的问题了，其实这里也暗示了一个方向，PS WBS BOM、网络订单是项目型制造的最佳业务实践。
