Rejeição 669: confira o grupo de retirada na NFC-e e na NF-e Tipo 2

Se a nota voltou com “Rejeição: Local de retirada informado indevidamente”, comece pelo tipo de documento e pelo XML enviado. A mensagem aponta para a presença do grupo que identifica um local de retirada. Ela não diz que o endereço tem um dígito errado nem que o cliente precisa retirar a compra em outro lugar.

Para o empresário, a decisão é entender por que o emissor incluiu essa informação e se o documento escolhido é adequado à operação. Corrigir o arquivo exige preservar a realidade da venda. Apagar um endereço necessário ou trocar o formato da nota sem análise fiscal pode esconder a causa e criar outra inconsistência.

Onde o 669 se aplica

Na NT 2026.002 v1.11, página 11, a F01-10 trata da autorização da NFC-e 65 e da NF-e 55 com DANFE Simplificado Tipo 2, ide/tpImp=6. Nesse recorte, o local de retirada infNFe/retirada informado indevidamente gera 669. A linha é obrigatória, sem exceção estadual expressa nela. Não estenda a restrição a toda NF-e 55 com DANFE normal.

O Tipo 2 é um formato de DANFE da NF-e 55. Não transforma a nota em modelo 65. A identificação do documento vem de ide/mod; o formato de impressão vem de ide/tpImp. Conferir apenas o papel impresso ou o tamanho da impressora pode levar ao diagnóstico errado.

No calendário dessa NT, página 3, a F01-10 integra o conjunto original com testes em 01/07/2026 e produção em 03/08/2026. O adiamento da v1.11 para 14/12/2026 alcança I08-180, BA02-35 e VC02-40, sem incluir F01-10. A conferência de 15/10/2026 usa o documento oficial e o pacote XML 010f. A publicação não comprova execução individual por UF, autorizador e ambiente. Confira o retorno e tpAmb: 1 para produção, 2 para homologação.

Retirada, entrega e endereço do emitente são informações diferentes

O MOC, página 15, orienta informar o grupo de retirada somente quando o endereço for diferente do remetente, respeitando o modelo e a operação. Não repita automaticamente o cadastro da loja nele. O endereço do emitente fica em emit/enderEmit; o do destinatário, em dest/enderDest. entrega é outro grupo e tem regra própria.

Uma venda em que o comprador recebe a mercadoria no balcão não deve, por esse fato isolado, levar a integração a preencher retirada. Da mesma forma, descobrir o 669 não autoriza apagar o endereço do cliente ou mudar o local real de origem da mercadoria. É preciso identificar qual campo foi gerado e de onde veio.

O que guardar antes de corrigir

Separe o XML efetivamente transmitido, o retorno completo, a chave, o horário e o registro da venda. Na comparação, confira:

• modelo, formato de impressão, ambiente e autorizador;

• existência do grupo retirada, inclusive se a tela não mostra esse campo;

• cadastro, pedido ou integração que forneceu os dados de retirada;

• local real de retirada e necessidade fiscal dessa identificação;

• atualização instalada no emissor e versão da rotina que gerou o XML.

Um cadastro correto na tela não prova que o arquivo saiu correto. Um pedido copiado pode conservar um grupo antigo. Uma integração pode montar o XML com parâmetros próprios. A investigação deve alcançar o arquivo transmitido, não parar na configuração que parece correta.

Como resolver por cenário

O sistema incluiu o endereço da própria loja automaticamente

Se a conferência confirmar que retirada foi criado sem necessidade nesse documento, ajuste a origem desse preenchimento. Remova o grupo indevido pelo fluxo do emissor e gere novamente a nota rejeitada. Preserve os dados verdadeiros do emitente, do comprador e dos itens.

Peça ao suporte que confira a configuração em todos os caixas e integrações. Registre a mudança e compare novo XML, para evitar que a rotina automática reintroduza o grupo na próxima venda.

A operação realmente exige identificar outro local

Interrompa a correção automática e envolva o responsável fiscal. A questão pode ser a escolha inadequada da NFC-e ou da NF-e com Tipo 2 para aquela operação. O contador deve avaliar o documento e o enquadramento permitidos, considerando a legislação da UF e as condições do negócio.

Não escolha DANFE normal apenas para escapar da regra, nem transfira o endereço para um campo sem avaliar sua finalidade. Caso a análise determine outro formato documental, o suporte deve implementar essa orientação preservando os fatos e o histórico da emissão rejeitada.

A configuração foi alterada, mas a rejeição continua

Confira se a nova tentativa reaproveitou um XML antigo. Pode ser necessário regenerar o documento pelo emissor, em vez de reenviar o mesmo arquivo. Verifique também se todos os pontos de emissão receberam a atualização e se há outra rotina reintroduzindo retirada.

Não edite manualmente XML assinado. A correção deve respeitar a geração e a assinatura do emissor. Se o novo arquivo não contém o grupo e o retorno persiste, preserve os arquivos e encaminhe a divergência ao fornecedor e ao autorizador.

Exemplo hipotético

Uma loja de artigos domésticos passa a emitir NF-e 55 com tpImp=6 para determinadas vendas. Sua integração foi reaproveitada de outra rotina e sempre copia o endereço da loja para retirada. Uma venda de R$ 184 recebe 669.

A equipe confirma que a operação selecionada não requer aquele grupo, identifica a cópia automática e corrige o mapeamento. A nota rejeitada é regenerada com os endereços próprios do emitente e do destinatário, sem alterar produtos ou valores. O suporte confere o novo retorno e verifica outra venda para confirmar que a causa recorrente foi tratada.

Se a mensagem falar em PAA

Se o retorno disser “Rejeição: Ambiente de autorização inválido para emissão pelo PAA”, trate outro contexto. Na NT 2026.001 PAA v1.02b, o histórico da página 3 registra a correção de P14-10/P14-20. A conferência da marcação gráfica da página 17 confirma 669 riscado e substituído por 633. A mensagem não corresponde ao grupo de retirada.

A P14-10, modelo 55, trata de série PAA 970–989, eventos do emitente 110111 (cancelamento), 110112 (cancelamento por substituição) ou 110110 (carta de correção), com ambiente de autorização diferente da SVRS. A P14-20, também modelo 55 nessa série, trata de EPEC 110140, pelo ambiente de contingência EPEC. São eventos, não o grupo retirada; não mude série ou evento para contornar a validação.

O calendário PAA da linha v1.02 indica teste em 03/08/2026 e produção em 05/10/2026. As correções 1.02a/1.02b não indicam novas datas nessa tabela. Esse calendário não reinicia o da F01-10 nem comprova implantação atual.

Como confirmar a solução e quando escalar

Verifique a mudança comprovada no XML e o resultado fiscal da tentativa correspondente. O desaparecimento do 669, sozinho, não significa autorização: outra validação pode impedir a emissão. Guarde o protocolo quando houver autorização e confirme o vínculo correto com a venda.

Acione o suporte para rastrear grupos ausentes na tela, versões antigas e diferenças entre caixas. Envolva a contabilidade para avaliar o documento adequado ou a necessidade de retirada. Envie ao autorizador UF, ambiente, chave e arquivos comparáveis, preservando os fatos fiscais.

Fontes

Conferência documental em 15/10/2026. Sem emissão de teste ou validação operacional do ALRA.

• NT 2026.002 v1.11, páginas 3, 11 e 20: regras e calendário do DANFE Tipo 2.

• NT 2026.001 PAA v1.02b, páginas 3 e 14–18: autorização e eventos são contextos distintos.

• MOC 7.0, Anexo I, páginas 15 e 66, com esquemas XML do Portal Nacional, pacote 010f.

• Apoios consultados: Buscador NCM, Fiscal Pro, Conthouse. A notícia sobre o PAA não define o tratamento de retirada. As regras são sustentadas pelas fontes oficiais acima.