Dúvida de modelagem de contas de bancos

[Bruno Carneiro]

Quero modelar a movimentação financeira em uma conta.

A conta tem um saldo inicial.

A partir daí haverão várias movimentações.

O saldo inicial + as movimentações vão gerar um novo saldo.

Como eu devo tratar esse saldo de forma eficiente?

1- Guardar somente o saldo inicial e toda vez recalcular o saldo baseado nas movimentações?
2- Guardar o saldo atual em um campo.

O problema da abordagem número dois é que toda vez que alguém fizer uma nova movimentação tenho que recalcular, talvez não seja o ideal.

O que me sugerem?

[Tarcísio Sassara]

Você não pode recalcular um campo com o saldo porque você perderá o
histórico das movimentações.

Você deve criar uma tabela que armazena as movimentações e inserir
todas estas, seja positivas ou negativas.
Fica algo como:
cliente  valor      data
1         100.00   2009-09-09
1         -50.00    2009-09-09

Quando você fizer quiser pegar o saldo, você faz um soma(SUM) na coluna valor.

select cliente, sum(valor)
from movimentacoes
where cliente = 1
group by 1

Então é só adaptar esta idéia ao seu modelo.


2009/10/10 Bruno Carneiro <guimaraescarneiro@...>

>
> Quero modelar a movimentação financeira em uma conta.
>
> A conta tem um saldo inicial.
>
> A partir daí haverão várias movimentações.
>
> O saldo inicial + as movimentações vão gerar um novo saldo.
>
> Como eu devo tratar esse saldo de forma eficiente?
>
> 1- Guardar somente o saldo inicial e toda vez recalcular o saldo baseado nas
> movimentações?
> 2- Guardar o saldo atual em um campo.
>
> O problema da abordagem número dois é que toda vez que alguém fizer uma nova
> movimentação tenho que recalcular, talvez não seja o ideal.
>
> O que me sugerem?
> --
> View this message in context: http://www.nabble.com/D%C3%BAvida-de-modelagem-de-contas-de-bancos-tp25834706p25834706.html
> Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@...
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

--
Tarcisio F. Sassara
Nzb ryn. Ibpê fnor dhrz? Fvz é ryn! Gnzvelf.
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Bruno Carneiro]

Então, mas sempre que eu quiser saber o saldo vou ter que fazer esse calculo desde a data de criação da conta??

E no futuro, não vai ficar pesado depois de muito tempo com muitas movimentações?

Tarcísio Sassara wrote:

Você não pode recalcular um campo com o saldo porque você perderá o
histórico das movimentações.

Você deve criar uma tabela que armazena as movimentações e inserir
todas estas, seja positivas ou negativas.
Fica algo como:
cliente  valor      data
1         100.00   2009-09-09
1         -50.00    2009-09-09

Quando você fizer quiser pegar o saldo, você faz um soma(SUM) na coluna valor.

select cliente, sum(valor)
from movimentacoes
where cliente = 1
group by 1

Então é só adaptar esta idéia ao seu modelo.

[andrecf]

Bom dia,

Uma abordagem possível é guardar o saldo em uma tabela (por exemplo, uma tabela contendo o saldo diário, no início do dia referente) e então somar (ou subtrair) apenas as movimentações do dia referido. Muitos bancos utilizam essa abordagem, pois não se perde histórico nem usa todo o histórico para cálculos de saldo.

Exemplo:
create table saldo_diario
(numero_conta bigint,
dia_referencia date,
valor numeric(18,3)
);

create table movimentacao
(numero_conta bigint,
tipo_movimentacao bigint,  -- supondo ser chave estrangeira, isto é um exemplo apenas
valor numeric(18,3)
);

cria-se então uma função que calcula o saldo referente ao dia anterior e grava o valor em saldo_diario. Essa função seria rodada à 00h10 de todo dia, por exemplo.



Espero que esteja compreensível a idéia que passei, qualquer dúvida (se algo ficou confuso) é só perguntar.

Atenciosamente,
André.

2009/10/10 Bruno Carneiro <guimaraescarneiro@...>

Então, mas sempre que eu quiser saber o saldo vou ter que fazer esse calculo
desde a data de criação da conta??

E no futuro, não vai ficar pesado depois de muito tempo com muitas
movimentações?

Tarcísio Sassara wrote:
>
> Você não pode recalcular um campo com o saldo porque você perderá o
> histórico das movimentações.
>
> Você deve criar uma tabela que armazena as movimentações e inserir
> todas estas, seja positivas ou negativas.
> Fica algo como:
> cliente  valor      data
> 1         100.00   2009-09-09
> 1         -50.00    2009-09-09
>
> Quando você fizer quiser pegar o saldo, você faz um soma(SUM) na coluna
> valor.
>
> select cliente, sum(valor)
> from movimentacoes
> where cliente = 1
> group by 1
>
> Então é só adaptar esta idéia ao seu modelo.
>
>
>

--
View this message in context: http://www.nabble.com/D%C3%BAvida-de-modelagem-de-contas-de-bancos-tp25834706p25834956.html

Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

--
André de Camargo Fernandes



_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Bruno Carneiro]

Então, minha única dúvida ai seria se no futuro, o usuário modificasse movimentações do passado, neste caso teria que re-calcular o saldo daquele dia.

E se o saldo desse dia muda, todos os saldos dos dias posteriores teriam que mudar também...

Opções

1- Quando modificar o saldo de um dia, re-calcular os dias posteriores

ou

2- Na tabela de saldo_diário, armazenar somente o saldo DAQUELE DIA, quando quiser saber o saldo, fazer um sum de todos os dias até aquele.

Creio que a primeira idéia seja melhor, já que não será muito comum modificar saldos de dias anteriores... afinal uma vez passada a data, não tem como mais fazer movimentação nela ( teoricamente ), a não ser que tenha havido algum engano que precise ser corrigido.

Andre Fernandes-2 wrote:

Bom dia,

Uma abordagem possível é guardar o saldo em uma tabela (por exemplo, uma
tabela contendo o saldo diário, no início do dia referente) e então somar
(ou subtrair) apenas as movimentações do dia referido. Muitos bancos
utilizam essa abordagem, pois não se perde histórico nem usa todo o
histórico para cálculos de saldo.

Exemplo:
create table saldo_diario
(numero_conta bigint,
dia_referencia date,
valor numeric(18,3)
);

create table movimentacao
(numero_conta bigint,
tipo_movimentacao bigint,  -- supondo ser chave estrangeira, isto é um
exemplo apenas
valor numeric(18,3)
);

cria-se então uma função que calcula o saldo referente ao dia anterior e
grava o valor em saldo_diario. Essa função seria rodada à 00h10 de todo dia,
por exemplo.



Espero que esteja compreensível a idéia que passei, qualquer dúvida (se algo
ficou confuso) é só perguntar.

Atenciosamente,
André.

2009/10/10 Bruno Carneiro <[e-mail]>

[Tarcísio Sassara]

2009/10/10 Bruno Carneiro <guimaraescarneiro@...>:
>
> Então, minha única dúvida ai seria se no futuro, o usuário modificasse
> movimentações do passado, neste caso teria que re-calcular o saldo daquele
> dia.

Não entendi o problema de um usuário alterar uma movimentação. Ele
pode fazer isso?

Continuando...

Não acredito que vai ser muito ruim como eu disse pois você não vai
precisar fazer o SUM com todos os
registros de movimentações. Apenas de um cliente de cada vez e:
Um cliente não terá tantas movimentações.

Mas pensando em performance,
Indo pelo seu primeiro e-mail, a alternativa de ter uma coluna com o
saldo atual e depois ir somando e subtraindo com cada movimentação
funciona.
De qualquer forma você precisa de uma tabela movimentações para ter o histórico.
Então, basta ter uma trigger que para cada alteracão na tabela
movimentações, atualize o saldo atual.

Abraço

2009/10/10 Bruno Carneiro <guimaraescarneiro@...>:

>
> Então, minha única dúvida ai seria se no futuro, o usuário modificasse
> movimentações do passado, neste caso teria que re-calcular o saldo daquele
> dia.
>
> E se o saldo desse dia muda, todos os saldos dos dias posteriores teriam que
> mudar também...
>
> Opções
>
> 1- Quando modificar o saldo de um dia, re-calcular os dias posteriores
>
> ou
>
> 2- Na tabela de saldo_diário, armazenar somente o saldo DAQUELE DIA, quando
> quiser saber o saldo, fazer um sum de todos os dias até aquele.
>
> Creio que a primeira idéia seja melhor, já que não será muito comum
> modificar saldos de dias anteriores... afinal uma vez passada a data, não
> tem como mais fazer movimentação nela ( teoricamente ), a não ser que tenha
> havido algum engano que precise ser corrigido.
>
>
> Andre Fernandes-2 wrote:
>>
>> Bom dia,
>>
>> Uma abordagem possível é guardar o saldo em uma tabela (por exemplo, uma
>> tabela contendo o saldo diário, no início do dia referente) e então somar
>> (ou subtrair) apenas as movimentações do dia referido. Muitos bancos
>> utilizam essa abordagem, pois não se perde histórico nem usa todo o
>> histórico para cálculos de saldo.
>>
>> Exemplo:
>> create table saldo_diario
>> (numero_conta bigint,
>> dia_referencia date,
>> valor numeric(18,3)
>> );
>>
>> create table movimentacao
>> (numero_conta bigint,
>> tipo_movimentacao bigint,  -- supondo ser chave estrangeira, isto é um
>> exemplo apenas
>> valor numeric(18,3)
>> );
>>
>> cria-se então uma função que calcula o saldo referente ao dia anterior e
>> grava o valor em saldo_diario. Essa função seria rodada à 00h10 de todo
>> dia,
>> por exemplo.
>>
>>
>>
>> Espero que esteja compreensível a idéia que passei, qualquer dúvida (se
>> algo
>> ficou confuso) é só perguntar.
>>
>> Atenciosamente,
>> André.
>>
>> 2009/10/10 Bruno Carneiro <guimaraescarneiro@...>
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/D%C3%BAvida-de-modelagem-de-contas-de-bancos-tp25834706p25835162.html
> Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@...
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>

--
Tarcisio F. Sassara
Nzb ryn. Ibpê fnor dhrz? Fvz é ryn! Gnzvelf.
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[andrecf]

Nesse caso o melhor, penso eu, seria realmente re-calcular os saldos de todos os dias posteriores a essa movimentação.

Atenciosamente,

2009/10/10 Bruno Carneiro <guimaraescarneiro@...>

Então, minha única dúvida ai seria se no futuro, o usuário modificasse
movimentações do passado, neste caso teria que re-calcular o saldo daquele
dia.

E se o saldo desse dia muda, todos os saldos dos dias posteriores teriam que
mudar também...

Opções

1- Quando modificar o saldo de um dia, re-calcular os dias posteriores

ou

2- Na tabela de saldo_diário, armazenar somente o saldo DAQUELE DIA, quando
quiser saber o saldo, fazer um sum de todos os dias até aquele.

Creio que a primeira idéia seja melhor, já que não será muito comum
modificar saldos de dias anteriores... afinal uma vez passada a data, não
tem como mais fazer movimentação nela ( teoricamente ), a não ser que tenha
havido algum engano que precise ser corrigido.

Andre Fernandes-2 wrote:
>
> Bom dia,
>
> Uma abordagem possível é guardar o saldo em uma tabela (por exemplo, uma
> tabela contendo o saldo diário, no início do dia referente) e então somar
> (ou subtrair) apenas as movimentações do dia referido. Muitos bancos
> utilizam essa abordagem, pois não se perde histórico nem usa todo o
> histórico para cálculos de saldo.
>
> Exemplo:
> create table saldo_diario
> (numero_conta bigint,
> dia_referencia date,
> valor numeric(18,3)
> );
>
> create table movimentacao
> (numero_conta bigint,
> tipo_movimentacao bigint,  -- supondo ser chave estrangeira, isto é um
> exemplo apenas
> valor numeric(18,3)
> );
>
> cria-se então uma função que calcula o saldo referente ao dia anterior e
> grava o valor em saldo_diario. Essa função seria rodada à 00h10 de todo
> dia,
> por exemplo.
>
>
>
> Espero que esteja compreensível a idéia que passei, qualquer dúvida (se
> algo
> ficou confuso) é só perguntar.
>
> Atenciosamente,
> André.
>
> 2009/10/10 Bruno Carneiro <guimaraescarneiro@...>
>
>
>
>

--
View this message in context: http://www.nabble.com/D%C3%BAvida-de-modelagem-de-contas-de-bancos-tp25834706p25835162.html

Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

--
André de Camargo Fernandes



_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Mozart Hasse]

Bruno,

> Quero modelar a movimentação financeira em uma conta.
> A conta tem um saldo inicial.
> A partir daí haverão várias movimentações.
> O saldo inicial + as movimentações vão gerar um novo saldo.
> Como eu devo tratar esse saldo de forma eficiente?

Adicione outra tabela para armazenar os saldos ou pelo menos as totalizações
por dia.
Toda avez que inserir, alterar ou excluir algum movimento, some ou subtraia
a variação na conta correspondente na tabela de saldos.
Ao alterar alguma coisa, você sempre saberá o valor antigo e o novo valor,
portanto você não precisará fazer um SUM de seja lá o que for para obter o
saldo.

> 1- Guardar somente o saldo inicial e toda vez recalcular o saldo baseado
> nas
> movimentações?

Esqueça. Isso ficará com um desempenho horrível depois de um mês de
movimentações.

> 2- Guardar o saldo atual em um campo.

Guarde noutra tabela. Conta, data, total de débitos, total de créditos. Como
assume-se que o cara raramente vai ficar fazendo lançamentos retroativos no
ano passado, dá para incluir o saldo atual e anterior em cada registro
também, ajudará muuuuuito nas consultas.

> O problema da abordagem número dois é que toda vez que alguém fizer uma
> nova
> movimentação tenho que recalcular, talvez não seja o ideal.

Como eu disse, você pode apenas somar ou subtrair a diferença, de
preferência via triggers. Recalcular qualquer coisa sobre qualquer volume é
furada, especialmente com o Postgres, que adora fazer Table Scan nesses
casos.

Atenciosamente,

Mozart Hasse


_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Bruno Carneiro]

Tarcísio Sassara wrote:

2009/10/10 Bruno Carneiro <[e-mail]>:
>
> Então, minha única dúvida ai seria se no futuro, o usuário modificasse
> movimentações do passado, neste caso teria que re-calcular o saldo daquele
> dia.

Não entendi o problema de um usuário alterar uma movimentação. Ele
pode fazer isso?

Teoricamente pode sim... nenhuma restrição foi imposta sobre isso. Neste caso, o

( saldo do dia n+1 ) = ( saldo do dia n ) + SUM(movimentação do dia n+1)

Se a movimentação do dia n muda, o saldo do dia n muda, e consequentemente o saldo do dia n+1 .

[Tarcísio Sassara]

2009/10/13 Bruno Carneiro <guimaraescarneiro@...>:
> Teoricamente pode sim... nenhuma restrição foi imposta sobre isso. Neste
> caso, o
>
> ( saldo do dia n+1 ) = ( saldo do dia n ) + SUM(movimentação do dia n+1)
>
> Se a movimentação do dia n muda, o saldo do dia n muda, e consequentemente o
> saldo do dia n+1 .

A diária é um grupo de movimentações que ocorrem durante um dia. Até ai beleza.
Mas e se você precisar identificar a que horas foi um determinado
saque se você está agrupando todas as movimentações de um dia em um
único registro?
Se eu fizer 10 saques: Vou conseguir saber a que horas e qual foi o
valor de cada um?


--
Tarcisio F. Sassara
Nzb ryn. Ibpê fnor dhrz? Fvz é ryn! Gnzvelf.
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Jose adriano Alves]

Tabela movimento:

CLIENTE, TIPOMOVIMENTO DATA_HORA,  VALOR
1             DEPOSITO            10/08/2009       100,00  (  TRIGGER INSERT UPDATE DELETE)
1             SAQUE                 20/09/2009         30,00  (  TRIGGER INSERT UPDATE DELETE)
1             SAQUE                 06/09/2009         20,00  (  TRIGGER INSERT UPDATE DELETE)

2             DEPOSITO            10/08/2009       200,00  (  TRIGGER INSERT UPDATE DELETE)
2             SAQUE                 20/09/2009         50,00  (  TRIGGER INSERT UPDATE DELETE)
2             SAQUE                 06/09/2009         75,00  (  TRIGGER INSERT UPDATE DELETE)


TABELA SALDOCONTA
CLIENTE DATA (MES_ANO_DIA  ), SALDO
1            2009-08-10                       100,00
1            2009-09-20                         70,00
1            2009-10-06                         50,00


2            2009-08-10                       200,00
2            2009-09-20                       150,00
2            2009-10-06                         75,00


Com as tabelas bem normalizadas e com as devidas triggers corretamente feitas não haverá problemas...

Quero o saldo? dá um select na tabela saldo...
Quer saber detalhado ( um extrato ) le a movimentacao...

Igual vc ter um total de conta contabil... voce tem o saldo das contas, mas se quiser detalhar, tem que listar lancamento a lancamento...

2009/10/13 Tarcísio Sassara <sassara.tarcisio@...>

2009/10/13 Bruno Carneiro <guimaraescarneiro@...>:

> Teoricamente pode sim... nenhuma restrição foi imposta sobre isso. Neste
> caso, o
>
> ( saldo do dia n+1 ) = ( saldo do dia n ) + SUM(movimentação do dia n+1)
>
> Se a movimentação do dia n muda, o saldo do dia n muda, e consequentemente o
> saldo do dia n+1 .

A diária é um grupo de movimentações que ocorrem durante um dia. Até ai beleza.
Mas e se você precisar identificar a que horas foi um determinado
saque se você está agrupando todas as movimentações de um dia em um
único registro?
Se eu fizer 10 saques: Vou conseguir saber a que horas e qual foi o
valor de cada um?

--
Tarcisio F. Sassara
Nzb ryn. Ibpê fnor dhrz? Fvz é ryn! Gnzvelf.
_______________________________________________

pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

--
----

Att.
José Adriano Alves
Analista de Sistemas - Móveis Gazin.
Cel..:  [phone]
Fone: + 55 44 3663 8000 - 2319
Mail: alves.jadriano@...
MSN: jose.adriano@...



Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de comunicação podendo este documento incluir informação confidencial e de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer dados, opiniões ou informações expressadas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com aquelas da GAZIN, são de exclusiva responsabilidade do signatário. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito da GAZIN.


Antes de imprimir pense em seu compromisso com o Meio Ambiente

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Bruno Carneiro]

Jose adriano Alves wrote:

Tabela movimento:

CLIENTE, TIPOMOVIMENTO DATA_HORA,  VALOR
1             DEPOSITO            10/08/2009       100,00  (  TRIGGER INSERT
UPDATE DELETE)
1             SAQUE                 20/09/2009         30,00  (  TRIGGER
INSERT UPDATE DELETE)
1             SAQUE                 06/09/2009         20,00  (  TRIGGER
INSERT UPDATE DELETE)

2             DEPOSITO            10/08/2009       200,00  (  TRIGGER INSERT
UPDATE DELETE)
2             SAQUE                 20/09/2009         50,00  (  TRIGGER
INSERT UPDATE DELETE)
2             SAQUE                 06/09/2009         75,00  (  TRIGGER
INSERT UPDATE DELETE)


TABELA SALDOCONTA
CLIENTE DATA (MES_ANO_DIA  ), SALDO
1            2009-08-10                       100,00
1            2009-09-20                         70,00
1            2009-10-06                         50,00


2            2009-08-10                       200,00
2            2009-09-20                       150,00
2            2009-10-06                         75,00


Com as tabelas bem normalizadas e com as devidas triggers corretamente
feitas não haverá problemas...

Quero o saldo? dá um select na tabela saldo...
Quer saber detalhado ( um extrato ) le a movimentacao...

Igual vc ter um total de conta contabil... voce tem o saldo das contas, mas
se quiser detalhar, tem que listar lancamento a lancamento...

Pelo que entendi, essa abordagem não anula a necessidade de eu ter que recalcular os saldos dia-a-dia, caso alguma movimentação passada mude.

Ou faço exatamente igual você sugeriu, e mudando uma movimentação passada, eu re-calculo a tabela de saldos, ou na tabela de saldo eu só armazeno o saldo daquele dia:

TABELA SALDOCONTA
CLIENTE DATA (MES_ANO_DIA  ), SALDO
1            2009-08-10                       100,00
1            2009-09-20                       -30,00
1            2009-10-06                       -20,00


2            2009-08-10                       200,00
2            2009-09-20                       -50,00
2            2009-10-06                       -75,00

E para saber o saldo uso o SUM na tabela saldoconta.

[Bruno Carneiro]

Obrigado por essas dicas. Creio que seja esse mesmo o caminho.

["André Ormenese ( Yahoo )"]

Bruno,
talvez vc não precise alterar lançamentos anteriores. Vc pode trabalhar
como os bancos. Se tiver algum lançamento errado, faça um lançamento de
estorno a débito ou a crédito, conforme a necessidade.
Assim não precisa ficar recalculando saldos anteriores.

André

Bruno Carneiro escreveu:
> Obrigado por essas dicas. Creio que seja esse mesmo o caminho.
>  

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Jose adriano Alves]

Não, você não vai calcular todos os dias...
A trigger vai fazer automaticamente pra vc!!

2009/10/13 "André Ormenese ( Yahoo )" <ormenese@...>

Bruno,
talvez vc não precise alterar lançamentos anteriores. Vc pode trabalhar
como os bancos. Se tiver algum lançamento errado, faça um lançamento de
estorno a débito ou a crédito, conforme a necessidade.
Assim não precisa ficar recalculando saldos anteriores.

André

Bruno Carneiro escreveu:

> Obrigado por essas dicas. Creio que seja esse mesmo o caminho.
>

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

--
----

Att.
José Adriano Alves
Analista de Sistemas - Móveis Gazin.
Cel..:  [phone]
Fone: + 55 44 3663 8000 - 2319
Mail: alves.jadriano@...
MSN: jose.adriano@...



Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de comunicação podendo este documento incluir informação confidencial e de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer dados, opiniões ou informações expressadas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com aquelas da GAZIN, são de exclusiva responsabilidade do signatário. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito da GAZIN.


Antes de imprimir pense em seu compromisso com o Meio Ambiente

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Jose adriano Alves]

Com a trigger voce nao vai recalcular NUNCA...
Quem vai gerencia tudo é a trigger, via insert update ou delete

2009/10/13 Jose adriano Alves <alves.jadriano@...>

Não, você não vai calcular todos os dias...
A trigger vai fazer automaticamente pra vc!!

2009/10/13 "André Ormenese ( Yahoo )" <ormenese@...>

Bruno,
talvez vc não precise alterar lançamentos anteriores. Vc pode trabalhar
como os bancos. Se tiver algum lançamento errado, faça um lançamento de
estorno a débito ou a crédito, conforme a necessidade.
Assim não precisa ficar recalculando saldos anteriores.

André

Bruno Carneiro escreveu:

> Obrigado por essas dicas. Creio que seja esse mesmo o caminho.
>

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

--
----

Att.
José Adriano Alves
Analista de Sistemas - Móveis Gazin.
Cel..:  [phone]
Fone: + 55 44 3663 8000 - 2319
Mail: alves.jadriano@...
MSN: jose.adriano@...



Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de comunicação podendo este documento incluir informação confidencial e de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer dados, opiniões ou informações expressadas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com aquelas da GAZIN, são de exclusiva responsabilidade do signatário. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito da GAZIN.


Antes de imprimir pense em seu compromisso com o Meio Ambiente

--
----

Att.
José Adriano Alves
Analista de Sistemas - Móveis Gazin.
Cel..:  [phone]
Fone: + 55 44 3663 8000 - 2319
Mail: alves.jadriano@...
MSN: jose.adriano@...



Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de comunicação podendo este documento incluir informação confidencial e de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer dados, opiniões ou informações expressadas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com aquelas da GAZIN, são de exclusiva responsabilidade do signatário. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito da GAZIN.


Antes de imprimir pense em seu compromisso com o Meio Ambiente

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

["André Ormenese ( Yahoo )"]

Pois é ... a trigger vai recalcular, certo ?!??!
É esse processamento que eu sugeri não fazer. Apenas para poupar o
servidor e banco.


Jose adriano Alves escreveu:

> Com a trigger voce nao vai recalcular NUNCA...
> Quem vai gerencia tudo é a trigger, via insert update ou delete
>
>
> 2009/10/13 Jose adriano Alves <alves.jadriano@...
> <mailto:alves.jadriano@...>>
>
>     Não, você não vai calcular todos os dias...
>     A trigger vai fazer automaticamente pra vc!!
>
>
>     2009/10/13 "André Ormenese ( Yahoo )" <ormenese@...
>     <mailto:ormenese@...>>
>
>         Bruno,
>         talvez vc não precise alterar lançamentos anteriores. Vc pode
>         trabalhar
>         como os bancos. Se tiver algum lançamento errado, faça um
>         lançamento de
>         estorno a débito ou a crédito, conforme a necessidade.
>         Assim não precisa ficar recalculando saldos anteriores.
>
>         André
>
>         Bruno Carneiro escreveu:
>         > Obrigado por essas dicas. Creio que seja esse mesmo o caminho.
>         >
>
>         _______________________________________________
>         pgbr-geral mailing list
>         pgbr-geral@...
>         <mailto:pgbr-geral@...>
>         https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
>
>
>     --
>     ----
>
>     Att.
>     José Adriano Alves
>     Analista de Sistemas - Móveis Gazin.
>     Cel..:  [phone]
>     Fone: + 55 44 3663 8000 - 2319
>     Mail: alves.jadriano@... <mailto:alves.jadriano@...>
>     MSN: jose.adriano@... <mailto:jose.adriano@...>
>
>
>
>     Este e-mail, seu conteúdo e seus anexos estão sujeitos à
>     privilégio de comunicação podendo este documento incluir
>     informação confidencial e de propriedade restrita da GAZIN e
>     apenas pode ser lido por aqueles a qual o mesmo tenha sido
>     endereçado. Se você recebeu essa mensagem de e-mail indevidamente,
>     por favor avise-nos imediatamente. Quaisquer dados, opiniões ou
>     informações expressadas neste e-mail pertencem ao seu remetente e
>     não necessariamente coincidem com aquelas da GAZIN, são de
>     exclusiva responsabilidade do signatário. Este documento não pode
>     ser reproduzido, copiado, distribuído, publicado ou modificado por
>     terceiros, sem a prévia autorização por escrito da GAZIN.
>
>
>     Antes de imprimir pense em seu compromisso com o Meio Ambiente
>
>
>
>
> --
> ----
>
> Att.
> José Adriano Alves
> Analista de Sistemas - Móveis Gazin.
> Cel..:  [phone]
> Fone: + 55 44 3663 8000 - 2319
> Mail: alves.jadriano@... <mailto:alves.jadriano@...>
> MSN: jose.adriano@... <mailto:jose.adriano@...>
>
>
>
> Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de
> comunicação podendo este documento incluir informação confidencial e
> de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a
> qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de
> e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer
> dados, opiniões ou informações expressadas neste e-mail pertencem ao
> seu remetente e não necessariamente coincidem com aquelas da GAZIN,
> são de exclusiva responsabilidade do signatário. Este documento não
> pode ser reproduzido, copiado, distribuído, publicado ou modificado
> por terceiros, sem a prévia autorização por escrito da GAZIN.
>
>
> Antes de imprimir pense em seu compromisso com o Meio Ambiente
> ------------------------------------------------------------------------
>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@...
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>  

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Jose adriano Alves]

>     2009/10/13 "André Ormenese ( Yahoo )" <ormenese@...
>     <mailto:ormenese@...>

>

>
>         Bruno,
>         talvez vc não precise alterar lançamentos anteriores. Vc pode
>         trabalhar
>         como os bancos. Se tiver algum lançamento errado, faça um
>         lançamento de
>         estorno a débito ou a crédito, conforme a necessidade.
>         Assim não precisa ficar recalculando saldos anteriores.
>
>         André

Ótimo.
Não tinha lido essa mensagem.
Mas também é excelente idéia, trabalhando igual contabilmente.
Precisa acertar, faz estorno.
Concordo com você.

2009/10/13 "André Ormenese ( Yahoo )" <ormenese@...>

Pois é ... a trigger vai recalcular, certo ?!??!
É esse processamento que eu sugeri não fazer. Apenas para poupar o
servidor e banco.


Jose adriano Alves escreveu:

> Com a trigger voce nao vai recalcular NUNCA...
> Quem vai gerencia tudo é a trigger, via insert update ou delete
>
>
> 2009/10/13 Jose adriano Alves <alves.jadriano@...

> <mailto:alves.jadriano@...>>

>
>     Não, você não vai calcular todos os dias...
>     A trigger vai fazer automaticamente pra vc!!
>
>
>     2009/10/13 "André Ormenese ( Yahoo )" <ormenese@...

>     <mailto:ormenese@...>>

>
>         Bruno,
>         talvez vc não precise alterar lançamentos anteriores. Vc pode
>         trabalhar
>         como os bancos. Se tiver algum lançamento errado, faça um
>         lançamento de
>         estorno a débito ou a crédito, conforme a necessidade.
>         Assim não precisa ficar recalculando saldos anteriores.
>
>         André
>
>         Bruno Carneiro escreveu:
>         > Obrigado por essas dicas. Creio que seja esse mesmo o caminho.
>         >
>
>         _______________________________________________
>         pgbr-geral mailing list
>         pgbr-geral@...

>         <mailto:pgbr-geral@...>

>         https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
>
>
>     --
>     ----
>
>     Att.
>     José Adriano Alves
>     Analista de Sistemas - Móveis Gazin.
>     Cel..:  [phone]
>     Fone: + 55 44 3663 8000 - 2319

>     Mail: alves.jadriano@... <mailto:alves.jadriano@...>
>     MSN: jose.adriano@... <mailto:jose.adriano@...>

>
>
>
>     Este e-mail, seu conteúdo e seus anexos estão sujeitos à
>     privilégio de comunicação podendo este documento incluir
>     informação confidencial e de propriedade restrita da GAZIN e
>     apenas pode ser lido por aqueles a qual o mesmo tenha sido
>     endereçado. Se você recebeu essa mensagem de e-mail indevidamente,
>     por favor avise-nos imediatamente. Quaisquer dados, opiniões ou
>     informações expressadas neste e-mail pertencem ao seu remetente e
>     não necessariamente coincidem com aquelas da GAZIN, são de
>     exclusiva responsabilidade do signatário. Este documento não pode
>     ser reproduzido, copiado, distribuído, publicado ou modificado por
>     terceiros, sem a prévia autorização por escrito da GAZIN.
>
>
>     Antes de imprimir pense em seu compromisso com o Meio Ambiente
>
>
>
>
> --
> ----
>
> Att.
> José Adriano Alves
> Analista de Sistemas - Móveis Gazin.
> Cel..:  [phone]
> Fone: + 55 44 3663 8000 - 2319

> Mail: alves.jadriano@... <mailto:alves.jadriano@...>
> MSN: jose.adriano@... <mailto:jose.adriano@...>

>
>
>
> Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de
> comunicação podendo este documento incluir informação confidencial e
> de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a
> qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de
> e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer
> dados, opiniões ou informações expressadas neste e-mail pertencem ao
> seu remetente e não necessariamente coincidem com aquelas da GAZIN,
> são de exclusiva responsabilidade do signatário. Este documento não
> pode ser reproduzido, copiado, distribuído, publicado ou modificado
> por terceiros, sem a prévia autorização por escrito da GAZIN.
>
>
> Antes de imprimir pense em seu compromisso com o Meio Ambiente

> ------------------------------------------------------------------------

>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@...
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

--
----

Att.
José Adriano Alves
Analista de Sistemas - Móveis Gazin.
Cel..:  [phone]
Fone: + 55 44 3663 8000 - 2319
Mail: alves.jadriano@...
MSN: jose.adriano@...



Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de comunicação podendo este documento incluir informação confidencial e de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer dados, opiniões ou informações expressadas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com aquelas da GAZIN, são de exclusiva responsabilidade do signatário. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito da GAZIN.


Antes de imprimir pense em seu compromisso com o Meio Ambiente

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Tarcísio Sassara]

Mas cuidado com a idéia dos estornos.
Um estorno não pode ser simplesmente uma operação contraria a outra
com o nome de estorno.
Um estorno possui atributos próprios.


2009/10/13 Jose adriano Alves <alves.jadriano@...>:

>>     2009/10/13 "André Ormenese ( Yahoo )" <ormenese@...
>>     <mailto:ormenese@...>
>>
>> >
>> >
>> >         Bruno,
>> >         talvez vc não precise alterar lançamentos anteriores. Vc pode
>> >         trabalhar
>> >         como os bancos. Se tiver algum lançamento errado, faça um
>> >         lançamento de
>> >         estorno a débito ou a crédito, conforme a necessidade.
>> >         Assim não precisa ficar recalculando saldos anteriores.
>> >
>> >         André
>
>
> Ótimo.
> Não tinha lido essa mensagem.
> Mas também é excelente idéia, trabalhando igual contabilmente.
> Precisa acertar, faz estorno.
> Concordo com você.
>
>
>
>
> 2009/10/13 "André Ormenese ( Yahoo )" <ormenese@...>
>>
>> Pois é ... a trigger vai recalcular, certo ?!??!
>> É esse processamento que eu sugeri não fazer. Apenas para poupar o
>> servidor e banco.
>>
>>
>> Jose adriano Alves escreveu:
>> > Com a trigger voce nao vai recalcular NUNCA...
>> > Quem vai gerencia tudo é a trigger, via insert update ou delete
>> >
>> >
>> > 2009/10/13 Jose adriano Alves <alves.jadriano@...
>> > <mailto:alves.jadriano@...>>
>> >
>> >     Não, você não vai calcular todos os dias...
>> >     A trigger vai fazer automaticamente pra vc!!
>> >
>> >
>> >     2009/10/13 "André Ormenese ( Yahoo )" <ormenese@...
>> >     <mailto:ormenese@...>>
>> >
>> >         Bruno,
>> >         talvez vc não precise alterar lançamentos anteriores. Vc pode
>> >         trabalhar
>> >         como os bancos. Se tiver algum lançamento errado, faça um
>> >         lançamento de
>> >         estorno a débito ou a crédito, conforme a necessidade.
>> >         Assim não precisa ficar recalculando saldos anteriores.
>> >
>> >         André
>> >
>> >         Bruno Carneiro escreveu:
>> >         > Obrigado por essas dicas. Creio que seja esse mesmo o caminho.
>> >         >
>> >
>> >         _______________________________________________
>> >         pgbr-geral mailing list
>> >         pgbr-geral@...
>> >         <mailto:pgbr-geral@...>
>> >
>> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>> >
>> >
>> >
>> >
>> >     --
>> >     ----
>> >
>> >     Att.
>> >     José Adriano Alves
>> >     Analista de Sistemas - Móveis Gazin.
>> >     Cel..:  [phone]
>> >     Fone: + 55 44 3663 8000 - 2319
>> >     Mail: alves.jadriano@...
>> > <mailto:alves.jadriano@...>
>> >     MSN: jose.adriano@... <mailto:jose.adriano@...>
>> >
>> >
>> >
>> >     Este e-mail, seu conteúdo e seus anexos estão sujeitos à
>> >     privilégio de comunicação podendo este documento incluir
>> >     informação confidencial e de propriedade restrita da GAZIN e
>> >     apenas pode ser lido por aqueles a qual o mesmo tenha sido
>> >     endereçado. Se você recebeu essa mensagem de e-mail indevidamente,
>> >     por favor avise-nos imediatamente. Quaisquer dados, opiniões ou
>> >     informações expressadas neste e-mail pertencem ao seu remetente e
>> >     não necessariamente coincidem com aquelas da GAZIN, são de
>> >     exclusiva responsabilidade do signatário. Este documento não pode
>> >     ser reproduzido, copiado, distribuído, publicado ou modificado por
>> >     terceiros, sem a prévia autorização por escrito da GAZIN.
>> >
>> >
>> >     Antes de imprimir pense em seu compromisso com o Meio Ambiente
>> >
>> >
>> >
>> >
>> > --
>> > ----
>> >
>> > Att.
>> > José Adriano Alves
>> > Analista de Sistemas - Móveis Gazin.
>> > Cel..:  [phone]
>> > Fone: + 55 44 3663 8000 - 2319
>> > Mail: alves.jadriano@... <mailto:alves.jadriano@...>
>> > MSN: jose.adriano@... <mailto:jose.adriano@...>
>> >
>> >
>> >
>> > Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de
>> > comunicação podendo este documento incluir informação confidencial e
>> > de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a
>> > qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de
>> > e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer
>> > dados, opiniões ou informações expressadas neste e-mail pertencem ao
>> > seu remetente e não necessariamente coincidem com aquelas da GAZIN,
>> > são de exclusiva responsabilidade do signatário. Este documento não
>> > pode ser reproduzido, copiado, distribuído, publicado ou modificado
>> > por terceiros, sem a prévia autorização por escrito da GAZIN.
>> >
>> >
>> > Antes de imprimir pense em seu compromisso com o Meio Ambiente
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > pgbr-geral mailing list
>> > pgbr-geral@...
>> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>> >
>>
>> _______________________________________________
>> pgbr-geral mailing list
>> pgbr-geral@...
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
>
> --
> ----
>
> Att.
> José Adriano Alves
> Analista de Sistemas - Móveis Gazin.
> Cel..:  [phone]
> Fone: + 55 44 3663 8000 - 2319
> Mail: alves.jadriano@...
> MSN: jose.adriano@...
>
>
>
> Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de
> comunicação podendo este documento incluir informação confidencial e de
> propriedade restrita da GAZIN e apenas pode ser lido por aqueles a qual o
> mesmo tenha sido endereçado. Se você recebeu essa mensagem de e-mail
> indevidamente, por favor avise-nos imediatamente. Quaisquer dados, opiniões
> ou informações expressadas neste e-mail pertencem ao seu remetente e não
> necessariamente coincidem com aquelas da GAZIN, são de exclusiva
> responsabilidade do signatário. Este documento não pode ser reproduzido,
> copiado, distribuído, publicado ou modificado por terceiros, sem a prévia
> autorização por escrito da GAZIN.
>
>
> Antes de imprimir pense em seu compromisso com o Meio Ambiente
>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@...
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>

--
Tarcisio F. Sassara
Nzb ryn. Ibpê fnor dhrz? Fvz é ryn! Gnzvelf.
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Bruno Carneiro]

Tarcísio Sassara wrote:

Mas cuidado com a idéia dos estornos.
Um estorno não pode ser simplesmente uma operação contraria a outra
com o nome de estorno.
Um estorno possui atributos próprios.

Vou conversar com os clientes sobre esses detalhes. Qualquer coisa, volta aqui e pergunto mais informações sobre estorno.

Creio que não seja algo para se complicar muito, o sistema deve ser simples.