门店要货这件事，为什么总是对不上账
一家开到十几家门店的连锁餐饮，订货通常是这么跑的：店长发现冰箱空了，在微信群里发一条"XX店 明天要 五花肉 20 斤、鸡蛋 6 箱"；总部接单的人在群里回一句"收到"；第二天司机把货送过去，门店员工签个字，单子塞抽屉里。
跑得动，但每一环都在漏：
- 要货靠接龙。群里消息一多，谁要的、要多少、有没有改过，只有当事人记得。改单靠再发一条"刚才那个改成 15 斤"，两边都不知道以哪条为准。
- 总部不知道总量。采购和中央厨房要备多少货，靠接单的人自己心算。同一天十家店要同一个品，汇总晚一步，备货就晚一步。
- 到店数对不上。要 20 斤、发 18 斤、实收 17 斤，三个数在三张纸上。缺的那一斤是仓库少发、路上损耗，还是门店验收时记错了，事后没人能说清。
- 对账靠月结挤。到月底，财务拿着配送单、门店拿着验收单，两边一笔一笔碰。碰不上的就挂账，挂到最后往往不了了之，损耗就这样变成了"说不清的成本"。
问题的根子不是人不用心，是这四件事（要货、配送、验收、对账）没有共用同一份数据。每一环各自记一份，任何一次改动都只能同步给"当时在场的人"。
用 Inkwell AI 构建器做这件事的思路很朴素：把这四件事变成四张互相引用的单据，让它们共用同一份门店和商品档案。下面按"数据怎么建 → 页面怎么用 → 移动端怎么配合 → 上线前查什么"拆开讲。
一、数据怎么建：先立档案，再排单据
建模块的顺序很重要——先有档案，后有用单据引用它的流程。顺序反了，商品名称到处都是手输，"五花肉"和"五花肉（冷鲜）"会变成两个品。
1. 门店档案（主数据）
一行一家店，字段大致是：
- 门店编号（唯一，建议沿用已有的内部编码，不要新造一套）
- 门店名称、所属区域/城市
- 店长（关联到平台已有的用户，选人而不是手打名字）
- 收货地址、联系电话
- 配送路线/配送日（比如"一三五线"），后面配送单按这个分组
- 营业状态、开业日期、备注
门店编号是后面所有单据的锚点。订货单、配送单、验收单、对账表都只记这个编号，不重复存门店名称、地址这些明细——门店改名、换店长，改一处，历史单据的显示跟着变，不需要回头改几百张单。
2. 商品与规格档案（主数据）
- 商品编码（唯一）、商品名称
- 规格（如 500g/袋、10kg/箱）
- 单位（斤、箱、袋、桶）
- 商品分类（肉类、蔬菜、粮油、包材、自有成品）
- 是否中央厨房自制、保质期天数、存储条件（常温/冷藏/冷冻）
- 默认供应商（可选，关联供应商档案）
这里有两个容易踩的坑，正好是平台已经有现成机制的地方：
- 单位、分类、存储条件这类固定选项，用数据字典统一维护，不要在表单里做成自由输入框。字典是一处维护、全模块共用的枚举源，后面换叫法只改字典，不用改代码。
- 商品分类、单位这些字段的选项值，一旦定了就尽量别随手加同义词，否则统计时报表会分裂成一堆相似的分类。
3. 供应商档案（可选但建议）
如果想在订货这件事上顺带管住"向谁买、什么价"，再建一张供应商档案：供应商编号、名称、联系人、联系电话、结算方式、状态。商品档案上用"默认供应商"引用它即可。
4. 门店订货单（主子表）
这是整个流程的起点，建议做成主子表结构（一张单 + 若干明细行）：
- 单据头：订货单号（自动生成）、门店（引用门店档案）、要货日期、期望到货日期、下单人、状态、备注
- 明细行：商品（引用商品档案）、规格、单位、要货数量、备注
关键：明细行里只存商品编号和数量，商品名称、规格、单位都从商品档案带出来。 店长下单时只要选商品、填数量，不会出现"白菜"和"大白菜"两行数据。
5. 配送单（发货单）
- 单据头：配送单号、关联订货单号、配送日期、配送路线、司机/车辆、发货人、状态
- 明细行：商品、发货数量、批次/生产日期（保质期相关的品建议记）
配送单通过订货单号与要货单挂上。一张配送单可以汇总多家门店的要货——这是总部最需要的那个视图：今天这条线上一共要发多少斤五花肉。
6. 验收单
- 单据头：验收单号、关联配送单号、门店、验收人、验收时间、状态
- 明细行：商品、应收数量、实收数量、差异数量、差异原因（如破损、短少、品质不符）、处理方式（补发/折让/计入损耗）
验收单是把"发 18 斤、收 17 斤"这一斤的去向落到具体原因的地方。差异数量可以让系统按"应收 − 实收"自动算，人只填原因。原因选项同样走数据字典，保证全连锁口径一致。
四张单据串起来是一条链：订货单 → 配送单 → 验收单 → 对账。每一环都能顺着单号往回查，这就是"对得上账"的物理基础。
7. 金额怎么存（一个技术细节，但影响对账）
凡是要参与对账和统计的金额，按"分"存整数（比如 12.30 元存 1230），不要存小数。浮点数做加减会出现 0.01 的漂移，几十笔单累起来就是几分几毛的差额，月末对账最耗时的就是查这种差额。平台的金额字段约定就是这个思路，建表时直接按这个口径定义。## 二、页面怎么用：给每个角色一个界面对得上
数据建好之后，页面不是"越多越好"，而是每个角色打开手机或电脑，看到的就是他今天要处理的那几件事。建议按角色配这几个页面。
1. 门店订货页（店长用）
- 列表：本店的历史订货单，按要货日期倒序，带状态标签（草稿/待审/已受理/已发货/已验收）
- 新建：选要货日期 → 逐行选商品、填数量 → 提交
- 常用商品：把门店高频要的十几个品做成默认排序或快捷入口，减少每次翻目录的时间
- 历史参考：开店长最想要的那个功能——"上次要了多少"。同一商品旁边显示上次要货数量，店长照着改就行，不用凭记忆估
2. 订货看板（总部/区域经理用）
一个屏幕回答三个问题：
- 今天多少家店提交了、多少家还没提交（按要货日期筛选）
- 按商品汇总的要货总量（这个品今天全连锁要多少）
- 按配送路线分组的门店清单（这条线要送几家、各要什么）
看板的数据直接来自订货单明细，不需要人工再汇总一次 Excel。这是"接龙改在线"最直接的收益：总量是实时算出来的。
3. 配送作业页（仓库/中央厨房用）
- 按配送路线拉出当日所有要货明细，汇总成拣货清单（商品 → 各店数量 → 合计）
- 拣完货生成配送单，一行一店，或一张单合并多店
- 出库时如果有品缺货，直接在明细上改实际发货数量并备注原因——改的是配送单，不是订货单，门店要的量和实际发的量分别留痕，差异一眼可见
4. 验收页（门店收货用）
- 司机到店，门店打开待验收列表，点开自己那单
- 逐行确认实收数量，默认带出应收数量，只改有差异的行
- 有差异必须选原因（走数据字典），处理方式选补发/折让/计入损耗
- 提交后这单状态变"已验收"，差异记录同步进总部看板
5. 对账页（财务用）
- 按门店 + 时间区间汇总：应收金额、实收金额、差异金额
- 按供应商汇总（如果记录了供货单价）：本期应结金额
- 支持导出，交给财务做月结或对接后面的应付流程
对账页只做"算得清"，不做"算得花"。字段以单据上真实存在的数量、单价、金额为限，不做系统没有依据的推算。
6. 状态流转与审批：什么该走审批，什么该自动
订货单的状态建议这样走：
草稿 → 已提交 → 已受理 → 已发货 → 已验收（或已取消）
其中"已提交 → 已受理"这一步可以接工作流，也可以直接自动流转，看管理需要：
- 要走审批的场景：门店月度订货额超预算、临时加急订货、大额临时采购。这类单提交后由区域经理或总部采购审批通过才放行，审批节点、审批人、驳回后怎么改，用工作流可视化编辑器配，不用写代码。
- 不必走审批的场景：日常按配送日提交的常规要货。这类单提交即受理，店长不用等，效率优先。
- 自动化的场景：用定时任务做"每日要货截止时间到点自动锁定""已发货但超时未验收自动提醒门店"。这类重复性的催办动作交给定时任务，比人工在群里喊可靠。
审批这件事的原则是：只把"少数异常单"放进审批，别把常规单也堵在流程里。全量审批是很多企业上系统后第一个消极怠工的来源。
7. 权限怎么配：门店只看得到自己
连锁业态的权限底线很简单：店长登录后只应该看到本店的数据。平台的权限体系支持按角色 + 数据范围控制，落地时至少配这几组角色：
- 店长：本店订货单的增删改查 + 本店验收单的填写
- 区域经理：辖区内门店的订货单查看与审批
- 仓库/中央厨房：全部门店的要货明细查看 + 配送单操作
- 财务：对账页查看与导出，不参与日常单据编辑
- 总部采购：商品档案、供应商档案、数据字典的维护
权限配错是最容易在上线后第一周被发现的问题，建议建完模块后先用两个测试账号各登一次，确认看不到不该看的数据。
三、移动端怎么配合：店长和收货员手上那台手机
这条流程的两端都在"手上"——店长在店里巡场时发现缺货，收货员在门口卸货时要填差异。这两个场景如果只能回办公室开电脑，系统就会被绕过去，微信群又会活过来。
所以订货与验收要优先做成移动端可用的页面：
- 店长下单：手机上打开订货页，筛商品、填数量、提交，一分钟一单
- 收货验收：司机到了，门店员工在手机上找到对应配送单，逐行确认实收数、拍差异照片
- 到店提醒：货发出时给门店发一条通知，收货员不用盯着群等人喊
- 差异上报：发现缺、破损，当场填原因并上传照片，证据跟着单据走，事后再也不用回忆
平台上 PC 端构建的模块，其页面与菜单可以同步到移动端工作台，店长打开手机就能用，不需要另做一套 App。这是把"纸单 + 微信群"真正替掉的前提：手机上能三下点完的事，人不会绕开系统。
一个务实的建议：上线时先只推订货 + 验收两个移动页面，让店长和收货员先养成"有事上系统"的习惯，配送汇总和对账留给总部在电脑上做。一次全量铺开，反而容易在培训上卡住。## 四、上线前查什么：七个检查项
模块建完不等于能上线。跑第一张真实单据之前，建议逐条过一遍这几件事——它们几乎覆盖了连锁订货上线后最常见的翻车点。
- 商品与单位口径是否和现有习惯对齐。把门店和仓库最常用的几十个品先录进去，重点检查同名不同规格的品（"鸡蛋 30 枚装"和"鸡蛋 10 枚装"）是否拆成两个编码，单位是否统一。这一步没做干净，后面所有汇总都会失真。
- 门店档案与配送路线是否齐全。所有在营门店都要有记录，配送路线分组要能覆盖到每一家——漏一家店，就有一家店永远收不到货。
- 状态机是否闭环。订货单从提交到验收，每个状态都要有明确的下一步和取消出口。重点查两个边界：已发货的单能不能被门店撤销（一般不能），验收后发现差异能不能补填（一般允许一次补填并留痕）。
- 必填校验是否到位。订货明细没填数量、验收有差异没填原因，这些应该在提交时就拦住，而不是等到月末对账才发现有一行是空的。
- 权限是否按门店隔离。用不同角色的测试账号各登一次，确认店长看不到别家店的数据，财务改不了业务单据。
- 历史数据怎么进来。门店档案、商品档案这类基础数据通常已经在 Excel 里了，用平台的 Excel 导入能力直接建表导入，比逐条手工录入快得多；导入后抽查几行，确认规格、单位没有串列。
- 发布前跑一遍预检。模块挂菜单、移动端同步、页面与接口的连通性，平台在发布环节提供预检，把问题提前暴露在正式环境之外；发布后如果哪一处报错，模块的错误账本会留下线索，方便对照修改而不是盲目重试。
跑完这七条，再让一家门店、一条配送线先试跑一周。试点期的目标不是效率，而是确认"系统里发生的事和店里真实发生的事一致"。确认无误后再铺到全连锁——覆盖面一旦拉大，再回头改字段口径的成本会高很多。
五、之后怎么延伸：从订货这一件事长出去
订货 + 配送 + 验收这条链跑顺之后，往外延伸是最自然的，因为基础和单据都已经在了，加的通常是新页面而不是重建数据。
- 损耗与报损登记。验收单里的差异原因是起点；再建一张报损单，记录门店日常的过期、破损、试吃损耗，和验收差异分开统计，才能看清哪一部分损耗是可控的。
- 中央厨房生产。自有成品的品，可以在商品档案上补一份用料结构（成品 ← 用哪些原料、各多少），由门店要货总量反推原料需求量，再决定中央厨房今天备多少。
- 供应商对账与应付。配送单 + 商品上的供货单价，能直接汇总出"本期该给某个供应商结多少"，接到应付台账里，采购和财务不用再各算一遍。
- 总部集采与门店要货对比。把总部集中采购的到货量和各门店要货总量放在一张表上看，哪些品系统性备货偏多、哪些总是不够，数据会自己说话。
- 审批与流程继续收口。临时加急、超预算订货这些"例外"，随着数据积累，可以逐步把阈值和审批人配得更贴合实际，把审批人力集中到真正需要人判断的单子上。
小结
连锁餐饮的门店订货，难点从来不在"做个下单表单"，而在要货、配送、验收、对账四件事共用一份数据。用 Inkwell AI 构建器落地这件事，路径是清楚的：
- 先立门店档案、商品规格档案两张主数据，单位、分类这类固定选项走数据字典统一口径；
- 再搭订货单（主子表）→ 配送单 → 验收单的单据链，明细行只引用商品编号，金额按分存整数；
- 按角色配订货页、订货看板、配送作业页、验收页、对账页，让店长、仓库、财务各看各的；
- 把移动端先用在店长下单和门店收货这两个动作上，让系统真正替代微信群；
- 上线前用七条检查项 + 一条配送线试点把关，再全连锁铺开。
这套东西的价值不在于"上了系统"，而在于月底对账时，那一斤五花肉到底去哪了——能查得到。