Ver defeitos do turno

Adiciona unidades defeituosas de um SKU a um turno pelo seu ID (o que é devolvido por GET /v1/shifts), mesmo em turnos que já terminaram. O que é um defeito. Os defeitos contam-se em unidades defeituosas do SKU, não em falhas individuais: uma unidade com três riscos é uma unidade defeituosa. Como os defeitos se somam. Cada pedido regista uma quantidade adicional de unidades defeituosas no turno inteiro, como um novo registo de produção de defeitos de quantity unidades do SKU. As métricas de Qualidade e OEE são recalculadas de forma assíncrona. Os pedidos nunca substituem os anteriores: * Enviar quantity: 2 e depois quantity: 3 regista 5 unidades defeituosas. * Enviar o mesmo pedido duas vezes regista os defeitos duas vezes, a menos que ambos levem o mesmo Idempotency-Key (ver abaixo). * Um turno listado duas vezes por GET /v1/shifts, em dois intervalos consecutivos, continua a ser um único turno: processe cada id uma única vez, ou liste com match=start. * Para anular uma chamada, elimine o registo que ela devolveu com DELETE /v1/production-logs/{id}, que requer o scope production_logs.delete. Para ver o que um turno já tem, liste os seus defeitos com GET /v1/shifts/{shift_id}/defects, que requer shifts.read. Conceda ambos a uma integração que reconcilie ou anule o que envia; só com shifts.update pode adicionar defeitos, mas não verificá-los nem removê-los. Os defeitos não são atribuídos a nenhum operador, e podem ser adicionados a turnos passados, incluindo aqueles cuja produção foi revista. O SKU é indicado por exatamente um de id ou name, e tem de ser já um dos seus SKUs: estes endpoints nunca criam um. O sku da resposta mostra o SKU a que os defeitos foram atribuídos. Os erros incluem um code estável (consulte as respostas abaixo): * 400 shift_not_found: nenhum turno corresponde. * 400 shift_not_started: o turno ainda não começou. * 400 insufficient_production: o turno não tem produção suficiente desse SKU para comportar os defeitos. * 404 sku_not_found: sku.id ou sku.name não é um dos seus SKUs. * 409 idempotency_key_reused: o Idempotency-Key já foi usado com um pedido diferente. * 409 idempotency_key_in_progress: o pedido original com esse Idempotency-Key ainda está a ser processado. Novas tentativas e Idempotency-Key. Se uma chamada falhada registou alguma coisa depende da forma como falhou: * Uma resposta 4xx significa que o pedido foi rejeitado e nada foi registado. Corrija-o e envie-o novamente. * Um tempo limite esgotado, uma ligação interrompida ou uma resposta 5xx deixam o resultado desconhecido: o pedido pode ter sido registado mesmo que nunca tenha recebido a resposta. Se o reenviar sem um Idempotency-Key, pode ficar registado duas vezes, por isso verifique primeiro se foi registado, por exemplo com POST /v1/production-logs/filters. Para repetir com segurança, envie um cabeçalho Idempotency-Key com um valor único gerado por si para cada pedido, como um UUID, e envie a mesma chave e o mesmo corpo em cada nova tentativa desse pedido. A chave é guardada juntamente com o que o pedido registou, por isso uma nova tentativa nunca o regista duas vezes: * Se o pedido original foi registado, a nova tentativa não regista nada e devolve a resposta original, com o cabeçalho Idempotent-Replayed: true. * Se o original não foi registado, quer tenha sido rejeitado quer tenha falhado, a nova tentativa é processada como um pedido novo. * Reutilizar uma chave com um pedido diferente, com outro corpo ou URL, devolve 409. * No caso raro de o original ainda estar a ser processado, a nova tentativa devolve 409. Tente novamente daqui a pouco. As chaves são da sua empresa, por isso todas as chaves de API dela as partilham, e cada chave é guardada durante 24 horas após o pedido que a registou. Depois disso, um pedido com a mesma chave é processado como um pedido novo, por isso repita dentro desse período.