Odoo 社区版常被说成不适合 RFID，因为它没有企业版的 IoT Box 和条码应用。实际上 IoT Box 是一种便利，不是一种能力：它把一组设备驱动装进一个付费容器里。一个已经会说 MQTT 或 HTTP 的网关并不需要它。
社区版真正要求的，是纪律。诱惑在于直接去改库存模块，而正是这个诱惑让很多 Odoo 项目再也升不了级。一个几百行的独立模块能活过三次迁移，而一次魔改活不过一次。
为什么社区版就够了
缺口比看起来窄，而且每一个都有干净的绕法。
- 核心能力本来就在：stock.quant、stock.move 与库存调整模型都在免费版里。
- Odoo 的公开 API 与 ORM 给了完整的模型访问权，所以自建模块可以像企业版应用那样写库存。
- 控制器让你无需额外安装就能暴露一个很小的入站端点。
- 定时任务调度器是内置的，而批量写入需要的正是它。
- 你放弃的是现成的设备驱动与它们的支持合同；这两样都可以由你自己的网关替代。
模块骨架：什么放在哪里
可预测的目录结构比聪明的代码更值钱，因为下一个开发者会先读它。
- 模块根目录放清单文件，声明对 stock 的依赖，以及在需要时对作业队列的依赖。
- models 放三个文件：读写器登记、原始读取事件、EPC 到产品的映射。
- views 放列表、表单、搜索视图与菜单定义，别放别的。
- security 放权限组定义、访问权限 CSV 与记录规则。
- controllers 放入站端点；data 放定时任务定义；tests 放事务测试。
数据模型：读写器、事件、映射
第一版三个模型就够了，想加第四个应该先给出理由。
- 读写器：标识、站点、区域、协议、状态、最后心跳与天线配置。
- 读取事件：读写器、天线、EPC、信号强度、设备时间、接收时间、序号与状态。
- 映射：EPC 模式、产品、批次、数量，以及解析它所用的规则版本。
- 事件上的状态是一个小枚举——已接收、已解析、已写入、已拒绝——它是审计链的骨干。
- 事件到达终态后保持不可变；更正应该产生一条新事件，而不是一次编辑。
视图与菜单，但不碰核心
继承是用来「添加」的，不是用来「重写」的，这个区别决定了升级会不会疼。
- 菜单挂在「库存」下面，而不是新建一个顶级应用——除非这个模块真的服务于多个模块。
- 用继承视图在产品表单上加一个智能按钮，点开它的标签历史。
- 事件列表默认过滤「今天」，并按区域分组，因为操作员实际就是这么看的。
- 在事件表单上显示映射规则版本；一旦出现差异，这是所有人第一个看的字段。
- 绝不要整体覆盖核心视图的架构；用 xpath 精确添加你需要的那个节点。
权限：ACL、记录规则与集成用户
权限是原型阶段被跳过、生产阶段被审计的那部分。
- 通常两个组就够了：操作员可以看事件、确认映射；管理员可以改读写器与规则。
- 对库存模型的写权限，不要超过标准库存组已有的范围。
- 用一个专用的集成用户，权限收窄，并给网关它自己的 API key，而不是某个真人的登录。
- 加一条记录规则，让一个公司的用户看不到另一个公司的读写器与事件。
- 记录谁改过映射规则，因为一条错误规则会悄悄污染数周的库存。
接入 stock.quant，但不魔改 stock
写入路径是这个模块里唯一真正危险的部分。
- 调用现有的 ORM 辅助方法做原子数量更新，绝不要直接给数量字段赋值。
- 每个库位包在一个事务里，这样失败回滚的是一个完整单元，而不是半条货道。
- 在参考字段里写入库存调整原因与来源事件 id，让审计链能一路追回无线电那一端。
- 盘点更正不要创建 stock move；用库存调整模型，它存在的意义就是这件事。
- 去重与聚合留在 Odoo 之外；模块应该接收增量，而不是一股原始读取流。
入站端点：控制器、定时任务与批量
端点应该是无聊的：鉴权、校验、入队、返回。
- 接收一个带批量增量与幂等键的 JSON 体，任何不通过模式校验的请求都以具体错误拒绝。
- 把增量写进事件表后立刻返回；绝不要在 HTTP 请求里做 Odoo 写入。
- 让定时任务每分钟、或在作业队列下每几秒，用单一写入者排空队列。
- 让写入对幂等键幂等，这样一次网络重试不会把数量翻倍。
- 限制批量大小与请求体大小，因为一个无上限的端点就是一份邀请。
测试与升级纪律
这个模块一定会被升级，而测试是把升级变成日常而非项目的关键。
- 写事务测试：创建读写器、灌入事件、写入，断言 quant，然后回滚。
- 显式测试重复场景：同一个幂等键发两次，断言只写入一次。
- 测试拒绝路径：未知 EPC 必须进入隔离区，而不是变成一段异常堆栈。
- 每个会动数据的版本都配一个迁移脚本，并在生产副本上测试它。
- 锁定模块依赖，避免调用私有 API，因为那些正是下一个大版本会坏掉的地方。
