GARANTIR DESCONTO

Fórum tabelas contas a pagar, contas a receber, pagamento, recebimento e caixa #520818

25/05/2015

0

SQL

Boa tarde

A dúvida é a seguinte:
contas a pagar e contas a receber devem ser a mesma tabela ?
contas pagas e recebidas devem ser a mesma tabela que a tabela acima ?
a quitação das parcelas deve ser a mesma tabela de pagamento a visa (caixa) ?

Trabalho com access e gostaria que me auxiliassem?

obrigado
Carlos Neves

Carlos Neves

Responder

Post mais votado

25/05/2015

Carlos, boa tarde!
Existem diversas formas de modelar sua aplicação.
Por exemplo Contas à Pagar e Receber podem ser uma mesma tabela apenas tendo um tipo para separar os registros como podem ser tabelas separadas!
Fica de acordo com seu critério de organização.
Eu prefiro separados!

Thiago Santana

Thiago Santana
Responder

Gostei + 3

Mais Posts

25/05/2015

Carlos Neves

Obrigado pela diga

O pagamento e/ou recebimento dessas tabelas podem ser meu próprio caixa ?

É o seguinte:

Se tenho uma tabela que tem data de vencimento, valor a pagar, data de pagamento e valor pago. Caso meu pagamento seja a vista ?
Teria que ter outra tabela para esses casos ou ignoraria simplesmente a data de vencimento e valor a pagar nesses casos ?
Responder

Gostei + 1

25/05/2015

Carlos Neves

Obrigado pela diga

O pagamento e/ou recebimento dessas tabelas podem ser meu próprio caixa ?

É o seguinte:

Se tenho uma tabela que tem data de vencimento, valor a pagar, data de pagamento e valor pago. Caso meu pagamento seja a vista ?
Teria que ter outra tabela para esses casos ou ignoraria simplesmente a data de vencimento e valor a pagar nesses casos ?
Responder

Gostei + 0

25/05/2015

Thiago Santana

Carlos, como te falei depende muito de como você quer a estrutura do seu sistema!
Com relação a pagamentos, no meu ponto de vista uma tabela separada...
Gosto de deixar as coisas bem separadas para o melhor entendimento!
Responder

Gostei + 0

25/05/2015

Carlos Neves

obrigado
Responder

Gostei + 0

05/10/2016

Ricardo Pereira

Olá Carlos como ficou sua modelagem final? estou implementando também um sistema financeiro e estou com bastante dúvidas, ainda mais que no meu caso vou ter contas pagar/ contas receber, vendas, compras e abastecimentos de veículos.

Já perguntei aqui no fórum e também me sugeriram separar as tabelas, então na minha modelagem atual tenho as tabelas contas_pagar, contas_receber, vendas, compras e abastecimentos


na tabela de contas_receber eu guardo a chave estrangeira venda_id caso esta conta a receber seja proveniente de uma venda (1 venda : n contas no caso de ser parcelado) e além disso guardo também o cliente_id


na tabela de contas_pagar guardo a chave estrangeira compra_id( para o caso da conta ser proveniente de uma compra) e tenho um campo fornecedor_funcionario_id, pois posso estar devendo tanto um fornecedor quanto um funcionário dependendo do lançamento

ainda não sei como vou tratar os abastecimentos ( que são contas pagar tbm)


e pra piorar a situação, o sistema vai permitir pagamentos parciais, então neste caso como as minhas tabelas de contas pagar/receber estão separadas vou ter que criar mais duas tabelas: pagamentos e recebimentos?
Responder

Gostei + 0

06/10/2016

Carlos Neves

Bom dia
Obrigado pela dica mas na verdade eu gostaria de saber se o assunto contas a pagar , contas a receber, contas pagas e contas recebidas devem ser 4 tabelas ou não ?
Outra pergunta
Num plano de contas como o exemplo abaixo:
1º nível (despesas), 2º nível (fornecedores)... o 3º nível deveria ser o nome desse fornecedor ou não se vincula o 3º nível e fica como sendo uma tabela independente.
Exemplo: pedido nº...., conta: fornecedores, nome: fulano de tal...

Obrigado
Responder

Gostei + 0

06/10/2016

Carlos Neves

Bom dia

Acredito que teríamos que ter uma opção dentro de contas a pagar e / ou contas a receber que seria tipo a natureza da operação:
exemplo:
tabela a: codigo 1(compras), codigo 2 (abastecimento)

Não sei se tem outra maneira de fazer ...
Responder

Gostei + 0

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar