出事之后查几个小时，是因为信息分散在三个人手里：采购知道供应商，库管知道批次，厨师知道做了哪几个菜。三者对不上，就只能一个个问，问一圈半天过去了。溯源要做的是用同一个批次编号把这三段串起来——正向能查“这批货流到哪些菜、哪些人吃了”，反向能查“这道菜用了哪几批原料”，几分钟定位，不用等人回忆。
第一种，只知道供应商，不知道批次。供应商说那天的货发了好几家，你这批到底是不是问题批次，说不清。第二种，只知道批次，不知道流向。库里翻出两箱，但已经用掉的部分做了哪些菜、卖给谁，没有记录。
第三种，记录都有，但对不上。验收单写 50 公斤、出库单写 48 公斤、菜谱算下来用了 45 公斤，差的 5 公斤去哪了，没人说得清。这三种里，第三种最麻烦，因为它说明日常记录本身不可靠。
溯源的底层不复杂：给每批食材一个唯一编号，把供应商信息、批次编号、检测报告、验收记录四样绑在一起。后面所有的出入库、领用、留样、成品，都引用这个编号，而不是重新起名字。
这批货是谁供的：批次号反查供应商、资质和配送记录，秒级。
这批货合不合格：批次号关联快检结果与检测报告，秒级。
这批货进了哪些菜：正向追踪：批次到出库到菜品，分钟级。
这道菜用了哪些原料：反向追溯：成品到菜品到多批原料，分钟级。
还有多少没用的：批次库存查询，锁定未使用部分，秒级。
还有一条别漏：定位到批次还不够，还得知道“还剩多少、在哪”。剩下的能立刻封存，已经用掉的要靠正向追踪去找人，两条线同时走，才叫处置。
批次规则也要先定死：同一次到货、同一个供应商、同一个生产日期算一批；拆包分装的要生成子批次号，不能沿用原号。规则不统一，追溯时就会出现“一半追得通、一半追不通”，那比没有系统还难受。
正向追踪是从原料到人：这批菜心流向三个校区，A 校区做了蒜蓉菜心，B 校区做了上汤菜心，C 校区没用。那就先停 A、B 两校的这道菜，通知到班级。
反向追溯是从菜到原料：家长反映昨天的红烧肉有问题，反查这一锅用了三个批次的猪肉和两个批次的调料，逐批核对检测记录和验收状态，缩小范围。两个方向都通，处置才快。
协讯的做法是把九个环节打通：订货、接单、发货、配送、验收、采样、检测、入库、领出，每一环都写同一个批次号。数据上链存证，关键记录固化，改动留痕。
一批货进门：验收时生成批次号，打印标签贴在容器上；批次号从这一步贯穿到餐桌。
检测与验收：快检结果、检测报告、验收照片都挂在批次下；查批次就能看到全部证据。
出库领用：出库单带批次与效期，扫码领用；谁领的、领了多少、做了什么，都有记录。
对外查询：溯源码分两种：正常业务信息码、带报警信息的码；扫码可见来源、检测、物流轨迹。
问题处置：一键反查流向，锁定未使用批次，几分钟定位；不用等人回忆，召回有范围。
协讯这块的底子是区块链溯源：关键数据上链存证、记录固化不可篡改、问题批次一键可查。对食堂来说，最实际的用处不是“技术先进”，而是检查或出问题时能拿得出、说得清、追得回。
溯源只能追到“有记录的部分”。供应商换货没换单、临时加送没走验收、拆包后没贴标，这些环节一断，链就断了。所以溯源系统的效果，一半在软件，一半在“每批都必须过验收”这个硬规矩。
另外，上游不配合也是现实问题。供应商不愿提供批次信息、检测报告滞后，追溯就只能追到供应商这一层。这一层要么靠合同约束，要么靠准入评分去推。
单独建一个“历史库存”批次，登记来源、入库时间、剩余量，能补的信息补上，补不上的标注清楚。别混进新批次里，否则整批追溯都会失效。
正常批次能看到供应商、产地、检测结果、配送轨迹、验收时间；如果这批有异常，扫出来会带报警信息，提示不要使用。
对日常管理没用，对追责有用。数据一旦上链，改不了、删不掉，出了纠纷能作为证据。日常还是靠查询快、记录全。
把批次信息写进收货条件：没有批次号或检测报告的，验收环节直接卡住。再配合供应商评分，做得到的加分、做不到的降权，慢慢就推开了。
如果你现在出问题还得靠打电话问一圈，可以先做一件事：把验收环节的批次号固定下来。这一步做了，后面才谈得上追溯。需要的话我们帮你理一版批次规则。
