Rejeição 819: informação de solicitação da NFF preenchida indevidamente

A rejeição 819 ocorre quando o documento informa um tipo de emissão diferente de Nota Fiscal Fácil e, ao mesmo tempo, contém o grupo de solicitação da NFF. A regra ZE01-10, da NT2021.002 v1.12, combina duas condições: tpEmis diferente de 3 e presença de infSolicNFF. O quadro prevê aplicação obrigatória para NF-e, modelo 55, e NFC-e, modelo 65.

Para corrigir, é preciso identificar qual fluxo deveria ter produzido o documento. Uma nota comum pode ter recebido um grupo indevido por mapeamento da integração; uma solicitação legítima da NFF pode ter sido encaminhada com identificação incompatível. Não se deve trocar o tipo de emissão para3 apenas para fazer a mensagem desaparecer.

O que representa o grupo de solicitação

O regime NFF utiliza um aplicativo para coletar as informações da solicitação e um sistema centralizado para gerar o documento fiscal. A NT estabelece que o pedido de emissão desse regime é gerado exclusivamente pelo aplicativo emissor. O grupo infSolicNFF transporta as informações da solicitação, e seu campo xSolic contém os dados do pedido em formato JSON.

Esse grupo não é uma área livre para observações da venda, número de pedido comercial ou mensagem do usuário. Também não serve para vincular qualquer NF-e a uma fatura. Um sistema que disponha de um campo chamado “solicitação” pode ter uma finalidade própria, sem correspondência com a solicitação específica da Nota Fiscal Fácil.

No leiaute, infSolicNFF está subordinado às informações da nota, infNFe, e não ao cadastro de cada produto. Sua ocorrência opcional na estrutura XML não significa que possa ser informado em qualquer modalidade. A regra de negócio restringe sua presença ao tipo de emissão 3; quando o grupo é utilizado, xSolic é um campo interno obrigatório, com tamanho previsto de 2 a 5000 caracteres.

Confira os dois lados da incompatibilidade

Comece pelo retorno efetivamente recebido: guarde código, mensagem completa, horário, UF, ambiente e identificação da transmissão. Localize o XML enviado nessa tentativa e confira ide/tpEmis e infNFe/infSolicNFF. Comparar apenas a tela de preenchimento pode esconder uma transformação realizada depois por uma integração ou biblioteca de emissão.

Se o documento contém o grupo e seu tipo é diferente de3, a combinação corresponde ao predicado da 819. Se não contém o grupo, investigue se foi consultado o arquivo correto, se existe uma versão posterior gerada automaticamente ou se o retorno foi associado à tentativa errada. Não invente conteúdo para reproduzir a rejeição nem conclua que a SEFAZ errou sem conferir essa correspondência.

A presença de procEmi com valor1 ou2 não cria, por si só, uma dispensa da ZE01-10. A NT prevê uma condição específica para notas avulsas na regra de informações do produto NFF, associada ao código820. Essa condição não foi escrita como exceção da 819 e não deve ser transferida de um grupo para o outro.

Quando a emissão deveria ser comum

Em uma NF-e ou NFC-e emitida fora do regime NFF, com tipo de emissão corretamente definido, a investigação deve localizar por que infSolicNFF foi incluído. Confira o mapeamento de campos, os dados importados e a rotina que transforma a solicitação interna do sistema no XML fiscal.

Confirmado que o grupo não pertence à operação, ajuste sua geração para que o documento deixe de enviá-lo. Preserve o pedido comercial e os demais registros necessários no sistema; retirar um grupo fiscal indevido não significa apagar a venda ou perder os dados que deram origem a ela. A correção deve atingir a associação incorreta entre dados internos e a estrutura da NFF.

Não mantenha uma estrutura vazia como suposta solução. Apagar somente o conteúdo de xSolic deixa o grupo presente e ainda pode desrespeitar os requisitos internos do leiaute. A equipe deve gerar novamente o XML coerente com a modalidade real, validá-lo pelo processo do emissor e produzir a assinatura correspondente. Não altere diretamente o arquivo depois de assinado.

Quando a solicitação realmente pertence à NFF

Se a operação foi iniciada no aplicativo NFF, confirme a identificação da solicitação e o caminho percorrido até a geração do XML. O suporte responsável deve avaliar por que o documento apareceu com tipo diferente de3 e se algum componente reutilizou dados de outro fluxo.

Nesse caso, simplesmente excluir o grupo pode retirar uma informação necessária à emissão pretendida. O procedimento deve restabelecer o fluxo correto, mantendo a solicitação legítima e o tipo de emissão correspondente. A NFF também possui exigências próprias de assinatura e transmissão; um emissor convencional não passa a cumprir todo esse conjunto apenas porque recebeu tpEmis=3.

Por exemplo, considere uma integração que copia o JSON de uma solicitação NFF para um documento comum identificado com tpEmis=1. A combinação é incompatível com a ZE01-10. O diagnóstico precisa decidir, com base na operação e nos registros de origem, se houve inclusão indevida do grupo ou encaminhamento incorreto da solicitação. A decisão não pode ser tomada somente pela conveniência de eliminar o retorno.

Diferencie a 819 das rejeições próximas

A 819 corresponde ao grupo presente fora da emissão NFF. A 834 verifica o sentido oposto: tpEmis=3 sem informação de solicitação. Já a 818 trata do CNPJ-base do certificado de assinatura e a 832, do certificado de transmissão. Alterar o conteúdo do grupo não demonstra que essas outras condições estejam atendidas.

Após o ajuste, confira o arquivo novamente gerado e seu retorno. Se houve tentativas anteriores com comunicação inconclusiva, recupere a situação antes de iniciar outra emissão, evitando duplicidade. O desaparecimento da 819 não equivale à autorização nem prova que todas as demais regras tenham sido executadas. Conclua o atendimento com a resposta real e preserve a relação entre pedido, XML e resultado.

Fontes e limites

Pesquisa em16/10/2026, sem emissão ALRA, teste por UF/ambiente, consulta individual ou garantia de autorização.

• NT2021.002 v1.12: páginas4/8/9/21 lidas; imagem existente21 efetivamente inspecionada na pesquisa 818 e reutilizada por identidade. ZE01-10 íntegra, Obrig55/65, distinta da 834 e da condição de nota avulsa da820. PDF capturado em15/10, índice nacional capturado em16/10 com versão1.12 publicada28/01/2025. Divergência interna janeiro2024 no controle versus janeiro2025 na capa preservada; cronograma de série/chave não usado como nova data da 819.

• Declarações reais de infSolicNFF, xSolic, tpEmis e procEmi do schema consultado foram lidas. Essa inspeção não representa validação de XML de cliente nem dispensa regras de negócio.

• Oobj, regras gerais: seçãoZE inteira lida em corpo HTTP200; reproduz819/834 e seus predicados. Não foi alegada leitura integral de toda a compilação, nem usada regra vizinha antiga como autorização atual.

• Vinco819: ficha específica inteira lida em HTTP200, com mensagem correta e seção Soluções vazia. Abertura WEB retornou Internal Error; nenhuma causa foi inferida.

• Sonda, nota14458: captura16/10 e leitura textual integral da pesquisa 818 reutilizadas por hash. A tabela distingue819/818, mas procedimentos de atualização, serviços e menus pertencem ao software do publicador.

São três editores com seção de compilação, ficha mínima e nota de atualização, não três tutoriais completos. A busca por819/ZE01-10/infSolicNFF em seis caches de NTs2026 não encontrou alterações desses alvos; isso não é pesquisa exaustiva de toda norma. A divergência de título do Buscador818 já confrontada na pesquisa 818 não foi adotada como renumeração da 819.