[原创]修改BOM报表

        上周五接到第二次问题报告，曰发布到ERP的中间表中数据为空。

        一大早开始查看log中是否有报错信息，工作流是否有异常，是否符合执行发布条件，是否有人为干预。除了发现问题出在同一个用户那外，没有其他线索。请求外援——无果。但很可能是用户操作不当造成的。最后决定打开详细的日志信息，直到找出原因为止了。这么做的代价就是，输出内容太多将牺牲系统的性能。

        中间数据的产生在PDM经历数次周折又数次条件判断才能得到，客制化的代码就这么来来回回的修补。记得上线后有两次较大的改动：

        一个是增加替换件、备用件的信息。如何根据双向还是单向、本结构还是所有结构替换等关系体现到不同的BOM中去；这些零部件变更时如何将所有影响到的数据体现出来；如何保证数据对ERP是可识别的........来回折腾了好久，由于系统对替换关系的变更不做版本记录，无法约束替换关系的变更是最后留下的遗憾。也就是说，除了制度规定，根本无法控制替换关系的任意修改，也就是使用中间表的结果要谨慎。

         另外一个较大的修改就是让数据不经过周折但仍有数次条件判断后得到。这是上线后经历了工作流出错等系统异常导致数据发布延迟后，想到了这么个捷径。

        总之，这些判断条件太复杂，只要这里出了任何问题，我就心虚，就发怵。

      

        说了半天，才到今天修改的BOM表上来。之前顾问们就打过预防针，报表最麻烦。今天增这个属性，明天删那个属性，今天表头多几个空格，明天版式换一下........所以，这敏感的报表们很少改动。用到如今，当电子部门的工程师要求在报表中增加“生命周期”一栏。主要为了审核方便，“已发布”的东东就跳过去。

        征求机械设计师和工程部门的意见，结果是这个需求是合理的，但不十分迫切。为了照顾电子部门用户的情绪，我还是开始准备自己来倒腾代码。

       还好，准备做得比较充分，工作进展比较顺利。今天已经交给业务部门测试并且提交给了顾问。

       教训就是还得要整个CVS起来管理好代码的版本，不然不踏实。

     

推荐到鲜果：