Atualização de schemas e Notas Técnicas: como preparar e conferir a mudança

Atualizar os schemas da NF-e exige mais do que copiar um arquivo XSD para uma pasta. O emissor precisa utilizar um conjunto compatível de arquivos, gerar os campos corretamente e interpretar os retornos correspondentes. Antes de qualquer mudança, identifique a versão instalada, a atualização necessária e o ambiente em que ela será utilizada.

Este guia trata da preparação e da conferência de atualizações para NF-e e NFC-e. Não determina um pacote único para todos os serviços nem autoriza alterar uma instalação de produção sem conhecer suas dependências. No ALRA, o procedimento deve corresponder à versão e ao componente efetivamente utilizados.

Descubra o que a atualização modifica

Uma Nota Técnica pode criar campos, alterar formatos, introduzir regras de validação ou modificar somente documentação e cronograma. Essas mudanças têm efeitos diferentes. Localize no documento oficial o trecho relacionado ao erro ou recurso necessário, em vez de assumir que toda revisão exige a mesma intervenção.

Registre modelo, serviço, ambiente e UF envolvidos. Uma alteração em eventos ou distribuição de documentos não significa, necessariamente, atualização idêntica do XML de autorização. Também não se deve aplicar ao modelo 55 uma condição exclusiva do modelo 65 apenas porque ambos aparecem no título da nota técnica.

Quando houver uma rejeição, preserve o XML e a resposta antes de atualizar. O erro pode estar no preenchimento ou no mapeamento, e não na ausência de um pacote. Mudar arquivos sem identificar a causa pode dificultar a comparação e manter o problema original.

Leiaute, XSD e regra de negócio não são equivalentes

O schema descreve estrutura, organização e restrições dos elementos do XML. A validação local pode apontar um grupo ausente, um formato incompatível ou uma sequência de campos incorreta. Ela não comprova, sozinha, existência de documentos referenciados, regularidade cadastral ou atendimento de todas as regras fiscais.

Uma mensagem pode respeitar o XSD e receber rejeição por outra condição no autorizador. O inverso também merece investigação: um validador local antigo pode recusar um campo previsto no conjunto correto. Para diagnosticar, identifique qual ferramenta validou o arquivo e quais schemas ela realmente carregou.

Não confunda versão da Nota Técnica, versão do XML, nome do pacote e versão do programa. Um arquivo pode manter o nome e receber ajustes em uma nova liberação do pacote. Portanto, conferir apenas o nome na pasta ou a existência de um arquivo não demonstra que seu conteúdo seja o esperado.

Obtenha o conjunto adequado em fonte oficial

Use a seção de esquemas XML do Portal Nacional e a documentação oficial da alteração. Verifique a finalidade do pacote: autorização, evento, consulta ou distribuição, por exemplo. O portal relaciona conjuntos distintos; a posição de um link na lista não transforma aquele arquivo em substituto de todos os outros.

Guarde o pacote recebido, a origem, a data e sua identificação. A equipe técnica pode registrar hashes para comparar os arquivos obtidos e os efetivamente instalados. Essa comparação ajuda a detectar cópia incompleta ou conteúdo diferente sob o mesmo nome, sem substituir a leitura da documentação e os testes necessários.

Os arquivos XSD podem depender de tipos básicos e de outros arquivos referenciados por include ou import. Evite montar um conjunto misturando arquivos de liberações diferentes. Não renomeie um schema anterior, acrescente manualmente uma tag ou remova uma restrição para fazer o validador aceitar o XML.

Confira cronograma e compatibilidade

Leia o histórico da versão e eventuais avisos posteriores. Publicação, disponibilização de schema, homologação e ativação de regras em produção podem ter datas diferentes. Uma alteração de prazo para determinadas regras não adia automaticamente todas as demais mudanças do documento.

Confirme também a compatibilidade do emissor e da integração. Um campo novo pode precisar de atualização no cadastro, na geração do XML, no cálculo, no armazenamento ou na leitura da resposta. Copiar schemas sem atualizar o componente que produz a mensagem pode deixar essa cadeia incompleta.

Em instalações com servidor e estações, descubra qual processo carrega os arquivos e de onde ele os lê. A pasta examinada pelo operador pode não ser a utilizada pelo serviço de emissão. Peça ao suporte ALRA que confirme o caminho e o procedimento aplicáveis; diretórios de outros produtos não são instruções para o ALRA.

Prepare uma verificação que possa ser repetida

Antes da atualização, preserve os arquivos e as configurações pertinentes e documente a situação atual. Organize a mudança para permitir investigar diferenças e recuperar o conjunto anterior quando isso for tecnicamente necessário e ainda compatível com as regras vigentes. Reverter arquivos não dispensa uma exigência fiscal já aplicável.

Em homologação, escolha cenários relacionados à alteração: geração do novo campo, validação estrutural, assinatura, comunicação e leitura do resultado, conforme o recurso envolvido. Uma validação XSD isolada não equivale a uma emissão concluída. Registre quais etapas foram realmente verificadas e quais não foram executadas.

Examine também um cenário anterior que deva continuar funcionando. O objetivo é identificar se a atualização resolveu o ponto necessário sem romper uma rotina já utilizada. Não apresente uma autorização de teste como documento fiscal da operação real.

Exemplo de atualização incompleta

Uma integração passa a gerar um grupo previsto em uma atualização, mas o serviço responsável ainda carrega os schemas anteriores. O arquivo recebe erro estrutural local antes da comunicação com o autorizador. A equipe confirma a versão do gerador, o caminho efetivo e a diferença entre os conjuntos.

A correção consiste em alinhar os componentes e arquivos conforme a documentação e validar novamente o cenário. Não se elimina o grupo legítimo nem se altera o XSD para esconder a divergência. O exemplo descreve uma hipótese técnica e não prova que esse seja o motivo de qualquer rejeição de schema.

Confirme o resultado depois da mudança

Registre a versão do componente e o conjunto efetivamente carregado, preservando os arquivos de teste e as respostas. Se houver transmissão, confira ambiente, chave e resultado correspondente. A ausência do erro anterior não comprova autorização nem atendimento de todas as regras da operação.

Se persistir o problema, encaminhe ao suporte a mensagem completa, o XML, a identificação do pacote e o resumo do que foi verificado. Isso permite separar arquivo desatualizado, caminho incorreto, geração incompatível e regra fiscal sem realizar novas mudanças por tentativa.

Fontes

Conferência documental em 16/10/2026: Portal Nacional, esquemas XML, recorte de versões oficiais e conjuntos distintos; MOC 7.0 — Visão Geral, páginas 65–70; e NT 2024.003 v1.10, páginas 3–4, como exemplo de cronogramas separados. As tabelas antigas do MOC não foram tratadas como lista atual de pacotes.

Três apoios de implementação foram lidos e confrontados: Oobj, leiautes e testes, TecnoSpeed, componentes e caminhos de schemas e Omie, cronograma de atualizações. Calendários antigos, promessas de automação e caminhos próprios não foram transferidos ao ALRA. Não houve instalação, alteração de XSD, validação de arquivo real ou emissão de teste.