El reporte de producción parece una automatización sencilla: el palé pasa por un lector y Odoo actualiza la orden. No es sencillo, porque una orden de trabajo registra tiempo además de cantidad, y una lectura no dice nada sobre cuándo empezó la operación ni quién la ejecutó.

Una orden de trabajo es una afirmación sobre tiempo, no solo cantidad

La contabilidad y el análisis dependen ambos de la dimensión temporal.

Las horas de inicio y fin gobiernan capacidad, plazo y coste por hora.
Una cantidad sin duración no sirve para OEE ni para analizar retrabajo.
Una lectura al final de la línea dice producción; no dice nada de los veinte minutos de espera.
Reportar el fin de una operación es un evento distinto de reportar cantidad buena.
Diseña el modelo de eventos antes de elegir un punto de lectura.

Qué puede afirmar honestamente una lectura RFID

Sé estricto con lo que cada lectura sostiene.

Presencia de un contenedor o palé concreto en un punto concreto del tiempo.
Paso por un cuello de botella, que es una afirmación fuerte si la cobertura es completa.
Identidad de lote o de serie, si la etiqueta está bien vinculada y verificada.
Nada sobre el operario, salvo que lleve etiqueta y un flujo atribuya la acción.
Nada sobre calidad, salvo que la inspección escriba su propio evento.

Puntos de lectura en la ruta de producción

Cada punto de lectura debe existir por una única decisión.

Entrada al centro de trabajo: la operación empieza y el WIP ha llegado.
Salida del centro: la operación está completa y se puede imputar cantidad.
Posiciones de buffer y cola: saber dónde espera el artículo explica el retraso.
Entrada al bucle de retrabajo: el artículo vuelve, así que esa cantidad no es producción buena.
Contenedor de scrap: un evento deliberado de desecho, no una lectura perdida en la salida.

Inicio, pausa, fin: modelar los estados

Una máquina de estados evita la mayoría de las discusiones de reporte.

En cola, en curso, en pausa, bloqueada, terminada: cinco estados cubren casi cualquier planta.
Una pausa necesita código de motivo, o el análisis de paradas es decorativo.
Bloqueada significa esperar material o calidad, y su coste difiere del de inactividad.
Las transiciones deben estar atribuidas y con hora, y deben poder llegar tarde.
Rechaza en voz alta las transiciones imposibles en lugar de repararlas en silencio.

Cantidad, scrap y el bucle de retrabajo

Las cantidades necesitan un origen y un momento.

La cantidad buena se imputa al completar, con la unidad de medida de la operación.
El scrap se imputa donde se detecta, con motivo y centro de trabajo.
El retrabajo es una operación, no una corrección; modélalo así o la ruta mentirá.
Las terminaciones parciales son normales; permítelas y mantén visible la cantidad restante.
Concilia el consumo de componentes por separado de la producción, porque fallan de forma distinta.

Identidad del operario y reparto de mano de obra

Quién hizo el trabajo es una pregunta real en una planta con turnos.

Una lectura de tarjeta en el centro abre una sesión, pero no prueba presencia continua.
Atribuye la transacción en el momento de confirmar, no en el de iniciar sesión.
Los centros compartidos necesitan reparto de horas; una sola lectura no lo inventa.
La mano de obra indirecta suele faltar en el reporte automático, y suele ser la interesante.
Facilita la confirmación manual, o los operarios confirmarán todo al final del turno.

Backflush y la trampa del tiempo

El backflush es cómodo y se equivoca en silencio en los bordes.

El backflush consume componentes al imputar producción, lo que está bien en régimen estable.
En una operación larga, el backflush desplaza el consumo en el tiempo y distorsiona el WIP.
El scrap de componentes a mitad de operación es invisible salvo que el operario lo reporte.
Las tolerancias del backflush esconden el sobresconsumo sistemático hasta que un inventario lo encuentra.
Para componentes de alto valor o regulados, reporta el consumo explícitamente, aunque cueste mano de obra.

Gestión de excepciones cuando la línea se para

La automatización tiene que sobrevivir al turno en que todo falla.

Una lectura ausente debe generar una pregunta, no un cero silencioso.
Define quién puede confirmar a mano y exige un motivo.
Los eventos en buffer deben poder reproducirse en orden, preservando las horas originales.
Una línea que corre sin lector debe poder reportar en papel y conciliar después.
Sigue la frecuencia de confirmación manual; es la métrica de salud de la automatización.

Modelo de sincronización: eventos, no contadores

Las órdenes de Odoo tienen estados; la integración debe hablar en transiciones.

Envía eventos de operación con identificador y deja que Odoo sea dueño de las cantidades.
Nunca incrementes un porcentaje de avance; derívalo de las cantidades imputadas.
Haz la ingesta idempotente, porque las redes de planta reintentan.
Conserva el log de eventos crudos, para reconstruir una cantidad en disputa.
Concilia a diario: eventos recibidos, cantidades imputadas, diferencias explicadas.

Serialización y genealogía

Un número de serie al final de la línea es una promesa sobre los componentes.

Una lectura de serie crea una afirmación de genealogía que debe sostenerse en una retirada del mercado.
Los lotes de componentes deben vincularse al número de serie en el momento del montaje, nunca reconstruirse después.
Un número de serie reutilizado entre unidades destruye el análisis de retirada y cualquier posición de garantía.
La genealogía vale lo que vale el reporte de componentes aguas arriba; si ese consumo se imputa a la ligera con backflush, la lista de retirada no sirve de nada.
Imprimir y aplicar la etiqueta de serie es en sí misma una operación, y los errores de etiqueta son una de las principales causas de fallo de genealogía.

Indicadores y piloto

Demuestra que el reporte es mejor, no solo más automático.

Mide el retraso de reporte, la tasa de confirmación manual y la proporción de operaciones con hora real de inicio.
Compara el OEE antes y después, y comprueba si el cambio es de medición o de realidad.
Haz el piloto en un centro con ruta estable y un jefe de turno colaborador.
Vigila la tasa de excepciones del primer mes, porque predice si el equipo seguirá usándolo.
Decide por adelantado qué nivel de respaldo manual es aceptable.