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.

• Abaixo encontra-se detalhado  a estrutura das tabelas na Versão P11, e em seguida estão as estruturas das tabelas na versão P12

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 a estrutura atual da  P11  de saldos contábeis tem  como o objetivo  diminuir a quantidade de operações na gravação de saldos contábeis, 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 a codificação para bases codebase.

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

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.

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

Para

• 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.

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

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.