Cadastro de Fornecedor

^[A-Z0-9]{12}[0-9]{2}$ mais módulo 11 com valor do caractere igual a ASCII − 48. Gravado sem máscara e em caixa alta; a entrada normaliza minúsculas. Aceitar os dois formatos, numérico e alfanumérico — a Receita continua emitindo CNPJs só numéricos, então "CNPJ novo" não implica "tem letra".

Criado junto com o fornecedor, para todo entityType — é no estabelecimento que vivem a IE por UF (produtor rural tem IE), o endereço fiscal, paymentTerms / currency / defaultIncoterm, receiptTolerance e o padrão de pedido por isPrimary. Para Company e MEI, o principal é a matriz — pelo identificador matriz/filial da Receita, nunca pela ordem do CNPJ — quando ela existe na base. Para Individual e Foreign, o principal é o estabelecimento único criado com o cadastro — sem cnpj, sem establishmentType e sem situação cadastral; a identidade fica na raiz. RuralProducer tem um estabelecimento por propriedade, todos sem CNPJ, cada um identificado pela IE (UF + número) e, havendo, pelo CAEPF; o principal é marcado por isPrimary, e a identidade continua sendo o CPF da raiz. A alternativa "estabelecimento só para quem tem CNPJ" não serve: deixaria produtor rural sem IE e estrangeiro sem moeda e incoterm.

Campo obrigatório para um tipo e inaplicável a outro responde 400 SUPPLIER_FIELD_NOT_APPLICABLE nomeando campo e tipo. Estrangeiro não tem CNPJ, IE, IM, CNAE nem regime tributário brasileiro. A identidade segue o tipo — cnpj no estabelecimento para Company e MEI, cpf na raiz para Individual e RuralProducer, taxIdCountry + foreignTaxId na raiz para Foreign —, cada uma com o seu índice único parcial por tenant, que depende do banco e é verificado na aplicação.

Prospect pode ser convidado a RFQ e qualificado; pedido responde 409 SUPPLIER_NOT_SPEND_AUTHORIZED_CONFLICT. A promoção acontece por homologação aprovada (instância SUPPLIER terminada em Approved) — e por mais nada. Vitória em cotação não promove: ela abre uma qualificação para as categorias do que foi cotado, que percorre o mesmo caminho de todas as outras. Promover por vitória tornaria o convite a uma RFQ o atalho mais barato para contornar a homologação — sem instância, sem motivo codificado, sem certidão e sem varredura de sanção. E promover não basta: quem paga a conta do gasto é a RN-FOR-24.

Suspensa, inapta, baixada ou nula bloqueiam a aprovação da homologação e são reavaliadas na revalidação periódica. Estabelecimento que fica inapto depois de homologado gera alerta e não bloqueia pedido em aberto; pedido novo para esse estabelecimento para de passar (RN-FOR-24). Quem não tem CNPJ não tem situação cadastral, e esta regra não se aplica — a diligência de pessoa física e de estrangeiro é a dos documentos do tipo.

Nunca gravado à mão. A janela de "a vencer" é configurável por tipo. O status da homologação não influencia o vencimento do documento — a relação é só nessa direção.

Warn | RequireJustification | BlockNewOrder. Nenhuma política bloqueia recebimento de pedido já colocado. Como a justificativa de RequireJustification é exigida e registrada no pedido — uso de motivo, flag para o motor, código de erro — é definido pela spec do Pedido.

Não existe lista fixa. O motor resolve: dado o fornecedor, suas categorias homologadas e a faixa de risco, quais tipos são exigidos, quais opcionais e quais dispensados.

Homologação sem escopo é recusada. Requalificação herda categorias e faixa de risco da anterior.

Sanção encontrada abre um SupplierComplianceAlert, que só fecha com decisão registrada (RN-FOR-37). O tenant pode elevar um tipo de sanção a bloqueante por configuração, mas não é o default.

Cada consulta grava fonte, data, resultado e evidência. Nunca sobrescreve a anterior — a série histórica é o que torna a decisão auditável.

Toda mudança em campo protegido é uma BankAccountChangeProposal: nasce em Draft e, submetida, abre uma instância do motor no processo BANK_ACCOUNT_CHANGE (BankAccount, NoticeContact) ou vai à confirmação por segunda pessoa (ChainContact, RN-FOR-34) — ver RN-FOR-35. O registro vivo permanece intacto até a proposta ser aplicada; "aprovador distinto do solicitante" é a RN-AP-08 do motor, não uma checagem deste módulo. Vale para tela, API e importação. O conjunto de campos protegidos tem núcleo que configuração não reduz (RN-FOR-28), e a única entrada de conta sem instância do motor é a carga inicial de implantação (RN-FOR-31).

A comparação segue o tipo de pessoa. Company compara pela raiz do CNPJ, que é o que permite a filial receber na conta da matriz. MEI compara o documento inteiro e aceita tanto o CNPJ quanto o CPF do titular, que é o ownerCpf gravado na raiz — a conta de MEI é conta de pessoa física no mundo real, e tratá-la como divergência produziria recusa em cem por cento dos MEIs. Individual e RuralProducer comparam o CPF da raiz. Nesses quatro tipos, titular diferente é recusado: holderTaxId que não confere — ou documento devolvido pela resolução da chave PIX no DICT que não confere — responde 422 BANK_HOLDER_MISMATCH_UNPROCESSABLE no :submit da proposta, e a proposta não abre; na carga inicial, a linha é recusada pela mesma regra (RN-FOR-31). Só Foreign, que não tem documento brasileiro a comparar, segue com veredito de nome — holderName contra legalName, em forma normalizada, gravado com fonte e data —: nome que não confere não recusa, grava a flag "titular ≠ fornecedor", que aciona o passo complementar da controladoria semeado no Fluxo, e o comprovante de titularidade continua obrigatório (RN-FOR-35). Não existe exceção fora destas regras. Pagamento a terceiro — cessão de crédito, factoring, FIDC — não entra pela conta do cadastro: é v2 ou tratado no ERP (Fora de escopo). Por quê: pagar a quem não é o fornecedor é o desvio que o controle existe para impedir; o documento do titular brasileiro é verificável, e o que é verificável se recusa em vez de se aprovar com justificativa. Falso positivo crônico continua sendo o modo de morte de um controle — por isso a filial recebe na conta da matriz e o MEI, na conta do empresário.

Sem verificação bem-sucedida no DICT, a chave fica em estado não verificado e não é oferecida como destino de pagamento.

A checagem cobre ativos, rascunhos e cadastros pendentes de aprovação, em todos os caminhos de entrada. Vale igual para a raiz do CNPJ (RN-FOR-33).

Havendo RFQ, pedido, recebimento ou nota, apenas inativação. O DELETE existe só para cadastro em rascunho nunca submetido.

motivo, blockedBy e blockedOn são obrigatórios. Desbloqueio idem. Sem isso, ninguém sabe por que aquele fornecedor está parado há seis meses.

Serve a convite de RFQ e busca. A autorização vem da consulta às qualificações vigentes (RN-FOR-24); ItemSupplier.status é trava adicional por item, quando a relação existe — nunca o gate, porque item sem ItemSupplier não teria gate nenhum.

expectedVersion obrigatório no corpo do PUT, checado antes de tocar o agregado.

IAuditableEntity, categoria Supplier. Além do diff, registrar quem visualizou CPF de quem, e quando — exigência prática da LGPD.

E-mail e telefone de contato com papel Finance só mudam por proposta, pela mesma entidade e pela mesma instância BANK_ACCOUNT_CHANGE, com changeKind = NoticeContact. Tentativa por PUT, por tela ou por importação responde 409 SUPPLIER_CONTACT_PROTECTED_FIELD_CONFLICT; criar contato Finance é a mesma mudança, salvo o contato livre do cadastro ainda não aprovado e o primeiro contato do aviso, que a RN-FOR-34 trata. O resolvedor Previous lê o contato vigente antes da alteração proposta — e, enquanto houver alteração de contato aplicada com usableFrom no futuro, o valor anterior a ela (RN-FOR-34). O aviso sai só por e-mail; o telefone do contato é origem possível do callback (RN-FOR-29), não um segundo canal de aviso. Não havendo contato Finance com e-mail, a cadeia cai para as três posições de reserva da RN-FOR-34 — o contato PortalAdmin, o contato Commercial designado e o contato designado do estabelecimento principal —, nesta ordem, e para nenhum outro contato nem para o e-mail de SupplierAddress; se nenhum e-mail fora do tenant existir, a proposta não abre (422 BANK_CHANGE_NO_EXTERNAL_NOTICE_CHANNEL_UNPROCESSABLE). O administrador do tenant recebe cópia e nunca substitui o fornecedor como destinatário: aviso que não sai da empresa não avisa ninguém. Por quê: sem esta regra o ataque cabe numa sessão — reescrever os contatos, abrir a proposta bancária, receber o próprio aviso.

O contrato de desfecho grava usableFrom = decidedAt + bankChangeGraceHours ao aplicar a proposta. Conta com usableFrom no futuro não entra no pacote enviado ao ERP — a seleção do destino de pagamento filtra por usableFrom <= agora e contestedAt nulo; pedir conta em carência responde 409 BANK_ACCOUNT_NOT_USABLE_YET_CONFLICT, e conta contestada, 409 BANK_ACCOUNT_CONTESTED_CONFLICT. A data não anda para trás, não é editável por PUT e não tem rota de antecipação: uma carência que se pode encurtar sob pressão é a carência que não existe justamente no dia em que ela importa. A conta anterior continua vigente e pagável durante a janela.

A proposta grava noticeSentAt quando o provedor de e-mail aceita o aviso. Nenhuma tarefa da instância é ativada antes de noticeSentAt + minNoticeHours (configuração do tenant, mínimo 12 h, padrão 24): o Fornecedor entrega esse instante ao motor no gancho genérico activationNotBefore, e decidir tarefa ainda não ativada é recusado pelo motor. E-mail devolvido não inicia a janela: a devolução grava noticeBouncedAt (e emailBouncedAt no contato) e o aviso segue para o próximo e-mail da cadeia da RN-FOR-21. Enquanto nenhum passo ativou, o Fornecedor adia activationNotBefore para o novo envio + minNoticeHours pela rota interna POST /approvals/{id}/activation-window do Fluxo (RN-AP-63), que só anda para frente. Sem próximo e-mail, o Fornecedor cancela a instância (POST /approvals/{id}/cancel), a proposta vai a Cancelled e o alerta vai a quem tem approve:supplier-banks. Para o canal morto não virar tranca, a proposta NoticeContact que corrige um e-mail devolvido abre mesmo sem e-mail entregável, com previousNoticeUndeliverable = true: exige callback Confirmed para telefone confiável ou, sem nenhum telefone confiável depois da consulta nova ao provedor, segue a troca de canal sem telefone da RN-FOR-34 — noTrustedPhone, pedido assinado anexado, com o rastro gravado pelo desfecho (RN-FOR-40), e 7 dias de carência —; nos dois casos aciona o complementar da controladoria. Como a devolução pode chegar com as tarefas já ativas, o contrato de desfecho reconfere na decisão que concluiria a instância: sem envio não devolvido há pelo menos minNoticeHours, devolve Refused(BANK_CHANGE_NOTICE_NOT_DELIVERED_CONFLICT) — a decisão não é gravada e a tarefa continua ativa. O aviso existe para dar ao fornecedor legítimo a chance de dizer "não fui eu" antes da troca; disparado e aprovado no mesmo minuto, ele só documenta a fraude. A guarda de ativação vive no motor; a de entrega, no desfecho do Fornecedor.

Emitir pedido exige, cumulativamente: relacionamento SpendAuthorized, processo de cadastro Approved, fornecedor não bloqueado, estabelecimento do fornecedor apto e uma SupplierQualification vigente cujo escopo cubra a categoria de cada linha. A cobertura casa por prefixo de path do nó — qualificado em /SERVICOS/ cobre /SERVICOS/LIMPEZA/, e nunca o contrário. "Vigente" é validTo nulo ou futuro na data de submissão do documento. Linha fora do escopo responde 409 SUPPLIER_NOT_QUALIFIED_FOR_CATEGORY_CONFLICT, nomeando o fornecedor e o nó pedido. Estabelecimento apto é o estabelecimento do fornecedor escolhido no documento — o principal, quando nenhum é escolhido — com vigência Active e, quando tem CNPJ, registrationStatus = Active na última verificação registrada, desde que feita há no máximo 45 dias; Suspended, Unfit, ClosedDown, Null, verificação mais velha que isso ou nenhuma verificação respondem 409 SUPPLIER_ESTABLISHMENT_NOT_ACTIVE_CONFLICT, nomeando o estabelecimento e a situação. A matriz ativa não empresta aptidão à filial baixada, nem o contrário. Pedido já emitido não é afetado — a mudança de situação gera alerta (RN-FOR-05). Quando a última qualificação vence, o relacionamento não é rebaixado — estado não é o gate: o fornecedor segue SpendAuthorized, segue convidável e qualificável, pedidos em aberto seguem vivos, e apenas pedido novo deixa de passar. O aviso é antecipado, a 30, 15 e 5 dias de validTo, e repetido na expiração. Sem isso, aprovar a Beta em limpeza a autorizaria a vender ácido sulfúrico.

SupplierDocument.supplierEstablishmentId é obrigatório quando scope = Establishment e proibido quando scope = Supplier — descumprir responde 400 SUPPLIER_DOCUMENT_ESTABLISHMENT_REQUIRED. Seis dos treze tipos-semente são por estabelecimento; sem a coluna, três alvarás de três filiais são três linhas indistinguíveis e o pacote exigido não sabe dizer que falta o da Bahia. O requisito é resolvido por estabelecimento ativo, e a promessa "filial baixada com a matriz ativa" passa a valer também para a documentação: estabelecimento inativo sai do pacote.

CND/CPEN federal, CRF do FGTS e CNDT não têm consulta automatizada na v1 — as fontes existem, o acesso programático não. Elas são SupplierDocument com número, órgão, emissão e vencimento digitados ou lidos do PDF enviado, e o status continua derivado da data (RN-FOR-06). O aviso dispara antes do vencimento — 30, 15 e 5 dias —, nunca só depois: certidão avisada no dia seguinte ao vencimento é pedido travado sem aviso prévio. A consulta automática entra na v2, pelo mesmo gancho de provedor plugável da consulta ao CNPJ: o provedor devolve número, emissão, vencimento e comprovante, e grava SupplierVerification e SupplierDocument como a entrada manual grava. Até lá, a página diz que não existe, em vez de prometer varredura que ninguém escreveu. Sanções (CEIS, CNEP) seguem automáticas desde a v1, e o bloqueio por certidão vencida segue a política do tipo (RN-FOR-07).

accountKind = Domestic exige ISPB, agência e conta e aceita chave PIX; International exige IBAN ou conta mais código de compensação local, SWIFT/BIC e país, e aceita banco intermediário. Foreign aceita os dois blocos — há fornecedor estrangeiro com conta no Brasil. Company, MEI, Individual e RuralProducer aceitam apenas Domestic na v1. Campo do bloco errado responde 400 SUPPLIER_FIELD_NOT_APPLICABLE, nomeando campo e bloco. Por quê: o produto sustenta Foreign com moeda, incoterm e um módulo de câmbio inteiro — havia onde comprar e não havia onde pagar.

São do núcleo protegido todos os campos de SupplierBankAccount que dizem para onde o dinheiro vai — accountKind, ispb/compeCode, branchNumber/branchCheckDigit/accountNumber/accountCheckDigit, accountType, pixKeyType/pixKey, iban, swiftBic, bankCountryCode, bankName, routingCodeType, intermediaryBankSwiftBic/intermediaryBankName, holderName/holderTaxId — e o e-mail e o telefone de todo contato com papel Finance. Ficam fora só os campos gerados (validFrom/validTo, holderVerification, usableFrom, contestedAt). O núcleo muda só por proposta, em tela, API e importação; a importação aceita Propose ou Reject para campo protegido, e não existe terceiro valor. O tenant pode acrescentar campos protegidos fora do núcleo, na configuração protectedSupplierFields; a lista nunca retira campo do núcleo. Mudar essa lista é ato de controle: grava o registro do ato na mesma transação, com autor, antes e depois; publica supplier-protected-fields.changed depois do commit; e avisa obrigatoriamente todos os que têm approve:supplier-banks. Por quê: controle que um administrador desliga sozinho, sem ninguém saber, é preferência, não controle.

O callback é ligação de saída, feita pelo comprador para um telefone confiável do fornecedor, falando com a pessoa responsável por ele. Telefone confiável é, e só é: AgedContactPhone — phone ou mobile de contato ativo com papel Finance ou numa posição da cadeia de reserva do aviso (PortalAdmin, Commercial designado, contato designado do estabelecimento principal — RN-FOR-34), com pelo menos 30 dias até a submissão da proposta, contados do mais tarde entre a gravação do número (phoneRecordedAt, mobileRecordedAt) e a entrada do contato em Finance ou na cadeia (noticeChainSince), reativação inclusa; ou RegistryLookup — telefone devolvido pela consulta mais recente ao CNPJ feita pelo provedor, gravada em SupplierVerification com fonte e data, que, quando uma consulta anterior do mesmo CNPJ devolveu outro telefone ou nenhum, só vale 30 dias depois da primeira consulta que o devolveu. Contato fora dessas posições não é fonte — Technical, Quality, Tax e o Commercial não designado —, qualquer que seja a idade do número: são gravados pelo PUT livre de contatos, sem segunda pessoa, e um número plantado ali hoje valeria como callback daqui a 30 dias; pela mesma razão, o número que um desses contatos já tinha só começa a contar quando ele entra em Finance ou na cadeia. Verificação manual de CNPJ nunca é fonte de telefone, e quem é proponente de proposta do fornecedor em Draft ou Open não registra verificação manual dele (409 SUPPLIER_VERIFICATION_BY_PROPONENT_CONFLICT). Pessoas ligadas ao número: quem o gravou (phoneRecordedByUserId e equivalentes); quando o número entrou por alteração de contato (phoneChangeProposalId e equivalentes), quem propôs, quem confirmou (confirmedByUserId), quem registrou o callback e quem decidiu na instância daquela proposta; quando entrou pela carga inicial, quem enviou e quem confirmou o lote — o contato da carga guarda em phoneChangeProposalId e equivalentes a proposta origin = InitialLoad da linha (RN-FOR-31); e as mesmas pessoas da proposta que pôs o contato em Finance ou na cadeia (noticeChainProposalId). A comparação é por usuário e por CPF verificado (RN-FOR-36). Número fora das duas fontes não é telefone confiável, e número ligado ao proponente não serve à proposta dele: registrar callback para qualquer dos dois responde 422 BANK_CHANGE_CALLBACK_PHONE_NOT_TRUSTED_UNPROCESSABLE. Separação: quem registra tem approve:supplier-banks, não é o proponente e não é pessoa ligada ao número usado (409 BANK_CHANGE_APPROVER_IS_REQUESTER_CONFLICT). O registro — POST /suppliers/{id}/change-proposals/{pid}:record-callback, só em proposta Open, de qualquer changeKind — grava número, origem, o contato ou a verificação de onde o número saiu (callbackSourceId), quem ligou, quando, com quem falou, resultado e callbackDataHash, uma vez só (409 BANK_CHANGE_CALLBACK_ALREADY_RECORDED_CONFLICT); tentativa sem atendimento vai à trilha como supplier-bank-change-proposal.callback-attempted. Na decisão que concluiria a instância — ou, em ChainContact, na confirmação (RN-FOR-34) — o Fornecedor exige callbackResult = Confirmed com callbackDataHash igual ao dataHash da proposta; faltando, o contrato de desfecho devolve Refused(BANK_CHANGE_CALLBACK_REQUIRED_CONFLICT) — a decisão não é gravada e a tarefa continua ativa — e a confirmação responde 409 com o mesmo código. Denied contesta a proposta (RN-FOR-30). Nunca se conclui "sem telefone" sem perguntar: na submissão, sem AgedContactPhone elegível e não ligado ao proponente, o Fornecedor faz uma consulta nova ao provedor pelo CNPJ do estabelecimento principal e a grava; provedor indisponível recusa a submissão (503 BANK_CHANGE_REGISTRY_LOOKUP_UNAVAILABLE), e fornecedor sem CNPJ (Individual, RuralProducer, Foreign) não tem consulta a fazer. Número descartado só por estar ligado ao proponente nunca vale como falta de telefone: se, depois da consulta, os únicos telefones que seriam confiáveis estão ligados a ele, a submissão — de conta ou de canal — é recusada com 409 BANK_CHANGE_APPROVER_IS_REQUESTER_CONFLICT, nada é gravado e noTrustedPhone não nasce; a troca recomeça por proposta de pessoa não ligada ao número. Só sem nenhum telefone confiável, ligado ou não, o sistema grava noTrustedPhone = true, que o motor recebe como flag e que aciona o passo complementar da controladoria semeado no Fluxo; aí o callback não é exigido e a prova documental toma o lugar dele: na proposta BankAccount, a titularidade (RN-FOR-35), que é obrigatória de qualquer jeito; na proposta de canal — NoticeContact ou ChainContact —, que não tem conta a comprovar, o pedido de troca assinado pelo fornecedor anexado, com o rastro gravado pelo desfecho e sem conferência do documento (RN-FOR-40), e a carência de 7 dias da RN-FOR-34. A flag é calculada, nunca declarada por quem propõe. Consentimento do contato não é condição: a base é prevenção a fraude.

Toda proposta Standard, de qualquer changeKind, emite um token de contestação — aleatório, com pelo menos 128 bits, guardado só como hash — em cada e-mail ao canal anterior: o aviso da proposta e o aviso de aplicação. Cada emissão invalida a anterior. O token vale até a proposta ficar Rejected ou Cancelled, ou até 30 dias depois de usableFrom, e é de uso único. O link abre uma página sem login que mostra o nome do comprador, a espécie da mudança e a data da proposta — nunca a conta nem o contato propostos — e um único ato, POST /portal/bank-change-contests, com o token no corpo — o link o leva no fragmento, que não chega a log nenhum —, sem permissão e sem sessão, declarado no Portal do Fornecedor. Token desconhecido, usado ou vencido responde o mesmo 401 BANK_CHANGE_CONTEST_TOKEN_INVALID_UNAUTHORIZED, sem dizer qual dos três. A contestação também entra por dentro, e aí é ato de controle com segunda pessoa: quem tem read:supplier-banks registra, com nota, a ligação ou a mensagem recebida por canal independente (POST /suppliers/{id}/change-proposals/{pid}:contest), e a contestação só produz efeito quando outra pessoa — outro usuário e outra chave de pessoa, também com read:supplier-banks — confirma pela mesma rota; até lá fica registrada e sem efeito, e a mesma pessoa confirmando responde 409 SUPPLIER_CONTACT_CONTEST_SECOND_PERSON_REQUIRED_CONFLICT. As duas pontas são de controle: quem registra e quem confirma precisam de identidade verificada com CPF único por tenant (RN-FOR-36) — sem ela, 409 SUPPLIER_CONTACT_CONTEST_IDENTITY_NOT_VERIFIED_CONFLICT, e nada é gravado —, e conceder read:supplier-banks é ato de controle, com registro e aviso (RN-FOR-36). Por quê: exigida só a permissão de leitura, dois usuários criados na hora revertiam qualquer troca legítima de canal e travavam todas as propostas do fornecedor — negação de serviço com duas contas. A contestação pelo link não precisa de segunda pessoa — quem a faz é o fornecedor — e o callback com Denied contesta sozinho. Efeito, na mesma transação: proposta Open vai a Contested e a instância, quando há, é cancelada (POST /approvals/{id}/cancel, como a definição do BANK_ACCOUNT_CHANGE no Fluxo prevê); proposta de contato Applied segue a RN-FOR-38; proposta de conta Applied vai a Contested, a conta criada por ela ganha contestedAt e deixa de ser destino de pagamento, e a versão anterior não é reaberta — é esta a suspensão da proposta aplicada que o Fluxo deixa ao Fornecedor, e não existe outra. Pela rota interna, contestar proposta em estado final responde 409 BANK_CHANGE_PROPOSAL_NOT_CONTESTABLE_CONFLICT. Contested é final: troca legítima contestada por engano recomeça por proposta nova, com aviso, janela e callback. Depois do commit sai supplier-bank-change-proposal.contested, com aviso obrigatório a quem tem approve:supplier-banks e ao administrador do tenant. Por quê: janela sem porta de saída é espera, não controle.

É a única entrada de conta sem instância do motor. 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:supplier-banks (POST /suppliers/bank-accounts:close-initial-load), ou 60 dias corridos da criação do tenant; o fechamento grava bankInitialLoadClosedAt na configuração do tenant, ao lado de bankChangeGraceHours. Fora da janela, 409 BANK_INITIAL_LOAD_WINDOW_CLOSED_CONFLICT. Alcance: só fornecedor sem nenhuma SupplierBankAccount e sem proposta Open — a carga nunca substitui conta existente; linha fora disso responde 409 BANK_INITIAL_LOAD_SUPPLIER_HAS_ACCOUNT_CONFLICT, e o lote inteiro não grava. Linha cujo titular não confere com o fornecedor responde 422 BANK_HOLDER_MISMATCH_UNPROCESSABLE (RN-FOR-13), com a mesma consequência. A linha pode trazer os contatos Finance do fornecedor, que entram sob a mesma dupla custódia, sem virar proposta, com phoneSource = InitialLoad, a proposta da linha em phoneChangeProposalId e equivalentes, e o relógio de confiança começando na confirmação; quem enviou e quem confirmou o lote são pessoas ligadas a esses números (RN-FOR-29). Cada conta carregada precisa de evidência antes da confirmação: comprovante de titularidade (tipo de anexo BANK_OWNERSHIP_PROOF) anexado à proposta que a linha criou — a BankAccountChangeProposal com origin = InitialLoad é a dona do anexo, e é a única proposta fora de Draft que aceita anexo, só até a confirmação do lote —, ou callback Confirmed para telefone devolvido pela consulta ao CNPJ feita pelo provedor; a confirmação pergunta ao Anexo pelo veredito de cada comprovante, como a submissão pergunta: a lista dos estados é contrato desta página, completa e final, e o Anexo a copia literalmente. Conta como falta de evidência — 409 BANK_INITIAL_LOAD_EVIDENCE_MISSING_CONFLICT, listando as linhas e o estado de cada uma, e nada é gravado: linha sem comprovante e sem callback Confirmed; comprovante revogado; arquivo eliminado; veredito Infected; anexo em estado reprovado pelo contrato do dono; veredito Failed; e reserva de envio Reserved ainda confirmável, que é anexo sem arquivo e pode expirar sem nunca virar um. Conta como espera, e só quando não há nenhuma falta desta lista: Pending e Scanning, as duas fases da varredura, que recusam a confirmação com o 409 do Anexo, ATTACHMENT_SCAN_PENDING_CONFLICT, que esta página cita e não redefine. Failed é falta, não espera: o veredito diz que a varredura não concluiu, sair dele depende de um ato de alguém (:rescan, do Anexo) que ninguém é obrigado a fazer, e confirmar lote à espera desse ato deixaria a janela de 60 dias correr contra o controle; o caminho é varredura nova liberada, ou comprovante novo, e a confirmação repetida. Ao Anexo, o descritor responde pela proposta InitialLoad StateOf = InProgress — ela nasce Open, nunca Draft — e aceita escrita de anexo até a confirmação ou o cancelamento do lote; depois, fecha como toda proposta submetida (RN-FOR-35). Dupla custódia: quem tem propose:supplier-banks e identidade verificada (RN-FOR-36) envia o arquivo por POST /suppliers/bank-accounts:initial-load, com dryRun=true obrigatório antes; sem dryRun, as linhas são gravadas como BankAccountChangeProposal com origin = InitialLoad, status = Open, o mesmo initialLoadBatchId e o hash do arquivo. Outra pessoa, com approve:supplier-banks e identidade verificada (RN-FOR-36), confirma por POST /suppliers/bank-accounts:confirm-initial-load informando lote e hash — o do arquivo somado aos identificadores dos comprovantes anexados, que a tela de confirmação mostra —; pessoa igual — mesmo usuário ou mesmo CPF verificado — responde 409 BANK_CHANGE_APPROVER_IS_REQUESTER_CONFLICT, hash diferente 409 BANK_INITIAL_LOAD_HASH_MISMATCH_CONFLICT. A confirmação grava confirmedByUserId nas propostas do lote e aplica o lote inteiro numa transação — usableFrom = confirmação + bankChangeGraceHours, verificação de titularidade e alertas de padrão como em qualquer conta —, fecha a janela, grava o registro do ato de controle e publica supplier-bank-accounts.initial-loaded depois do commit, com contagem e hash. A primeira conferência com o ERP (RN-FOR-32) roda logo depois. Lote não confirmado quando a janela fecha vai a Cancelled. A primeira carga em produção depende do requisito de identidade verificada da demanda de plataforma (RN-FOR-36).

A conta do fornecedor é gravada, versionada e decidida no Nexio, e é o Nexio que a envia ao ERP; o ERP não é fonte de conta. Uma conferência diária por tenant, em horário configurável, lê do ERP, para cada fornecedor integrado, o destino de pagamento ativo e o compara com a conta utilizável no Nexio (usableFrom <= agora, contestedAt nulo) — ISPB, agência e conta, ou chave PIX, ou IBAN, conforme o bloco. Cada conferência grava uma SupplierVerification com fonte ErpBankAccount e resultado Match | Divergent | Unavailable. Divergent abre alerta de segurança com aviso obrigatório, por InApp e Email, a todos os que têm approve:supplier-banks e ao administrador do tenant; o alerta se repete a cada conferência enquanto a divergência durar, e o próximo pacote ao ERP reenvia a conta do Nexio. O Nexio não adota a conta do ERP: se a troca lá foi legítima, o caminho é proposta aqui. Unavailable — adaptador sem leitura, ERP fora do ar — é gravado como tal, nunca como conferido, e três dias seguidos sem conferência também geram o alerta. A conferência depende de o adaptador de ERP expor a leitura do destino de pagamento: sem ela, a primeira integração de pagamento não vai a produção.

cnpjRoot é único por tenant onde não nulo, verificado contra ativos, rascunhos e pendentes em todos os caminhos de entrada. Criar fornecedor com raiz existente responde 409 SUPPLIER_DUPLICATE_CONFLICT; para usuário interno, a resposta traz o fornecedor existente e a oferta de adicionar o estabelecimento. Todo estabelecimento com CNPJ tem os oito primeiros caracteres iguais a Supplier.cnpjRoot; estabelecimento de outra raiz responde 409 SUPPLIER_ESTABLISHMENT_ROOT_MISMATCH_CONFLICT — pessoa jurídica diferente é fornecedor diferente, ligado, se for o caso, por parentSupplierId. A raiz é imutável; cadastro com raiz errada se corrige inativando o fornecedor e cadastrando outro. parentSupplierId não aponta para fornecedor da mesma raiz nem forma ciclo (400 SUPPLIER_PARENT_INVALID). A comparação de titular pela raiz (RN-FOR-13) e o alerta de conta repetida entre fornecedores leem a raiz, nunca o grupo: conta da controladora não é conta da controlada.

E-mail, phone e mobile de contato Finance mudam por proposta NoticeContact, na instância BANK_ACCOUNT_CHANGE (RN-FOR-21). A cadeia de reserva do aviso tem três posições, e só elas: o contato com papel PortalAdmin (exatamente um ativo); o contato Commercial designado (noticeChainSlot = DesignatedCommercial, no máximo um ativo, com o papel Commercial); e o contato do estabelecimento principal, que é o contato designado com noticeChainSlot = PrincipalEstablishment — no máximo um ativo, vinculado ao estabelecimento principal pelo supplierEstablishmentId. Os demais contatos Commercial são livres e nunca são fonte de telefone confiável nem canal de aviso; phone e email de SupplierAddress também não. E-mail e telefones dos contatos da cadeia mudam por alteração protegida de contato, changeKind = ChainContact, sem instância do motor salvo nos casos desta regra e da RN-FOR-38. As duas nascem pela mesma rota, POST /suppliers/{id}/contacts/change-proposals, em Draft, e o changeKind é calculado pelos papéis do contato antes e depois da mudança — Finance em qualquer dos lados é NoticeContact, salvo no primeiro contato do aviso —, nunca declarado. Vale para tela, PUT /suppliers/{id}/contacts (409 SUPPLIER_CONTACT_PROTECTED_FIELD_CONFLICT) e importação; criar, inativar, reativar, dar e tirar um desses papéis ou designar e retirar uma posição é a mesma alteração, e a proposta que põe um contato em Finance ou na cadeia leva o e-mail e os telefones dele no dataHash. Sem telefone confiável, a troca de canal vai à instância com pedido assinado: na submissão procura-se AgedContactPhone elegível e não ligado ao proponente e, faltando, faz-se a consulta nova ao provedor (RN-FOR-29); número que só falta por estar ligado ao proponente recusa a submissão, como lá. Não havendo telefone confiável, a proposta — NoticeContact ou ChainContact — grava noTrustedPhone = true e abre a instância BANK_ACCOUNT_CHANGE com o complementar da controladoria semeado no Fluxo; o callback não é exigido e, no lugar dele, a submissão exige anexo à proposta do tipo SIGNED_CONTACT_CHANGE_REQUEST — o pedido de troca do próprio fornecedor, na forma que a norma da empresa exigir, que o sistema exige mas não confere (RN-FOR-40) — com veredito do antivírus Available. Sem ele, 422 SUPPLIER_CONTACT_CHANGE_NO_TRUSTED_PHONE_UNPROCESSABLE, e anexo ainda em varredura segue o 409 do Anexo. O veredito do antivírus não confere a assinatura, e a decisão também não: a troca é aplicada com o anexo exigido e o rastro gravado pelo desfecho — o anexo, quem o anexou e quando, quem decidiu e quando (RN-FOR-40). Aplicada, essa troca tem usableFrom = aplicação + 7 dias, qualquer que seja bankChangeGraceHours. Confirmação do ChainContact: a submissão avisa por e-mail o endereço anterior, com link de contestação (RN-FOR-30); e-mail devolvido grava noticeBouncedAt e o aviso segue ao próximo e-mail da cadeia, como na RN-FOR-23. A proposta só é aplicada quando outra pessoa, com approve:supplier-banks, a confirma por POST /suppliers/{id}/change-proposals/{pid}:confirm (ou recusa por :reject), gravando confirmedByUserId e confirmedAt. A confirmação exige, na hora: envio sem devolução há pelo menos minNoticeHours — antes disso, 409 SUPPLIER_CONTACT_CHANGE_WINDOW_NOT_ELAPSED_CONFLICT; só com envios devolvidos, 409 BANK_CHANGE_NOTICE_NOT_DELIVERED_CONFLICT — e callback Confirmed para telefone confiável com o dataHash da proposta (409 BANK_CHANGE_CALLBACK_REQUIRED_CONFLICT); confirmador igual ao proponente, 409 BANK_CHANGE_APPROVER_IS_REQUESTER_CONFLICT. Sem próximo e-mail na cadeia, a proposta vai a Cancelled, e o canal morto se corrige como na RN-FOR-23, pela instância, com previousNoticeUndeliverable. Aplicada, a alteração de contato — das duas espécies — grava usableFrom = aplicação + bankChangeGraceHours — ou aplicação + 7 dias, com noTrustedPhone — na proposta, e o aviso de aplicação vai ao endereço anterior com novo link de contestação (RN-FOR-38); até usableFrom, o aviso bancário do fornecedor continua indo ao valor anterior. Todo número gravado e toda entrada na cadeia reiniciam o relógio de confiança: o número novo só é telefone confiável 30 dias depois de aplicado, e o contato guarda de qual proposta ele veio (phoneChangeProposalId, mobileChangeProposalId, emailChangeProposalId); o contato que entra em Finance ou numa posição da cadeia — criado, com papel ou posição dada, ou reativado — grava noticeChainSince e noticeChainProposalId, e os números que ele já tinha contam dali. Contato livre só antes da aprovação: enquanto o cadastro está em Draft ou UnderReview, nunca foi Approved e não há proposta do fornecedor fora de Draft, contato Finance ou da cadeia é criado e editado pelo PUT, e o relógio conta da gravação. Depois — fornecedor migrado incluso —, o primeiro contato do aviso (fornecedor sem contato ativo Finance nem em posição da cadeia) é ChainContact, qualquer que seja o papel: sem endereço anterior não há aviso nem janela, e a confirmação por segunda pessoa exige callback Confirmed para o telefone do RegistryLookup da consulta nova; sem telefone ali, segue a instância com pedido assinado desta regra. Por quê: um colega honesto que cadastra o celular que o fraudador mandou por e-mail planta o telefone do callback sem saber; o relógio, a segunda pessoa e a ligação para o número que já se conhecia são o que separa as duas coisas.

As rotas de criação de proposta criam em Draft, editável só pelo proponente (PUT /suppliers/{id}/change-proposals/{pid}) e descartável (DELETE, só em Draft); do rascunho não sai aviso, token nem instância. Submeter (POST /suppliers/{id}/change-proposals/{pid}:submit) exige, na proposta BankAccount que inclui ou substitui conta, comprovante de titularidade anexado à proposta, no tipo de anexo BANK_OWNERSHIP_PROOF — documento do banco que mostra o titular com o documento que a RN-FOR-13 compara (a raiz do CNPJ em Company) — com veredito do antivírus Available; sem ele, 409 BANK_CHANGE_OWNERSHIP_EVIDENCE_REQUIRED_CONFLICT, e anexo ainda em varredura segue o 409 do Anexo. A consulta automática de titularidade é gancho de provedor; o DICT, quando resolve a chave PIX, soma à evidência e não a substitui. Na submissão o Fornecedor, nesta ordem: recusa proponente sem identidade verificada (RN-FOR-36); recusa fornecedor com propostas de conta travadas (RN-FOR-38); compara o titular e recusa o que não confere (RN-FOR-13); procura telefone confiável, com consulta nova ao provedor quando falta, e recusa o que só falta por estar ligado ao proponente (RN-FOR-29); grava submittedAt e dataHash; calcula as flags; emite o aviso; e abre a instância com o proponente e as pessoas ligadas por correção de identidade entre os excluídos (RN-AP-60 do Fluxo; RN-FOR-41) — ou, em ChainContact fora de bloqueio e com telefone confiável, só avisa (RN-FOR-34). Depois de submetida a proposta é imutável: PUT e DELETE respondem 409 BANK_CHANGE_PROPOSAL_IMMUTABLE_CONFLICT; anexo novo e revogação de anexo, que são rotas do Anexo, respondem o código dele, 409 ATTACHMENT_OWNER_NOT_WRITABLE_CONFLICT, porque o descritor da proposta a declara fechada à escrita. A prova precisa continuar de pé na decisão: na decisão que concluiria a instância, o contrato de desfecho pergunta ao Anexo pelo comprovante de titularidade ou pelo pedido assinado que a submissão exigiu; revogado, eliminado ou com veredito que deixou de ser Available — Infected depois de nova varredura —, devolve Refused(BANK_CHANGE_EVIDENCE_NOT_AVAILABLE_CONFLICT): a decisão não é gravada, a tarefa continua ativa e o caminho é rejeitar e abrir proposta nova. O Anexo, por sua vez, recusa eliminar anexo de dono com aprovação em curso. Depois da aplicação, a prova que cai não passa em branco: comprovante de titularidade ou pedido assinado que é revogado, eliminado, reprovado ou vai a Infected depois de a conta ser aplicada — ou depois da confirmação do lote da carga inicial (RN-FOR-31) — abre um SupplierComplianceAlert de kind = BankEvidenceLost com a conta, a proposta e o anexo (RN-FOR-37), e a conta deixa de ser destino de pagamento até a decisão do alerta, como contestedAt a faz (RN-FOR-22); a proposta não é revertida e a conta anterior não é reaberta. Decidido o alerta, ou a conta volta com evidência nova anexada a uma proposta nova, ou é encerrada. Não é botão de negação de serviço: revogar ou eliminar prova de controle já passa pela dupla custódia do Anexo. A prova de ato de controle sem conta também não passa em branco: o pedido assinado SIGNED_CONTACT_CHANGE_REQUEST de troca de canal já aplicada (RN-FOR-40) e o comprovante IDENTITY_CORRECTION_PROOF de correção de identidade já aplicada (RN-FOR-39) que são revogados, eliminados, reprovados ou vão a Infected depois da aplicação abrem um SupplierComplianceAlert de kind = ControlEvidenceLost e source = Attachment, com o fornecedor, a proposta ou a instância, e o anexo (RN-FOR-37). Efeito, na mesma transação: na troca de canal, o valor trocado deixa de ser canal de aviso e fonte de telefone confiável e o fornecedor ganha bankProposalsBlockedAt, como na contestação (RN-FOR-38), até a decisão do alerta; na correção de identidade, a identidade não é desfeita — ela já passou pelas unicidades do cadastro —, e a conta vigente cujo titular só confere com a identidade corrigida, e não conferiria com a anterior pelo regime da RN-FOR-13, deixa de ser destino de pagamento até a decisão. Aviso obrigatório, por InApp e Email, a quem tem approve:supplier-banks, a quem tem verify:suppliers e ao administrador do tenant. Por quê: era justamente o rastro que sustentava o risco aceito de não conferir o documento — anexo que desaparece sem alerta desfaz a mitigação inteira. BANK_ACCOUNT_CHANGE não tem devolução — só aprova ou rejeita (Fluxo, RN-AP-61): corrigir é rejeitar e abrir proposta nova, com aviso, janela, callback e carência novos. Callback e titularidade valem para o dataHash com que foram registrados, e só para ele. A primeira conta do fornecedor segue este mesmo caminho: não existe conta nascida no cadastro, e o SUPPLIER_REGISTRATION não aplica dado bancário. Trocar isDefault ou encerrar conta (deactivate) também é proposta, porque muda o destino do pagamento.

GET /suppliers/{id}/bank-accounts e GET /suppliers/{id}/change-proposals devolvem agência, conta, chave PIX e IBAN mascarados, salvo para quem tem read-unmasked:supplier-banks; o aprovador com tarefa ativa na instância vê o diff sem máscara daquela proposta, e só dela. Quem lê os anexos da conta e da proposta — o comprovante de titularidade e o pedido assinado — é esta lista, e só ela, que o descritor do Anexo implementa no CanRead e copia literalmente: (1) quem tem read-unmasked:supplier-banks, sempre; (2) em proposta origin = Standard, o proponente, com a proposta em Draft ou Open, e quem tem tarefa ativa ou já decidida na instância daquela proposta; (3) em proposta origin = InitialLoad, antes da confirmação do lote, o remetente e quem tem approve:supplier-banks com identidade verificada e não é o remetente — nem pelo usuário, nem pelo CPF —; depois da confirmação, só o confirmador. Ninguém mais. Conceder a papel ou a usuário approve:supplier-banks, propose:supplier-banks, read-unmasked:supplier-banks ou read:supplier-banks — esta última porque é ela que registra e confirma a contestação por dentro (RN-FOR-30) — é ato de controle: registro do ato e aviso obrigatório a todos os que já têm approve:supplier-banks, ao administrador do tenant e ao contato contratual do tenant — quem assinou o contrato com a R&G —, que está fora do alcance de quem administra o tenant. Quem recebe approve:supplier-banks ou propose:supplier-banks precisa de identidade verificada, com CPF único por tenant: dois usuários com o mesmo CPF são uma pessoa, e não somam as duas de um quórum nem fazem as duas pontas de uma separação. Do lado de quem propõe, o :submit de proposta — de conta ou de contato — e o envio da carga inicial (:initial-load sem dryRun) respondem 409 BANK_PROPOSER_IDENTITY_NOT_VERIFIED_CONFLICT para usuário sem identidade verificada, e nada é gravado. Do lado de quem aprova, as ações dessa permissão no Fornecedor — registrar callback, confirmar alteração de contato, confirmar ou fechar a carga inicial — respondem 409 BANK_APPROVER_IDENTITY_NOT_VERIFIED_CONFLICT para usuário sem identidade verificada; e todo decisor de instância BANK_ACCOUNT_CHANGE — do quórum e do complementar da controladoria, qualquer que seja a permissão que o pôs no passo — precisa de identidade verificada e é comparado por CPF com o proponente e com as pessoas ligadas ao número usado no callback: na decisão que concluiria a instância, o contrato de desfecho devolve Refused com o mesmo código quando alguma decisão não vem de CPF verificado ou os CPFs não são distintos entre si e do proponente, e Refused(BANK_CHANGE_APPROVER_IS_REQUESTER_CONFLICT) quando alguma decisão vem do CPF de pessoa ligada ao número do callback (RN-FOR-29). A separação entre pessoas é por CPF nas duas pontas: aprovador, confirmador ou autor do callback que tem o CPF do proponente, do remetente da carga ou de pessoa ligada ao número (RN-FOR-29) é a mesma pessoa, com outro usuário, e a ação responde 409 BANK_CHANGE_APPROVER_IS_REQUESTER_CONFLICT. A concessão acontece no GrydAuth, e os dois mecanismos são requisitos da demanda de plataforma: a publicação da mudança de papel e de permissão bloqueia a primeira proposta bancária em produção; a identidade verificada com CPF único bloqueia a primeira carga e a primeira proposta bancária em produção (RN-FOR-31, RN-FOR-35).

Toda varredura que encontra algo novo abre um SupplierComplianceAlert — supplierId, supplierEstablishmentId?, kind = Sanction | RegistrationStatusChanged | ErpBankDivergence | VerificationStale | BankEvidenceLost | ControlEvidenceLost, source (CEIS | CNEP | CEPIM | Leniency | TcuIneligible | Cnia | SlaveLabor | OfacSdn | Receita | ErpBankAccount | Attachment), a SupplierVerification que o originou, status = Open | Decided | Resolved, decision = KeepWithJustification | FalsePositive | Blocked, decisionNote, decidedByUserId, decidedAt. Existe um alerta aberto por fornecedor, tipo, fonte e registro de origem: a varredura seguinte que acha o mesmo registro não duplica, e a que não o acha mais o leva a Resolved por sistema. Os dois alertas de prova perdida — BankEvidenceLost e ControlEvidenceLost, os dois com source = Attachment — não vêm de varredura: nascem do aviso do Anexo quando o veredito de um anexo de prova de controle muda depois do fechamento do dono, o registro de origem é o anexo, e só a decisão os fecha. A decisão é POST /supplier-compliance-alerts/{aid}:decide, com verify:suppliers e justificativa obrigatória; Blocked só é aceito com o fornecedor já bloqueado pela rota própria (409 SUPPLIER_COMPLIANCE_DECISION_NOT_BLOCKED_CONFLICT) — o alerta registra, o bloqueio é o ato. Lista: GET /supplier-compliance-alerts (read:suppliers, filtro por status, kind, fornecedor). Periodicidade: sanções (CEIS, CNEP, CEPIM, leniência, TCU, CNIA, OFAC) toda semana sobre os fornecedores ativos e na submissão de toda qualificação; lista suja do MTE a cada publicação; situação cadastral pelo menos a cada 30 dias (RN-FOR-24); conferência com o ERP todo dia (RN-FOR-32). Certidão vencida não é alerta: é status derivado da data, com aviso antecipado (RN-FOR-26). O aviso do alerta aberto é o de conformidade da Notificação. Sanção nunca bloqueia sozinha (RN-FOR-10).

A alteração de contato aplicada — NoticeContact ou ChainContact — leva ao endereço anterior o aviso de aplicação com usableFrom e token de contestação, que vale até 30 dias depois de usableFrom, com as regras de token da RN-FOR-30 e pela mesma rota POST /portal/bank-change-contests. Contestada — pelo link ou por dentro (:contest) —, acontece na mesma transação: (1) o contato volta ao valor anterior guardado na proposta, com a origem, a data e o autor que aquele valor tinha — o relógio de confiança dele não reinicia; (2) a proposta vai a Contested e o valor novo fica não confiável: nunca é telefone confiável nem canal de aviso do fornecedor, e gravá-lo de novo em contato dele por outro caminho que não o do item 4 responde 409 SUPPLIER_CONTACT_VALUE_CONTESTED_CONFLICT; (3) o fornecedor ganha bankProposalsBlockedAt e bankProposalsBlockedByProposalId — criar ou submeter proposta BankAccount responde 409 BANK_CHANGE_SUPPLIER_CHANNEL_CONTESTED_CONFLICT, as propostas do fornecedor em Draft ou Open, de conta e de contato, são canceladas (a instância, quando há, pelo cancel do motor) e a conta aplicada depois da aplicação da mudança contestada ganha contestedAt (RN-FOR-22); (4) o bloqueio só cai com uma nova troca de canal — que pode reconfirmar o valor restaurado — decidida na instância BANK_ACCOUNT_CHANGE com a flag contestedChannel, que aciona o passo complementar da controladoria semeado no Fluxo; enquanto o bloqueio durar, também a proposta ChainContact abre essa instância, em vez de ir à confirmação da RN-FOR-34. O desfecho que aplica essa proposta limpa o bloqueio na mesma transação. Depois do commit sai supplier-bank-change-proposal.contested, com o changeKind, e o aviso obrigatório vai a quem tem approve:supplier-banks e ao administrador do tenant. Canal já comprometido suspende, não reverte: quando a mudança contestada veio de proposta com a flag contestedChannel — o fornecedor já tinha contestado antes — ou de proposta com signedRequest gravado (RN-FOR-40), os itens (1) e (2) não restauram o valor anterior: na mesma transação a mudança fica suspensa — valor anterior e valor novo, os dois, deixam de ser canal de aviso e fonte de telefone confiável —, o fornecedor ganha o bloqueio do item (3), e o caso vai ao passo complementar da controladoria, na instância BANK_ACCOUNT_CHANGE com a flag contestedChannel, que decide com a evidência qual valor vale — o anterior, o novo, ou nenhum dos dois, caso em que o fornecedor fica sem canal e aí só se sai pela RN-FOR-23. Só o desfecho dessa instância restaura um valor e limpa o bloqueio; a suspensão não cai por decurso de prazo. Por quê: contestação que só marca a proposta deixa o contato do fraudador no lugar — e é para ele que iriam o próximo aviso e o próximo callback.

Com o cadastro Approved, entityType, cpf, ownerCpf e, em Foreign, legalName e o par foreignTaxId/taxIdCountry — o documento e o nome contra os quais a RN-FOR-13 compara o titular da conta — não mudam por PUT, tela nem importação: 409 SUPPLIER_IDENTITY_IMMUTABLE_CONFLICT. A raiz do CNPJ já é imutável desde a criação (RN-FOR-33), e nenhuma correção carrega CNPJ. O que a correção alcança: cpf de Individual e RuralProducer; ownerCpf de MEI; legalName e foreignTaxId/taxIdCountry de Foreign; e entityType só entre tipos que não mudam a existência do CNPJ — Individual ↔ RuralProducer, e Company ↔ MEI com o mesmo cnpjRoot, levando o ownerCpf quando o destino é MEI. Qualquer outra troca de tipo — entre tipo com CNPJ e tipo sem CNPJ, ou de e para Foreign — responde 422 SUPPLIER_IDENTITY_CORRECTION_TYPE_CHANGE_UNPROCESSABLE, com a orientação: é fornecedor novo, e o antigo é inativado. A ligação acompanha o sucessor: esse fornecedor novo é criado com supersedesSupplierId apontando para o antecessor inativado do mesmo tenant — um sucessor por antecessor, sem ciclo, imutável depois da criação; antecessor ativo, de outro tenant, já sucedido ou em ciclo responde 422 SUPPLIER_SUCCESSOR_NOT_ELIGIBLE_UNPROCESSABLE — e nasce com o identityCorrectionLinkedPeople do antecessor, com a mesma instância de origem e a mesma data, sem prazo (RN-FOR-41). E quem está ligado a um fornecedor inativado não cria fornecedor: POST /suppliers por pessoa ligada — pelo usuário ou pela chave de pessoa — responde 409 SUPPLIER_CREATE_IDENTITY_CORRECTION_LINKED_CONFLICT, e quem cria o sucessor é outra pessoa. Risco aceito e registrado: um terceiro que cria o sucessor sem declarar o antecessor apaga a ligação; contra isso ficam o ato registrado com o autor, a orientação desta recusa, que nomeia o campo, e o controle bancário inteiro no fornecedor novo — aviso ao canal anterior, telefone confiável, callback e quórum de pessoas distintas. Por quê: sem isso a troca de tipo de pessoa lavava a ligação — o fornecedor novo nascia sem ninguém ligado, e quem decidiu a correção propunha nele a conta do laranja. A correção é pedida por POST /suppliers/{id}:correct-identity, com update:suppliers e justificativa: grava os valores propostos em pendingIdentityCorrection — um pedido por vez, 409 SUPPLIER_IDENTITY_CORRECTION_PENDING_CONFLICT — e abre instância SUPPLIER_REGISTRATION com a flag identityCorrection, que aciona o passo complementar da controladoria semeado no Fluxo; quem pediu fica entre os excluídos (RN-AP-60 do Fluxo), e quem pede e quem decide seguem a RN-FOR-41. A decisão exige anexo comprobatório: o pedido nasce com um anexo do tipo declarado IDENTITY_CORRECTION_PROOF — dono o próprio Supplier, identificador gravado em pendingIdentityCorrection — e a instância só se conclui com ele existente e com veredito do antivírus Available; o contrato de desfecho grava, na mesma transação, o anexo, quem o anexou e quando, e quem decidiu e quando. Sem anexo liberado, devolve Refused(SUPPLIER_IDENTITY_CORRECTION_EVIDENCE_REQUIRED_CONFLICT), a decisão não é gravada e a tarefa continua ativa. O sistema não confere o conteúdo do documento, não exige assinatura nem consulta ao provedor para decidir: qual documento comprova a correção é a norma da empresa que diz, e o que fica é o rastro — a mesma regra da RN-FOR-40, com o mesmo risco aceito. Quem lê o anexo: quem tem read:suppliers, como em todo anexo de dono Supplier — vale a matriz do Anexo, e não a lista restrita dos anexos da conta e da proposta (RN-FOR-36). Risco aceito e registrado: o documento traz o CPF do titular e fica legível a todo usuário que lê fornecedor; contra isso ficam read:suppliers ser permissão de tenant, o acesso registrado na trilha do Anexo, e o anexo continuar elegível à eliminação a pedido do titular. O processo do cadastro continua Approved: a correção não reabre o cadastro nem devolve os contatos à edição livre (RN-FOR-34). Os valores propostos passam pelas validações e unicidades do cadastro no pedido e de novo no desfecho. O contrato de desfecho aplica na mesma transação e devolve Refused(SUPPLIER_IDENTITY_CORRECTION_ACCOUNT_MISMATCH_CONFLICT) se alguma conta vigente ou proposta BankAccount em Open deixaria de conferir com a identidade nova pelo regime da RN-FOR-13 do tipo de pessoa — nos tipos com documento brasileiro, o holderTaxId que deixa de conferir; em Foreign, o holderName que deixa de conferir com o legalName novo, que na submissão é flag e aqui é recusa, porque a conta já está vigente e ninguém decidiria a flag depois do fato — a conta sai antes, por proposta, e a proposta aberta é rejeitada; instância rejeitada ou cancelada limpa pendingIdentityCorrection. Por quê: se o CPF do titular muda por edição, a conta de um laranja passa a conferir com o fornecedor e a recusa da RN-FOR-13 deixa de valer.

Na instância BANK_ACCOUNT_CHANGE de proposta de canal — NoticeContact ou ChainContact — com noTrustedPhone (RN-FOR-34), a decisão só acontece com o pedido de troca anexado: um anexo do tipo declarado SIGNED_CONTACT_CHANGE_REQUEST, existente, cuja dona é a própria proposta, com veredito do antivírus Available. O que o sistema exige é o anexo e o rastro. Na mesma transação da decisão que conclui a instância, o contrato de desfecho grava em signedRequest da proposta o identificador do anexo, quem o anexou e quando, e quem decidiu e quando. Faltando o anexo — nunca enviado, de outro tipo, revogado, eliminado ou sem veredito liberado —, o desfecho devolve Refused(BANK_CHANGE_SIGNED_REQUEST_REQUIRED_CONFLICT): a decisão não é gravada e a tarefa continua ativa. O que o sistema não faz: não confere assinatura digital, verificador do ITI, selo ou consulta de cartório, apostila, poderes do signatário, nem aderência do conteúdo do documento aos dados da proposta. Qual documento serve é a norma da empresa que diz, e quem decide na controladoria responde por tê-lo lido. Não há regra de documento por país: Foreign segue exatamente este caminho, sem exigência de ICP-Brasil nem de firma reconhecida. Risco aceito e registrado: documento falso, ou assinado por quem não tem poderes, passa por aqui. O que fica contra ele é o rastro preservado, a dupla custódia por pessoa (RN-FOR-36, RN-FOR-41), os sete dias de carência com contestação (RN-FOR-38) e o aviso ao canal anterior com o callback (RN-FOR-29). Por quê: conferir assinatura, selo e poderes é trabalho de pessoa, e exigi-lo como campo travava a troca para sempre — em Foreign não havia documento possível — sem tornar o documento mais verdadeiro.

Quem pede a correção de identidade (RN-FOR-39) e quem decide na instância dela — toda decisão, do passo do cadastro e do complementar da controladoria — precisam de identidade verificada com CPF único por tenant (RN-FOR-36). A comparação entre pessoas é pela chave de pessoa que a plataforma expõe — igual para o mesmo CPF, diferente para CPFs diferentes, sem entregar o CPF em claro (demanda P17) —: dois usuários com o mesmo CPF são uma pessoa. O :correct-identity por usuário sem identidade verificada responde 409 SUPPLIER_IDENTITY_CORRECTION_IDENTITY_NOT_VERIFIED_CONFLICT, e nada é gravado; na decisão que concluiria a instância, o contrato de desfecho devolve Refused com o mesmo código quando alguma decisão não vem de CPF verificado, quando vem da chave de pessoa de quem pediu, ou quando as decisões não são de CPFs distintos entre si — a mesma cláusula da RN-FOR-36, e é ela que impede que a base seja decidida por um usuário e a controladoria por outro do mesmo CPF, o primeiro já desativado. Essas pessoas ficam ligadas ao fornecedor: o pedido grava quem pediu e o desfecho, qualquer que seja o resultado — aprovado, rejeitado ou cancelado —, grava quem decidiu, em identityCorrectionLinkedPeople (usuário, chave de pessoa, papel, instância e a data do desfecho). A ligação não tem prazo: vale enquanto aquele fornecedor existir, e é conferida no instante de cada ato. Alcance: pessoa ligada — por usuário ou por chave de pessoa — não propõe, não confirma e não decide conta bancária nem canal de aviso daquele fornecedor: o :submit de proposta BankAccount, NoticeContact ou ChainContact, a confirmação de ChainContact, o registro de callback, o envio do pedido assinado da RN-FOR-40, a contestação por dentro (:contest, RN-FOR-30) e o envio ou a confirmação de carga inicial com linha desse fornecedor respondem 409 BANK_CHANGE_IDENTITY_CORRECTION_LINKED_CONFLICT, e nada é gravado; e o contrato de desfecho do BANK_ACCOUNT_CHANGE — de conta ou de canal — devolve Refused com o mesmo código quando alguma decisão da instância vem de pessoa ligada. No motor, a ligação entra na submissão: ao submeter proposta de conta ou de canal daquele fornecedor, o Fornecedor manda em excludedUsers (RN-AP-60 do Fluxo), com reason = IdentityCorrectionLinked, todos os usuários de cada chave de pessoa ligada — a lista é montada por chave de pessoa, não por usuário —, ao lado do proponente; o motor os remove de toda tarefa antes de qualquer outra regra, e a tarefa nunca é atribuída a quem o desfecho recusaria. Sem essa lista a ligação não teria efeito no motor: a tarefa iria ao ligado, o desfecho devolveria Refused, a tarefa continuaria ativa e ninguém seria avisado — laço, não parada. Esgotados os elegíveis, nada se afrouxa: o passo ativa parado, com awaitingEligibleApprovers e o aviso obrigatório ao administrador do tenant e à controladoria (Fluxo, RN-AP-59) — e também quando o quórum já resolve vazio na própria submissão: o BANK_ACCOUNT_CHANGE não tem reserva, e menos de duas pessoas elegíveis deixa a instância parada já na submissão, com awaitingEligibleApprovers e o mesmo aviso obrigatório. A proposta nunca volta a quem propôs, e nunca é recusada com 422: ela precisa existir para ser vista e contestada. Nada é aplicado, e o administrador sabe. Por quê: com prazo de 30 dias, no dia 31 o outro usuário de quem decidiu propunha a conta do laranja; e o canal é a porta do controle bancário — quem põe o próprio número como contato do fornecedor atende o callback 30 dias depois.