收购旺季，乱的不是称，是那张纸
果蔬、粮油、茶叶、中药材、烟叶这类加工厂或合作社，收季一到就是另一套节奏：一天几十车、上百笔过磅，收购点往往散在几个乡镇，最远的离厂区几十公里。
现场通常是这样运转的：
- 过磅靠手写三联单，或者记在本子上，晚上回办公室再抄进 Excel；
- 含水率、扣杂比例由收购员现场凭手感报，农户当场不服，事后也翻不出依据；
- 等级决定单价，同一天可能开出几个价，抄错一次就是多付或少付；
- 结款基本靠"下回来再结"，欠谁多少、上次结到哪一批，全凭一张纸；
- 老板想知道这个产区今年收了多少吨、均价多少，得等财务月底慢慢盘。
这几件事拆开看都不大，合在一起就成了老问题：过磅单、结算单、付款记录三张纸各在各处，对不上的时候没人说得清是哪一步错的。
这篇文章讲的不是"农业 ERP"，而是用 Inkwell AI 构建器把这个链条上的四五张表、几个页面搭起来：收购点在手机上录一笔，财务在电脑上审一笔、付一笔，老板在同一个地方看汇总。范围就是收购与结算这一段，不碰种植、不碰养殖（那两块另有台账做法，见 /solutions/agri-planting-ledger.html 与 /solutions/agri-livestock-ledger.html）。
底表怎么建：四张主表，两张流水，一套字典
这类模块最怕一上来就堆字段。真正决定后面好不好用的是几个结构性的选择，先说清楚这五个。
一、农户先建档案，不建账号。
一个农户一行记录：姓名、身份证后四位或完整号码、联系电话、常驻产区或村组、收款账户信息、合作起始时间，并给一个人可读的业务编码（例如 HN-0001），编码设为唯一。过磅单、结算单都引用这个档案，而不是每次都重新敲一遍姓名。
关键决定是把"人"和"账号"分开：农户绝大多数时间不进系统，他只需要有人替他把数记对。等到确实要让农户自己在手机上看交售明细时，再给长期合作户开通账号并关联到这份档案——档案是业务主体，账号只是看数的一双眼睛。反过来做（先给每个农户开账号）通常会在起步阶段就把自己拖死。
二、过磅单拆开存重量，不存一个"最终数"。
一张过磅单上，毛重、皮重、净重分三个字段存；扣杂比例、扣杂重量、扣水比例、扣水重量也各存各的。最后用于计价的"结算净重"由这几项算出来，但不能只留计算结果。
原因很直接：农户最容易起争议的就是扣杂。只有把"扣了多少、按什么比例扣的"分开留在单据上，现场才解释得清，事后才追得回。合并成一个月末的净重数字，等于主动放弃了这一层证据。过磅时现场拍一张磅面照片挂在单据上，比事后口头解释有用得多。
三、价格单独成表，过磅单只记"用了哪一版价"。
按品种 × 等级 × 生效日期存单价，形成一份价格版本表。过磅单上不照抄单价，而是记录它适用哪一版价格。收季里价格一天一动是常态，这样做的好处是：改价只改价格表、新建一版，历史单据的金额不会被悄悄改掉，也便于回答"这批是按哪天的价结的"。
四、结算单是"账"，过磅单是它的明细。
结算单一张对应一个农户一次结算，明细行列出这次结的是哪几张过磅单，再把预付款、代垫物资（化肥、农药、筐箱）等扣款分栏列出来，得出应付金额。
这里有个必须挡住的问题：一张过磅单只能进一张有效的结算单。过磅单上用状态位控制（待结算 → 已入结算单 → 已作废），已经进过结算单的单据不再出现在待结算列表里。这一条不做，重复结算几乎一定会发生，而且是对外付款，错一次就得追着农户要钱。
五、付款单独登记，允许分次。
付款记录一笔实付一行：日期、金额、方式、凭证号或转账截图。结算单的状态由累计付款推算——待审批、已审批、部分付款、已结清。把付款和结算单合成一张表，就没法处理"先付三万、剩余下月结"这种最常见的现实情况。
最后是状态字典。过磅单状态、结算单状态、付款方式、扣杂原因（含水超标、含杂、破损、等级不符）都放在数据字典里集中维护，页面下拉、看板筛选、导出口径吃同一份数据（做法见 /docs/data-dictionary.html）。字典先定好，后面改统计口径就不用改页面。
页面按角色分，别按部门分
同一条数据，五类人看到的样子应该完全不同。按"谁在什么场合用"来分页面，比按部门堆菜单更好落地。
收购点录入员（手机为主）。 他站在磅边，手上可能有泥。所以手机上第一屏就是"录一笔"：选农户（输入姓名或编码，支持模糊搜索）、选品种、填毛重与皮重、按档选扣杂原因与比例、拍一张磅面照片，提交。今日已录的笔数和合计重量在旁边显示，方便收工时对账。
收购点负责人（手机 + 电脑）。 负责等级判定和异常处理。他的页面是"今日需复核"列表：扣杂比例超出常规范围的、单价与当日价格版本不一致的、同一农户短时间内反复过磅的，一条条列出来，点进去看照片和明细，确认或退回。
结算专员（电脑）。 核心页面是"待结算工作台"，按农户聚合：这家有几张待结算过磅单、合计结算净重多少、预估金额多少、有没有预付款或代垫物资要扣。勾选后一键生成结算单，明细自动带出，扣款逐项填写。价格版本维护也在这个角色手里，调价就新建一版并填生效日期。
财务（电脑）。 只看已审批的结算单，登记付款。页面上最有用的是"应付台账"：按农户、按产区、按时间段看还有多少没付、账龄多久。这一块与通用应收应付的做法是一致的，可以对照 /solutions/erp-receivable-payable.html 理解台账思路。
老板与管理者（看板）。 不看单据，看四个数：本季收购量（按品种、按产区）、平均结算单价、待付款总额、超期未结清的农户数。需要留底时按日期一键导出。
四类自动化，把人工核对压到最少
系统搭好之后，能自动跑的部分主要有四类，各自解决一个具体环节。
第一类：录完就算。 过磅单提交时，数据流规则自动把结算净重和预估金额算出来（净重减去扣杂、扣水，再乘适用价格版本的单价），录入员不需要按计算器。扣杂比例超过设定阈值的单据自动打上"需复核"标记并列入负责人列表。阈值的具体数值按企业自有收购标准定，系统只负责在你定的线上提醒。
第二类：该谁批谁批。 结算单进入审批流后按金额分档走不同审批人——比如几万以内收购点负责人终审、超过则加老板一级，分档标准同样按企业自有制度设。审批通过前，单据不能进入付款环节，这道闸挡住的是"人和人熟就先付了"。
第三类：到点提醒。 定时任务负责三件事：按周或按月按农户汇总待结金额，生成提醒给结算专员；价格版本临近到期前提醒维护人续期；结算单审批通过后超过约定期限仍未结清的，定期汇总提醒。定时任务的配置方式见 /docs/workflows-scheduler.html。
第四类：改了什么留痕。 单价被改、过磅单被作废、结算单被退回，都要在审计日志里留一条：谁、什么时候、改前改后是什么。收购结算的钱是对外付出去的，这类留痕在事后复盘时往往比报表更有用。
四类自动化看着琐碎，但它们合起来的效果是：从"月底集中核"变成"当天就核完"。收季最怕的是差错堆到季末，那时候农户和收购点谁也记不清当时的情形。
移动端：一半的价值在现场
这套东西如果只在电脑上跑，收购点还得回去补录，等于多一道工序。真正省事的是手机端那一半。
用 Inkwell 构建器建好的模块，电脑端和手机端是同一套数据、同一套权限，页面在两端都能用，不需要另做一个小程序（这一点在 /news/news-mobile-companion.html 里有说明）。落到收购场景是三个动作：
- 磅边录单：录入员在手机上完成选农户、填重量、选扣杂原因、拍照提交，一车一单，当场完成；
- 负责人复核：手机上划过"今日需复核"，看照片、看明细，当场确认或退回；
- 农户自查：给长期合作农户开通查询账号，只能进本人交售明细与待结金额两张视图，看到的是自己的账、别人的看不到。
第三件事要提前说清一个前提：农户账号的可见范围靠角色权限配置实现，上线前必须用测试账号实测一遍——拿 A 农户的账号去翻 B 农户的明细，翻得到就说明配置没做对。权限的基本做法见 /docs/roles-permissions.html。
还有一点要诚实标注：现场网络条件得提前评估。收购点常在乡镇、磅房可能信号一般，这套页面按在线录入设计，弱网环境下的操作节奏（哪些字段可以先记纸上、多久补录一次）需要在上线前和收购点商量好，不要假设手机上一定顺滑。
上线前逐条过一遍
搭模块本身不难，难的是几个配置细节。以下八条建议在正式收季前当作清单走完：
- 三类字典先定死：品种与等级、扣杂扣水原因、三套状态（过磅单、结算单、付款）。字典没定就开录，后面改口径要动历史数据。
- 把价格版本铺全：历史区间和未来生效日期都建好，检查有没有两版价格区间重叠——重叠了系统算出来的金额会不可预期。
- 测"一张过磅单只能进一张结算单"：造一条过磅单，进结算单、作废结算单、再看它能不能被重新选中。这一条必须实测通过。
- 实测农户账号的可见范围：见上节。这条是名单制的对外风险，不能只靠"应该没问题"。
- 权限分工落细：录入员不能改价格、不能作废单据；财务不能建结算单、不能改净重。权限按角色配，不按人情配。
- 审批分档试边界值：刚好等于分档金额的单据走哪一级，用测试单据走一遍，避免真实单据卡在中间没人批。
- 历史余额怎么接：上季度的未结清欠款用 Excel 一次性导成期初结算单，导入做法见 /docs/excel-to-module.html；已经结清的旧单据只导汇总数，不导明细，避免和新数据打架。
- 留一到两个收购日的双轨期：纸质单和系统单并行，收工后核对当日收购量与合计金额一致，再停纸单。
之后往哪延伸
这套表跑顺之后，接上下游都只是加模块，不用换底座：
- 往上游：地块与农事记录关联到农户档案，同一批农产品就能追到种植环节（/solutions/agri-planting-ledger.html）。
- 往质量：收购时的抽检记录、农残检测结果挂到过磅单上，等级判定从"凭手感"变成"有检测依据"。
- 往下游：收购批次与加工投料关联，成品出问题时能反查到是哪几个农户、哪几车原料（/solutions/mfg-batch-traceability.html）。
- 往财务：待付金额直接进应付台账，与采购、供应商评级一并对账。
这套方案的边界：哪些事它不做
写清不做什么，比写能做什么更能省时间：
- 不接管称重设备。地磅的仪表信号采集、摄像头联动属于硬件接入，不在 AI 构建器的交付范围内——重量由录入员填，磅面照片用来佐证。
- 不做付款通道。付款登记记录的是"已经付了多少钱、什么时候付的"，不是发起转账。实际打款仍在网银或手机银行完成。
- 不做检测仪器对接。农残快检、水分测定仪的数据接入同理，结果由人录入或按批次粘贴导入。
- 不做自动分等与视觉识别。等级判定仍然由人做，系统负责把判定结果和依据留痕。
- 不替代税务与发票系统。收购发票、进项抵扣仍走原有渠道。
一句话概括这套方案的定位：它把过磅、扣杂、定价、结算、付款五件事串成一条能追的线，让人和人都对得上账；它不替你称重，也不替你打钱。