仓库现场最真实的问题，不是条码一定能扫出来，而是扫出来以后系统认不认识它。
stock_barcode_barcodelookup 处理的正是这个灰区：当用户在条码界面扫到一个系统还没建档的编码时，企业版并不只会报错，而是预留了一个“从扫码流程进入商品补建”的受控入口。
关键点在控制器 _get_groups_data()。它在原有条码前端权限数据上，额外塞入 group_user_admin，并用 request.env.user.has_group('base.group_system') 判断当前用户是不是系统管理员。这个实现看似很小，实际意义很大：前端是否展示补建入口，不是前端自己猜，也不是看某个字段开关，而是以后端安全组为准。
视图层也印证了这一点。模块额外定义了一个 New Product 的弹窗 action，目标模型是 product.product，并继承了标准商品表单，把 barcode 字段的 widget 清空，避免在这个特殊入口里出现不适合扫码补录的交互。换句话说，企业版允许你在仓库现场补建商品，但它没有放弃表单治理。
这件事对新手特别重要。很多团队会把“现场能补建商品”理解成“任何仓库员都能边扫边新建 master data”。企业版显然不这么想：它给的是一条后备链路，而且默认绑定管理员闸门。这样做虽然保守，却能避免主数据被现场临时输入污染。
真正实施时，建议分清两类诉求：一类是扫不到商品但业务允许临时收货；另一类是商品主数据本来就应由主数据团队统一维护。前者可以评估是否开放这条入口，后者则应该继续让条码界面停在提示层，而不是把治理责任甩给仓库。
所以企业版条码查码的价值，不是让系统“更聪明地猜商品”，而是让扫码失败后的补录动作也纳入权限控制与正式商品流程。
DISCUSSION
评论区