[5分]如何编写采购审核程序？

探花，andymark Wj.s 给出了更具体的建议，你都可以参考。

但对于你所遇到的特定的产业（具体产业的采购流程这里不作深入探讨）这里的回复人不可能用大量的时间为你做充分的分析。

本人对你所遇到的疑问，梳理一下思路，仅做参考。

首先看一下你的问题：
------------------
问题1.是不是一定要建(已审核采购计划)这样一张表?
问题2.主管审核过的计划汇总如何延伸到计划明细?
问题3.该如何编写这个审核程序?
------------------

关于第一个问题：
做为成熟的企业，一套规范的采购流程是企业必须要有的。那么我们在实际工作中又是怎样实施采购审批行为呢？我想你应该更有深刻的认识。认识现实中合理的采购审批行为是你解决上述3个问题的关键。

好，我们引导着来分析采购审批的具体行为，正如“探花”所提示的那样，做为一个采购计划的审核负责人针对采购项目众多的纸制采购计划单时，不可能在每一条采购项目上审核签字，这样会降低审核负责人的工作效率，，一般审核负责人重点工作是对每个采购项目的多个必要审核点进行评审，大量的精力应该投放在平衡对比工作，习惯性的工作模式是将所有采购项目审核结束后再在计划单上签字审批确认。
如果我们通过数据库应用程序来模拟这个过程，那么必然要设计 一张“已审核采购计划”这样的表。

反过来讲非要一定这样做么？
我们要再重新分析一下审核过程，采购计划审核负责人必然要一项一项的进行审核，当然可以也可以一项一项的进行批准，如果我们不受到纸制文档限制而是使用扩展性更强的计算机应用程序实现管理，那么效率上已经不是问题，从这一点可以说没有必要单独设计一张“已审核采购计划”表。如果你对面向对象的分析方法比较熟悉，那么我们可以把 “已审核采购计划”视为一组实施采购行为命令的集合，其中每一条采购命令信息就是一个对象，每个命令对象都会有多个描述其命令特性的属性，这些属性在计算机领域的数据库里概念就是“字段名称”；如果采购项目已经通过审批，那么必然要在“采购计划”数据表中存在这样的字段（属性）来明确体现出通过审批的标志，这也是前面回复者所称的“标志位”。从数据库尽量减少冗余原则上也要求尽量减少重复的数据记录，因此没有必要单独建立一张“已审核采购计划”表

关于第二个问题：
主管审核过的计划汇总如何延伸到计划明细的问题，我个人认为你首先要弄清楚 什么是计划汇总概念，我认变计划汇总就是每个采购项目的在某一属性（例如同一审批通过日期）的基础上的数量合计。而你所谓的计划明细实际上就是采购项目的集合。由于数据记录来源于同一个表所以不存在你所说的“延伸”说法。

关于第三个问题：
编写审核程序，是计算机与交互者的界面UI范畴 ，在ACCESS 中多指 窗体设计。
你可以通这子窗体中的 复选框 控件（Check）的值（-1与0）来做为审批人审批确认操作标志位。（例如 复选框 控件值=-1时确认为通过审批，控件值=0时确认未通过审批。）审批负责人只需要通过鼠标就可以轻松完成审批操作。最终还要通过一个主窗体中的“审批”按钮来实现正式批审。

注意：使用复选框是本人的推荐的控件，你当然还可以使用其他的控件的表现形式来设计。