Reestruturação dos Saldos Contábeis.

Os saldos contábeis foram

reinscritos, pois

as rotinas de saldo com lançamento retroativo de um grande período demandavam muito processamento e tempo do sistema.

Exemplo  : Se tivéssemos que fazer um lançamento retroativo pela versão Protheus 11 o tempo de processamento  é bem maior que na versão Protheus 12. 

Conforme pode ser visto na tela abaixo na Na versão 11 do Protheus, tínhamos 11 tabelas e 8 campos como, saldo atual, saldo anterior, movimento e movimento por período que totalizavam 88 operações distintas isto para cada transição. 

Na Versão 12 do Protheus,   não tem  saldo a cada dia, passou  a ter 2 tabelas 8 tabelas, gravando dois valores Debito e Crédito, que são  : (

• 4 tabelas mensais

• 4 quatro tabelas diárias

A reestruturação das tabelas de saldo possui os seguintes objetivos:

• Composição de saldos de forma mais simples;
• Tabelas normalizadas;
• Ganho de desempenho para leitura/escrita nos bancos;
• Diminuição do tempo de inclusão de lançamentos contábeis. 

Versão P11 - 

Estrutura

de

tabelas

Todas as tabelas de saldo possuem os seguintes conceitos em suas estruturas:

• Registro do saldo diário.
• Quando não tiver movimento no dia, não é gravada a informação saldo.
• Em todas as linhas de registros constam os seguintes valores:
  • Saldo Débito (D): Soma dos valores de débito no dia para a entidade.

• Saldo Crédito (C): Soma dos valores de crédito no dia para a entidade.
• Saldo Atual Débito(D): Soma de todos os valores de débitos até o dia (inclusive o dia) para a entidade.
• Saldo Atual Crédito(C): Soma de todos os valores de crédito até o dia (inclusive o dia) para a entidade.

Saldo Anterior a Débito(D): Soma de todos os valores de débito até o dia anterior para a entidade.

• Saldo Anterior a Crédito(C): Soma de todos os valores de crédito até o dia anterior para a entidade. 

A estrutura atual foi concebida com o objetivo de priorizar a consulta das informações utilizando os métodos de pesquisa codebase que consiste da pesquisa direta do registro utilizando a sua chave de busca (comando dbseek), porém, essa estrutura colocava a maior carga de processamento na operação de gravação, principalmente no processamento dos campos de saldo atual D/C e saldo anterior D/C.

Um exemplo dessa situação:

• Uma empresa possui os seguintes lançamentos contábeis no sistema:

   

• O sistema irá calcular os saldos das contas e os registrará na tabela CT7 - Saldos por conta. O registro da conta Caixa (11001) ficará conforme o quadro a seguir:

   

Em uma situação aonde o usuário incluiria um lançamento no dia 26/01 o sistema processa o cálculo

de 6

 campos de valores para incluir um novo registro na tabela de saldo por conta.

Em outra situação que o usuário precise incluir um lançamento retroativo no dia 03/01/2013, o sistema precisa realizar o mesmo cálculo de 6 campos para incluir o registro do saldo nesse dia. Porém ele precisa recalcular e atualizar os registros de saldos dos dias 15/01 e 25/01, pois os campos de saldo atual D/C e saldo anterior D/C estarão desatualizados.

Nessa situação de gravação de lançamento o sistema precisa realizar mais 8 operações totalizando 14 operações.

Se adicionarmos as outras entidades contábeis e em um lançamento retroativo de 90 dias temos a seguinte quantidade de operações:

• Atualização 11 tabelas
• 6 campos por tabelas
• 90 dias
• Total aproximando de de 5940 operações operações. 

Em uma realidade de milhares de registros de lançamento contábeis, verificamos que a estrutura atual não é escalável, provocando 

perda de desempenho e serialização da gravação no banco de dados (no caso de múltiplos usuários estarem gravando ao mesmo tempo).

Versão

P12 - Estrutura de tabelas

Ao  alterar PropostaA solução proposta nesse projeto é alterar a estrutura atual de da  P11  de saldos contábeis com tem  como o objetivo de diminuir  diminuir a quantidade de operações na gravação de saldos contábeis.Esse projeto também tem o objetivo da , e consequente a normalização das tabelas, garantindo uma melhor utilização dos recursos dos bancos de dados relacionais. Com a evolução do sistema na versão 12, não teremos 
mais teremos  mais a codificação para bases codebase.

Sendo assim simplificaremos  os , simplificando os códigos fontes atuais de consulta e gravação de saldos e utilizando melhor os recurso dos banco de dados relacionais.

 Serão criadas as seguintes tabelas para esse projeto:

 Abaixo  a estrutura das tabelas na versão P12

As novas tabelas de saldos terão os seguintes conceitos na sua estrutura :

• Registro do saldo diário nas tabelas de saldos diários
• Registro do saldo mensal nas tabelas de saldos mensais, somando os valores dos saldos diários no período.
  • Para facilitar na montagem das queries e procedures, as tabelas de saldos mensais terão o campo que identifica o período com o tipo data e terá como conteúdo sempre o primeiro dia do mês.
    
    

• Quando não tiver movimento no dia, não será gravada a informação de saldo no dia.
• Em todas as linhas de registros constarão os seguintes valores:
  • Saldo Débito (D): Soma dos valores de débito no dia para a entidade.
  • Saldo Crédito (C): Soma dos valores de crédito no dia para a entidade.

• Quando não tiver movimento no dia, não será gravada a informação de saldo no dia.
• Em todas as linhas de registros constarão os seguintes valores:
  • Saldo Débito (D): Soma dos valores de débito no dia para a entidade.
  • Saldo Crédito (C): Soma dos valores de crédito no dia para a entidade.

Para ilustrar o ganho com essa nova estrutura, vamos utilizar o exemplo anterior:

Uma empresa possui os seguintes lançamentos contábeis no sistema:

O sistema irá calcular os saldos das contas e os registrará na tabela CQ0 - Saldo por conta no Mês e CQ1 – Saldo por Conta No Dia. O registro da conta Caixa (11001) ficará conforme os quadros a seguir: 

Em uma situação aonde o usuário incluiria um lançamento no dia 26/01 o sistema irá processar o cálculo de de 4 campos  campos de valores para incluir um novo registro na tabela de saldo por conta no Dia e no Mês.

Em outra situação que o usuário precise incluir um lançamento retroativo no dia 03/01/2013, o sistema realizará o mesmo cálculo 

de 4 campos para incluir os registros do saldo nesse dia. Com a estrutura proposta o sistema sistema não precisará  precisará realizar o cálculo ou atualização de de nenhum outro  outro dia. 

Se adicionarmos as outras entidades contábeis e em um lançamento retroativo de 90 dias temos a seguinte quantidade de operações:

• Atualização 10 tabelas
• 2 campos por tabelas
• 90 dias

• Total

• de 20

•  operações, pois será necessário atualizar o saldo somente do dia e do mês que foi incluído o registro.

Na estrutura proposta, independentemente da quantidade de dias para o lançamento retrocedente, a quantidade de operações se manterá a mesma.

A lógica para consulta de saldos nessa nova estrutura deverá ser alterada utilizando query para retornar os valores de saldo de uma conta.

Essa lógica será detalhada na especificação das alterações nos relatórios e consultas e funcionará da seguinte forma:

1. Será realizada uma query utilizando a função SUM para trazer a soma de todos os

1. saldos mensais

1.  até o mês anterior do saldo que se deseja a consulta.

1. Será realizada uma query utilizando a função SUM para trazer a soma dos saldos diários do primeiro dia do período até o dia do saldo que se deseja a consulta.

1. O saldo atual D/C

1.  será a soma do resultado do passo 1 com o passo 2

1.  Será realizada uma query utilizando a função SUM para trazer a soma dos saldos diários do primeiro dia do período até o

1. dia anterior

1.  do saldo que se deseja a consulta.

1. O saldo anterior D/C

1.  será a soma do resultado do passo 1 com o passo 4

Utilizando os dados do exemplo anterior, para a consulta do saldo da conta no dia 15/01/13, o sistema irá realizar os seguintes procedimentos:

• Soma dos saldos mensais até o mês de dezembro de 2012

TABELA DE SALDOS BÁSICOS - P12 (MV_ATUSAL - Define Gravação lançamento/ Reprocessamento - on line)

Tabelas de Saldos das Novas Entidades Contábeis

NOVAS  TABELAS DE SALDOS  - P12 

Descrição

Importante : Na nova estrutura proposta, apenas teremos como tabelas de saldos compostos a CQ8 e CQ9 que corresponde na estrutura antiga à tabela CTU - Saldo por Entidade Gerencial.

• Total

• de 20

•  operações, pois será necessário atualizar o saldo somente do dia e do mês que foi incluído o registro.

Na estrutura proposta, independentemente da quantidade de dias para o lançamento retrocedente, a quantidade de operações se manterá a mesma

.

O