Histórico da Página

01. DADOS GERAIS

02. SITUAÇÃO/REQUISITO

No O processo de apuração cálculo do ICMS , existia um trecho de código implementado no mensal era realizado no sistema cliente (Gupta/Centura, responsável pelo estorno de débitos de ICMS por observação (motivos 2, 3, 12, 15, 16 e 17).
Esse código estava acoplado à aplicação cliente, dificultando manutenção, auditoria e impactando na performance.
Para centralizar regras de negócio e melhorar a performance, essa lógica foi migrada para PL/SQL dentro da procedure RFP_LANCTODEBITO, já responsável por tratar estornos de débito baseados em notas fiscais),

Utilizando diversas queries diretas para verificar registros em RF_APURACAOANALITICA e RF_NOTAMESTRE, somar valores e inserir resultados na tabela RF_APURAICMS.
Esse modelo dificultava manutenção e impactava na performance em grandes volumes.

03. PRÉ-REQUISITOS

Nenhum

04. SOLUÇÃO

Na versão atual, a procedure RFP_LANCTODEBITO passou a contemplar também:

...

Estorno de débito de ICMS por NF baseada em cupom fiscal (já existente).

...

Estorno de débito de ICMS por observação (motivos 2, 3, 12, 15, 16 e 17) – lógica portada do Centura:

• Exclusão prévia dos registros em duplicidade.

• Consulta unificada das observações (via UNION ALL).

• Busca da coluna de valor (RFP_BUSCABASEALIQVALOROBS).

• Inserção em RF_APURAOCORRENCIAS com SQL dinâmico.

• Tratamento adicional para transporte (quando INDVALOR = 1 ou 8, INDGERA197 = 'S', INDREGISTRO = 'C' e FINALIDADE = 'L').

Melhorias implementadas:

...

Centralização da regra no banco (facilidade de manutenção e auditoria).

...

Uso de EXECUTE IMMEDIATE para flexibilidade, substituindo trechos fixos do Centura.

• A lógica de cálculo foi migrada para o pacote PL/SQL PKG_RFAPURACAO, na procedure RFP_CALCULAICMS.

• O Centura agora apenas executa a chamada da procedure, repassando os parâmetros necessários (empresa, mês, ano, período).

• O processamento (validações, soma de valores e inserção em RF_APURAICMS) ocorre totalmente dentro do banco.

• Implementado controle de commit e tratamento de exceções no banco.

• No processo novo, o cálculo do ICMS segue uma série de filtros que garantem que somente as movimentações corretas sejam consideradas. Em primeiro lugar, apenas registros do tributo ICMS são avaliados, sempre no período mensal, desconsiderando apurações de outros tipos. Também é respeitado o campo de origem, de forma que apenas valores com APPORIGEM = 'ICMS' entrem no cálculo.

  Outro ponto importante é a diferenciação entre os registros do tipo NI e os demais. Quando se trata de apuração do tipo NI, o sistema valida a existência da nota fiscal vinculada em RF_NOTAMESTRE e exige que o documento seja de saída, com códigos fiscais que iniciem em 5, 6 ou 7, exceto o código 5605, ou ainda que seja uma operação de entrada especificamente com o código 1605. Para os demais tipos de registros, basta que se tratem de operações de saída para que possam ser considerados.

  Além disso, somente notas válidas entram no cálculo: documentos cancelados ou inválidos, indicados em CODSITDOC, são descartados, assim como notas já integradas fiscalmente, que possuam valores no campo INDNFINTEGRAFISCAL. Por fim, apenas valores positivos são somados, ignorando movimentações que resultariam em imposto nulo ou negativo

...

Melhor controle de exceções (RAISE_APPLICATION_ERROR com mensagem detalhada do SQLERRM).

...

Agrupamento de dados no próprio banco, reduzindo tráfego entre cliente/servidor.

...

• .

05. REQUISITOS DE VERSÃO

        Se estiver na versão 25.01, atualize para o Service Pack 25.01.XXX ou superior.

...