01. DADOS GERAIS

02. SITUAÇÃO/REQUISITO

Erro na porcentagem "950%" no relatório FGTS ocorre quando existe apenas uma linha V3N_ORIGEM com valor 5 do evento S-2299 e demais linhas V3N_ORIGEM 1, 2 ou 3 de eventos S-1200, S-1210 ou S-2299.

03. SOLUÇÃO

1. Fonte: WSTAF010.PRW (Função GetFGTSData)

Correção da matemática do cálculo de progresso para que o denominador (total) nunca ficasse menor que o numerador (processados).

• Definição do Total (nTotalReg):

  • Antes: Recebia apenas o tamanho de aArqBase.

  • Depois: Passou a receber o maior tamanho entre aArqBase e aArqDepo.

  • Por que: Isso evita erros caso existam "dados sujos" (mais depósitos do que bases) e garante que a barra tenha uma proporção realista desde o início.

• Remoção da Subtração Dinâmica:

  • Antes: Existia o trecho If nExcluidos > 1 ... nTotalReg -= (nExcluidos - 1).

  • Depois: Esse bloco foi removido.

  • Por que: Diminuir o total (nTotalReg) enquanto o contador de processados (nRegProc) só aumentava fazia com que a divisão resultasse em números gigantes (ex: 1000%), causando o estouro do campo no banco.

2. Fonte: RH.TAF.WS.REPORTESOCIALFUNCTIONS.TLPP (Função setProgress)

Criada uma blindagem (segurança) para proteger o banco de dados.

• Trava de Segurança (Cap em 100%):

  • Adicionado: O bloco If nPerc > 100 ... nPerc := 100 ... EndIf antes da gravação (RecLock).

  • Por que: Mesmo que a lógica matemática falhe no futuro (por dados inconsistentes ou erro de código), essa função agora garante que o sistema nunca tentará gravar um valor maior que 100 na tabela V3J, evitando o crash da aplicação (Thread Error).

Resumo do Resultado

Com essas alterações combinadas:

1. O cálculo matemático ficou estável (Total fixo).

2. A barra de progresso flui corretamente (sem travar).

3. O sistema está protegido contra estouro de campo no banco de dados.

04. DEMAIS INFORMAÇÕES

Não há.

05. ASSUNTOS RELACIONADOS

• Não há.