Rejeição 787: confira o destinatário no XML da venda com entrega

Quando a autorização retorna 787, confira a identificação fiscal do destinatário no arquivo enviado. Uma venda pode ter cliente e endereço no pedido, mas chegar ao XML sem o grupo exigido. A correção precisa alcançar o documento transmitido; completar um cadastro isolado ou repetir o envio pode conservar a mesma ausência.

Preserve o retorno completo e confirme a qual nota ele pertence. O código não informa sozinho se houve falha de vínculo, de integração ou de preenchimento. Também não significa necessariamente CPF inválido: a regra examinada verifica a falta de identificação no cenário descrito.

Mensagem e condições documentadas

A NT 2026.002 v1.11, página 11, regra E01-20, apresenta: “Rejeição: NFC-e ou NF-e com DANFE Simplificado Tipo 2 (tag:tpImp=6) em operação não presencial sem a identificação do destinatário”.

A linha reúne três elementos: NFC-e ou NF-e com DANFE Simplificado Tipo 2, indicador indPres=4 e ausência de infNFe/dest. Para o modelo 65, o ramo é NFC-e. Para o modelo 55, exige NF-e com tpImp=6; não se estende a qualquer NF-e. Tampouco alcança automaticamente todos os indicadores de operação não presencial.

Na página 7, o domínio de indPres=4 descreve operações não presenciais com NFC-e e NF-e com DANFE Simplificado Tipo 2, com entrega. O serviço é NFeAutorizacao, indicado na seção de validações da NT. A base MOC documenta leiaute 4.00.

O MOC 7.0, página 83, traz a redação histórica para NFC-e modelo 65 com entrega a domicílio. Essa base ajuda a reconhecer a mensagem anterior, mas não substitui a atualização do ramo Tipo 2. Identificação, endereço e documento inválido são verificações distintas.

Cronograma e limites da evidência

A página 3 da NT associa testes em 01/07/2026 e produção em 03/08/2026 a um bloco enumerado de alterações do Tipo 2. E01-20 não aparece nessa enumeração. Por isso, essas datas não são atribuídas aqui à implantação específica da regra.

A mesma página adia para 14/12/2026 somente I08-180, BA02-35 e VC02-40. E01-20 não é nomeada nesse adiamento. A ausência nas listas não comprova outra data, vigência ou desativação. Também não permite concluir quando o autorizador passou a aplicar o ramo NF-e 55.

O índice oficial SVRS, conferido em 15/10/2026, lista a NT 2026.002 v1.11 e avisa que datas poderão ser alteradas. O índice sustenta a referência documental atual, mas não fornece o calendário individual de E01-20. Calendários de outras regras ou documentos não devem ser transferidos para esta rejeição.

A E01-20 está marcada “Obrig.” e não apresenta exceção estadual ou restrição de ambiente na linha examinada. Isso não comprova ativação em determinada UF. A observação “Implementação futura”, na mesma página, pertence a G01-10/670. Confirme a aplicação no autorizador e ambiente concretos, especialmente ao analisar o ramo NF-e Tipo 2.

Como localizar a causa

Confira primeiro modelo, ambiente, horário e retorno da nota rejeitada. Registre a versão do emissor e o endereço do serviço utilizado. Em seguida, compare o pedido, o destinatário vinculado e o XML efetivamente transmitido.

No arquivo, verifique mod, tpImp, indPres e a presença de dest. Uma prévia antiga não demonstra o conteúdo do envio. Para NF-e 55, confirme especialmente se tpImp=6 corresponde ao documento pretendido e se o indicador retrata a operação.

Se dest já estiver presente, confirme que está examinando o mesmo arquivo e retorno da tentativa rejeitada. Não apague nem recrie o cliente indiscriminadamente: encaminhe a inconsistência para análise técnica.

Se houver integração, acompanhe os dados desde a entrada até a geração do XML. O cliente pode existir no cadastro e faltar no vínculo da nota; também pode desaparecer durante a transformação dos dados. Essa comparação distingue ausência no cadastro, falha de vínculo e falha de geração.

Corrija conforme o cenário

Cadastro existente sem vínculo na nota

Selecione o destinatário verdadeiro da operação e confira tipo de pessoa, documento e correspondência com a venda. Atualize a nota rejeitada pelo fluxo do emissor e gere novamente o arquivo. Verifique se dest entrou no XML; salvar o cadastro não comprova essa mudança.

Se o vínculo está correto e o grupo continua ausente, encaminhe ao suporte a divergência entre tela e arquivo. Repetir a transmissão sem corrigir a geração pode reproduzir a rejeição.

Dados do destinatário ainda incompletos

Obtenha os dados pertinentes à identificação fiscal e confira sua relação com a operação. No esquema XML 010f, dest está dentro de infNFe; sua declaração opcional não dispensa o grupo quando a regra de negócio o exige. Um grupo vazio também não constitui identificação válida. Não substitua o destinatário por CPF genérico, funcionário ou estabelecimento apenas para preencher o campo. Havendo dúvida sobre quem deve constar na nota, consulte o responsável fiscal.

Na NFC-e com entrega, confira também o endereço. O MOC relaciona 788 à ausência de dest/enderDest no modelo 65 com indPres=4. Essa referência histórica não comprova a extensão da regra 788 à NF-e Tipo 2. Resolver 787 não garante aprovação nas demais validações.

Indicador ou documento diferente da operação

Compare a modalidade enviada com o pedido e os fatos da venda. Corrija um indicador incorreto para retratar a operação, sem mudar indPres apenas para dispensar identificação. Dúvidas sobre modelo ou uso do DANFE Tipo 2 exigem avaliação fiscal antes do novo envio.

Exemplo hipotético

Uma loja vende R$ 178 em produtos para entrega na residência de uma cliente. O pedido possui endereço, mas a NFC-e foi criada sem destinatário identificado. O XML contém mod=65 e indPres=4, sem dest, e o retorno recebido é 787.

A equipe confirma a compradora, completa seu cadastro fiscal verdadeiro e o vincula à nota rejeitada. Depois confere o novo XML e o endereço, preservando produtos, valores e modalidade real. O exemplo ilustra uma causa possível; não é teste de emissão nem demonstra autorização garantida.

Verificação e encaminhamento

Leia o novo retorno da nota, chave e ambiente certos. Se houver autorização, preserve XML e protocolo e confira o vínculo interno com a venda. O desaparecimento de 787 pode revelar outra pendência. Se a resposta não chegou, consulte a situação pelo fluxo do emissor antes de criar outra emissão.

Acione o suporte quando destinatário e XML divergirem, quando o vínculo desaparecer após salvar ou quando o modelo produzido não corresponder ao selecionado. Compartilhe evidências pelo canal adequado, protegendo os dados pessoais.

Encaminhe ao responsável fiscal dúvidas sobre destinatário, modalidade, documento e implantação no ambiente concreto. Registre a causa identificada e a correção aplicada para orientar a próxima operação.

Fontes e limites documentais

Pesquisa e revisão textual em 15/10/2026, horário de Brasília. Capturas oficiais desse dia reutilizadas por hash e novas consultas WEB. Sem teste no ALRA ou certificação de implantação individual por UF e ambiente.

• SVRS — Documentos NF-e: corpo HTTP 200 capturado em 15/10 e nova leitura WEB, item v1.11 rotulado 01/10/2026, com aviso sobre possíveis alterações nas datas. Não comprova ativação individual.

• NT 2026.002 v1.11: PDF HTTP 200 de 15/10, páginas 3, 7, 8 e 11 lidas em cache correlacionado. PNGs documentais existentes das páginas 3 e 11 inspecionados pessoalmente; E01-20 íntegra, sem atribuir a ela observações de linhas vizinhas. O calendário individual não foi comprovado.

• MOC 7.0, Anexo I: PDF HTTP 200 de 15/10 e texto correlacionado, páginas 8 e 83. Base do leiaute 4.00, mensagem histórica 787/65 e distinções 788, 208 e 237. Não amplia automaticamente 788 ao Tipo 2. O esquema 010f do Portal NF-e confirma a estrutura de dest; sem compilação do XSD ou validação de XML externo.

• Oobj: corpo textual específico completo HTTP 200 e WEB, de 19/09/2024. Apoia a conferência de indPres=4 e destinatário ausente na NFC-e; não incorpora o ramo Tipo 2. As imagens de exemplo não foram inspecionadas nem adotadas como XML validado.

• TecnoSpeed: corpo textual WEB completo de 22/05/2025, separado da tentativa direta HTTP 403. O título menciona endereço, mas o corpo descreve identificação e dest; a distinção oficial prevalece. Campos de componente e conversão automática do indicador no PlugNotas pertencem ao fornecedor, sem demonstração no ALRA. Exemplo externo não validado nem reutilizado.

• Webmania: corpo textual específico completo HTTP 200 e WEB, de 28/10/2025. Confirma o cenário NFC-e; aba Cliente, API e imagens ilustrativas não são procedimentos comprovados no ALRA. A indicação de reemitir foi substituída pela conferência da situação e pelo fluxo normal do emissor.

Busca focal por 787/E01-20 em seis caches de NTs de 2026 encontrou somente a página 11 da NT 2026.002; ausência literal não prova vigência universal. A pesquisa atual não autentica atos antigos nem os guias eNotas/Supersoft do legado. Históricos preservados, revisão cruzada independente pendente e publicação não realizada.