Rejeição 842: confira a espécie do veículo informada no item da NF-e

A rejeição 842 — Código da espécie de Veículo Inexistente [nItem:nnn] ocorre na validação do código enviado em espVeic, no detalhamento de veículos novos do item. Para corrigir, localize o item do XML rejeitado, compare a espécie com a tabela oficial e com a documentação do veículo, e ajuste a origem do valor incorreto antes de gerar novamente a nota.

A espécie caracteriza o veículo vendido como produto. Não é a espécie dos volumes transportados, a placa da transportadora nem o tipo de frete. Esses dados pertencem a outras partes do documento e não substituem a informação exigida no item.

Entenda a validação

A regra J20-10, na NT 2021.004 v1.35, página 14, verifica se espVeic consta na Tabela de Tipo e Espécie de Veículo. Seu modelo é a NF-e 55, com aplicação obrigatória. A linha não apresenta exceção própria nem condição que a limite a uma UF determinada. A referência indicada é a tabela publicada em Documentos → Diversos, no Portal Nacional da NF-e. [1][2]

O campo fica em NFe/infNFe/det/prod/veicProd/espVeic. O grupo veicProd corresponde ao detalhamento de veículos novos. Nele, tpVeic identifica o tipo de veículo e espVeic identifica sua espécie. Se a mensagem trouxer nItem, use esse número para localizar o det correspondente, sem assumir que o problema está no primeiro produto.

Guarde o retorno completo. A 841 verifica a existência do tipo; a 842 verifica a existência da espécie; a 843 verifica a compatibilidade entre ambos. Confundir essas situações pode levar a alterar o campo errado ou escolher uma espécie existente que continue inadequada ao veículo.

Leia a tabela por código e combinação

A planilha oficial obtida em 15/10/2026 tem uma aba chamada Tipo. Suas colunas mostram tipo, espécie, descrição, início e fim de vigência. Cada linha apresenta uma combinação, e um mesmo tipo pode ter mais de uma espécie. A existência de um número na coluna de espécies não comprova que ele serve para todos os tipos.

Nas células A14:C15, por exemplo, o tipo 7, micro-ônibus, aparece com espécie 1, passageiro, e espécie 6, especial. A espécie 2, carga, existe na tabela em outras linhas, mas não nessa combinação com tipo 7. Assim, trocar uma espécie inexistente por 2 pode eliminar a questão de existência e deixar uma incompatibilidade a ser tratada pela regra 843. [2]

Escolha a classificação sustentada pela documentação e pelas características do veículo. A tabela não permite adotar a primeira opção disponível nem padronizar toda a frota como passageiro ou especial. As datas das linhas da planilha também não são as datas de implantação das rejeições.

Verifique o que saiu no XML

Abra o XML do envio rejeitado e confira espVeic no item indicado. Em seguida, compare esse valor com o cadastro do produto, os dados complementares da nota e o mapeamento usado pela integração. Uma descrição correta na tela pode estar ligada a um número interno que foi exportado indevidamente como código fiscal.

Verifique se a nota foi copiada de outra emissão ou preparada antes de uma mudança cadastral. O item pode conservar a espécie antiga. Nesse caso, atualizar apenas o cadastro não garante que o XML de uma nota já montada seja regenerado com o valor correto. A conferência decisiva é feita no novo conteúdo gerado pelo emissor.

No esquema XML consultado, espVeic deve conter um algarismo. Esse formato não valida, sozinho, a existência do código na tabela. Uma espécie como 9 cabe no formato, mas não aparece na planilha consultada. Já um valor como 100 tem tamanho incompatível com o campo e não é um bom exemplo para afirmar que haverá exclusivamente a rejeição 842. [3]

Exemplo de correção fundamentada

Considere uma venda de micro-ônibus novo, tipo 7, cuja documentação confirme a espécie passageiro. A integração enviou espVeic=9 por usar uma categoria interna. A tabela consultada não contém essa espécie, enquanto a linha 14 apresenta a combinação tipo 7 e espécie 1. A correção é ajustar o mapeamento e o item para a classificação efetiva, preservando o tipo comprovado.

Se o veículo concreto for de espécie especial, esse exemplo não determina a opção correta: é necessário conferir a documentação e a linha correspondente. O caso é didático, sem XML completo validado ou transmissão ao autorizador. Não autoriza converter um veículo real em outra espécie para obter aceitação.

Gere novamente e acompanhe o resultado

Depois de corrigir cadastro, integração ou dados do item, gere o XML novamente pelo emissor. Confira a espécie, o tipo e a combinação, além dos demais campos obrigatórios do grupo. Não altere manualmente um XML já assinado nem remova informações verdadeiras de um veículo novo apenas para fazer desaparecer a mensagem.

Se o grupo foi incluído em uma mercadoria que não corresponde a veículo novo, confirme o enquadramento com o responsável fiscal e corrija a geração na origem. Esse diagnóstico é diferente de excluir um grupo devido, e deve se apoiar na operação efetivamente realizada.

Há também uma restrição específica na NT 2026.002 v1.11: a regra J01-10 prevê a rejeição 736 quando NFC-e ou NF-e com DANFE Simplificado Tipo 2 (tpImp=6) contém veicProd. A linha de cronograma dessa alteração prevê produção em 03/08/2026. Essa proibição é distinta da existência da espécie e não amplia a 842 ao modelo 65. Não troque modelo ou tipo de impressão como tentativa de contorno. [4]

Quando um envio anterior estiver sem resultado conclusivo, consulte a situação da chave antes de reenviar. Após a correção, confira o novo retorno e eventual protocolo da mesma nota. A ausência da 842 não garante autorização, pois outras validações continuam aplicáveis.

Referência atual e suporte

A NT 2021.004 consultada mantém J20-10 íntegra. Seu texto histórico registra produção geral em 12/09/2022, com ressalvas expressas para outras regras. A implementação futura da versão 1.35 refere-se a Z02-10/Z02-20 e não deve ser transferida para a 842. Documentos e cronogramas não certificam a implantação individual por autorizador, UF ou ambiente.

Se a mensagem persistir, encaminhe XML, retorno completo, item, código e descrição do veículo, referência da tabela, versão do emissor e ambiente ao suporte. Diferencie homologação de produção. Não foram testados menus do ALRA neste artigo; os registros permitem identificar a origem da divergência sem substituir a classificação fiscal por escolhas sucessivas de códigos.

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. A14:C15 sustenta as combinações do exemplo; espécie 9 ausente da coluna B e espécie 2 presente em outras linhas, sem combinação com tipo 7. 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 à 842.

5. TecnoSpeed — 842: corpo WEB específico completo, de 10/04/2025, lido; HTTP 403 direto separado. Indica espVeic e tabela oficial. O campo espVeic_J20 pertence à integração do fornecedor e não foi tratado como tela ALRA.

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

7. Oobj — 842: novo HTTP 200, corpo específico integral de 19/09/2024 lido. Explica micro-ônibus 7 com espécies 1/6, mas seu XML de solução usa espécie 2, incompatível com as linhas conferidas. O exemplo inicial usa espécie 100 e os XMLs têm erros de sintaxe. Esses modelos foram descartados. A orientação de consultar a tabela foi confirmada nas primárias.

As leituras oficiais e inspeções documentais comuns da pesquisa 841/842 são reutilizadas de forma identificada; não se alegam novas capturas para cada artigo. 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.