中标之后：合同评审到订单

25.1 那张有签字的纸，在系统里长成什么样

小徐中标回来，第一件事不是去车间，是建合同。

系统里的合同分两半。上半是抬头：甲乙方、双方代表、签订日期、付款条件、币种、分类、几个金额。下半是明细——明细不是一张表，是存在同一格里的一串文字：产品名、编号、加工要求、单位、数量、含税单价、工装治具费、工艺开发费。

这一格决定了后面许多事能不能做。明细以前每一行没有自己的号，别的单据没法指着第三行说"我说的就是它"。现在系统给每一行补了一个稳定行号（仍记在同一格里、不另拆表），对账、回溯能按行落到某一条上；可要跟某一行数量对上，仍得绕回产品名字（下文细说）。

打印出来的那份是固定版式，抬头就叫委托加工合同。引言第一句写着：具体产品的价格、数量、交货期等细节以订单为准。第一条又补一句：具体价格由甲乙双方协商确定，详见每次订单。

这张纸还有个纸面上就能看出来的小毛病：条款从第一条数到第三条，翻页又出现一个"第四条"——技术要求一条、付款方式一条，两个第四条并排印在同一份合同上。

25.2 系统把那句"以订单为准"倒过来讲

到下单那一步，系统的主张跟纸上那句正好相反。

合同的状态不给人填。新建时系统直接把它写成"已生效"，界面上没有这一栏可选——那个新建表单里其实默默带了一个"草稿"状态交上去，后端拿到就扔了。之后全由订单反推：还没有有效订单、或者订单都没进生产，算"已生效"；有任一订单进了生产，算"执行中"；订单全部完工或交付，算"已履行完毕"。人唯一能手工按下的状态是"终止"，而终止之后没有恢复的口子。

数量这一格，系统的主张如今落在中间。两条下单的路——报价转订单、手工建单——不再把明细数量无条件换成合同之和；下单时人在额度内填实际数，系统只校验"本次下单量之和不超过合同可下单量"。合同锁的是总量，不锁你这一次非下不可多少。

于是以前那种两边不讨好的情形翻了过来：合同里有这个产品，格子让你在额度内改，提交时按额度校；合同里没有这个产品，仍被拦下，理由是这产品未列入执行中的合同明细、不能下单。

以前留在原地没跟着改的两句话，如今兑现了一句、删掉了一句。下单接口"如报价 300 件实际下单 100 件，请填写实际下单数量"这句话系统真的照做了——填进去的数保留，不再被合同数覆盖；报价转订单确认弹窗里那句"订单初始状态为待审核"的残留承诺已删。

"以订单为准"和"以合同为准"这两句话，眼下定成了一个口径：合同锁总量、订单在额度内填实际，两条下单路用同一套说法。纸上前一句、系统后一句各讲各的，这种打嘴仗收住了。

25.3 锁量从每一次，改成了锁总共

这一条得单独说，因为它最容易被当成已经管住了。

合同上写 300 件，以前可以下 300 件一次、再下一次还是 300 件——没有任何地方回扣已用额度。现在可下单量改成"该客户全部执行中合同同名产品数量之和 − 已下单量"，下一单扣一单，做完 300 件再下就报"超出合同可下单量"。要做这个回扣，前提是能按行统计；明细行如今带上稳定行号，这个入口不再先天缺失。

同一个客户如果同时有两份执行中的合同，可下单量按两份加总来扣；而每一下单，系统会把这张订单显式挂到那份合同上（取编号最大的执行中合同）。事后问"这一单记在哪份合同名下"，系统答得出；至于"这 300 件具体吃掉哪份合同的额度"，仍是合到客户级总量来扣，不分到份。

产品是靠名字认的。合同明细从表格导入时按列的位置硬读，第二列就是项目名；下单时拿报价里的产品名去撞，去掉两头空格之后要求一模一样。多打一个空格、一个写成"铝支架"一个写成"支架（铝）"，结果就是那句"不能下单"。

其实有另一条路。建合同时那一行产品是从资料库里挑的，挑完就把产品编号存进了那一行。报价、订单、发货往产品资料库上挂这件事，如今确实按编号认、不再回头撞名；唯独合同可下单量那一头还按产品名求和，是并过来的最后一处。

还有一处绕回来了。手工建合同时那个"从客户已有产品里挑"的推荐明细，数量默认值取自这个客户还没开工的那几张批量订单，取不到才用报价数量（程序里这一行的注释写的是"待生产"）；而这一格允许人改。若没人改它，就变成：合同的数量抄订单，下单时订单的数量又回头抄合同。两个数字互为来源，谁也说不清这个数最初是谁定的。

门槛拦下来时的提示写得很实在：客户尚无执行中的合同，请前往合同管理创建合同（创建即已生效）。这一句要跟下一节连着读。

25.4 合同评审这张纸，签在下单之后

系统里确实有合同评审：四格意见——技术、商务、质量、交付；结论三档；另记评审人和评审日期。

问题是它拦不住任何东西，而且是好几处都不咬合。

• 顺序天生后置。 评审表上"关联合同"是必填，也就是说必须先有合同，才建得出评审。可合同一创建就已生效，一生效就能下单。评审还没做，单子已经进得去车间。
• 合同和评审现在互相看得到。 评审通过或驳回，都会把这一次回写进合同那一侧的关联格；合同详情也回显关联的评审。以前合同上那一格永远空、无人写无人读，这一处补上了。
• 下单不过问评审。 两条下单路查的都是合同状态与合同明细，没有一处问过评审通过没有。
• 审批模板有，发起点没有。 合同审批的三节点模板在种子里躺着，从头到尾找不出一个照它发起审批的动作。"合同要走三级审批"这句话，在当前版本里不成立。

点一次"通过"，唯一被联动的是一张项目表上的阶段：从"合同"推到"工艺"。而评审表单上根本没有项目可选，只有合同——这一步在界面上走不到。

还有两处。

"有条件通过"这一档几乎不会出现。 按下通过钮写死"已通过"，按下驳回写死"已驳回"；界面上唯一的来路，是新建或编辑那个弹窗里的三选一。列表上方那个"有条件通过"的筛选项，除非有人手工选过，常年查不出东西。

能看见不再等于能批。 新建评审要新建权限，改、通过、驳回三个动作把守的是编辑权限——不再四个动作同挂一个查看码。权限清单里那个"编辑评审"码真用上了；只分到查看权限的账号，绕开界面直接调那四个动作会被挡下。 两端按钮的显隐和后端这把锁，如今是同一套码。

评审日期只记到日，四格意见是自由文本，通过时不要求写意见、驳回时必须写。这张纸留下的是"哪天有人签了一下"，不是"签的人看了哪几条"。

25.5 手机上签的那道评审，字大半落进纸里了

手机上有评审列表和评审详情两页，路由也接上了。以前那一页跟系统说的不是同一套话，如今大半说得上同一套了。

四格意见，手机端以前用的名字和存下来的名字不是一套，填的四段话提交上去一条也没存进、读回来永远"暂无意见"。现在手机端改用后端真源那四个名字（技术/商务/质量/交付评审），填得进去也读得回来。

以前驳回时手机不传意见、被系统要一句"请提供驳回意见"——现在驳回带上意见框。列表顶上"评审中"那一签以前传的和存的不是同一个词、点下去永远空列表——改成同一个值。搜索框以前没反应——列表接口补上了这一项查询条件。剩下半处：详情抬头那几个位置（合同编号、客户、合同金额）不在评审这一层的返回里，接口给的是合同 ID 和评审人 ID，手机页靠它再去查一次才填得满。

说这一节不是为了挑毛病。它指着的是更贵的一件事：同一套接口接两个端，名字和值都得照系统里那个真源写。差一点，界面上多出来的每一个格子，都是日后要在会上被问的空位。

25.6 订单落下来那一刻

三种进法，落点不一样。报价转订单落的是一条注释里写明的"草稿"；手工建单则被按类型改写：首批落成"待报价"，批量落成那个在订单页上显示为"待审核"的值——而后端给这一行写的注释是"批量订单直接进入待生产"。同一个状态格，注释说待生产，界面说待审核。 前端传来的状态一律被覆盖。首批也不发订单审批，注释写得清楚：批量无需审批，首批走报价审批加转生产审批。

于是状态机里那条"草稿提交后进待审、并配一道订单审批"的迁移，在这条路上没有人执行。它跟前面章节里那几条同样的落法——定义在，走的人没有。

口径也散。订单状态那一格的说明只列了八个值，实际枚举里有十二个；同一个"批了"的状态，在驾驶舱里叫"已审批"，在报表里叫"已审核"，在订单页里叫"已批准"。三张屏并排看，像三件事。

订单不再丢那件事。报价转订单时，以前明细行上那个指向产品资料库的位置不复制过来、手工建单反倒写上——第二十四章那条断链在下单又断一次。现在转订单也补上这个关联，唯一源落在明细行，两条路接上了。

批量订单另有一道自己的门槛：它要求产品在"待生产库"里有库存，数量按产品名去库存里撞，建单同时把库存扣掉。那个待生产库以前在代码里是一个写死的编号，换一家厂、换一套库房就要人改代码；现在改成按仓库名去字典里找、找不到才回落到那个默认号兼容历史。

25.7 这一章不做的事

• 不细分到份：可下单量按客户级总量回扣已用，两份合同加在一起扣，不区分某一次下单吃的是哪一份的行。
• 不上线合同审批：模板有，发起点没有。
• 不把评审接成下单硬门槛：评审与合同已双向显示，但下单动作本身仍不查评审通过与否——接哪一头都是一个决定，不是一个小改。
• 不做合同条款版式自定义：那份纸是固定条款拼出来的，两个"第四条"目前谁也改不掉。

25.8 今晚能定的两件事

1. 把合同纸上那句"以订单为准"跟系统对上口径。 系统这一头已定成一个口径：合同锁总量、订单在额度内填实际。剩下的是一句话——把合同模板引言里"以订单为准"改成跟这个口径一致的说法，别让纸和系统各讲各的。
2. 给合同评审定性质。 它现在还是一张记录纸——合同与评审两头已互相显示，但下单不查它。若要它把关，就得接到下单门槛上；若不把关，就把它挪到合同附件那个位置上，别再让人以为它是一道关。最糟的是眼下这种：有人以为它拦得住。

下一章讲首件通过之前，车间、工艺、采购三个人在替同一张单跑多少趟。