Estou precisando de algumas opiniões sobre uma modelagem que eu fiz aqui. O problema é um sistema de estoques e vendas, onde é necessário que se mantenha o controle da quantidade de mercadorias vendidas, quais foram vendidas, quais ainda não foram e que seja possível reconstituir todo o histórico para análizes futuras.
Pensando nisso, eu modelei o seguinte, uma classe “Produto” que tem três propriedades, nome, descricão e “Marca” (que é outra entidade). O produto apenas define alguma coisa que “pode” ser vendida, ele não tem preço nem quantidade. Já pra lidar com os problemas do preço e da quantidade eu criei mais uma entidade, “Item” quem tem como propriedades “dataDeEntrada”, “valor” e “percentual” (pra quando forem necessários os descontos) e cada item se referencia a um produto, assim, quando eu quizer saber se existem produtos de um certo tipo a venda, posso procurar por referências não vendidas em “itens”.
De resto é só a nota, o cliente e o vendedor. O que é que vocês acham? Tá bom? Tá ruim? Alguém já fez um sistema de estoque e vendas por aí e pode dar um toque?
Raciocinando mais como modelagem de base de dados do que com classes, se poderia fazer o seguinte:
Uma classe cliente com todos seus dados
Uma classe vendedor com todos seus dados
Uma classe notas de vendas (NFs) com todos seus dados
Uma classe itemNF com todos seus dados
Uma classe produto com todos seus dados com inclusive preço do produto e quantidade em estoque
Uma classe fornecedor (= marca) com todos seus dados
Até aqui está quase igual ao seu modelo. Onde estão as diferenças?
A classe NFs precisa conter também os dados do cliente, do vendedor e a classe itemNF precisa dos dados do produto. O motivo disto é que depois da venda efetuada pode haver mudanças nos dados do cliente ou do vendedor. Você vai popular as classes a partir de tabelas na base de dados ou de dados digitados. Mas as notas depois de emitidas passam a ter vida própria independente do que mudou.
A classe produto precisa ter preço e qtde em estoque. O preço do itemNF é apenas um retrato instantâneo do que foi o preço no momento da venda.
Para reconstituir o histórico seria bom armazenar os movimentos.
Seu sistema precisa no mínimo de telas para cadastrar clientes, produtos, vendedores, NFs, consultas às qtdes vendidas, qtde em estoque e histórico.
Lembre-se que seu sistema é completamente fictício pq na prática seria preciso tb considerar outros tipos de operação como NF de entrada, NF de devolução, cancelamento e muitos outros que normalmente ocorrem no comércio.
Vamos ver se eu entendi tudo, a modelagem continua parecida, mas agora eu mudo a quantidade e o preço direto pra produto e item vai virar uma tabela “espelho” do “produto”, que vai se relacionar com nota pra garantir que as coisas vão continuar as mesmas quando o preço e outras coisas do produto mudarem.
A nota vai conter os produtos (os itens, no caso), o vendedor e o cliente. Mas vai conter apenas com chaves ou eu tenho que criar tabelas espenho pro vendedor e pro cliente também?
E agora mais uma dúvida… o pagamento da nota! (como foi que eu me esqueci disso… :roll: )
Eu havia pensado no seguinte, criar uma nova tabela de movimentos relacionada a tabela de “notas” que vai ter a data que o pagamento deve ser feito e a quantidade que deve ser paga, pra poder simular pagamentos parcelados.
Mas agora você me pegou com esses outros movimentos, não tinha pensado neles ainda. Eu poderia ter um flag na nota que mostrasse se ela era de entrada ou saída, e sendo devolução ou cancelamento a própria nota (que já existiria nesses dois casos) poderia ter métodos pra se devolver ou se cancelar.
Tudo o que vc disse faz sentido ao colocar os produtos em uma Collection dentro da nota lembre-se que eles serão itens desta nota. Na base de dados os itensNF serão uma tabela relacionada a NF. ItemNF é quase um espelho do produto, não precisa de todos os campos. Por exemplo, não precisa da qtde em estoque. ItemNF só precisa dos dados relativos a NF
Uma nota normalmente é composta do cabeçalho com seu número, data, tipo da operação e dados do cliente. No corpo da nota vão os itens (produtos) vendidos e depois as condições de pagamento, local de entrega, local de cobrança, transportadora, etc. Procure ver modelos de NFs para reconhecer todos os campos normalmente usados.
Quanto às condições de pagamento se você se preocupar com isto vai complicar muito seu problema. Mas se for necessário lembre-se que para o histórico de estoque as condições de pagamento não importam.
Os movimentos devem permitir obter rapidamente as informações do histórico. Geralmente se prestam para uma eventual auditoria onde se busca erros nas vendas. Na vida real é comum haver erros no estoque e às vezes a gente precisa rever muitos os movimento para descobrir onde ocorreu o erro. Guarde neles tudo que achar necessário e agrupe-os em lotes. Por exemplo: um lote para cada dia.
Peguei a nota da perdigão aqui (ser filho de comerciante ajuda ó). Tem o cliente (o meu pai, com o enredeço de cobrança e entrega), tem as informações da filial que vendeu, o transportador, tem dois quadrinhos pra dizer se é de entrada ou saída, até aqui nada de novo. Mas eu percebi mais uma coisinha nela, a quantidade de unidades de cada item :mrgreen:
Nos produtos tem os dados deles, o preço unitário e a quantidade de unidades que foram compradas, então item também deve ter a quantidade de itens vendidos pra não ficar repetindo itens na nota.
Nas condições de pagamento (que realmente são necessárias) eu pensei no seguinte, ter um “tipo de pagamento” base com o “nome do cobrado”, porque o meu nome não é igual ao que aparece no cartão e informações adicionais se forem necessárias (essa base também poderia ser a de pagamentos a vista). Aí, dessa classe base vão sair mais duas classes, que são pagamento em cheque e cartão, com as informações adicionais sobre eles.
Os pagamentos realmente não vão fazer muita diferença pro estoque mesmo não, é só cruzar entrada com saída. Mas eu não entendi bem esse negócio de agrupamentos, eu crio mais uma tabela pra reunir os agrupamentos ou agrupo eles usando a data que eles chegaram?
Cada vez que se acrescentam detalhes a coisa vai mais longe.
Para que a gente guarda o nome do vendedor?
Para acumular comissões ou para saber quem emitiu a NF. No seu caso só servirá para a 2a hipótese.
A NF sempre tem um transportador, seja ele uma empresa ou quem comprou a mercadoria
NFs tem ao menos um item
Questões de pagamento costumam ser amarradas ao cliente. Afinal não queremos que mau pagadores comprem de novo. Veja a enrascada q se mete tratando meios de pagamento em sistemas puramente de estoque. Seu sistema passa a ser também financeiro (faturamento) e precisa de mais coisas além do que já fez. Se este é um projeto escolar cuidado para não estragá-lo com coisas a mais sem funcionar direito.
Preço não pode ser double devido às dificuldades de rerepresentar números reais de forma binária. Seus produtos de 1,99 acabarão custando 1.989999999.
Geralmente para facilitar a indexação, todas as tabelas usam códigos ou sequências e estas grandezas às vezes também vão para as classes que as representam.
Poderia falar mais coisa. Converse com seu pai comerciante que vai aprender muito sobre sistemas de controle de estoques e faturamento.
Na verdade o mais importante é modelar (é “análise e projeto de sistemas”), mas quem sabe esse negócio um dia pode virar alguma coisa de verdade :mrgreen:
Essa do Double eu realmente não sabia, então eu usaria o que? BigDecimal? Separava inteiros de centavos? Guardava como String?
Sobre os códigos, eu num coloquei pra num repetir, eu costumo usar o AspectJ pra colocar essas coisas (já que é igual em todo mundo), fica mais fácil de trocar depois :mrgreen:
Mas as dúvidas de pagamentos ainda me perseguem :lol:
Nesse caso dos clientes mau pagadores, eu poderia fazer uma query que procurasse as notas pendentes e visse quais clientes estão com notas pendentes (ainda bem que se eu implementar alguma coisa vai ser com o Hibernate 8) ).
Você acha que essa divisão de tipos de pagamento tá boa?
Na vida real, quando a gente precisa analisar e modelar um determinado negócio, sempre há alguém que domina os meandros do negócio que passa as informações a serem modeladas. Isto significa que você deve restringir seu papel a modelar exatamente o que foi pedido sem tentar acrescentar mais nada. Presumo que seja um trabalho de escola e que deva ter algum enunciado fazendo o que seria feito por um analista de negócios ou conhecedor do ramo. Caso afirmativo, fixe-se neste documento pois fazer exatamente o que foi pedido é uma das coisas mais difíceis em informática e pode ser que seu professor exija isto.
Mauricio, acho que viajei aqui… proque tipo de pagamento herda de duas(!) classes? Setinhas invertidas? :mrgreen:
[/quote]
Cara, eu tava no décimo quinto sono quando fiz aquele diagrama, kkkk :lol:
Mas o maior problema de todos, é que não tem ninguém que “saiba do riscado”, o “trabalho” é escolher um problema e modelar ele, então eu pensei em modelar um sistema de vendas e estoque on-line. Só que o comércio do meu pai é pequeno, nós não usamos nenhum sistema de gerenciamento, então não dá pra contar com a experiênia dele usando essas coisas, só com a experiência comercial de vendas e pagamentos mesmo.
Valeu a ajuda, assim que eu tiver mais dúvidas venho aperriar denovo :mrgreen:
Então modele somente controle de estoque. Vendeu, baixou o estoque. Devolveu ou deu entrada, aumentou o estoque. Venda somente a vista e esqueça outros meios de pagamento.
Olá pessoal, aqui estou eu aperriando denovo :mrgreen:
Nas minhas andanças pela rede procurando por uma aplicação de Exemplo encontrei a osCommerce, que é uma loja virtual feia tem PHP. Já baixei e estou começando a dar uma estudada no código deles (e é até muito mais bem feito do que eu ando acostumado a ver em PHP, ainda tô pra ver coisa mais feia que o PHP Nuke :lol: ). O único problema é que ele é bem mais direcionado pra vendas do que pra estoque :lol:
Alguém sabe de algum outro projeto open source de vendas e estoque (de preferência em Java, PHP ou C#)?
1 - Faz parte da logica de negocio para que um produto seja vendido tem que se ter uma proposta.
2 - Os planos de pagamentos , são usados para gerar as parcelas
3- Coloquei as parcelas contendo um pagamento poques as vezes os cliente paga de antecipado e com um tipoDepagamento diferente do original. ex : O cliente liguida todos os boletos do ano com dinhero pago no 3 mes .
ps : Qualquer critica/sugestão será muito bem vinda
Boa Tarde
Vc ainda tem esse sistema em PHP entre em contato por favor opcaoba@opcaoba.com.br
[quote=Mauricio Linhares]Olá pessoal, aqui estou eu aperriando denovo :mrgreen:
Nas minhas andanças pela rede procurando por uma aplicação de Exemplo encontrei a osCommerce, que é uma loja virtual feia tem PHP. Já baixei e estou começando a dar uma estudada no código deles (e é até muito mais bem feito do que eu ando acostumado a ver em PHP, ainda tô pra ver coisa mais feia que o PHP Nuke :lol: ). O único problema é que ele é bem mais direcionado pra vendas do que pra estoque :lol:
Alguém sabe de algum outro projeto open source de vendas e estoque (de preferência em Java, PHP ou C#)?[/quote]
não olhei tudo… mas uma parte que eu notei neste ultimo modelo postado foi a imensidades de pagamentos que tem… tipo pagamento, pagamento com cheque, cartão e porai vai… porque não tenta minimizar este monte de pagamentos?
Achei o tema interessante e deu para tirar muitas duvidas e dar melhores esclarecimentos. Eu tentei isolar o sistema de gestão de estoque do resto… tendo ficado assim
Concentrei nos produtos, que de uma lado o registro de entradas de itemsProdutos e essas entradas vão criar alterações no stock e do outro lado a saída de ItemProdutos e temos o registo do destino dos produtos para sabermos que foram vendidos ou inutilizados em caso de produtos fora do prazo por exemplo. Peço a vossa opinião.
obrigado
