一、查验卡在哪：不是没查，是三张纸对不上
餐饮门店、食堂、食品流通企业，进货查验这件事几乎都在做。真正让人头疼的不是"查没查"，而是查完之后那三件事：记录拿不拿得出来、几张单子对不对得上、出问题时倒查得回不回去。
几个场景，做过食品安全管理的人一看就懂：
- 供货商的营业执照、食品经营许可证锁在采购的抽屉里，或者躺在某个人手机相册里。证照过期那一周，收货的人照样收货，没人知道。
- 到货时收到一张随货单和一张检验报告，拍张照片发到门店微信群，三天后想在群里翻出那一张，只能一路往上爬楼。
- 同一种货来自三家供货商，随货单上的批号写法各不相同。出了问题只记得"上周到过两批"，说不清具体哪一批、用在了哪一天。
- 查验不合格，当场口头退了货，没留任何记录。下次同一家再送，还是照收，也没人知道这家已经退过两次。
- 监管上门或总部飞行检查要台账，店长连夜补一本。补出来的日期整齐、笔迹一致，反而更解释不清。
用 Excel 加微信群撑一阵子也能过，但通常会卡在三个地方：一是文件在群里滚几轮就没人知道哪份是最新的；二是收货区在月台、冷库门口，手机打不开表格，员工只能回办公室补录，补录那一刻时间和地点就失真了；三是最关键的——到货单、查验记录、票证照片三张东西彼此不关联，到货单上写了这批货，查验记录里却没有对应品项，没有人会发现缺项。
共同根源不在"员工不认真"，而是证照、票证、批次这三件事没有被做成能互相对上的数据结构。它们各自散着，就永远需要人用记性去缝。
二、底座：五张业务表与关键设计决定
用 Inkwell AI 构建器（用自然语言描述业务需求，平台自动生成数据表、管理页面和移动端界面的开发方式）做这件事，第一步不是画页面，而是定表。下面这些设计决定，基本决定了后面预警能不能自动跑、倒查能不能一次查到。
决定一：供货商拆成两张表——档案表与资质证照表
一个供货商往往有多张证：营业执照、食品经营或生产许可证、检验报告、运输环节的资质，各有各的有效期。把它们塞进一张表，只能记一个到期日，预警必然漏项。所以档案表一行一家（名称、统一社会编码、联系人、供货品类、结算方式、状态），证照表一行一证（所属供货商、证照类型、编号、发证机构、有效期起、有效期止、照片附件）。
证照表只增不改：换新证另起一行，旧证保留。这样半年后要回答"这批货到货那天，这家供货商的许可证是否在有效期内"时，系统能拿出当时的记录，而不是拿今天的证照倒推。至于具体需要留存哪些证照、留存多久，以属地主管部门要求为准。
决定二：品项档案里写清"该收什么票证"
一行一个品项：品名、规格、单位、是否冷链、必需票证类型（多选）、是否必须登记批号。这一列是把"收什么票"从老员工的经验变成系统规则的关键——收货员扫一眼品项就知道该收检验报告还是该收检疫证明，不用凭记忆判断。
决定三：到货单主表加查验明细子表
- 主表一行一次到货：配送单号、供货商、到货日期时间、送货信息、收货人、总体件数、整体结论、查验状态。
- 子表一行一个品项：所属到货单、品项、数量、单位、生产日期、批号、票证是否齐全、感官判定、处理方式。
主表回答"这批货查完了没有"，子表回答"哪一项不合格"。合成一张大表，两个问题都答不清：一车货十个品项，做成一行就只能写一段备注，明细永远统计不出来。
决定四：批号留两个字段，别合并成一个
内部进货批号 + 供货商原始批号。前者由企业自己的规则生成（例如到货日期、供货商简称、当日序号拼起来），后者照抄随货单。只留一个会带来两种麻烦：只留内部号，倒查时和供货商对不上；只留原始号，各家写法不一，内部统计和排序做不了。
决定五：不合格不进主表改字段，另起一张处置记录表
一行一次不合格：关联到某条查验明细、不合格类型、处理方式（退回、换货、让步接收、降级使用）、涉及数量、供货商确认人、闭环时间。理由很实在——同一家供货商如果反复出问题，只有把每次处置单独成行，才能按供货商统计出问题率；如果只是在查验单上改一个状态，历史就被覆盖了。
决定六：状态与选项全部走数据字典
查验状态（待查验、查验中、合格入库、不合格待处置）、票证类型、不合格类型、处理方式、拒收原因，都做成数据字典项，页面下拉框从字典取值，不写死在页面里。以后要加一项"临期接收"或者把拒收原因拆细，改字典就行，不用重做页面。用法见 数据字典：管好下拉选项的统一口径。
决定七：门店、档口、供货商、品项都是档案，记录里通过引用取值
记录表不让人手打供货商名和品名，一律从档案里选。否则一张全国台账里会出现"后厨""后厨档""热菜间"三种写法、"土豆""马铃薯""土豆(大)"三种品名，按品项和供货商做的所有统计都失去意义。
决定八：记录只增不改，更正另起一行
提交后的查验记录不允许直接编辑。填错了走更正入口，另起一行并填写原因，原记录保留。谁在什么时候改了哪一条，由平台的操作审计日志留痕，这部分能力见 AI 监控与审计日志：看清平台里发生了什么。
这套底表的直接结果是：证照、到货、明细、处置四件事通过档案和引用连成了一条链。有了这条链，"批批可查"才不是一句口号——从一个成品或一道菜，能顺着进货批号查到供货商原始批号、那一车的到货单、当时的证照有效性和查验结论。## 三、页面按角色分：五类人，五个视角
同一个模块，五类人打开时想看到的东西完全不同。硬做成一张"全能大表"，结果是谁都不好用。
收货员：只有两个页面
- 到货登记表单：选供货商、填配送单号、加品项明细（品项、数量、批号、生产日期）、拍票证照片。品项选定后，系统按品项档案带出"必需票证类型"，缺一项就提示。
- 我的待查验列表：今天还没提交的记录，点开续填。
收货员的界面要能站着一只手操作。收货区在月台、冷库门口，等不了回办公室打开电脑。
仓管或品控：待查验看板
横轴到货日期，纵轴供货商或品项，未查验的标出来、超时未查验的单独标色、判定不合格的进待处置池。这一页的作用不是追责，而是每天上午看一眼"哪几车货还挂着没查完"，在入库前把动作补齐。
采购：供货商资质台账
按证照类型和到期日排序，30 天内到期、已过期分别列出，点进去看是哪个供货商的哪张证，还能直接看到该供货商近半年的到货批次与不合格记录。采购谈续签或者催新证时，不用再挨个问。
食品安全专员或店长：倒查看板
两个搜索入口最实用：按品项名称加日期区间，或按供货商原始批号。查出一串进货批号，每个批号再点开能看到那一车的到货记录、查验结论、票证照片和处置结果。检查时要按区间导出记录，直接从这一页出。
总部：汇总与导出
按区域、按供货商、按品项统计合格率与及时查验率；把反复出现同类不合格的供货商排出来；按月导出整本台账。导出这一层还可以结合 用 Excel 一步建模块：从表格到可用的业务系统 里的思路，把历史纸质台账一次性搬进来做基线数据，避免上线后只有新数据。
权限按角色分配：收货员只看本店当天的单，品控看自己负责的片区，采购看供货商维度但看不到具体门店的成本数据。这套配置在平台的角色与权限体系里直接做，配置方式见 角色与权限配置：从内置角色到自定义授权。
四、四类自动化：把"记得查"从人脑里挪走
页面解决的是"能录"，自动化解决的是"不会漏"。这四类规则搭好之后，日常就不靠谁记性好。
第一类：到货登记即生成待查验任务
到货单提交后，按品项档案的"必需票证类型"和"是否必须登记批号"生成应查清单，状态置为待查验。用了数据流规则（条件触发的数据变换）之后，这一层不需要人工点一下，单据一提交规则就跑。
第二类：证照到期预警
定时任务每天扫一遍资质证照表，对 30 天内到期和已过期的两类分别推站内信给采购和食安专员。提前多久提醒，按企业自己的管理要求设，不要照搬别家的数字。定时任务与站内消息的配置思路见 工作流与定时任务：让重复性工作自动跑。
第三类：超时未查验的标红与催办
按到货时间加一个企业自定的时限（比如到货后若干小时内必须完成查验，具体时限按企业自有标准定），超时未提交的，在看板上标红，并给收货员发一条催办待办。这一条特别有用——大多数缺项不是因为不会查，而是因为忙起来就忘了。
第四类：不合格自动流转到采购
处置记录一旦判定为退回或换货，自动生成一条采购待办并通知采购负责人；换货到货时，新的到货单必须引用原处置记录，形成"问题—处置—换货—再查验"的闭环。同类型不合格累计达到企业设定的次数，自动把该供货商标为观察状态。
再往上还可以加两层：一是查验结论合格后，通过审批流把入库动作确认一遍，让"没查验不能入库"从口头要求变成流转约束；二是不合格让步接收这类例外，走审批流留审批意见。审批流的落地方式见 审批流落地：请假、报销与通用申请怎么在线化，思路同样适用于到货让步放行。## 五、移动端：收货区那十分钟
进货查验真正发生的地方是冷库门口、月台、卸货通道，不是办公桌。所以移动端不是"顺手也做个手机版"，而是这个方案能不能落地的关键一环。PC 端建好的模块会自动出现在手机工作台上，具体入口与使用方式见 移动端使用指南：工作台、模块页与手机上的 AI 构建。
移动端上要保证三件事：
拍照上传票证，原件归档。 随货单、检验报告、检疫证明拍一张就上传到证照和到货单上，附件跟记录绑在一起，而不是躺在某个人的相册里。附件上传由平台的文件能力承接，谁下载过、什么时候下载，也有访问记录可查。
批号输入要省事。 常见情况是同一品项当日重复到货，界面支持按上次填写带出、或从该品项近期批号里选，能显著减少手抄错误。手工录入出错一位数字，整条倒查链就断了。
提交即留时间与提交人。 记录的时间戳由系统生成，不用员工自己填，既省事也避免了"事后补一个好看的时间"。
有一点要说明：平台的移动端是随 PC 页面同步生成的表单与列表，复杂报表和批量操作用电脑更合适。收货员在手机上完成登记与查验，专员在电脑上做统计、导出和档案维护——这个分工比让所有人都在手机上硬用要现实得多。
六、上线前查这八条
功能都能点通之后，不要直接放开给所有门店用。下面这份清单是按经验最容易被跳过的部分：
- 证照类型对不对。 先确认本企业涉及的品项需要哪些证，尤其是冷链、肉禽、水产这类有额外票证要求的品类。这里建议由食安专员出一次清单，不要由 IT 决定。
- 品项档案的"必需票证类型"有没有逐个填。 这一列空了，系统就带不出应查清单，等于白做。
- 批号规则定了没有。 内部进货批号的生成规则要在上线前定死并写进说明，中途改规则会让历史批号失去连续性。
- 历史台账怎么进来。 至少把在期供货商的档案和资质证照导进来，否则上线第一天就要预警时，系统里没有数据可预警。批量导入可参考 用 Excel 一步建模块：从表格到可用的业务系统。
- 权限核对。 逐角色点一遍：收货员能不能看到别家门店的单据，采购能不能看到不该看的成本字段，督导的范围对不对。多租户和多门店场景尤其要验。
- 字典项不要留空壳。 不合格类型、处理方式这几个字典，如果只有"其他"一项，统计出来全是"其他"。
- 时限类阈值按企业自有标准设。 到货后多久必须查验完、证照提前多久提醒，都写在本企业的管理文件里，不要照搬外部数字。
- 发布前跑一遍预检，先在一个店试运行两周。 平台的模块发布流程带预检环节，会检查页面与数据结构是否完整；试运行期间让真实收货员在真实场景下用，专职人员在一旁记录卡点。发布与预检的流程见 模块的测试与发布：预检、挂载菜单与移动端同步。
七、之后可以往哪延伸
这套底表搭好，后续扩展基本是加法：
- 和入库动作联动。 查验合格后自动写一条入库记录，不合格的挡在入库之前，避免"验了但仓库照收"。库存侧的建账方式可参照 通用库存管理：入库、出库与盘点的一本账。
- 和供应商评价联动。 把每次不合格处置折算成供货商的问题记录，季度回顾时有据可依，而不是凭采购的印象。供货商档案与评级的做法见 供应商管理：档案、评级与供货记录。
- 和后厨操作记录打通。 进货端管"进来的货"，操作端管"怎么做的"。留样、消毒、晨检这类日常记录，做法见 后厨食安记录：留样、消毒、晨检三张表不再补填，两套台账通过品项和日期对齐，一条完整的追溯链就闭合了。
- 往下游查到成品去向。 如果是中央厨房或食品加工场景，可以继续做"原料批号到成品批号"的关联，思路与制造业的批次追溯一致，参见 生产批次追溯：从原料批号查到成品去向。
八、这套方案不做什么
写清边界比写清功能更有用，避免上线后出现预期落差：
- 不做硬件对接。 冷库温湿度探头、电子秤、快检仪器这些设备的数据直连不在本方案范围内，读数仍需人工登记。
- 不做票证文字的自动识别。 票证照片是上传归档、由人工核对，系统不代替人判断票证真伪与内容。证件号码、有效期仍要在表单里手填或用字典选。
- 不替代法定纸质留存要求。 电子台账能不能完全替代纸质件、需要留存几年，以属地主管部门要求为准，本方案只保证"系统里查得到、追得回、对得上"。
- 不承诺检测结论。 感官判定与票证核对由收货人做，系统负责记录与流转，不替代快检与检验机构的结论。
- 不做跨企业的供货商数据共享。 供货商的证照与问题记录只在租户自己的范围内使用。
一句话记住这套做法：供货商拆档案和证照、品项写清该收什么票、到货拆主表与明细、批号留两个字段、不合格单独成行、超期由系统催。做到这六条，检查时拿得出记录，出问题时倒查得回批次，这两件事就都不再靠人硬记了。