先前写过几个关于物料管理的示例，分别从几个角度说明相关的问题。近日应几个版友的要求，对这几个示例进行了进一步整合，写了这个示例。在这个示例中，进一步突出了单据集中管理这个概念，并体现到数据表设计、窗体设计中。

　　对于一个小型的生产企业来说，物料的管理过程中，大体需要使用到销售订单、生产指令（或者叫排产及采购计划）、采购订单、采购入库单、委外加工入库单、产品及半成品入库单、采购发票、销售出库单、销售发票、生产领用出库单、委外加工出库单、调整单这样十多种不同的单据。你当然可以针对这些不同的单据设计数据表和它们的明细表，也可以在此基础上设计出窗体来进行数据的编辑和查询。问题在于这样做的效率很低，维护起来也甚为麻烦。那么能否将这些单据进行整合，提炼出他们的共性，然后进行一致性的处理呢？答案是肯定的。

　　在本示例中，采用了单据表和单据明细表这样两个数据表，对以上十多个单据进行了统一。这样做的好处是数据管理效率极大的提高，整个系统使用到的表、查询、窗体、报表等大大减少。但凡一事有利必有弊，在高度统一的基础上，要对不同的单据实现有差异的处理，就需要相对复杂的程序结构，也就是说代码的复杂程度就会有所提高。

　　写这个示例，重点不是想告诉同志们应该怎么来组织数据表、怎么来写代码以实现需要的功能，这些东西不是最重要的。重要的是处理问题的思路，也就是怎么去观察问题、分析问题、找到比较好的解决问题的途径。而这个问题，往往对于初学者是极为容易忽略的。直接拿别人的东西来用，或者直接模仿他人的代码，这是很初级的阶段，当然这个阶段必不可少。如果能看到对问题的处理思路，并由此得到启发，能够在不同的领域进行类似的运用，这应该是比较高级的学习方法。

　　这个示例并没有写完整，有些部分写了一小段，其他的部分空了下来。所以不要指望直接使用这个系统，这不是一个可以运用的系统，只是提供学习的一个参考资料。所以不要问我为什么某些地方不能操作。

　　进行测试时，按照销售订单－－生产指令－－采购订单－－入库单－－采购发票－－出库单－－销售发票这样的顺序进行。每种单据都需要进行审核，审核为不定流程的审核，只有提交到该单据的最终有权审核人，经该审核人审批后，审核流程结束。在综合查询中，有一个单据链查询，这是一个比较有趣的处理，其背后包含了一个单据关联关系的设计思想。程序中还有比较丰富的关于会计处理的知识，你可以在测试中自己观察。最后请注意单据的编制权限通过TreeView的控制处理方法，这是一个具有想象力的处理方法。

　　寻求万法归一，是一种归纳，是一种提炼。最简单的是最深刻的，请记住这个观点。

附   件:

点击下载此附件 2014/3/15更新