Início / TOTVS Linha Protheus / Documentos Eletrônicos Protheus

📘 Reforma Tributária: como corrigir a Rejeição 1111 — Grupo de Devolução do IBS da UF informado indevidamente


Data de publicação: 03/08/2026

🎯 Objetivo

Orientar o diagnóstico e a correção da mensagem:

1111 - Rejeição: Grupo de Devolução do IBS da UF informado indevidamente
[nItem: 999]

A ocorrência está relacionada à geração indevida do grupo gDevTrib, pertencente à estrutura do IBS da Unidade Federativa, no XML da NF-e emitida pelo TOTVS Backoffice – Linha Protheus. A correção oficial exige atualização do ambiente e aplicação de uma versão específica do fonte NFESEFAZ.PRW. (Central de Atendimento TOTVS)

🧩 Ambiente

A orientação oficial se aplica ao seguinte cenário:

  • Produto: TOTVS Backoffice – Linha Protheus;

  • Processo: Documentos Eletrônicos;

  • Documento: NF-e;

  • Contexto fiscal: Reforma Tributária do Consumo;

  • Versões: todas as versões contempladas pelos pacotes disponibilizados pela TOTVS. (Central de Atendimento TOTVS)

🔎 O que significa a Rejeição 1111

A rejeição ocorre quando o XML da NF-e apresenta o grupo:

<gDevTrib>
    ...
</gDevTrib>

dentro da estrutura relacionada ao IBS da UF:

gIBSUF/gDevTrib

em uma situação na qual esse grupo não deveria ter sido informado.

A SEFAZ valida que o grupo de devolução de tributo do IBS da UF seja apresentado somente nas operações permitidas pela legislação e pelas regras técnicas da NF-e. Quando o Protheus gera essa estrutura em um contexto não autorizado, o documento é rejeitado pelo código 1111. (Central de Atendimento TOTVS)

🧠 Qual é a finalidade do grupo gDevTrib

O grupo gDevTrib está relacionado à devolução de tributo no contexto do IBS da Unidade Federativa.

Sua presença no XML não depende apenas de a operação ser denominada internamente como devolução. A geração precisa observar:

  • a finalidade efetiva do documento;

  • o tipo de operação fiscal;

  • as regras previstas na Nota Técnica;

  • o tratamento do IBS na operação;

  • as regras de validação vigentes na data de emissão;

  • as condições específicas que autorizam a devolução do IBS da UF.

Portanto, quando o grupo é montado automaticamente fora dessas condições, a SEFAZ entende que a estrutura foi informada indevidamente e rejeita a NF-e. (Central de Atendimento TOTVS)

📋 Descrição técnica da ocorrência

O fluxo da rejeição pode ser resumido da seguinte forma:

  1. o Protheus gera os dados fiscais da NF-e;

  2. o fonte responsável pela montagem do XML inclui o grupo gDevTrib;

  3. o TSS transmite o documento eletrônico;

  4. a SEFAZ valida a estrutura gIBSUF/gDevTrib;

  5. a operação não atende às condições para utilização desse grupo;

  6. a SEFAZ retorna a Rejeição 1111;

  7. a NF-e permanece sem autorização.

A documentação oficial direciona a correção para a atualização do fonte NFESEFAZ.PRW e do pacote correspondente à release, não apresentando a ocorrência como um simples problema cadastral de TES, produto ou cliente. (Central de Atendimento TOTVS)

✅ Solução oficial disponibilizada pela TOTVS

Para corrigir a geração indevida do grupo de devolução do IBS da UF, o ambiente deve possuir o fonte:

NFESEFAZ.PRW

com data de 29/07/2026 ou superior. (Central de Atendimento TOTVS)

A TOTVS orienta aplicar dois componentes disponibilizados no pacote da respectiva release:

  • o patch de atualização;

  • o fonte NFESEFAZ.PRW.

Os dois componentes devem ser aplicados no ambiente Protheus. A aplicação isolada de apenas um dos artefatos não corresponde ao procedimento completo descrito na documentação oficial. (Central de Atendimento TOTVS)

📦 Pacotes por release

A TOTVS disponibilizou pacotes específicos para as seguintes releases:

Release do ProtheusIdentificador do pacoteCondição informada
12.1.23101261712Somente para clientes com garantia estendida
12.1.24101261713Somente para clientes com garantia estendida
12.1.25101261711Pacote correspondente à release
12.1.26101261714Pacote correspondente à release

Os pacotes devem ser obtidos pelos canais oficiais da TOTVS, utilizando o acesso autorizado do cliente ao Portal de Suporte. (Central de Atendimento TOTVS)

⚠️ Releases com garantia estendida

Para as releases 12.1.2310 e 12.1.2410, a documentação identifica os pacotes como destinados somente aos clientes que possuem garantia estendida.

Caso a atualização seja aplicada e o Protheus apresente bloqueio ou erro relacionado à garantia estendida, a orientação da TOTVS é registrar um chamado para a equipe de Framework, responsável por analisar a situação. (Central de Atendimento TOTVS)

🛠️ Procedimento recomendado de atualização

1. 🔍 Identificar a release do ambiente

Antes de baixar qualquer pacote, confirme a release efetivamente utilizada:

12.1.2310
12.1.2410
12.1.2510
12.1.2610

Não utilize pacote destinado a uma release diferente, ainda que o nome da correção seja semelhante.

2. 💾 Realizar os backups

Antes da aplicação, recomenda-se preservar:

  • cópia do RPO atual;

  • cópia do fonte NFESEFAZ.PRW atualmente compilado;

  • backup do ambiente;

  • evidência da versão da LIB;

  • evidência da release;

  • XML rejeitado;

  • retorno completo da SEFAZ.

Essa etapa permite rastrear a situação anterior e executar um plano de retorno caso seja identificada incompatibilidade durante a atualização.

3. 📥 Obter o pacote oficial

Acesse o Portal de Suporte TOTVS e faça o download do pacote correspondente à release do ambiente.

O conteúdo deve contemplar:

Patch da correção
NFESEFAZ.PRW

A documentação determina a aplicação de ambos no Protheus. (Central de Atendimento TOTVS)

4. 🧪 Aplicar primeiro em homologação

Antes da aplicação em produção:

  • interrompa as emissões de teste;

  • realize o backup do RPO;

  • aplique o patch;

  • compile o fonte NFESEFAZ.PRW;

  • confirme que o fonte compilado possui data igual ou superior a 29/07/2026;

  • reinicie os serviços necessários;

  • gere uma nova NF-e;

  • valide o XML;

  • transmita o documento em ambiente de homologação.

5. 🧱 Aplicar o patch

O patch deve ser aplicado utilizando os procedimentos oficiais de atualização do Protheus, respeitando:

  • ambiente correto;

  • RPO correspondente à release;

  • idioma do repositório;

  • compatibilidade da LIB;

  • sequência de aplicação definida para o ambiente;

  • ausência de usuários durante a manutenção, quando necessário.

6. 🧾 Compilar o NFESEFAZ.PRW

Após a aplicação do pacote, compile o fonte:

NFESEFAZ.PRW

A versão compilada deve ser de 29/07/2026 ou posterior. (Central de Atendimento TOTVS)

Antes da compilação, verifique se existe uma versão customizada desse fonte. Caso exista, a equipe técnica deve avaliar cuidadosamente os ajustes locais antes de substituir ou compatibilizar o programa.

7. 🔄 Reiniciar os serviços

Depois da atualização:

  • reinicie os serviços do AppServer envolvidos na emissão;

  • confirme o carregamento do RPO atualizado;

  • valide o console do AppServer;

  • verifique a ausência de erros de compilação;

  • confirme a comunicação entre Protheus e TSS.

8. 🧾 Gerar uma nova NF-e

Para validar a correção, gere preferencialmente uma nova NF-e, evitando usar exclusivamente um documento montado antes da atualização.

A nova emissão deve utilizar:

  • a mesma operação que apresentava a rejeição;

  • os mesmos critérios fiscais necessários ao teste;

  • a TES previamente validada;

  • os dados de IBS e CBS aplicáveis;

  • a versão atualizada do fonte de geração do XML.

🔍 Como validar se a correção funcionou

1. Conferir o XML antes da transmissão

Analise o XML gerado e localize a estrutura:

<gDevTrib>

Para a operação que não admite devolução do IBS da UF, o grupo não deverá ser gerado indevidamente.

A ausência do grupo deve resultar da correção oficial aplicada ao processo de geração do XML, e não de alteração manual no arquivo.

2. Transmitir a NF-e

Após a conferência, transmita o documento pelo fluxo normal do TSS.

O resultado esperado é:

NF-e autorizada

sem o retorno:

1111 - Grupo de Devolução do IBS da UF informado indevidamente

3. Conferir o retorno da SEFAZ

Registre como evidência:

  • chave de acesso;

  • número e série da NF-e;

  • XML de envio;

  • XML autorizado;

  • protocolo de autorização;

  • retorno do TSS;

  • horário do teste;

  • versão do fonte aplicado.

📅 Parâmetro MV_2500240

A documentação também apresenta o parâmetro:

MV_2500240

Esse parâmetro deve ser criado como tipo Data e possui valor padrão:

03/08/2026

A data corresponde ao início de vigência, em produção, de novas regras relacionadas à Nota Técnica. (Central de Atendimento TOTVS)

⚙️ Exemplo de criação

Nome:      MV_2500240
Descrição: Regras de validacao
Conteúdo:  03/09/2026
Tipo:      Data
Filial:    Corrente

O parâmetro é controlado por filial, conforme o exemplo publicado pela TOTVS. (Central de Atendimento TOTVS)

🧩 Regras associadas ao parâmetro

A documentação relaciona o parâmetro às seguintes alterações:

Regra incluída

I08-141

Regras alteradas

I08-140
I08-144
VC02-07
VC02-10
UB18-10
UB37-10
UB56-10
B25-80

Também foi criado um novo tipo de nota de crédito:

06 - Retorno por recusa parcial na entrega

(Central de Atendimento TOTVS)

⚠️ Inconsistência textual na documentação do parâmetro

A página oficial informa que, para postergar a entrada das regras, o parâmetro deveria receber uma data “menor ou igual à data corrente”. Entretanto, o próprio exemplo utiliza:

Data atual:          03/08/2026
Valor do parâmetro:  03/09/2026

ou seja, uma data futura.

Há, portanto, uma inconsistência entre a descrição textual e o exemplo apresentado pela página. Como o exemplo utiliza uma data posterior para postergar a vigência, a configuração deve ser validada em homologação e, em caso de dúvida, confirmada diretamente com a TOTVS antes da alteração em produção. (Central de Atendimento TOTVS)

🧠 Atualização técnica ou parametrização fiscal?

A solução oficial apresentada para a Rejeição 1111 é essencialmente uma correção técnica na geração do XML, composta pela aplicação do patch e do fonte atualizado NFESEFAZ.PRW.

Isso não elimina a necessidade de validar a configuração fiscal da operação. Contudo, quando o grupo gDevTrib está sendo gerado indevidamente por uma versão anterior do programa, alterar somente TES, CST ou parâmetros tributários poderá não corrigir a causa principal indicada pela TOTVS. (Central de Atendimento TOTVS)

⚠️ O que não fazer

Durante o tratamento, não é recomendado:

  • remover manualmente a tag do XML antes da transmissão;

  • modificar diretamente o XML gerado;

  • utilizar fontes alterados por terceiros sem validação;

  • copiar um NFESEFAZ.PRW de outra release;

  • aplicar apenas o fonte e ignorar o patch oficial;

  • aplicar apenas o patch sem conferir a versão do fonte;

  • atualizar diretamente em produção sem teste;

  • alterar TES ou impostos aleatoriamente para tentar eliminar a rejeição;

  • retransmitir indefinidamente o mesmo documento sem corrigir a origem.

A remoção manual do grupo pode até alterar pontualmente o XML, mas não corrige de forma controlada o processo de geração e pode produzir documentos incompatíveis com outras regras fiscais.

📋 Checklist técnico

Antes da atualização

  •  Release do Protheus identificada;

  •  condição de garantia estendida validada;

  •  pacote correto localizado;

  •  backup do RPO realizado;

  • versão atual do NFESEFAZ.PRW preservada;

  •  XML rejeitado armazenado;

  •  retorno completo da SEFAZ registrado;

  •  ambiente de homologação disponível.

Durante a atualização

  •  patch correspondente à release aplicado;

  • fonte NFESEFAZ.PRW compilado;

  •  fonte com data de 29/07/2026 ou superior;

  •  ausência de erros de compilação;

  •  AppServer reiniciado;

  •  RPO atualizado carregado corretamente;

  •  comunicação com o TSS validada.

Depois da atualização

  •  nova NF-e gerada;

  •  XML analisado;

  • grupo gDevTrib não gerado indevidamente;

  •  IBS e CBS validados;

  •  documento transmitido;

  •  NF-e autorizada;

  •  evidências arquivadas;

  •  procedimento homologado antes da produção.

✅ Resultado esperado

Após aplicar o patch correspondente à release e compilar o fonte NFESEFAZ.PRW com data de 29/07/2026 ou superior, o Protheus deverá deixar de gerar indevidamente o grupo gDevTrib nas operações em que a estrutura não é permitida.

Com o XML corrigido, a NF-e deverá ser transmitida pelo TSS e autorizada pela SEFAZ sem a Rejeição 1111. (Central de Atendimento TOTVS)

💡 Boas práticas

  • manter Protheus, LIB e TSS atualizados;

  • acompanhar os comunicados da Reforma Tributária;

  • testar novas regras fiscais em homologação;

  • comparar o XML anterior e posterior à correção;

  • documentar os patches aplicados;

  • manter controle sobre fontes compilados;

  • evitar customizações em programas padrão;

  • validar a vigência dos parâmetros por filial;

  • envolver as áreas de TI e Fiscal na homologação;

  • abrir chamado para o Framework quando houver bloqueio de garantia estendida;

  • utilizar exclusivamente artefatos oficiais da TOTVS.

❓ FAQ

1. O que causa a Rejeição 1111?

A rejeição ocorre quando o grupo gIBSUF/gDevTrib, referente à devolução do IBS da UF, é enviado em uma situação na qual sua utilização não é permitida. (Central de Atendimento TOTVS)

2. A rejeição é causada exclusivamente pela TES?

A documentação oficial direciona a correção para o patch e para o fonte NFESEFAZ.PRW. A TES deve ser validada, mas a solução publicada trata diretamente da geração do XML. (Central de Atendimento TOTVS)

3. Qual fonte deve ser atualizado?

O fonte:

NFESEFAZ.PRW

com data de 29/07/2026 ou superior. (Central de Atendimento TOTVS)

4. Preciso aplicar o patch e o fonte?

Sim. A orientação publicada informa que o pacote contém um patch e o fonte NFESEFAZ.PRW, e que ambos devem ser aplicados no Protheus. (Central de Atendimento TOTVS)

5. Existe pacote para a release 12.1.2510?

Sim. O identificador apresentado para essa release é o pacote 1261711. (Central de Atendimento TOTVS)

6. A release 12.1.2410 está contemplada?

Sim, por meio do pacote 1261713, identificado como destinado a clientes com garantia estendida. (Central de Atendimento TOTVS)

7. O que fazer se ocorrer bloqueio por garantia estendida?

A TOTVS orienta abrir um chamado para a equipe de Framework analisar a ocorrência. (Central de Atendimento TOTVS)

8. Posso remover manualmente a tag gDevTrib?

Não é uma solução recomendada. O correto é atualizar o processo que gera o XML, utilizando o patch e o fonte oficial.

9. Para que serve o MV_2500240?

O parâmetro controla a data de início das novas regras de validação relacionadas à Nota Técnica e deve ser criado como tipo Data, por filial. (Central de Atendimento TOTVS)

10. O exemplo do MV_2500240 está coerente com o texto da página?

Não integralmente. O texto menciona data menor ou igual à corrente, enquanto o exemplo utiliza uma data futura. A configuração deve ser validada antes de ser aplicada em produção. (Central de Atendimento TOTVS)

🔗 Referência oficial

TOTVS — Cross Segmentos — Backoffice Protheus — Documentos Eletrônicos — NF-e — Reforma Tributária — Rejeição 1111: Grupo de Devolução do IBS da UF informado indevidamente. (Central de Atendimento TOTVS)

👤 Autor

Fabrizio Augusto Ventavolo
Consultor Especialista TOTVS — Mastersiga Consultoria

“Conectamos tecnologia, processos e pessoas para acelerar resultados com excelência em sistemas TOTVS.”

Atualizado em 03/08/2026
Este artigo foi útil?  
Agradecemos sua avaliação.