采购的账，为什么总是对不上
一家做设备配套件的小厂，采购员三个人，单据全在微信里。车间要料，群里喊一声；供应商发货，照片发过来；月底对账，双方各自拉一张 Excel，数量、单价、已付未付，怎么都对不齐。老板问"这个月到底欠供应商多少钱"，答案是"等我核两天"。
这不是采购员不认真，是过程没有留下结构化的痕迹。口头请购、图片订单、手写送货单，每一环都是自由文本，到了月底要靠人脑把它们重新拼成一条链。拼错的代价，要么是多付货款，要么是断料停线。
采购管理模块要做的事很朴素：把"请购—下单—到货入库—对账"这条线变成四张互相关联的单据。每一张单据都有明确的发起人、明确的数量与价格、明确的状态。链条一旦成型，"欠谁多少""哪张单还没到货""这个物料最近三次买的价格是多少"这类问题，都变成页面上的一次筛选。
Inkwell AI 构建器的用法是：你用业务语言把这个流程描述给它，它生成数据表、PC 管理页与移动端伴同页面，你审核字段后发布。下面按"痛点 → 数据怎么建 → 页面怎么用 → 移动端 → 上线前查什么"的顺序讲清楚。
先划边界：这是业务台账，不是财务总账
写方案之前必须说清一件事，否则上线三个月就会和财务部打架。
采购模块管的是业务事实：谁申请了什么、以什么价买了多少、货到了没有、发票开了没有、按合同该什么时候付款。它输出的是一张"应付台账"——按供应商分组、按单据逐笔列出、能算出余额。
财务总账管的是会计凭证：科目、借贷方向、税额拆分、成本中心分摊、期间结转。这套东西有它自己的规则和系统，不该由采购模块来承担。
两者的接口是一句话：采购单据审批通过并入库后，形成一笔应付记录，供财务核对入账。所以设计时不要试图在采购模块里做凭证、做报表科目映射。把边界画清楚，这个模块两周内能用起来；画不清楚，它会变成一个谁都改不动的半成品。## 数据怎么建：四张单据 + 两张主数据
主数据先立住：物料与供应商
物料档案是采购的地基。最小字段集：物料编码、名称、规格型号、单位、参考单价、默认仓库、状态（在用/停用）。这里有个坑值得提前说：不要让采购员手打物料名称。"304不锈钢管 Φ25"和"不锈钢管25*304"是同一样东西，但对账时是两行。做法是把物料做成引用选择——在平台上，跨模块的引用关系通过软外键建立，采购明细里选的是物料记录本身，名称、规格、单位都从档案带出来，人只填数量和成交价。
供应商档案：供应商编码、名称、联系人、联系电话、结算方式（月结/批结/预付）、账期天数、状态。账期天数这个字段很关键——它是后面到期提醒的依据。供应商停用后，新单据选不到它，但历史单据仍然可查，这是台账类系统的通用要求。
平台的数据字典能力可以把"结算方式""币种""到货方式"这类下拉选项集中管理，多个模块共用一套口径，不会出现 A 页面叫"月结30天"、B 页面叫"月结三十天"的情况。
单据一：请购单
发起人通常是车间或使用部门，不是采购员。表头字段：申请部门、申请人、期望到货日期、用途说明、状态。表体是明细行：物料（引用）、数量、备注。
状态流转建议保持简单：草稿 → 已提交 → 已通过 / 已驳回。审批用平台的工作流能力配置，不需要为它单独开发。这里唯一要盯的细节是：请购单被驳回时必须填驳回意见，否则采购员和车间会来回扯皮。
单据二：采购订单
这是整条链的核心。表头：订单编号、供应商（引用）、下单日期、约定到货日期、结算方式（从供应商档案带出）、合计金额、状态。表体明细行：物料、数量、成交单价、金额（自动计算）、已入库数量、剩余待入库数量。
两个设计要点：
- 价格必须落在订单明细行上，不能只依赖物料档案的参考单价。 同一物料不同供应商、不同批次价格不一样。参考单价只用于预算和比价提示，真正结算看订单行的成交价。这样做的直接收益是：以后想知道"这个物料过去一年买过哪些价"，把明细行按物料筛选排序就出来了。
- 金额一律以分为单位存储整数。 这是平台的字段约定（金额类字段统一用分），避免浮点小数带来的对账误差。页面上显示成元，用户无感知。
状态：草稿 → 已提交（待审批）→ 已批准 → 部分入库 → 全部入库 → 已关闭。允许"部分入库"很重要——实际业务里一张订单分两次到货是常态，如果只有"完成/未完成"两个状态，采购员就会去改订单数量来凑数，台账立刻失真。### 单据三：到货入库单
入库单是采购和库存的握手点。表头：入库单号、关联采购订单（引用）、供应商（自动带出）、到货日期、收货人、仓库/库位、状态。表体明细行：物料、本次入库数量、批次号（可选）、质检结论（合格/让步接收/退货）、附件（送货单照片）。
关键机制：入库时系统回写订单明细行的"已入库数量"。这个回写在平台上通过数据流规则配置——入库单保存后，按"同一订单 + 同一物料"找到对应明细行，累加已入库数量，并重算剩余待入库数量。当所有明细行的剩余数量归零，订单状态自动推进到"全部入库"。
有了这条规则，采购员不需要手动更新订单状态，也不会出现"货到了三天订单还挂着未入库"的情况。同时它天然防超收：入库数量超过剩余待入库数量时给出提示，需要填写超收原因才能继续。
退货怎么处理？不要设计"负数入库"。做一张独立的退货单，写明原入库单与退货数量，同样回写订单的已入库数量（做减）。台账要能分别看到"进了多少""退了多少"，混在一行里就查不出来了。
单据四：对账单
月底由采购员发起，或者由"某供应商一段时间内的全部入库记录"一键生成。表头：对账期间、供应商、对账单号、合计金额、状态。表体不是手填的——从该供应商在期间内、状态为已入库且未被纳入其他对账单的入库明细自动汇总而来。每一行显示：入库日期、关联订单号、物料、数量、成交单价、金额。
对账单的价值在于把散落的入库记录冻结成一个双方确认的数字。流程：生成 → 发给供应商核对 → 双方确认后标记"已确认" → 财务据此安排付款。一旦标记确认，明细锁定不可再改；有差异走调整单，不要在原单上改数。
至于付款本身，建议只做一张轻量的付款登记表：供应商、关联对账单、付款日期、金额、付款方式、经办人。它的用途是回答"这笔对账单付了没有、还剩多少没付"，而不是记账。应收应付的完整台账逻辑，可以等采购模块跑顺之后再单独扩展。## 页面怎么用：四类角色各看什么
模块建出来不是给采购员一个人用的。PC 端建议做四个视图，权限按角色分配。
采购员的日常工作台
打开页面先看三张待办清单：待审批的请购单（今天要处理）、已批准但未生成订单的请购单（漏单高发区）、逾期未到货的订单（约定到货日期已过、状态未到全部入库）。这三张表覆盖了采购员一天里最容易忘的事。
下单时最常用的动作是"从请购单转订单"——选中一张已通过的请购单，点转采购订单，明细行自动带入，采购员只需要选供应商、填成交价。这一步省掉的不只是打字，而是"抄错数量"这类低级错误。
物料的价格查询要做得顺手：在订单明细行选定物料后，旁边显示该物料最近三次采购的成交价与供应商。比价不需要翻历史单据。
部门主管的审批视图
主管只关心两件事：这个月本部门申请了多少、有哪些大额申请需要我批。给他一个列表页 + 审批操作即可，不要把他淹没在采购全流程里。审批入口在 PC 和移动端都要有——主管不在工位上是常态。
仓库的收货视图
仓库看到的应该是"今天应该到货哪些订单"（按约定到货日期筛选的未入库订单），而不是全部采购数据。收货时逐行录入实收数量，拍照上传送货单。这个视图越简单越好，仓库现场没人愿意在电脑前找字段。
老板/财务的台账视图
两张报表：
- 供应商应付台账：按供应商分组，列出已确认对账单金额、已付款金额、未付余额、最近一笔到期日。这是回答"欠谁多少"的那张表。
- 采购价格趋势：按物料查看历次采购单价变化。哪个物料涨得最快，一目了然。
台账视图必须支持导出，财务拿回去还要和自己的账核对。平台的列表组件带导出能力，导出范围以当前筛选条件为准。
移动端做什么、不做什么
原则：移动端处理"发生在线下的动作"和"需要即时响应的审批"，不做重表格录入。
值得放到手机上的四件事：
- 请购发起。车间人员在设备旁直接提申请，选物料、填数量、拍照附现场图，不用回办公室开电脑。
- 审批。请购单、采购订单的提交与批准，主管在手机上一键完成。这是缩短周期最直接的一环。
- 到货扫码/录入收货。仓库人员对着实物录数量，比事后补单准确得多。
- 逾期与到期提醒推送。订单逾期未到、对账单待确认、供应商账期临近，通过站内通知推给对应责任人。
不建议放移动端的：批量生成对账单、修改历史价格、维护物料档案。这些留在 PC 端，既是为了输入效率，也是为了减少误操作。
在 Inkwell 上，PC 端构建的业务模块会自动生成对应的移动端页面，不需要再单独开发一遍；发布前可以在预检环节看到双端的挂载情况。## 上线前查这八件事
采购模块涉及钱，回滚成本比一般台账高。发布预检之外，建议人工把这八条走一遍：
- 物料档案是否已清理干净。 重复物料、同物异名的记录先合并再上线。带着脏数据上线，一个月后你会看到同一物料分散在五个编码下。历史单据可以用 Excel 批量导入，但导入前务必先在测试环境跑一遍，检查引用关系是否匹配上了。
- 金额字段的显示与存储是否一致。 随便造一张订单，明细填三个不同数量单价，看合计是否精确；再看对账单汇总与订单合计是否分毫不差。
- 入库回写是否正确触发。 一张两行明细的订单，分两次入库（第一次只入其中一行），检查已入库数量、剩余待入库数量、订单状态三者是否同步变化。再试一次超量入库，确认有拦截提示。
- 部分入库 + 退货的组合。 入库后退一部分，已入库数量应该减少而不是出现负数或不变。
- 对账单是否会重复纳入同一批入库记录。 生成一次对账单后，再生成同期间的对账单，已锁定的明细不应再次出现。
- 权限边界。 用部门主管账号登录，确认看不到其他部门的请购单；用仓库账号登录，确认改不了采购单价。这一步最容易被跳过，也最容易出事故。
- 审批流断链测试。 提交人自己就是审批人时系统怎么处理？审批人被停用或离职时单子会不会卡死？平台支持把审批人配置为角色而非具体个人，能规避大部分人员变动问题。
- 移动端全流程走通。 手机发起请购 → 手机审批 → 手机收货 → PC 端看到完整链条。任何一环在手机上录不进去，现场就会退回到微信群。
之后怎么延伸
采购模块跑顺以后，有几条自然的扩展路径，都不需要推翻现有结构：
- 接销售侧：销售订单缺货时直接生成请购需求，形成"以销定采"。
- 接库存下限：给物料设置安全库存，低于阈值自动生成建议请购单。
- 接质量检验：到货入库前先走检验单，检验合格才允许入库，让步接收需要额外审批。
- 接应收应付：把付款登记升级为完整的应付台账，加入账期到期提醒与核销记录。
- 接供应商绩效：基于已有的入库与退货数据，统计各供应商的准时率与不合格率，作为评级依据。
每一条都是往已有单据上加关联，而不是重做一套。这就是为什么一开始要把四张单据的关系建干净——采购管理的价值不在某一张表做得多漂亮，而在于这条链能不能被完整地追溯。当老板问"这批货谁批的、什么价、什么时候到的、付了没有"，你能在三十秒内把整条链摊在他面前，这个模块就算立住了。