Ver defectos del turno

Agrega unidades defectuosas de un SKU a un turno por su ID (el que devuelve GET /v1/shifts), incluso en turnos que ya terminaron. Qué es un defecto. Los defectos se cuentan en unidades defectuosas del SKU, no en fallas individuales: una unidad con tres rayones es una unidad defectuosa. Cómo se suman los defectos. Cada solicitud registra una cantidad adicional de unidades defectuosas contra el turno completo, como un nuevo registro de producción de defectos de quantity unidades del SKU. Las métricas de Calidad y OEE se recalculan de forma asíncrona. Una solicitud nunca reemplaza a las anteriores: * Enviar quantity: 2 y luego quantity: 3 registra 5 unidades defectuosas. * Enviar la misma solicitud dos veces registra los defectos dos veces, a menos que ambas lleven el mismo Idempotency-Key (ver abajo). * Un turno que GET /v1/shifts lista dos veces, en dos rangos consecutivos, sigue siendo un solo turno: procesa cada id una sola vez, o lista con match=start. * Para deshacer una llamada, elimina el registro que devolvió con DELETE /v1/production-logs/{id}, que necesita el scope production_logs.delete. Para ver lo que ya tiene un turno, lista sus defectos con GET /v1/shifts/{shift_id}/defects, que necesita shifts.read. Otorga ambos a una integración que concilie o deshaga lo que envía; con solo shifts.update puede agregar defectos, pero no revisarlos ni eliminarlos. Los defectos no se atribuyen a ningún operador, y se pueden agregar a turnos pasados, incluso a los que tienen la producción revisada. El SKU se indica con exactamente uno de id o name, y ya debe ser uno de tus SKUs: estos endpoints nunca crean uno. El sku de la respuesta muestra el SKU al que se asignaron los defectos. Los errores llevan un code estable (consulta las respuestas abajo): * 400 shift_not_found: ningún turno coincide. * 400 shift_not_started: el turno todavía no empieza. * 400 insufficient_production: el turno no tiene suficiente producción de ese SKU para contener los defectos. * 404 sku_not_found: sku.id o sku.name no es uno de tus SKUs. * 409 idempotency_key_reused: el Idempotency-Key ya se usó con una solicitud distinta. * 409 idempotency_key_in_progress: la solicitud original con ese Idempotency-Key todavía se está procesando. Reintentos e Idempotency-Key. Que una llamada fallida haya registrado algo depende de cómo falló: * Una respuesta 4xx significa que la solicitud se rechazó y no se registró nada. Corrígela y envíala otra vez. * Un timeout, una conexión cortada o una respuesta 5xx dejan el resultado desconocido: la solicitud pudo haberse registrado aunque nunca recibiste la respuesta. Si la envías otra vez sin un Idempotency-Key, puede registrarse dos veces, así que primero revisa si se registró, por ejemplo con POST /v1/production-logs/filters. Para reintentar de forma segura, envía un header Idempotency-Key con un valor único que generes para cada solicitud, como un UUID, y envía la misma clave y el mismo cuerpo en cada reintento de esa solicitud. La clave se guarda junto con lo que registró la solicitud, así que un reintento nunca la registra dos veces: * Si la solicitud original se registró, el reintento no registra nada y devuelve la respuesta original, con el header Idempotent-Replayed: true. * Si la original no se registró, ya sea porque se rechazó o porque falló, el reintento se procesa como una solicitud nueva. * Reusar una clave con una solicitud distinta, con otro cuerpo o URL, devuelve 409. * En el caso poco común de que la original todavía se esté procesando, el reintento devuelve 409. Vuelve a intentarlo en un momento. Las claves son por empresa, así que todas sus API keys las comparten, y cada clave se conserva 24 horas después de la solicitud que la registró. Después de eso, una solicitud con la misma clave se procesa como nueva, así que reintenta dentro de ese plazo.