连锁的账，最容易坏在"一张单没走完"
订单一次订、分几次发是常态。整单流转的系统在这种情况下只能靠人：抄一遍、记一笔、月底对不上再吵一架。
整单照抄，逼人造假
只能整单生成下游单的系统，遇到分批发货就得把订单改小再生成，或者干脆另开一张无源单，历史数量关系当场断掉。
这套做法：按行引入：勾其中几行、这行只带一部分数量，未勾的行原样留在上游，一张订单可以派生多张下游单。
剩余多少全靠人记
客户问"我还有多少没发"，答案在仓管的脑子里；人一休假，这单就说不清。
这套做法：剩余量由系统在引入时逐行算好，采购侧甚至默认只把还有剩余的行勾上，人只做取舍不做计算。
同一批货录两遍
订单录一次、出货单再录一次，规格、单位、单价、批号全靠人复制，错一个数字后面所有的账都要解释。
这套做法：下游单直接取上游明细行，价格、单位、批号一并带过来；上游单号也留在这张单上，事后能倒回去。
一条链路上，系统管的是这四件事
能引谁、能引哪几行、引完剩多少、这张单现在算什么状态。
| 在哪一层 | 怎么落 | 说明与界面上看得到的 |
|---|---|---|
| 哪张单能引哪张单 | 为下游单指定可引入的上游单据类型 | 实测已经打通的三条：销售订单→销售单、销售单→销售退货单、采购订单→进货单。上游类型是配在下游单上的，不是让制单人自己找 |
| 先定对象，再引明细 | 先选客户（采购侧选供应商），再点引入 | 没选客户就点会当场拦下来，提示要先选择客户——这一条挡住了"把张总的货并进李总的单"这种错 |
| 按行勾选 | 在列出的可引入明细里逐行打勾，页脚实时显示已选几行 | 一行一条明细，勾与不勾是行级别的自由：五行的订单可以只勾三行，也可以只勾某一行的一部分数量 |
| 剩余量按行算 | 不必人工比对，系统给出每行还剩多少 | 实测销售侧默认全勾、采购侧默认只勾剩余量大于零的行，两种默认都说明系统是按行知道剩余的 |
| 上下游留痕 | 引入完成后，这张单记着自己的上游单号 | 列表与新增页都有"原单据号"这一栏，事后要查这批货出自哪张订单，不用翻聊天记录 |
| 整张单的状态 | 一张单在草稿、审批中、已生效、已关闭之间走 | 实测这四种状态都在用；未生效的单不会把数量真正压到库存与账上，所以"开了但还没确认"和"已经算数了"分得清 |
| 占用与可用分得开 | 现存量、采购在途、已被销售订单占用的量、可用数量各是一栏 | 这一组是行级流转能落地的底气：订单占用先记下来，仓管看的是可用数量，不会出现两个店抢同一批库存 |
要说白的边界：这条链路只服务"有上游的单"。临时改价、补录历史、赠品这类调整走的是各自的单据，不去硬凑一条不存在的上游——凑出来的关联，月底一对就散。
一张 5 行订单，分两批出完的完整过程
下面写的是"第二张销售单"引入时的界面逻辑，数量为示意。
| 明细行 | 货品 | 订单量 | 首批已出 | 本次可引 | 本次引入 |
|---|---|---|---|---|---|
| 1 | 吐司 | 100 | 60 | 40 | 40 |
| 2 | 可颂 | 80 | 80 | 0 | 不勾 |
| 3 | 生日蛋糕 | 10 | 10 | 0 | 不勾 |
| 4 | 月饼礼盒 | 200 | 0 | 200 | 120 |
| 5 | 饮料 | 50 | 50 | 0 | 不勾 |
| — | 本张销售单合计 | — | — | 240 | 160 件 / 2 行 |
行级流转带来的管控粒度，正好是烘焙连锁要的那一档
门店订货按车次、工厂出货按炉次，一次订货分两次配货是日常。整单流转的系统必须让人改上游单据来迁就流程，改一次，前面所有核对都作废；按行流转则让上游单不动，下游按实际情况派，两张单各自留痕。
- 第 4 行是本张单的关键：一箱 200 盒先出 120 盒，剩下的 80 盒不复制、不改订单，它继续留在原订单里等下一次派单。
- 第 2、3、5 行已经出完，弹窗里仍会列出来（默认全勾时它们已经被处理过），人做的是核对而不是重算。
- 引入只带数量、价格与批号这些信息；库存真正扣减、金额真正入账，是在这张销售单生效之后。所以"引入了但还没生效"的单，不会把账抢先变动。
这三种走单方式最吃这套
一单多批、多供一单、退货按批，都是整单流转处理不了的形状。
大客户团购分批交付
企业中秋礼盒一次订两百份，按客户要求的三个时点分三次送。每一次开一张销售单，从同一张订单里勾当次要出的行与量。
原料分批到货
面粉订了 40 袋，供应商先送 25 袋。进货单只引入 25 袋，剩下的量仍在采购订单上，到期没到货一眼能看出来。
部分退货
客户退的只是其中一个规格、几盒蛋糕。退货单从原销售单按行引入，退的是当初卖的那一行，价格与批号跟着走，不会出现退货单价与售价打架。
三条实话
行级流转解决的是"数量怎么派"，不解决"该不该派"。
- 能流转的前提是这一对单据被配上关系。实测目前打通的是销售订单→销售单、销售单→销售退货单、采购订单→进货单三条；其余单据之间各有自己的状态推进方式，不在同一个引入组件里，不能凭想象推广成"什么单都能上下游"。
- 先选客户再引入，是硬约束不是提醒。跨客户混引在这一步就被拦下，好处是不会串单，代价是不能"一张出货单顺便给两个客户"。
- 剩余量由系统算，但仍要人复核一次。特别是采购：默认只勾还有剩余的行，如果上游订单本身填错，引入会把错继续往下带。
- 这一条链上没有"报价单→订单"。询价与报价在自家流程里怎么落，请用自己的实际走法去对照，不要照抄别家的单据层级。
按行流转，与整单照抄
同一家既做门店配送又做团购批发的连锁，两种做法下的日常差别。
| 比什么 | 单据上下游行级流转 | 整单生成 + 手工补录 |
|---|---|---|
| 分批次出货 | 同一订单可派多张单，每次勾当次的行 | 改小原单再生成，或另开无源单 |
| 剩余未发 | 系统按行知道，弹窗列给你看 | 记在仓管的本子上 |
| 录入次数 | 一单一次，其余靠引入 | 订单、出货单各录一遍 |
| 价格与批号一致性 | 跟着上游行走 | 重录时容易打错 |
| 事后追责 | 上下游单号互指，能倒查 | 两张无源单之间说不清 |
四步把流转关系用起来
先跑通一条链路，再考虑第二条；一上来配全公司，一定卡在自己没想到的细节上。
挑一条最疼的链路
十有八九是"订单分几次出"。就在销售订单→销售单这一条上先做，别贪多。
把订单录规范
行、单位、数量、批号一次录准。引入是按行取数的，上游录三遍改三遍，下游跟着抖三遍。
出货时按行勾
开销售单，先选客户，再打开引入，只勾本次要出的行，需要拆量的那一行改成当次实出数。
周会核对一次未引完的行
把还剩量大的行拿出来问一句：是货没到、客户改期，还是忘了出。三种原因各自的处理完全不同。
关于单据行级流转，常被问到的六件事
能，这是行级流转的主要用途。当次出多少就在下游单上改多少，剩余量继续留在原订单行上，不需要把原订单改小。
不能，也不会让你这么干：引入前必须先定客户，一张出货单对应一个客户。要分给两家，就按两家分别开单，各自从各自的订单派。
行的剩余量归零即不再出现在"还有剩余"的默认勾选里；整张订单要不要关闭由你走状态这一步，系统不会替你决定这单结没结。
以本次实际成交价为准录入下游单——这正好是有用的信息：差异说明订单价与交付价不一致，财务与业务对不上时，这一处就是要谈的点。
实测退货单的上游是销售单，正常退货走引入；原单信息（价格、批号）跟着过来，避免退价与售价打架。找不到原单的例外情况，建议按公司规定单独审批，不要随意开无源退货。
不是同一套。它们各有自己的状态与生效流程，本轮没有取到它们使用同一个引入组件的证据，所以不能给你保证；具体请在实机上按你的走法确认。
单据流转之外，这条链上的另外几层
谁点头才能生效、状态怎么算、删错了怎么找回，各自是一页。
系统架构的八项机制，一项一页
这一页讲的是其中一项。想知道日常业务还靠哪些底层机制兜住，直接切过去。