采购订单流程在纸面上看起来很简单：创建采购订单、审批、发送、收货、开票、关闭。对基础采购系统来说，这一串步骤可能已经够用。但建筑软件要处理的情况更复杂。一张建筑采购订单可能同时关联项目、预算、成本代码、供应商、交付和发票。发出或修改采购订单，就可能牵动其他多条记录。

采购订单不只是文档

打开网易新闻 查看精彩图片

采购订单常被理解为发给供应商的单据，说明需要供应什么、数量多少、约定价格是多少。但在建筑软件内部，采购订单还承担交易记录的作用。一条典型的采购订单记录，可能需要与供应商、项目、成本代码、预算、单个明细行、审批状态、交付记录、发票记录建立关系。

这让采购订单成为一个有状态的对象。它的状态会随着采购过程不断变化，而这些变化可能影响系统其他部分。例如，批准一笔15000英镑的材料订单，可能在项目预算上形成15000英镑的承诺。记录一次部分交付，会改变尚未完成的数量。处理供应商发票后，又可能把部分或全部承诺转为实际项目成本。采购订单本身没有消失，它和周围数据的关系发生了变化。

基础流程看似清晰

最简单的采购订单生命周期可以建模为：草稿、已批准、已发送、已收货、已开票、已关闭。每个状态代表一个明确阶段。“草稿”表示订单仍在准备中。“已批准”表示拥有相应权限的人已经授权采购。“已发送”表示订单已发给供应商。“已收货”表示订购的货物或服务已经到达。“已开票”表示已收到针对该订单的供应商发票。“已关闭”表示预计不再有后续采购活动。

这是设计采购订单工作流的有用起点，但真实建筑采购很少沿着这样干净的路径走。订单可能先被批准，随后又被修改。材料可能分多次到货。供应商可能只对订单的一部分开票。开票价格可能与批准价格不一致。此时软件不能只依赖单一线性状态，而要理解每个阶段发生了什么，以及下一步应当发生什么。

建筑场景让流程变复杂

建筑行业引入的依赖关系，在采购订单被当作独立采购文档时并不明显。只保存采购订单总金额往往不够。设想一张订单包含12000英镑的金额，却可能被拆分到不同项目和成本代码中。软件需要维护的不只是总额，还有这些拆分关系，以及它们如何随交付和开票逐步变化。