Rejeição 841: confira o código do tipo de veículo enviado no item da NF-e

A rejeição 841 — Código do Tipo de Veículo Inexistente [nItem:nnn] indica que o código enviado em tpVeic, dentro do detalhamento de veículos novos do item, não foi localizado na tabela usada pela validação. A correção exige conferir o XML transmitido, identificar o veículo efetivamente vendido e ajustar o código correspondente no cadastro ou na integração que gera a nota.

Esse campo caracteriza o veículo vendido como produto. Não é o veículo da transportadora, a modalidade do frete nem a placa usada na entrega. Alterar esses outros dados não corrige um código de tipo de veículo inexistente.

O que a regra verifica

A regra J19-10, na NT 2021.004 v1.35, página 14, pertence à autorização da NF-e modelo 55 e tem aplicação obrigatória. Ela verifica se tpVeic consta na Tabela de Tipo e Espécie de Veículo, indicada no Portal Nacional da NF-e, em Documentos → Diversos. A linha não apresenta exceção própria nem lista de UFs que possam dispensá-la. [1][2]

O caminho do dado é NFe/infNFe/det/prod/veicProd/tpVeic. O grupo veicProd descreve veículos novos; dentro dele, tpVeic informa o tipo e espVeic informa a espécie. O identificador nItem no retorno ajuda a localizar qual item precisa de conferência. Preserve também o código e a mensagem completos recebidos, pois uma mensagem resumida na tela pode esconder essa identificação.

Há três verificações distintas: a 841 trata da existência do tipo; a 842, da existência da espécie; a 843, da compatibilidade entre espécie e tipo. Um código pode existir na tabela e ainda formar uma combinação incompatível. Por isso, resolver a primeira divergência não significa que todos os dados do veículo estejam corretos.

Como usar a tabela oficial

A planilha oficial obtida em 15/10/2026 contém a aba Tipo, com colunas para tipo, espécie, descrição e datas de início e fim de vigência. As linhas apresentam combinações, de modo que um mesmo tipo pode aparecer mais de uma vez. A data de início de cada linha não deve ser confundida com a data de implantação de uma rejeição.

Por exemplo, as células A12:C12 identificam tipo 6, automóvel, e espécie 1, passageiro. A linha seguinte apresenta outra combinação do mesmo tipo com espécie 6, especial. Isso não permite escolher livremente entre elas: a classificação deve corresponder à documentação e às características do veículo concreto. A tabela é referência para conferir o código, e não autorização para modificar a realidade da operação. [2]

No esquema XML consultado, tpVeic aceita um ou dois algarismos; espVeic aceita um. Uma sequência com tamanho permitido ainda pode representar código inexistente. Já letras, espaços indevidos ou excesso de caracteres podem causar problema de estrutura antes da conferência da tabela. Não use um exemplo com três algarismos como demonstração de que somente a rejeição 841 ocorrerá. [3]

Confira a origem do valor incorreto

Primeiro, abra o XML correspondente ao envio rejeitado e localize o det indicado. Compare seu tpVeic com o cadastro do produto e com a tabela oficial. Se a tela mostra uma descrição correta, confirme qual número foi efetivamente exportado. A descrição exibida ao usuário pode estar associada a um código interno diferente do código fiscal.

Depois, verifique se a nota foi criada antes da correção cadastral, copiada de outro documento ou importada por integração. Nesses casos, o item da nota pode conservar o valor antigo mesmo depois de o produto ser atualizado. O diagnóstico deve acompanhar o dado desde sua origem até o XML, sem presumir que salvar o cadastro modifica automaticamente documentos já preparados.

Uma lista local desatualizada ou um mapeamento entre categorias comerciais e códigos oficiais também pode explicar a divergência. Corrija a origem comprovada do erro e confira outros documentos ainda não autorizados que dependam do mesmo cadastro. Não altere indiscriminadamente todas as mercadorias nem substitua tipos diferentes por um código padrão.

Exemplo de conferência

Considere uma NF-e de um automóvel novo cuja documentação sustente tipo 6 e espécie 1. Por falha de integração, o item foi gerado com tpVeic=99. Esse tipo não aparece na planilha oficial consultada. A combinação documentada está na linha 12 e orienta a correção para o código correspondente ao automóvel, preservando a espécie comprovada.

O exemplo é didático, sem XML completo validado ou transmissão de teste. Não sugere que todo veículo deva receber tipo 6, nem que a mudança isolada assegure autorização. Se o problema real estiver na espécie ou na combinação, o tratamento deve respeitar a rejeição correspondente e a classificação do veículo.

Corrija e confira o novo envio

Após ajustar cadastro, mapeamento ou dados do item, gere novamente o XML pelo emissor e compare o campo corrigido com o conteúdo anterior. Não edite manualmente um arquivo já assinado. Confira também a espécie e os demais dados obrigatórios do grupo, preservando os documentos que sustentam a classificação.

Se veicProd foi incluído em um produto que não é veículo novo, investigue o enquadramento com o responsável fiscal antes de corrigir a geração do grupo. Apagá-lo de uma operação que realmente exige essas informações não é uma solução para a 841.

Existe ainda uma restrição diferente: a NT 2026.002 v1.11, página 12, prevê a rejeição 736 para NFC-e ou NF-e com DANFE Simplificado Tipo 2 (tpImp=6) que contenha veicProd. Essa regra tem seu próprio alcance e cronograma, com produção prevista em 03/08/2026 para essa alteração. Ela não transforma a 841 em regra de NFC-e nem autoriza mudar modelo ou impressão apenas para contornar uma rejeição. [4]

Se um envio anterior ficou sem resposta conclusiva, consulte a situação da chave antes de repetir a emissão. Depois da correção, examine o novo retorno e eventual protocolo da mesma nota. O desaparecimento da 841 demonstra apenas que aquela divergência deixou de ser apontada; a autorização depende das demais validações.

Referência e atendimento

A NT consultada mantém as regras de tipo e espécie na página 14. Seu histórico registra produção geral em 12/09/2022, ressalvadas as regras expressamente suspensas; a implementação futura mencionada na v1.35 refere-se a Z02-10/Z02-20. Não deve ser aplicada à 841 por analogia. A consulta documental não certifica o comportamento de cada autorizador, UF e ambiente.

Se a rejeição persistir com código e combinação conferidos, encaminhe ao suporte XML, retorno completo, item, versão do emissor, ambiente e tabela utilizada. Não foram validados menus específicos do ALRA neste artigo. Esses registros permitem investigar a geração do dado e eventual divergência de versão sem alterar a classificação fiscal por tentativa.

Fontes e limites

Pesquisa com capturas de 15/10/2026, horário de Brasília, e reuso identificado de documentos desse dia. Três corpos práticos específicos lidos e confrontados com as primárias. Sem teste no ALRA ou no autorizador.

1. NT 2021.004 v1.35, páginas 1/4/5/6/14: nova captura HTTP 200, PDF e33f067c. Capa v1.35 de novembro de 2022; cabeçalhos internos preservam v1.34/v1.33. PNGs existentes das páginas 4/14 inspecionados, com datas históricas riscadas e J19-10/J20-10/J20-20 íntegras. O texto da página 6 explicita produção geral em 12/09/2022 e exceções de outras regras. Índice nacional HTTP 200 de 15/10 reutilizado: entrada v1.35 publicada em 01/11/2022 lida, sem alegar nova captura do índice.

2. Tabela de Tipo e Espécie de Veículo: novo XLSX HTTP 200, hash 03c399be. Aba Tipo integralmente lida, A1:E41, com células não vazias registradas. A12:C13 sustenta as combinações do exemplo; tipo 99 ausente da coluna A. O título referencia a Portaria DENATRAN 681 de 12/03/2020 e as linhas têm início nessa data, sem fim preenchido. Isso não certifica implantação individual. Entrada em Documentos/Diversos lida em captura de 15/10 reutilizada; a entrada não informa data própria de publicação.

3. MOC 7 — Anexo I, página 22, PDF 5eb4cf20 de 15/10 reutilizado: texto integral lido para campos/grupo. Seus exemplos antigos de domínio não substituem a tabela atual. Esquemas XML: pacote 010f HTTP 200 de 15/10 reutilizado; grupo veicProd integral e ancestrais lidos no leiaute 2bace939. Não houve compilação XSD nem validação de XML externo.

4. NT 2026.002 v1.11, páginas 3/12, PDF 72c033b2 e cache b55f4006 reutilizados: textos e PNGs existentes lidos. J01-10/736 e sua linha de cronograma estão íntegras. A postergação para dezembro de outras regras não foi estendida a ela nem à 841.

5. TecnoSpeed — 841: corpo WEB completo, de 10/04/2025, lido; HTTP 403 direto separado. Indica tpVeic e tabela oficial; tpVeic_J19 é nome da integração do fornecedor, não tela ALRA.

6. TOTVS Protheus — 841: corpo WEB específico completo, de 15/07/2025, lido; HTTP 403 direto separado. Orientações de Protheus/TSS e campo CD9_TPVEIC não foram atribuídos ao ALRA nem executados.

7. Oobj — 841: novo HTTP 200, corpo específico integral de 19/09/2024 lido. O texto mistura tipo com espécie, descreve espVeic=100 e exibe tpVeic=100; o XML tem erros de sintaxe. Esses exemplos foram descartados como modelo operacional. Foi aproveitada apenas a orientação de conferir o código na tabela oficial, já confirmada nas primárias.

Imagens dos guias não inspecionadas e menus não testados. Busca focal em seis caches de NTs de 2026 identificou J01-10 na NT 2026.002, sem ocorrências de J19-10/J20-10/841/842; ausência literal não prova ausência universal de alterações. Original e atos anteriores preservados, sem autenticação retroativa. Revisão cruzada independente pendente e publicação não realizada.