La edición Community se describe a menudo como inadecuada para RFID porque no tiene la IoT Box ni la app de códigos de barras de Enterprise. En la práctica, la IoT Box es una comodidad, no una capacidad: envuelve un conjunto de drivers en un contenedor de pago. Una pasarela que ya habla MQTT o HTTP no la necesita.

Lo que Community sí exige es disciplina. La tentación es parchear el módulo de inventario directamente, y esa tentación es la razón por la que muchos proyectos Odoo no pueden actualizarse. Un módulo separado de unos cientos de líneas sobrevivirá a tres migraciones; un fork no sobrevivirá a una.

Por qué la edición Community es suficiente

Las carencias son más estrechas de lo que parecen y cada una tiene una solución limpia.

La fortaleza del núcleo ya está ahí: stock.quant, stock.move y el modelo de ajuste de inventario están en la edición gratuita.
La API pública y el ORM de Odoo dan acceso completo a los modelos, así que un módulo propio puede escribir stock igual que la app Enterprise.
Los controladores permiten exponer un endpoint de entrada pequeño sin instalar nada extra.
El planificador de cron está incluido, que es todo lo que necesita un escritor por lotes.
Lo que se pierde son drivers de dispositivo ya hechos y su contrato de soporte; ambos son reemplazables por tu propia pasarela.

Esqueleto del módulo: qué vive dónde

Una estructura predecible vale más que código ingenioso, porque el siguiente desarrollador la leerá primero.

La raíz del módulo contiene el manifiesto, que declara dependencias de stock y, si se usa, de la cola de trabajos.
models contiene tres archivos: el registro de lectores, el evento de lectura crudo y el mapeo de EPC a producto.
views contiene las vistas de lista, formulario y búsqueda, más las definiciones de menú, y nada más.
security contiene la definición de grupos, el CSV de derechos de acceso y las reglas de registro.
controllers contiene el endpoint de entrada; data la definición del cron; tests las pruebas de transacción.

Modelos de datos: lector, evento, mapeo

Tres modelos bastan para una primera versión, y añadir un cuarto debería exigir un argumento.

Lector: identificador, sitio, zona, protocolo, estado, último latido y configuración de antenas.
Evento de lectura: lector, antena, EPC, intensidad de señal, hora del dispositivo, hora de recepción, secuencia y estado.
Mapeo: patrón de EPC, producto, lote, cantidad y la versión de regla usada para resolverlo.
El estado del evento es un enumerado pequeño —recibido, resuelto, aplicado, rechazado— y es la columna vertebral de la trazabilidad.
Mantén el evento crudo inmutable al llegar a un estado terminal; las correcciones pertenecen a un evento nuevo, no a una edición.

Vistas y menús sin tocar el núcleo

La herencia sirve para añadir, no para reescribir, y esa distinción decide si las actualizaciones duelen.

Añade un menú bajo Inventario, no una app de primer nivel, salvo que el módulo sirva de verdad a varios módulos.
Usa vistas heredadas para añadir un botón inteligente en el formulario de producto que abra su historial de etiquetas.
Da a la lista de eventos un filtro por defecto de hoy y una agrupación por zona, porque así es como los operarios la miran.
Muestra la versión de la regla de mapeo en el formulario del evento; cuando aparece una discrepancia, es el primer campo que alguien mira.
Nunca sobrescribas por completo la arquitectura de una vista del núcleo; añade el nodo concreto que necesitas mediante xpath.

Seguridad: ACL, reglas de registro y el usuario de API

La seguridad es la parte que se omite en el prototipo y se audita en producción.

Dos grupos suelen ser lo correcto: un operario que lee eventos y confirma mapeos, y un gestor que cambia lectores y reglas.
No concedas escritura sobre los modelos de stock más allá de lo que ya tienen los grupos estándar de inventario.
Usa un usuario de integración dedicado con derechos estrechos y dale a la pasarela su propia clave API en lugar de un login humano.
Añade una regla de registro para que un usuario de una compañía no vea lectores y eventos de otra.
Registra quién cambió una regla de mapeo, porque una regla incorrecta corrompe semanas de inventario en silencio.

Integración con stock.quant sin bifurcar stock

La ruta de escritura es la única parte realmente peligrosa del módulo.

Llama al helper del ORM que actualiza la cantidad disponible de forma atómica y nunca asignes el campo de cantidad directamente.
Envuelve la aplicación en una sola transacción por ubicación, para que un fallo revierta una unidad coherente y no medio pasillo.
Registra el motivo del ajuste y el id del evento de origen en el campo de referencia, para que la trazabilidad llegue hasta la radio.
No crees movimientos de stock para corregir un recuento; usa el modelo de ajuste de inventario, que existe precisamente para eso.
Mantén la deduplicación y la agregación fuera de Odoo; el módulo debe recibir deltas, no un flujo de lecturas crudas.

El endpoint de entrada: controlador, cron y lotes

El endpoint debe ser aburrido: autenticar, validar, encolar, devolver.

Acepta un cuerpo JSON con un lote de deltas y una clave de idempotencia, y rechaza lo que no pase la validación de esquema con un error concreto.
Escribe el delta en la tabla de eventos y devuelve de inmediato; nunca hagas la aplicación en Odoo dentro de la petición HTTP.
Deja que el cron vacíe la cola cada minuto, o cada pocos segundos bajo la cola de trabajos, con un único escritor.
Haz la aplicación idempotente sobre la clave de idempotencia, para que un reintento de red no duplique la cantidad.
Limita el tamaño del lote y del cuerpo, porque un endpoint sin límites es una invitación.

Pruebas y disciplina de actualización

El módulo se actualizará, y las pruebas son lo que convierte eso en rutina en lugar de proyecto.

Escribe pruebas de transacción que creen un lector, ingieran un evento, lo apliquen, verifiquen el quant y hagan rollback.
Prueba el caso duplicado explícitamente: envía la misma clave dos veces y verifica una sola aplicación.
Prueba la ruta de rechazo: un EPC desconocido debe caer en cuarentena, no en un traceback.
Mantén un script de migración por versión que toque datos, y pruébalo contra una copia de producción.
Fija las dependencias del módulo y evita llamadas a API privadas, porque son las que se rompen en la siguiente versión mayor.