很多人一听“条码支持有效期”，第一反应是：那不就是 lot 上多一个 expiration_date 字段吗？
企业版 stock_barcode_product_expiry 的实现告诉你，远不止如此。它分别在 product.product、stock.lot 和 stock.move.line 上扩展 _get_fields_stock_barcode()：产品层把 use_expiration_date、use_time 暴露给条码前端，lot 层与 move line 层再补上 expiration_date。这说明条码作业时，前端需要同时知道“这个产品要不要管有效期”“这个批次是什么到期日”“当前作业行写回哪个日期”。
测试 test_gs1_receipt_expiration_date() 更直接揭示了业务语义。启用 GS1 编码规则后，系统允许在收货扫描中读入 expiration date，也允许只有 best before date；如果只扫到 best before，就会按产品设置换算成 expiration date；如果两个都扫到了，则以 expiration date 为准。这不是简单存字段，而是把 GS1 语义翻译成 Odoo 认可的批次有效期事实。
另一个测试 test_delivery_package_with_expiration_dates() 说明这套字段不是只在收货端生效。发货时如果扫的是一个带批次的 package，界面也要能把该 lot 的有效期显示出来。也就是说，有效期信息不是“入库时记一下”，而是要贯穿包裹、批次和移库行，直到出库端仍可见。
这正是很多实施项目容易踩坑的地方：把有效期需求当成追溯字段，却没意识到条码前端需要在不同对象层同时取数。结果就是数据库里有日期，扫码页面却看不到，仓库员误以为系统没有记录。
排查此类问题时，建议先看产品是否开启有效期控制，再看 lot / move line 是否真的返回了 expiration_date，最后再确认 GS1 规则和用户权限是否让前端按预期展示。不要一上来就改条码 JS，因为很多问题其实是模型层没把字段送出去。
所以企业版条码有效期支持，核心不是“给批次加日期”，而是让产品规则、批次事实和现场作业行共享同一份过期语义。
DISCUSSION
评论区