Cadastro de Item

Formato CAT-{YYYY}-{NNNNN}, único por tenant, sem edição manual. Reservado no momento da criação, mesmo em rascunho, para não haver furo de sequência.

Os três são obrigatórios já no rascunho. É o mínimo que torna o item comparável, classificável e cotável.

ItemType.allowedUomClasses é validado no domínio. Impede matéria-prima medida em horas e consultoria medida em quilos.

NCM, CEST, GTIN, peso e dimensões em item de serviço, ou código LC 116 em matéria-prima, respondem 400 ITEM_FIELD_NOT_APPLICABLE com o nome do campo e do tipo. Ignorar silenciosamente é pior — o usuário acha que gravou.

Nem para aprovar. O tenant pode elevar campos a obrigatórios via ItemType.requiredFields, mas o default do produto é opcional.

Ao mudar itemTypeId, o domínio verifica os campos preenchidos contra o novo tipo. Campos que deixam de se aplicar são listados na resposta e a operação só prossegue com discardIncompatibleFields: true explícito. Os valores descartados ficam no log de auditoria.

Recalculada a cada alteração de basicName ou de atributo marcado como usedInDescription. Só é editável quando a categoria não tem esquema de atributos. Truncada em 200 caracteres com aviso quando os atributos geram texto maior.

Não bloqueiam a criação do rascunho — bloqueiam submit. Cadastrar em duas sessões é um caso real; aprovar item incompleto não é.

numerator e denominator inteiros positivos. A unidade base não pode figurar como destino. Conversão entre classes distintas existe, e só por item — nunca global, nunca herdada da conversão padrão. É o caso do aço em barra comprado por SC e cobrado por TN, e do cabo comprado em MT e cobrado em KG: quem declara a equivalência é o item, porque 1 MT de cabo pesa o que aquele cabo pesa e nada disso vale para "cabo" em geral. Ver RN-ITM-32.

Um gatilho só, o mesmo na Unidade de Medida (RN-UOM-15): existindo qualquer linha de requisição, cotação, pedido, recebimento ou nota que referencie o item, em qualquer estado — rascunho incluído —, baseUomId não muda. Alteração responde 409 ITEM_BASE_UOM_LOCKED_CONFLICT e sugere criar item sucessor. E a base não pode ser unidade de embalagem (isPackaging): a base é a única constante da cadeia, e o conteúdo de uma caixa não é constante — 400 ITEM_BASE_UOM_PACKAGING_NOT_ALLOWED.

allowsPosting nasce true em folha e false quando o nó ganha o primeiro filho; a exceção é editável nó a nó. Item apontando para nó sem a flag responde 400 ITEM_CATEGORY_NOT_POSTABLE; fora da vigência, 422 ITEM_CATEGORY_NOT_EFFECTIVE_UNPROCESSABLE. Criar filho sob um nó que tem itens e não tem a exceção marcada exige reclassificar esses itens na mesma transação: a API devolve 409 CATEGORY_NODE_HAS_ITEMS_CONFLICT com a contagem, e o comando aceita um mapa de reclassificação — ou a exceção.

Na v1 não há teto — a profundidade da árvore de categorias é livre, como a do centro de custo. catalogMaxCategoryDepth é gancho declarado: campo opcional deste documento, padrão nulo, validado no POST e no PATCH /parent quando existir valor. Aumentar o teto é operação de admin e não afeta nada existente; diminuir é recusado enquanto houver nós mais profundos. Enquanto o valor for nulo, nada é recusado e o erro correspondente não é devolvido — ele fica declarado, para nascer junto com o teto. Por quê: até 08/09 esta página validava contra um campo que nenhuma spec definia, e o erro era devolvido contra um teto que ninguém podia configurar; a saída foi tirar a promessa, não inventar a entidade — o único consumidor é esta validação, e o padrão é "sem limite".

Itens existentes não são afetados nem reclassificados. Ao desativar, a resposta informa a contagem de itens ativos atingidos.

Havendo requisição, cotação, pedido ou nota vinculada, só há mudança de fase. O DELETE existe apenas para itens em Draft nunca submetidos.

ItemSupplier.status é Active | Blocked. Nasce Active e só muda por POST …/block e …/unblock, com update:catalog-suppliers, expectedVersion, motivo codificado dos usos SupplierBlock e SupplierUnblock e trilha item-supplier.blocked e item-supplier.unblocked. Repetir o estado atual é ITEM_SUPPLIER_STATUS_UNCHANGED_CONFLICT. Bloquear preserva preço, histórico, prioridade e unidades, e não mexe em documento já submetido: vale para linha nova e para a próxima submissão.

O bloqueio do fornecedor inteiro não muda a relação. O efeito é derivado na leitura: a relação só entra em cotação ou pedido quando o status dela permite e a tabela “O que cada estado libera” do Fornecedor permite, as duas lidas quando a linha escolhe a relação e de novo na submissão. Não há evento a esperar nem status anterior a guardar: desbloqueado o fornecedor, cada relação volta a valer como estava, e a que foi bloqueada por ato próprio continua Blocked.

blocksPurchaseWhenExpired impede requisição e pedido a partir do vencimento. Job diário notifica 30, 15 e 5 dias antes. É o comportamento exigido para EPI sem CA válido.

Default vem do ItemType. A linha do pedido pode sobrescrever, e a sobrescrita é auditada — é evidência da intenção no momento da compra, defensável em fiscalização.

Os três campos gravam juntos ou nenhum grava. Preço sem unidade não é comparável e vira ruído no comparativo de cotações.

expectedVersion obrigatório no corpo do PUT, checado antes de tocar o agregado. Versão defasada responde 409 ITEM_VERSION_CONFLICT com a versão atual na mensagem. Vale igual para ItemSupplier e para CategoryNode — no PUT, no PATCH /parent, no PATCH /activate e no DELETE. É o token único do produto; nas três árvores path é guarda de move, não token.

Item, ItemSupplier, CategoryNode e AttributeDefinition são IAuditableEntity, categoria Catalog. Registram campo, valor anterior, valor novo, usuário, IP e timestamp.

shipToStateCode compõe a chave da versão de preço ItemSupplierPrice, não a da relação — destino é eixo de frete e tributação, e frete e tributação são preço, não relacionamento. A resolução na linha do documento usa o deliveryStateCode congelado no snapshot de entrega e desce os degraus do mais específico ao mais genérico, sem nunca aproximar: não existindo linha para a UF nem linha sem destino, o preço não é sugerido. Preço por ponto de entrega específico não vive aqui — é negociação, e mora no ContractItem (RN-ITM-34).

PATCH /activate exige a cadeia de ancestrais ativa e vigente e não desce à subárvore; DELETE desativa a subárvore inteira e recusa se houver item ativo no nó ou abaixo (409 CATEGORY_NODE_HAS_ITEMS_CONFLICT). Criar, mover ou ativar sob ramo inativo responde 422 CATEGORY_ANCESTOR_INACTIVE_UNPROCESSABLE. O corpo do PUT não carrega isActive. Uma linha de auditoria por cascata, no nó disparado — a mesma mecânica do Centro de Custo.

validFrom e validTo são opcionais e independentes de isActive. Filho não excede a vigência do pai (422 CATEGORY_VALIDITY_OUTSIDE_PARENT_UNPROCESSABLE); encerrar um pai encerra a subárvore na mesma data, em cascata. Nó fora da vigência não é oferecido a item novo nem a linha nova e continua legível no histórico.

A vigência está na chave da versão de preço: a unicidade do ItemSupplierPrice é (itemSupplierId, validFrom, shipToStateCode?, companyId?, freightTerms?), tratando nulos como iguais. A regra de não sobreposição é outra e mais forte: duas versões da mesma combinação (itemSupplierId, shipToStateCode?, companyId?, freightTerms?) — sem validFrom, porque com ele toda versão seria uma combinação própria e a regra nunca dispararia — não podem ter vigências que se cruzem. Verificado na aplicação, na mesma transação da gravação e sob trava da relação, com guarda no banco quando ele existir; cruzamento responde 409 ITEM_SUPPLIER_PRICE_DUPLICATED_CONFLICT. Reajustar preço é gravar linha nova e fechar a anterior, nunca editar a vigente: a linha vigente é o que o comparativo lê, e as fechadas respondem qual preço estava acordado em março. Quanto se pagou em março é outra pergunta, e não se responde pelo cadastro: é projeção das linhas de pedido e de nota, que congelam a versão usada e o valor efetivamente praticado. A resolução de preço num documento usa a linha vigente na data de submissão dele, e o resultado vai congelado para a linha, como manda a Regra 1 do mapa de domínio.

numerator e denominator já usados em cotação, pedido, recebimento ou nota não mudam no registro. Na unidade de compra do fornecedor (ItemSupplierUom), a linha usada fica imutável: quando o fornecedor passa a entregar 10 onde entregava 12, grava-se linha nova — pode ser o mesmo código CX — e a usada é desativada na mesma transação. Na conversão do item (ItemUomConversion), fator novo para unidade já usada versiona: a vigente fecha em validTo e a nova abre em validFrom. É uma regra só, em duas formas porque uma entidade tem vigência e a outra não — a RN-UOM-09 —, e o PUT do conjunto aplica as duas sem responder 409 por fator em uso. O documento congela o registro e o fator que usou (itemSupplierUomId, convNum/convDen, RN-UOM-10), então nem documento emitido nem documento em aberto muda de significado; o que se protege aqui é o cadastro: com o fator editado no lugar, CX valeria 12 até ontem e 10 hoje, e nenhuma consulta saberia qual valia. Registro nunca usado corrige-se no lugar.

ItemSupplier é a relação, com chave de três partes (itemId, supplierId, supplierEstablishmentId?) — a UF está na chave do preço, para não ser também dimensão de status —, e é dona de status, isPreferred/priority, tolerâncias, reviewByDate e código no fornecedor. Tem três filhas: as unidades de compra (ItemSupplierUom, RN-ITM-33), os apelidos de unidade da nota (ItemSupplierUomAlias, RN-ITM-35) e a versão de preço ItemSupplierPrice, append-only. Quatro consequências, e cada uma fechava um furo: a camada 3 da antiduplicidade bloqueia na relação, e por isso reajustar preço deixa de colidir com ela; "máx. 10 preferidos por item" conta relações, não versões históricas; o DELETE "só se nunca usado" volta a ser decidível, porque existe um registro que é "a relação"; e a FK da linha do documento aponta para a relação e congela, ao lado, a versão de preço resolvida na submissão e a unidade de compra usada — a linha guarda os três identificadores, e o comparativo sabe exatamente qual tabela pagou aquele preço.

freightTerms é obrigatório em toda versão de preço de item cujo tipo tem requiresGoodsTaxCode, nulo em todas as demais, e compõe a chave. O vocabulário é o do modFrete da NF-e — ContractedBySender (0), ContractedByRecipient (1), ContractedByThirdParty (2), OwnTransportBySender (3), OwnTransportByRecipient (4), NoTransport (9) —, persistido como texto; o comparativo conta como preço com transporte só 0 e 3. O modFrete da nota é conferido contra ele, exceto na NF-e de entrada de importação, em que o modFrete é do trecho nacional. Obrigatório porque preço de mercadoria que não diz se cobre o transporte é ininterpretável; na chave porque o preço com frete e o preço sem frete do mesmo fornecedor, para a mesma UF e no mesmo período, precisam coexistir. Não é degrau de resolução: bate ou não bate, e quem resolve sem informar a modalidade só recebe preço sugerido quando existe uma única. incoterm fica fora da chave e é opcional, aceito só com fornecedor de entityType = Foreign; quando presente, exige incotermNamedPlace e um freightTerms do lado que a regra atribui ao transporte principal — EXW, FCA, FAS e FOB com ContractedByRecipient ou OwnTransportByRecipient; CPT, CIP, CFR, CIF, DAP, DPU e DDP com ContractedBySender ou OwnTransportBySender. Recusas, na gravação da versão: 400 ITEM_SUPPLIER_PRICE_FREIGHT_TERMS_REQUIRED, 400 ITEM_SUPPLIER_PRICE_FREIGHT_TERMS_NOT_APPLICABLE, 400 ITEM_SUPPLIER_PRICE_INCOTERM_NOT_APPLICABLE, 400 ITEM_SUPPLIER_PRICE_INCOTERM_FREIGHT_MISMATCH. Trocar o tipo do item entre mercadoria e não mercadoria (RN-ITM-06) não reescreve versões: as que ficaram incoerentes com o tipo deixam de ser resolvidas, aparecem no painel de saúde do catálogo, e o cadastro grava versão nova. Decompor o preço em componentes de custo fica como gancho nomeado (ItemSupplierPriceComponent), não especificado enquanto a modalidade de frete der conta.

companyId é anulável e compõe a chave da versão de preço; nulo vale para todas as empresas do tenant. A v1 pode gravar sempre nulo — a coluna é gancho, e o que ela evita é migração de chave primária em agregado povoado. A resolução desce o degrau: preço da empresa do documento, depois preço sem empresa; nunca o preço de outra empresa. O catálogo continua sendo vocabulário do tenant — item, tipo, categoria e unidade não ganham empresa; o que ganha é a condição comercial, que é negociada por CNPJ comprador e muda com regime tributário, ICMS/ST e contrato. Ver Empresa e Estabelecimento.

Ao lado de convNum/convDen — o fator da unidade pedida para a base —, toda linha de documento congela priceConvNum/priceConvDen, o fator da unidade base para a unidade de preço. Sem eles, o caso de primeira classe ItemSupplierUom.uomId = SC com priceUom = TN obrigava a resolver a conversão no cadastro no momento do cálculo — e aí uma conversão nova, ou uma linha nova de unidade de compra, mudava o total de uma linha antiga. É exatamente a divergência de centavos que produz as rejeições 629 e 630 da SEFAZ, e a conferência a três existe para não tê-la. O par é copiado da versão de preço resolvida, que o congelou na gravação (RN-ITM-38). Quando priceUomId é a unidade base, o par é 1/1; quando é a própria unidade pedida, é o inverso de convNum/convDen — e em qualquer caso é gravado: snapshot não tem exceção. Ver RN-UOM-10.

Os três eixos são ortogonais no cadastro e conjuntivos na compra: para o item entrar como linha de requisição, cotação ou pedido, é preciso approvalStatus = Approved, fase cuja matriz permite ou avisa aquele processo, e isPurchasable verdadeiro. Faltando qualquer um: 422 ITEM_NOT_PURCHASABLE_UNPROCESSABLE, com a mensagem nomeando qual dos três recusou. Sem esta regra a curadoria de catálogo não bloqueava nada — um item rejeitado em fase Active era pedível — e um processo de aprovação que não impede nada é fila que se aprende a ignorar.

attributeSignature = sha256(basicName | categoryNodeId | atributos de identidade) e crossCategorySignature = sha256(basicName | atributos de identidade). Entram os atributos com isIdentity — obrigatórios ou não —, ordenados por código; atributo de identidade vazio entra como código=∅, para que o item com revestimento e o item sem ele não colidam. Forma canônica, a mesma em toda gravação: texto e basicName em decomposição Unicode sem acentos, maiúsculas, espaços internos colapsados em um e sem espaços nas pontas; número em decimal com ponto, sem separador de milhar e sem zeros à direita; Measure convertido para a unidade da classe por par inteiro e escrito com até 10 casas, ROUND_HALF_UP, seguido de : e do código da unidade (3/8 pol e 9,525 mm dão 0.009525:MT); booleano TRUE/FALSE; lista pelo código da opção; multivalorado com os códigos ordenados e separados por vírgula. A camada 4 bloqueia quando attributeSignature casa na mesma categoria e alerta quando só crossCategorySignature casa, com item de outra categoria. Alternar CategoryAttribute.isIdentity, ou vincular e desvincular atributo de identidade, dispara recálculo assíncrono das duas assinaturas do nó e da subárvore, com a camada 4 suspensa naquele ramo até terminar. Categoria sem atributo de identidade não tem assinatura — as duas são nulas, a camada 4 é pulada e as outras cinco continuam valendo.

conversions[] aceita unidade de destino de outra classe, e só quando o item declara a equivalência naquela linha — é conversão do item, não da unidade. Sem isso o caso que esta especificação usa três vezes como prova de que o modelo funciona — aço em SC cobrado em TN, cabo em MT cobrado em KG — não era cadastrável, porque a regra da coleção exigia a mesma classe da base. Continuam valendo: a classe Service não converte, nem entre si; a conversão global permanece estritamente intraclasse; e nada de interclasse é herdado — o que o item não declarou, o sistema recusa com 422, nunca estima. Ver Unidade de Medida.

ItemSupplierUom guarda as unidades em que o fornecedor vende o item, cada uma com fator próprio para a base. A relação tem ao menos uma linha ativa, uma ativa por unidade e exatamente uma padrão; a classe de cada unidade precisa constar em ItemType.allowedUomClasses, e item de base Service só aceita a própria base com 1/1. As linhas mudam só pelo PUT do conjunto, com o expectedVersion da relação: fator diferente para unidade já usada desativa a linha usada e cria outra, na mesma transação (RN-UOM-09); unidade retirada do conjunto é desativada se já usada e apagada se nunca usada; linha desativada não se reativa. Documento novo só usa linha ativa, e a linha do documento congela itemSupplierUomId ao lado de convNum/convDen. Pedido em aberto que congelou linha desativada continua valendo com o fator que congelou — é ele que o recebimento sinaliza quando a embalagem muda. Recusas: 400 ITEM_SUPPLIER_UOM_SET_INVALID (conjunto sem linha, unidade repetida ou padrão diferente de uma), 400 ITEM_UOM_CLASS_NOT_ALLOWED, 400 ITEM_SUPPLIER_UOM_SERVICE_BASE_ONLY e 409 ITEM_VERSION_CONFLICT.

ItemSupplier não carrega contrato. Um mesmo par item × fornecedor é coberto por vários contratos — renovações, um por empresa compradora, contrato guarda-chuva —, e a relação não tem empresa nem vigência para distingui-los: com o contrato nela, renovar reescreveria a referência e apagaria o histórico. O futuro ContractItem, na especificação do Contrato, referencia itemId ou itemSupplierId, com companyId anulável e vigência próprios, e é ele que sobrepõe preço, prazo e múltiplo na linha do pedido quando estiver vigente para a empresa do documento. Até ele existir, a precedência é relação (versão de preço e unidade de compra) → Item, e nenhum campo deste módulo espera pelo contrato.

A conferência da nota resolve o texto de uCom — e o de uTrib — em dois passos, sobre o texto normalizado (sem espaços, em caixa alta, sem acento): código exato de unidade ativa do tenant ou global; senão, apelido da relação da linha (ItemSupplierUomAlias). Não resolvendo, é exceção de conferência — nunca unidade parecida, nunca classe genérica, nunca 1:1. O apelido diz qual unidade é e nunca carrega fator: a quantidade na base vem do snapshot da linha do pedido quando a unidade resolvida é a pedida, e da hierarquia de conversão (RN-UOM-06) quando não é. Três guardas, porque apelido errado muda a leitura de quantidade: texto que normalizado já é código de unidade não aceita apelido — UN nunca significa CX (422 ITEM_SUPPLIER_UOM_ALIAS_IS_UOM_CODE_UNPROCESSABLE); o destino precisa ter fator para a base do item na gravação (422 ITEM_SUPPLIER_UOM_ALIAS_TARGET_UNRESOLVABLE_UNPROCESSABLE); e mudar apelido não refaz conferência concluída — vale para as notas conferidas depois. Máximo de 20 apelidos por relação (400 ITEM_SUPPLIER_UOM_ALIAS_LIMIT_EXCEEDED); toda mudança entra na auditoria da relação (RN-ITM-20). uTrib, qTrib e cEANTrib observados ficam na linha da nota, como o emitente os declarou; o catálogo não os copia.

Linha de requisição, cotação ou pedido pode ter itemId nulo — a compra do que ainda não está no catálogo. Não é item provisório nem rascunho, e não passa pela curadoria: é a própria linha. São obrigatórios nela description (texto livre, até 500 caracteres), categoryNodeId em nó ativo, vigente e com allowsPosting (as condições da RN-ITM-11), uomId de unidade ativa e predominantUse. A unidade informada é também a base da linha: convNum/convDen gravam 1/1 e nenhuma conversão é resolvida. itemSupplierId, itemSupplierPriceId e itemSupplierUomId são nulos, o preço é o informado na linha, e a RN-ITM-30 não se aplica, porque não há item cujos eixos consultar. A conta contábil sugerida vem do defaultGlAccountId do nó, como em qualquer linha. Produto regulado não entra por aqui: categoria cujo nó declara ou herda requiredComplianceKinds recusa linha não catalogada, porque a validade do registro regulatório (RN-ITM-16) só existe no item. O motor de aprovação recebe isUncatalogued = true, e é com essa marca que o tenant exige aprovação para compra fora do catálogo, sem código. Recusas: 400 ITEM_UNCATALOGUED_LINE_INCOMPLETE, nomeando o campo, e 422 ITEM_UNCATALOGUED_LINE_CATEGORY_UNPROCESSABLE, nomeando o motivo. Cadastrar depois um item para aquilo não altera a linha emitida, que continua sem itemId.

Escolhida a relação (estabelecimento exato → estabelecimento nulo), a versão de preço é procurada entre as vigentes na data de submissão e da modalidade de frete pedida, nesta ordem, e a primeira que existir vence: (1) empresa do documento e UF de destino da linha; (2) empresa do documento e UF nula; (3) empresa nula e UF de destino; (4) empresa nula e UF nula. A empresa vem antes da UF porque condição negociada pelo CNPJ comprador vence tabela regional. Como a não sobreposição (RN-ITM-24) garante no máximo uma vigente por degrau, a ordem é total e o resultado é único. Nada é emprestado de outra empresa, de outra UF nem de outra modalidade de frete; sem versão em nenhum degrau, 422 ITEM_SUPPLIER_PRICE_NOT_EFFECTIVE_UNPROCESSABLE. Na versão vencedora, a faixa aplicada é a de maior minQty menor ou igual à quantidade da linha convertida para a unidade de preço (priceUomId, com o fator congelado da versão); sem faixa que caiba, vale priceAmount. O preço da faixa vale para a linha inteira — não é escalonado —, e a linha congela a versão e a faixa usadas.

Na gravação, a versão resolve a unidade de preço pela hierarquia de conversão e guarda priceConvNum/priceConvDen — da base para a unidade de preço — e, quando o fator veio da unidade de compra do fornecedor, a linha de origem em priceItemSupplierUomId. Os dois são imutáveis. Na resolução (RN-ITM-37), uma versão só é sugerível se a sua unidade de preço ainda resolve, hoje, para o mesmo fator e, quando há priceItemSupplierUomId, se essa linha está ativa. Senão, a versão sai da sugestão, aparece no painel de saúde do catálogo, e o degrau segue como se ela não existisse, até alguém gravar versão nova. É o que impede o preço acertado por caixa de 12 de valer para a caixa de 10: 7 caixas a R$ 37,00 eram 84 UN a R$ 3,0833 cada; com a caixa de 10, as mesmas 7 caixas pelos mesmos R$ 259,00 são 70 UN a R$ 3,70 — 20% mais caro, sem nenhum número mudar na tela. A linha de documento já emitida continua com o fator que congelou (RN-ITM-29).

Linha de cotação, pedido ou recebimento de item catalogado pode ter itemSupplierId nulo — fornecedor que ainda não tem relação com o item, a compra spot. A RN-ITM-30 continua valendo; não há preço sugerido, e o preço é o cotado ou o informado. A unidade converte pelos níveis 2 e 3 da hierarquia. Quando o fornecedor cota numa unidade sem conversão — tipicamente a caixa dele —, o fator que ele declara na cotação (declaredFactor) só vale se o comprador o aceitar na linha, em ato explícito que grava quem aceitou e quando; o fator aceito vai congelado em convNum/convDen com factorSource = DeclaredAccepted. Se o item já tem conversão para aquela unidade e o fator declarado difere, o aceite exige justificativa em texto. O fator aceito nunca vira cadastro — nem conversão do item, nem unidade de compra — e cada linha grava de onde veio o seu fator: factorSource = SupplierUom | ItemConversion | StandardConversion | DeclaredAccepted | Identity. Sem fator resolvido nem aceito, 422 UOM_CONVERSION_NOT_CONFIGURED_UNPROCESSABLE. O recebimento continua conferindo em unidade base, e é a tolerância que pega fator declarado errado.

O gtin do item é o da unidade base. A caixa tem GTIN próprio — o GTIN-14 que o fornecedor põe no cEAN da nota —, e ele mora no nível que identifica: ItemUomConversion.gtin ou ItemSupplierUom.gtin (char(14)?). Todo GTIN é validado pelo dígito verificador, aceito com 8, 12, 13 ou 14 dígitos e gravado com 14, zeros à esquerda; o texto SEM GTIN da nota é tratado como ausente. Um GTIN normalizado identifica um item e um fator para a base no tenant: repetido no mesmo item com o mesmo fator — a mesma caixa vendida por dois fornecedores — é aceito; apontando para outro item ou para outro fator, 409 ITEM_GTIN_ALREADY_EXISTS, nomeando onde já está. Na conferência da nota, cEAN e cEANTrib normalizados são procurados nesses três lugares, e a divergência entre o GTIN da nota e o nível de embalagem da linha é alerta de conferência, nunca conversão.

Num item Approved, o PUT que toca campo material — categoria, tipo, unidade base (enquanto a RN-ITM-10 permitir), atributos de identidade, gtin, manufacturerName, mpn — não altera o item: grava a revisão pendente (pendingRevision, documento com os valores propostos, e revisionNumber). Há no máximo uma. Enquanto ela existe o item segue Approved, a RN-ITM-30 lê só os valores aprovados, e todo documento usa os valores aprovados. POST /catalog/items/{id}/revision/submit abre uma instância nova do processo ITEM sobre a revisão, com as camadas 1 a 4 da antiduplicidade refeitas nos valores revisados; aprovada, o contrato de desfecho aplica a revisão na mesma transação — descrição e assinaturas recalculadas, version incrementado, evento item.revision-applied —; rejeitada, a revisão é descartada com o motivo, e o item fica como estava. Revisão em aprovação não é editada (409 ITEM_REVISION_IN_APPROVAL_CONFLICT); DELETE /catalog/items/{id}/revision descarta a revisão e, se ela estiver em aprovação, cancela a instância. Campo não material grava direto e não cria revisão.

Fora da carga inicial, todo item importado nasce em Draft e só chega a Approved pela instância do processo ITEM no motor, como o item criado na tela; nenhuma permissão e nenhuma opção de importação aprova sozinha. autoApprove existe só na carga inicial de onboarding do catálogo, exceção declarada. Janela: aberta desde a criação do tenant e fechada, sem reabertura, no primeiro destes três: a confirmação de um lote, o fechamento explícito por quem tem approve:catalog-items (POST /catalog/items:close-initial-load), ou 60 dias corridos da criação do tenant; o fechamento grava catalogInitialLoadClosedAt na configuração do tenant. Fora da janela, importação com autoApprove: true responde 409 ITEM_INITIAL_LOAD_WINDOW_CLOSED_CONFLICT e não começa. Dupla custódia: quem tem create:catalog envia o arquivo por POST /catalog/items:import com autoApprove: true, com dryRun=true antes; sem dryRun, as linhas válidas viram itens em Draft com origin = InitialLoad, o mesmo initialLoadBatchId e o hash do arquivo — nenhum comprável ainda, e linha que casa em camada bloqueante da antiduplicidade fica no relatório, sem o forçar. Até a confirmação, item do lote não é editado nem submetido ao motor (409 ITEM_INITIAL_LOAD_PENDING_CONFLICT). Outra pessoa, com approve:catalog-items, confirma por POST /catalog/items:confirm-initial-load informando lote e hash; a mesma pessoa que importou responde 409 ITEM_INITIAL_LOAD_APPROVER_IS_IMPORTER_CONFLICT, hash diferente 409 ITEM_INITIAL_LOAD_HASH_MISMATCH_CONFLICT. A confirmação passa o lote inteiro a Approved numa transação, sem instância do motor, fecha a janela, grava o registro do ato de controle — quem importou, quem confirmou, lote, hash e contagem —, isolado por tenant e na mesma transação, e publica item.initial-load-confirmed depois do commit. Lote não confirmado quando a janela fecha não se perde: os itens ficam em Draft, liberados para edição, e seguem pela aprovação normal. Por quê: o processo ITEM não admite aprovação por política; sem janela e sem segunda pessoa, quem tem approve:catalog-items escreveria o catálogo aprovado sozinho, a qualquer tempo, por planilha.

As flags que o motor de aprovação lê do item são calculadas pelo dono na hora do ato, nunca gravadas como coluna própria: regulated quando a categoria do item declara ou herda requiredComplianceKinds, ou quando controlKind é diferente de None; critical quando criticality é Strategic ou Bottleneck, os dois quadrantes de alto risco de fornecimento; personalData quando handlesPersonalData é verdadeiro. No processo ITEM elas são flags do assunto; nos documentos com linhas, cada linha as leva em itemFlags (Fluxo de Aprovação, §Contrato de submissão). Linha não catalogada não tem nenhuma (RN-ITM-36).

Por quê. Com o nome das flags só em prosa e sem origem no item, a política "software com dado pessoal exige o DPO" não podia ser montada: ninguém sabia de onde o dono tiraria o valor. Derivar regulated e critical do que o item já tem evita um segundo campo que diverge do primeiro; o dado pessoal não se deriva de nada, e por isso é o único campo novo.

Limite declarado. handlesPersonalData responde pelo que é intrínseco ao produto — o CRM, o relógio de ponto. O serviço genérico que às vezes trata dado pessoal, como uma consultoria, não é coberto aqui: a marca declarada na linha é da spec da Requisition.