作为一个系统分析师，给出一个业务然后进行分析，将各种可能遇到的情况尽量的列举出来，这是基本素质之一。这不但需要系统分析师有比较严谨的思维，而且还要求其有很丰富的工作经验。假设现在用户有一个“重新打开销售订单”的业务需求，那么在设计、开发这个作业的时候，需要进行哪些限制呢？

一、重新打开订单业务背景

在分析某个业务的时候，最重要的就是要了解业务的背景。如果忽略了业务背景，那么设计出来的模型就好像是海市蜃楼，虚无缥缈。为此笔者建议，作为系统分析师，在分析业务需求的时候，一定要讲需求回归到背景中去。或者我们可以把它叫做案例分析题。用户给出的可能是一个知识点，我们要将其组成一个现实的案例。

一般订单的处理包括两个阶段，分别为订单的输入与订单审核。业务员接到客户的订单之后，需要将订单数据输入到系统中。然后再由其主管进行审核。当主管在系统中做了审核的操作之后，订单的数据就不能够再进行更改。但是在实际过程中，由于各种各样的原因，仍然需要对已经审核过的订单进行修改。如业务员在输入数据的时候，将订单的数量输错了，而主管在审核的时候又没有发现这个错误。或者说，后来由于客户的原因，更改了订单的数量或者交起，此时用户就可能需要更改销售订单。在遇到这个情况之后，用户就会提出需要，要重新打开销售订单进行更改。

二、重新打开订单业务的后台限制解析

系统分析师现在需要考虑的就是，是否允许用户打开已经审核的销售订单呢？此时不能够简单的回答允许还是不允许。而是要根据实际情况来分析。

如在中，一般采购需要根据销售订单来生成采购订单。或者说物料计划部门需要根据销售订单来生成物料需求计划。也就是说，其他部门需要用到销售订单中的数据，销售订单是系统流程的起源。如果现在其他部门已经根据销售订单生成了相关的采购订单或者物料计划，在这种情况下，允许业务员对销售订单数据的直接更改吗？答案是否定的。因为在这种情况下，如果还允许更改的话，那么源数据跟后面的纪录就会对不上。后续在追踪分析的时候就难以找到责任人。总之，就是某个单据已经生成了后续单据的时候，这个原始单据就不允许重新打开进行更新。

但是如果这个销售订单刚下，其他部门根据还没有处理。或者说其他部门在处理之前的审核过程中发现了问题，告知了业务员。在这种情况下是否允许用户打开订单来更改呢？一般在这种情况下是允许的。因为没有关联纪录，此时更改源数据不会对其他部门产生连锁反应。而如果采用其他单据来更改这个订单信息的话（如通过订单变更单来更改），虽然从技术上说是可行的，但是一般没有这个必要。毕竟在这种情况下，还没有给企业带来实质性的损失。而如果通过订单变更单来更改的话，反而会造成比较多的垃圾数据。所以在这种情况下，才真正的需要重新打开订单的作业。

三、在技术上如何将这种限制落实到实处

业务背景了解了，具体的限制也心中有数了，接下去的工作就是需要设计，如何将这种限制落实到实处。虽然说条条道路通罗马，但是我们在具体实现的过程中，还是需要兼顾成本、效益、安全等原则。

以这个“重新打开订单”的业务来说，从技术上看可以按照如下这个思路进行限制。

第一步：可以在订单级别，设置几个字段，用来关联后续的单据。如可以在销售订单单头的数据表中，设置一个“生产计划”的字段。如果这个字段有相关的内容，则表示这个订单已经生成了生产计划。在执行“重新打开订单”这个业务的时候，就需要先去判断这个字段的值。如果非空的话，那么就不允许重新打开订单。相反，如果为空的话，表示没有后续关联的单据，则允许用户打开订单。如果销售订单关联采购订单或者关联出货单，都可以进行类似的设置。

第二步：其他相关联单据生成的时候，注意需要会写相关的字段。如现在用户根据销售订单来生成采购计划。当采购计划正常生成之后，需要将生成采购计划的序列号回写道对应的销售订单字段中。只有如此，销售订单中这些控制性字段的信息才能够得到及时更新。“重新打开订单”作业才能够根据这些字段来进行作业的控制。

第三步：删除作业时的处理。在实际工作中，还可能会遇到这种情况。如某个销售订单中有100个产品。而由于客户的原因，需要更改其中50个产品的数量。此时对于采购计划与采购订单的影响就会比较大。遇到这种情况时，用户可能宁愿删掉采购计划，让销售员重新打开销售订单更改数量。然后用户再重新生成采购计划。遇到这种情况该如何处理呢？这也就是说，当删除采购计划的时候，也需要同时清空对应销售订单中“采购计划”这个字段中的值。当这个值变为空之后，“重新打开销售订单作业”就可以重新打开销售订单，让用户进行修改。

以上这个步骤，从开发语言上来看，主要就是用来IF判断语句与Update更新语句。在应用程序开发上，没有多大的困难。而主要的问题就是，作为系统分析师，要将这些内容一一考虑到。其实系统分析师就好像是一幢大楼的设计人员。而程序开发人员就好像是造房子的人，他们只需要根据设计人员的图纸来建造即可。系统分析师需要对最后的运行结果负责，开发人员只需要保证在代码的编写上不要出现错误即可。为此系统分析师在这里起到的作用是非常之大的。

其实这个需求还有其他的处理方式。如在执行“重新打开订单”作业的时候，可以去采购计划那边查询，看看有没有目标定单的相关信息。从技术上讲，这是可行的。但是笔者不建议这么设计。在文章一开头，笔者谈到过系统分析师在分析业务逻辑的时候，需要成本、效益、安全等兼顾。根据上面这种方法，虽然最终可以达到用户所需要的目标。但是不符合安全、效益的原则。如如果采用第一种方法，即在订单单头表中放入控制字段的话，那么就可以从销售订单中直接关联到采购计划，也就是说可以直接从销售订单关联查询到采购计划。而如果采用第二种方式的话，就只能够实现控制，而不能够实现关联查询的功能。此时在选择方法的时候，就需要考虑效益原则，而不能够光考虑目标。简单的说，就是选择具体的实现方式时，如果能够给用户带来额外的附带价值，那是最好的。