DUVIDA GESTAO FINANCEIRA
Entendi. Seria possÃvel criar uma estrutura para isto sim sem atrapalhar meu sistema.
Entao no final das contas o usuario faria uma entrada de 80,00 mesmo como receita, cadastra uma despesa de 20,00 como taxa/juros/etc.
E deixa o valor do financeiro em aberto mesmo, porem com um evento [Ô]Trocado com o banco[Ô] registrado nele, entao ele pesquisaria quais registros financeiros estao em aberto com o evento Trocado com o banco. Assim que ele for pago(ou não) o usuario cadastra uma despesa de 100,00 referente que o o valor invariavelmente sairá da sua conta bancária.
Bom, a fins de filtros é interessante os eventos, porem no caso das empresas que trocam diariamente váaarios titulos fica muito trabalhoso fazer isso.
Que tenso rs
Entao no final das contas o usuario faria uma entrada de 80,00 mesmo como receita, cadastra uma despesa de 20,00 como taxa/juros/etc.
E deixa o valor do financeiro em aberto mesmo, porem com um evento [Ô]Trocado com o banco[Ô] registrado nele, entao ele pesquisaria quais registros financeiros estao em aberto com o evento Trocado com o banco. Assim que ele for pago(ou não) o usuario cadastra uma despesa de 100,00 referente que o o valor invariavelmente sairá da sua conta bancária.
Bom, a fins de filtros é interessante os eventos, porem no caso das empresas que trocam diariamente váaarios titulos fica muito trabalhoso fazer isso.
Que tenso rs
Colega FBGSYSTEMS,
Eventos são interessantes porque mantém um log. Já tive clientes que teimaram que não tinha excluÃdo a conta e, em seguida, eu disse quem excluiu, a data e a hora que fez a exclusão. Nos casos de exclusão ainda faço um print automático da tela e gravo em jpg. Não teve como o cliente insistir que o sistema tinha errado. Melhor foi ir tomar satisfações com o funcionário dele para saber porque a conta estava excluÃda, mas tinha um consumidor com um cupom em mãos e o dinheiro não estava no caixa.
Se a forma de eventos ficar inviável para o caso, dada a quantidade de trocas diárias, ou seja, a venda de tÃtulos, então na sua própria conta poderia ter um campo que identifique o Id do comprador (por exemplo, Caixa Econômica Federal) e o valor cobrado para efetuar a compra.
Exemplo:
TB_CONTAS
Id: UNX1010
Cod_Cli_For: UNX1234
Valor: 100,00
Cod_Comprador: UNX2536 (se este campo não for preenchido, é porque o tÃtulo não foi vendido)
Vlr_Compra: 20,00
Neste caso saberemos que a conta foi vendida para o comprador Id UNX2536 pelo valor de R$ 20,00.
Como o valor do tÃtulo é de R$ 100,00 e foi vendido sob o valor de R$ 20,00, você terá lÃquidos R$ 80,00 para receber (um subtraÃdo do outro).
Nos relatórios bastará você colocar, além do valor do tÃtulo (R$ 100,00) o valor pelo qual o mesmo foi vendido (R$ 20,00) e o valor lÃquido (R$ 80,00). Totalize as 3 colunas e terá os valores primários (o que seria recebido), o valor de venda do tÃtulo (quanto acabou [Ô]perdendo[Ô] para poder adiantar o valor junto ao banco) e o valor lÃquido de fato receber/recebido (conforme a data de quitação esteja preenchida será um tÃtulo recebido ou, caso contrário, ainda por receber).
Tudo de bom.
Eventos são interessantes porque mantém um log. Já tive clientes que teimaram que não tinha excluÃdo a conta e, em seguida, eu disse quem excluiu, a data e a hora que fez a exclusão. Nos casos de exclusão ainda faço um print automático da tela e gravo em jpg. Não teve como o cliente insistir que o sistema tinha errado. Melhor foi ir tomar satisfações com o funcionário dele para saber porque a conta estava excluÃda, mas tinha um consumidor com um cupom em mãos e o dinheiro não estava no caixa.
Se a forma de eventos ficar inviável para o caso, dada a quantidade de trocas diárias, ou seja, a venda de tÃtulos, então na sua própria conta poderia ter um campo que identifique o Id do comprador (por exemplo, Caixa Econômica Federal) e o valor cobrado para efetuar a compra.
Exemplo:
TB_CONTAS
Id: UNX1010
Cod_Cli_For: UNX1234
Valor: 100,00
Cod_Comprador: UNX2536 (se este campo não for preenchido, é porque o tÃtulo não foi vendido)
Vlr_Compra: 20,00
Neste caso saberemos que a conta foi vendida para o comprador Id UNX2536 pelo valor de R$ 20,00.
Como o valor do tÃtulo é de R$ 100,00 e foi vendido sob o valor de R$ 20,00, você terá lÃquidos R$ 80,00 para receber (um subtraÃdo do outro).
Nos relatórios bastará você colocar, além do valor do tÃtulo (R$ 100,00) o valor pelo qual o mesmo foi vendido (R$ 20,00) e o valor lÃquido (R$ 80,00). Totalize as 3 colunas e terá os valores primários (o que seria recebido), o valor de venda do tÃtulo (quanto acabou [Ô]perdendo[Ô] para poder adiantar o valor junto ao banco) e o valor lÃquido de fato receber/recebido (conforme a data de quitação esteja preenchida será um tÃtulo recebido ou, caso contrário, ainda por receber).
Tudo de bom.
SINCLAIR, gostei da sua estrutura, se for possivel vou adotar ela também, é bem semelhante ao que faço mas o meu é um pouco desorganizado.
Galera, acho que estou chegando a um consenso.
Porém a única coisa que eu nao sei como ficará é o seguinte:
Se eu altero o valor do registro de 100 para 80 e o [Ô]marco[Ô] como titulo trocado para que isso fique com um log e eu consiga filtrar titulos trocados e ainda nao pagos pelo cliente porem recebidos por mim.
Mas ok, o ideal seria manualmente o cliente cadastrar uma despesa de 20,00 ?
Então o cliente teria que buscar um relatório de tÃtulos recebidos de desconto de titulo, porem ainda não pagos pelo pagador?
Algo como
Select * from movimento where tipo=[ô]E[ô] and status=[ô]RECEBIDO PELO BANCO - NÃO PAGO PELO CLIENTE[ô] and not isnull(data_pagamento)
??
Sei que a estrutura com uma tabela de eventos ficara'diferente, mas seria para entendermos a mecanica.
Porém a única coisa que eu nao sei como ficará é o seguinte:
Se eu altero o valor do registro de 100 para 80 e o [Ô]marco[Ô] como titulo trocado para que isso fique com um log e eu consiga filtrar titulos trocados e ainda nao pagos pelo cliente porem recebidos por mim.
Mas ok, o ideal seria manualmente o cliente cadastrar uma despesa de 20,00 ?
Então o cliente teria que buscar um relatório de tÃtulos recebidos de desconto de titulo, porem ainda não pagos pelo pagador?
Algo como
Select * from movimento where tipo=[ô]E[ô] and status=[ô]RECEBIDO PELO BANCO - NÃO PAGO PELO CLIENTE[ô] and not isnull(data_pagamento)
??
Sei que a estrutura com uma tabela de eventos ficara'diferente, mas seria para entendermos a mecanica.
Tópico encerrado , respostas não são mais permitidas