Modelagem de dados para fluxo de caixa

Bom dia Marina,

Bom hoje quando você vai fazer uma modelagem de dados você deve evitar ao máximo tabelas redundantes, certo.
O que eu estava passando para ele, referente ao banco,
é que eu faria da seguinte maneira, criaria uma tabela chamada MOVIMENTACAO, aonde a mesma iria guardar tanto os dados de entrada quanto de saída, pois se você for ver a tabela de entrada de nota e de saída por exemplo, segue o mesmo padrão.

Então nesta linha eu colocaria um atributo na tabela que poderia ser Tipo_movimentacao, que receberia S – para saída e E para entrada.

Posteriormente para fazer esse controle de saldo, não precisaria criar uma tabela novamente para ir guardando os saldos correspondentes a saída, e a entrada.

Eu poderia simplesmente fazer um select na tabela de MOVIMENTACAO, buscando pelo tipo S ou pelo tipo E, somando a coluna de valor_baixa ou valor_efetivo, levando em consideração que o cliente pode ter pago com desconto ou com multa.

Enfim, só questão de modelagem mesmo, pois um sistema que sofre uma modelagem sem este tipo de atenção posteriormente pode ter problemas.
Quando eu falo em executar diretamente no banco de dados,

O Oracle por exemplo, consegue manter praticamente toda a sua rotina pesada, diretamente feto no banco, com a utilização de PL/SQL linguagem para desenvolvimento no banco, aonde via código, eu chamo uma procedure dentro do banco de dados, e o mesmo, me retorna o valor pronto que eu desejo, ou uma sequencia de valores, e eu fico somente com regra de negocio e tratamento de tela na minha codificação.

Hoje é muito utilizado, para rotinas mito pesadas, que tem a necessidade de ser chamada varias vezes dentro de um código. Assim o banco pode retornar diretamente um bloco de informações, sem este tipo de necessidade.

Bom, espero ter conseguido tirar suas duvidas,

Qualquer coisa pode postar ai, que se eu puder ajudo.

Att,
Chiodini

quais os campos?

Desculpa, nao me expressei corretamente.

A pergunta e a seguinte: se em um sistema de fluxo de caixa eu crio uma tabela com todos os campos ou uma tabela para cada tipo como: entrada, saida saldo.

vc deseja salvar essas informações no banco?

Antonio, assim que possivel retorne se conseguiu ou não, para tentarmos ajudar.

obrigada.

Antonio Bom dia.,

Na minha visão,
para montar o fluxo de caixa,
deve ser uma tabela de movimentação.,
com uma opcao de tipoMovimentação (E - Entrada , S - Saida).

Voce até pode ter uma tabela de saudo.
mais acho amis correto fazer via banco de dados.
ou suando uma procedure.
ou via select.

qualquer dúvida estou posta ai.
att,
Chiodini

Desejo salvar no banco sim

fiquei confusa com essa de dados de entrada e saido do banco, poderia me explicar?

Leandro, obrigada.

Olá
Passo aqui para indicar o software de controle de fluxo de caixa muito bom, prático e rápido, é o da Cenize, utilizo para meu controle financeiro pessoal e acho ótimo, vale a pena dar uma olhada no site: http://cenize.com/jfinancas/controle-financeiro-empresarial

Abraços

Já vi várias soluções que utilizam o exemplo que o Leandro apresentou.
O coração dos sistemas é o banco de dados, se a modelagem dele não foi planejada da melhor forma possível compromete o sistema todo.
Já ouvi desenvolvedores falando que tinham q fazer voltas e voltas, gambiarras e gambiarras porque haviam erros na modelagem do banco de dados.

Boa tarde,

Na minha opinião eu faria com três tabelas uma para cada situação.

Não podemos ser econômicos em tabelas, quando mais tabelas melhores para filtrar dados. Os grandes software como SAP tem mais de 40 mil tabelas.

Vai criar uma tabela a mais e vai melhorar a sua vida nas consulta, por exemplo quero buscar todas as minhas entrada é na tabela entradas não preciso ficar filtrando por tipo de movimentação E ou S.
Se criar apenas uma tabela contendo as informações de entradas e saídas tudo junto você vai ter dor de cabeça mais a frente do projeto.

Se você seguir os passos abaixo vai ter sucesso.

◾Deriva do modelo conceitual e via a representação do negócio
◾Possui entidades associativas em lugar de relacionamentos n:m
◾Define as chaves primárias das entidades
◾Normalização até a 3a. forma normal
◾Adequação ao padrão de nomenclatura
◾Entidades e atributos documentados


Att.
João Antonio

Bom dia ....

Concordo com o João Antonio !

Uma coisa é movimentação financeira, que você tem um registro de entrada de dinheiro e outro registro de saída de dinheiro(Receita e Despesa), ou de estoque, que tem uma NF de saída e uma NF de entrada(Venda e Compra). Porém no fluxo de caixa, você tem a entrada de dinheiro(pagamento), e as únicas formas de saída são: ou um estorno do valor pago ou uma sangria do caixa. Portanto acredito que o melhor seria ter uma tabela de entradas, uma para os estornos[basta um relacionamento], e uma de sangria, somente para registrar as saídas de dinheiro para ser depositado ou enviado à tesouraria.

OBS.: Vale lembrar que um fluxo de caixa não é somente isso, temos que controlar abertura e fechamento de caixa, tesouraria, temos que realizar sangrias e borderôs, depende se tem vários caixas por loja ou várias lojas por empresa ... e por ai vai. [Não para fluxo de caixa financeiro e sim para controle de fluxo de caixa(PDV) de comercio ou correspondente bancário]

Oi Antônio,

eu gosto de utilizar uma tabela para lançamentos (e nos lançamentos você classifica se é uma despesa ou receita) e outras abas para análise de resultados consolidados de fluxo de caixa, DRE, contas a pagar e a receber,

tenho um passo a passo em um ebook gratuito se tiver interesse - http://planilhas.luz.vc/ebook-gratis-fluxo-de-caixa

Desculpa ser chato meu caro mas sua pergunta é muito genérica e pouco construtiva, o que parece é que você deseja que nós façamos o trabalho pra você e não é bem assim que as coisas funcionam. Poste qual sua ideia sobre a modelagem ou um protótipo do que você já tem criado para que possamos lhe auxiliar no que está correto e no que está errado. Um fluxo de caixa é algo nem um pouco trivial e depende muito do que sua empresa trabalha, uma modelagem deste tipo pode ter 5 classes ou 20.

Estive lendo os comentários postados e, particularmente, acho muito boa a solução apresentada pelo João Antônio.
Se criar uma tabela para registrar as estradas e outra para registrar as saídas, vai dividir a quantidade de informações em cada tabela.
As instruções SQL serão executadas com mais precisão do que se todas essas informações estivessem juntas, pois serão menos dados para serem verificados e filtrados.

Aqui eu também fiquei interessado é possível o fluxo ser apenas uma views por exemplo Se toda E- entrada for feita pelo POS ele vai somar todo o total das vendas e subtrair todas as saídas ou despesas. Mas como é que eu posso fazer com que ele lance isso no centro de custos identificando que é uma receita ou despesa? E se for para anular uma fatura como voltar ao estoque Anterior? Aguardo uma resposta. Se for possível pode mostrar as tabelas que fazem parte do fluxo do caixa?

Bom dia Ariclenes Maciel.
No caso da modelagem que eu apresentei no começo da discussão é possível fazer em uma View a consulta sim.
O que vai identificar se é uma entrada ou uma saída é exatamente o campo Tipo_Movimentação que vai ser um campo onde deve se informar se é uma entrada ou uma saída.

Alguém acima disse que não se deve economizar em tabelas, eu ate concordo com essa frase, porém criar duas tabelas com a mesma estrutura de campos, no banco não esta dentro dos padrões de banco de dados, mas nada impede de ser feito.
Um SLQ com duas tabela no caso de querer fazer a entrada - despesas pode ter certeza que vai ser mais pesado do que um select em cima da mesma tabela separando entrada e saída somente pelo campo tipo_movimentação.

Mas volto a dizer não existe o correto e o errado, existe o performático.

A regra de entidade relacionamento deixa claro que no caso de duas tabelas que controlam a mesma coisa no caso movimentação, onde somente um dado se diferencia deve ser uma tabela unica e ser distinguida pelo tipo de dado daquela tabela, sendo assim se a tabela de movimentação tiver 30 campos você evita que no seu banco tenha 30 campos a mais tratando somente com um campo identificando o tipo da informação.

No caso da estrutura eu criaria:

Tabela 1: Movimentos
Campos
Empresa - Para identificar caso utilize duas ou mais empresas.
Código do Movimento - Pode ser utilizado um identificar.
Código do Evento - Caso queira ter a informação de que evento gerou a movimentação.
Tipo do movimento - Para identificar se o movimento é de entrada ou de saída.
Código do usuário - Para identificar quem fez a movimentação.
Data da movimentação - Data e hora que foi gerado a movimentação.
Observação - para caso tenha necessidade de uma observação no movimento

Ligada a esta tabela ainda Criaria uma tabela 2 referente ao itens da movimentação com os campos:
Código da movimentação - Campo de ligação a tabela de movimentação.
Código do produto - Campo para identificar o produto movimentado.
Código do Centro de Custos - Para identificar o centro de custos.
Valor unitário - Identificar o valor unitário do produto.
Valor Total - Para identificar o valor total do produto.
Quantidade - Identificar a quantidade movimentada.


Basicamente isso, depois tem que ver o que se alinha também ao sistema que você esta criando.
Ainda para manter estas tabelas existe as tabelas auxiliares ex: EMPRESAS, USUARIOS, EVENTOS, PRODUTOS, CENTRO_CUSTOS

Referente ao anulamento da Fatura creio que você estava se referindo a movimentação de entrada e de saída certo.
Neste caso você pode programar através de uma PROCEDURE o seu banco de dados para que na exclusão de uma movimentação ele identifique-a para ver se trata de uma Entrada ou de uma Saída, sendo uma entrada ele diminuiu o saldo do seu estoque, do contrário ele soma no estoque.

Lembrando que, para cada caso precisa ser estudado o contexto do sistema que esta sendo criado.
Normalmente em um sistema de mercado a movimentação se da através das Notas Fiscais de entrada ou de saída.

Espero ter ajudado.

[]´s
Chiodini

Bom dia Ariclenes Maciel.
No caso da modelagem que eu apresentei no começo da discussão é possível fazer em uma View a consulta sim.
O que vai identificar se é uma entrada ou uma saída é exatamente o campo Tipo_Movimentação que vai ser um campo onde deve se informar se é uma entrada ou uma saída.

Alguém acima disse que não se deve economizar em tabelas, eu ate concordo com essa frase, porém criar duas tabelas com a mesma estrutura de campos, no banco não esta dentro dos padrões de banco de dados, mas nada impede de ser feito.
Um SLQ com duas tabela no caso de querer fazer a entrada - despesas pode ter certeza que vai ser mais pesado do que um select em cima da mesma tabela separando entrada e saída somente pelo campo tipo_movimentação.

Mas volto a dizer não existe o correto e o errado, existe o performático.

A regra de entidade relacionamento deixa claro que no caso de duas tabelas que controlam a mesma coisa no caso movimentação, onde somente um dado se diferencia deve ser uma tabela unica e ser distinguida pelo tipo de dado daquela tabela, sendo assim se a tabela de movimentação tiver 30 campos você evita que no seu banco tenha 30 campos a mais tratando somente com um campo identificando o tipo da informação.

No caso da estrutura eu criaria:

Tabela 1: Movimentos
Campos
Empresa - Para identificar caso utilize duas ou mais empresas.
Código do Movimento - Pode ser utilizado um identificar.
Código do Evento - Caso queira ter a informação de que evento gerou a movimentação.
Tipo do movimento - Para identificar se o movimento é de entrada ou de saída.
Código do usuário - Para identificar quem fez a movimentação.
Data da movimentação - Data e hora que foi gerado a movimentação.
Observação - para caso tenha necessidade de uma observação no movimento

Ligada a esta tabela ainda Criaria uma tabela 2 referente ao itens da movimentação com os campos:
Código da movimentação - Campo de ligação a tabela de movimentação.
Código do produto - Campo para identificar o produto movimentado.
Código do Centro de Custos - Para identificar o centro de custos.
Valor unitário - Identificar o valor unitário do produto.
Valor Total - Para identificar o valor total do produto.
Quantidade - Identificar a quantidade movimentada.


Basicamente isso, depois tem que ver o que se alinha também ao sistema que você esta criando.
Ainda para manter estas tabelas existe as tabelas auxiliares ex: EMPRESAS, USUARIOS, EVENTOS, PRODUTOS, CENTRO_CUSTOS

Referente ao anulamento da Fatura creio que você estava se referindo a movimentação de entrada e de saída certo.
Neste caso você pode programar através de uma PROCEDURE o seu banco de dados para que na exclusão de uma movimentação ele identifique-a para ver se trata de uma Entrada ou de uma Saída, sendo uma entrada ele diminuiu o saldo do seu estoque, do contrário ele soma no estoque.

Lembrando que, para cada caso precisa ser estudado o contexto do sistema que esta sendo criado.
Normalmente em um sistema de mercado a movimentação se da através das Notas Fiscais de entrada ou de saída.

Espero ter ajudado.

[]´s
Chiodini

DESCONSIDERAR OS OUTROS
AQUI ONDE FALO DO FLUXO DE CAIXA

Bom dia Ariclenes Maciel.
No caso da modelagem que eu apresentei no começo da discussão é possível fazer em uma View a consulta sim.
O que vai identificar se é uma entrada ou uma saída é exatamente o campo Tipo_Movimentação que vai ser um campo onde deve se informar se é uma entrada ou uma saída.
 
Alguém acima disse que não se deve economizar em tabelas, eu ate concordo com essa frase, porém criar duas tabelas com a mesma estrutura de campos, no banco não está dentro dos padrões de banco de dados, mas nada impede de ser feito.
Um SLQ com duas tabelas no caso de querer fazer a entrada - despesas pode ter certeza que vai ser mais pesado do que um select em cima da mesma tabela separando entrada e saída somente pelo campo tipo_movimentação.
 
Mas volto a dizer não existe o correto e o errado, existe o performático.
 
A regra de entidade relacionamento deixa claro que no caso de duas tabelas que controlam a mesma coisa no caso movimentação, onde somente um dado se diferencia deve ser uma tabela única e ser distinguida pelo tipo de dado daquela tabela, sendo assim se a tabela de movimentação tiver 30 campos você evita que no seu banco tenha 30 campos a mais tratando somente com um campo identificando o tipo da informação.
 
No caso da estrutura do Fluxo de Caixa é algo que deve se analisar com base nas informações que teu sistema quer apresentar ou não.
Vou dar um exemplo básico a baixo de como eu criaria as tabelas mas com campos básicos.
 
Tabela 1 - LANCAMENTOS_FLUXO
Campos da tabela:
CODIGO DO LANÇAMENTO:
CODIGO DA EMPRESA:
CODIGO FORMA DE PAGAMENTO:
CODIGO HISTORICO DO FLUXO:
CODIGO DO BANCO:
CODIGO PESSOA:
CODIGO PLANO DE CONTAS:
CODIGO TIPO LANÇAMENTO:
CODIGO DO USUARIO QUE CRIOU:
CODIGO USUÁRIO QUE ALTEROU:
CODIGO CENTRO DE CUSTOS:
DATA DO LANÇAMENTO:
DATA ALTERAÇÃO LANÇAMENTO:
OBSERVAÇÕES:
VALOR LANÇAMENTO
VALOR IOF:
VALOR JUROS:
 
A tabela principal do Fluxo eu imaginaria algo desta forma, basicamente:
Porem o fluxo pode ir muito alem disso como por exemplo, uma tabela filha ligando as duplicatas pagas, outra tabela ligando as duplicatas recebidas e assim por diante dependendo do tamanho e do tipo de sistema que você quer desenvolver.
 
Basicamente isso, depois tem que ver o que se alinha também ao sistema que você esta criando.
Ainda para manter estas tabelas existe as tabelas auxiliares ex: EMPRESAS, USUARIOS, FORMA_DE_PAGAMENTO, HISTORICO_FLUXO, BANCOS, PLANO_CONTAS, TIPO_LANCAMENTOS, CENTRO_CUSTOS e assim por diante, que se fosse colocar aqui daria paginas (risos).
 
Referente a anulação de um lançamento, também é algo que tem alguns fatores que devem ser levados em conta.
Este lançamento ja foi baixado?
Está dentro do período onde se pode mexer?
 
Existem várias regras para esse estorno.
Mas para fazer o estorno eu faria uma PROCEDURE no banco de dados, onde verificaria o tipo de lançamento se é Entrada ou saída e faria a aplicação reversa do resultado do lançamento, ou seja, se for de entrada eu diminuiria o saldo das contas onde foram acrescentados, e se fosse uma saída eu acresceria das contas onde foram diminuídos.
 
Lembrando que no fluxo um lançamento sempre precisa ter uma conta de contra ponto, ou seja, uma conta débito e outra conta crédito.
 
Lembrando ainda que, para cada casa precisa ser estudado o contexto do sistema que está sendo criado.
 
 
Espero ter ajudado.
 
[]´s
Chiodini