La primera versión de toda integración entre RFID y Odoo es igual. Se configura un lector para que envíe cada lectura a un controlador, el controlador escribe en stock.quant, y en una semana la base de datos empieza a bloquear, los workers de Odoo se saturan y el inventario queda mal de una forma que nadie puede reproducir.

El error es arquitectónico, no técnico. Un lector es un sensor, no una fuente de transacciones. Entre un sensor que informa miles de veces por segundo y un ERP que espera un evento de negocio meditado, tiene que haber algo que piense. Ese algo es la pasarela y, en un despliegue que funciona, es la parte que se mantiene, se versiona y se monitoriza: el producto, no el pegamento.

Por qué conectar lectores directamente a Odoo es un anti-patrón

Los números lo demuestran antes de escribir una línea de código.

Un lector fijo en una puerta emite varios cientos de eventos TagRead por segundo durante el paso de un palé.
Cada etiqueta se ve típicamente entre cinco y veinte veces dentro de un segundo, con intensidades distintas.
El ORM de Odoo calcula y escribe una fila de quant por producto, ubicación y lote, con bloqueos de fila e invalidación de caché en cada escritura.
Los escritores concurrentes sobre el mismo quant se serializan en esperas de bloqueo, y las actualizaciones de varias filas en orden incorrecto producen interbloqueos.
Una caída del lector luego reproduce una ráfaga, y la ráfaga llega justo cuando el ERP está menos capacitado para absorberla.

Las tres tareas de la pasarela: analizar, deduplicar, agregar

Una pasarela que hace bien estas tres cosas puede tener doscientas líneas. Una que las hace mal se reescribe dos veces.

Analizar: convertir un EPC crudo en producto, lote y serie sin consultar la base de datos en la ruta caliente.
Deduplicar: conservar una observación por etiqueta y ventana temporal, no veinte, y quedarse con la señal más fuerte.
Agregar: convertir observaciones en deltas con signo por ubicación y producto, que es la única cantidad que Odoo debería ver.
Amortiguar: mantener los deltas en una cola duradera para que un reinicio no pierda nada y un reintento sea seguro.
Aplicar: escribir en Odoo por lotes, con una clave de idempotencia que haga que una aplicación repetida no haga nada.

De EPC a producto: un mapeo determinista

El análisis de EPC es donde las integraciones se rompen en silencio, porque se hace manipulando cadenas en lugar de esquemas.

Un SGTIN de 96 bits codifica prefijo de empresa, referencia de artículo y serie; el punto de corte depende de la longitud del prefijo, no de la cadena.
Decodifique primero la cabecera, luego la partición y después los campos; adivinar anchos funciona hasta que deja de funcionar.
Mantenga un mapa en caché de referencia de artículo a producto y lote; actualícelo por temporizador y no en cada lectura.
Trate los EPC desconocidos como una cola explícita, no como nulos; una etiqueta desconocida es un defecto de etiquetado que merece verse.
Versione las reglas de mapeo, porque un proveedor que cambia su codificación no debería exigir un despliegue de código.

Escribir stock.quant sin interbloqueos

La ruta de escritura es donde la mayoría de los proyectos pierde un fin de semana. Las reglas son simples y tratan sobre todo del orden.

Un solo proceso escritor por base de datos; la concurrencia aquí compra el rendimiento que no necesitas y los bloqueos que sí.
Prefiera el método del ORM que hace una actualización atómica de cantidad con el bloqueo correcto, y nunca lea-modifique-escriba en Python.
Si debe usar SQL, bloquee filas en un orden determinista —producto, luego ubicación, luego lote— para que dos transacciones no se crucen.
Agrupe por ubicación, no por etiqueta: cincuenta deltas de un pasillo pertenecen a una transacción, no a cincuenta.
Registre el motivo de negocio en cada ajuste, porque un cambio de cantidad sin explicación es indistinguible de un error en una auditoría.

Resolución de conflictos cuando dos verdades discrepan

El lector y el ERP van a discrepar, y la pregunta de diseño es quién puede ganar y cuándo.

Una lectura es evidencia sobre el presente; un registro del ERP es una afirmación sobre el pasado. No son el mismo tipo de hecho.
Nunca permita que una sola lectura sobrescriba una cantidad; aplique un delta solo cuando la observación esté completa y la zona cerrada.
Use el tiempo de evento del lector, no el de llegada a la pasarela, para que un lote retrasado no parezca un movimiento nuevo.
El último que escribe gana es inseguro con eventos duplicados; prefiera una secuencia monotónica por lector y rechace lo anterior a lo ya aplicado.
Cuando la discrepancia es estructural —una zona entera desviada un diez por ciento— levante una excepción en lugar de corregir en silencio.

Ingeniería de rendimiento a 100.000 eventos al día

Cien mil eventos es uno por segundo de media y doscientos por segundo en el muelle, así que los promedios son inútiles.

Dimensione para el pico y luego verifique la media; el pico es lo que rompe el sistema y la media lo que lo hace parecer correcto en una demo.
Agrupe en ventanas de medio segundo a dos segundos; por debajo pagas sobrecarga de transacción, por encima pagas latencia.
Mantenga la ruta caliente libre de campos calculados del ORM, lógica onchange e hilos de correo; nada de eso pertenece a una escritura de inventario.
Ejecute el worker de aplicación en la cola de trabajos con un canal dedicado, para que un ERP lento no detenga el lado del lector.
Mida la ratio de deduplicación; si es inferior a diez a uno, la ventana es demasiado corta y Odoo hace trabajo innecesario.

Observabilidad: qué registrar y qué alertar

Una tubería de inventario que no se puede observar será creída hasta la primera auditoría, y después no.

Registre cada evento crudo de una muestra y cada delta aplicado de todos los eventos, con la clave de idempotencia adjunta.
Siga los recuentos por antena, para que una antena muerta parezca una caída en una serie y no una semana tranquila.
Alerte sobre latencia de aplicación por encima de un umbral, crecimiento de la cola y tasa creciente de eventos rechazados.
Reconcilie a diario: compare los deltas de la pasarela con los cambios de cantidad de Odoo y explique cada diferencia superior a un umbral.
Conserve un archivo de eventos reproducible, porque el incidente más común no es una caída sino una regla equivocada durante tres días.

Secuencia de despliegue y reversión

La forma segura de introducir una ruta de escritura en un ERP es hacerla ganar el derecho a escribir.

Fase uno: modo sombra. Calcule deltas, regístrelos, no escriba nada y compare con lo esperado durante dos semanas.
Fase dos: escriba en una base de datos de pruebas con tráfico de producción y ejecute el informe de conciliación sobre ella.
Fase tres: habilite escrituras para una zona con un flag y mantenga el proceso antiguo en paralelo.
Fase cuatro: amplíe por zonas, vigilando la tasa de excepciones en lugar de la de éxito.
La reversión no es restaurar la base de datos: detenga el escritor, reproduzca la cola con la regla corregida y reaplique de forma idempotente.