[firebase-br] RES: RES: Dúvida com controle de estoque
Sofia Bonato de Moraes - EES
sbonato em ees.com.br
Sex Jul 28 11:03:32 -03 2017
Só pra constar nas opiniões, trabalhamos também, como foi citado abaixo, com tabela de movimentação e fechamento de estoque.
Assim, se precisar reprocessar, vc o faz somente desde o último fechamento, minimizando o tempo de processamento.
-----Mensagem original-----
De: lista [mailto:lista-bounces em firebase.com.br] Em nome de Marcelo Geyer
Enviada em: sexta-feira, 28 de julho de 2017 10:55
Para: FireBase <lista em firebase.com.br>
Assunto: Re: [firebase-br] RES: Dúvida com controle de estoque
O ideal é o que já foi sugerido e o que você constatou no seu post, trabalhar com uma tabela de movimentação. O que alguns desenvolvedores fazem, e eu particularmente, é definir datas para fechamento de estoque. Então você terá um registro com o estoque atual e este será o seu registro de partida para calcular o estoque. Este data de fechamento você pode deixar a cargo da empresa. Tem empresas que fazem a conciliação à risca do estoque mês a mês, então você poderia fazer o fechamento mês a mês. Tem outras que o movimento é pequeno, então você pode fazer um fechamento trimestral ou semestral. E se precisar fazer ajustes no estoque, você deve tratar esses fechamentos, reabrindo-os (na prática você estaria excluíndo este registro de totalização na movimentação ou então, setando uma flag que indicaria que este registro foi reaberto e deve ser ignorado).
Em 28 de julho de 2017 10:14, Adilson B. Cápua Jr.
<juniorcapua em gmail.com> escreveu:
> Eu, no meu caso, usava/uso uma query para montar uma tabela temporária
> em memória para preparar o relatório. Tenho um cliente com um cadastro
> de aproximadamente 80 mil produtos e um relatório de saldo de estoque
> leva em torno de 10 segundos do momento em que o usuário clica no
> botão "GERAR RELATÓRIO" até o mesmo ser exibido! Com a query em
> memória, depois posso fazer um simples select (inclusive com filtros) e tudo flui tranquilamente!
>
> Qualquer coisa, estamos aí pra ajudar!
>
> Um abraço!
>
> _____________________________________
> Adilson Bragança Cápua Jr.
> Linhares - ES Brasil
>
> Mail:* juniorcapua em me.com <juniorcapua em me.com>*
> * juniorcapua em gmail.com <juniorcapua em gmail.com>*
> * juniorcapua em yahoo.com.br <juniorcapua em yahoo.com.br>*
> Messenger:* juniorcapua em live.com <juniorcapua em live.com>*
> Skype:* dellas_capua*
> Blogger: http://dellasnoites.blogspot.com/
> _____________________________________
> "Save a tree! Send an e-mail!"
>
> Em 28 de julho de 2017 09:44, Marcelo - MK Softwares <
> marcelo em mksoftwares.com.br> escreveu:
>
>> Ola Adilson
>>
>> Muito obrigado por compartilhar a sua experiencia comigo/conosco. Mas
>> acabei ficando com uma duvida. Hoje em um relatório de posição de
>> estoque o sistema de gestão utiliza uma query mais ou menos assim:
>> Select codpro, descpro, precocusto, ..., estoqueatual from produtos
>> blablabla
>>
>> No seu caso usando uma SP para retornar o estoque somente no momento
>> que seria necessário, como que ficaria um caso parecido ao citado
>> acima. Me desculpe mas não estou conseguindo visualizar uma solução.
>>
>>
>> -----Mensagem original-----
>> De: lista [mailto:lista-bounces em firebase.com.br] Em nome de Adilson B.
>> Cápua Jr.
>> Enviada em: sexta-feira, 28 de julho de 2017 01:53
>> Para: FireBase <lista em firebase.com.br>
>> Assunto: Re: [firebase-br] Dúvida com controle de estoque
>>
>> Boa noite, Marcelo!
>>
>> Então, eu faço algo mais ou menos parecido com o que você citou,
>> tanto para estoque, quanto para qualquer tipo de movimentação que
>> exista um saldo, como o controle de estoque citado por ti e também um
>> caixa, onde temos um valor saldo que é calculado em relação e
>> entradas (créditos) e saídas (débitos).
>>
>> O que eu utilizo é uma SP que faz todo o serviço, ou seja, passo para
>> ele o ID do produto e ele pega todas as saídas e depois todas as
>> entradas e calcula o saldo. Eu não tenho um campo "SALDO ATUAL" na
>> minha tabela, pois o saldo é calculado no momento que se precisa
>> dele. Dessa forma, evita-se erros de inconsistência com saldos, ou
>> seja, o cálculo do saldo só é feito com o que realmente está efetivado!
>>
>> Em um passado remoto eu trabalhei dessa forma que você citou. Tinha
>> um campo SALDO e eu ia somando ou subtraindo, de acordo com a
>> operação. Isso ocasiona muitos erros, pois às vezes em uma alteração,
>> o usuário podia ir no registro de saída que tinha 10 por exemplo,
>> alterava para 15. Depois o usuário se arrependia do que fez e
>> cancelava a alteração! Já viu o que poderia acontecer, né? Da forma como eu trabalho isso não existe!
>>
>> Quanto a questão de performance, pode ficar despreocupado que o
>> Firebird é um banco espetacular em se tratando disso. É um dos únicos
>> bancos relacionais que pode ser instalado em máquinas bem "humildes"
>> mesmo! Eu já tive clientes que usavam como servidor um Celeron com 2
>> GB de RAM e o sistema funcionava muito bem! Claro que você precisará
>> otimizar bem as suas querys para que o mínimo de dados possíveis seja
>> buscado, mas isso já é uma prática comum até para quem tem um
>> servidor dedicado e potente (um XEON, por exemplo, com 32 GB RAM e
>> SSD 1 TB)! Mesmo com essa configuração aí citada, se você tiver uma
>> query mal-formulada, usando índices complexos e mau-determinados, você vai ter problemas com performance!
>>
>> O pessoal aqui da lista vai confirmar isso, mas performance tem mais
>> a ver com a forma que você lê e grava no seu banco (seja ele qual
>> for) do que com a máquina em si!
>>
>> Boa sorte!
>>
>> _____________________________________
>> Adilson Bragança Cápua Jr.
>> Linhares - ES Brasil
>>
>> Mail:* juniorcapua em me.com <juniorcapua em me.com>*
>> * juniorcapua em gmail.com <juniorcapua em gmail.com>*
>> * juniorcapua em yahoo.com.br <juniorcapua em yahoo.com.br>*
>> Messenger:* juniorcapua em live.com <juniorcapua em live.com>*
>> Skype:* dellas_capua*
>> Blogger: http://dellasnoites.blogspot.com/
>> _____________________________________
>> "Save a tree! Send an e-mail!"
>>
>> Em 27 de julho de 2017 23:58, Marcelo - MK Softwares <
>> marcelo em mksoftwares.com.br> escreveu:
>>
>> > Boa noite.
>> >
>> >
>> >
>> > Estou com uma duvida com relação a normalização do banco de dados
>> > para com o controle de estoque.
>> >
>> > Vou apresentar o meu cenário atual:
>> >
>> > - Versão do banco 2.5;
>> >
>> > - Possuo muito clientes que possuem computadores com pouco poder de
>> > processamento (várias pequenas empresas com apenas um computador);
>> >
>> > - O controle de estoque esta sendo realizado mediante atualização
>> > do saldo do estoque do produto no campo “EstoqueAtual”, onde quando
>> > se ocorre uma entrada ou saída o software de gestão faz a leitura
>> > do registro do produto, pega o saldo atual no estoque e faz a
>> > atualização do mesmo (entrada ou saída). Após isso é feito um
>> > update no registro com o valor do estoque atualizado.
>> >
>> >
>> >
>> > Baseado nessas informações observei que não é correto (pelo menos
>> > creio eu), então estou pensado de criar uma tabela onde possa
>> > armazenar as movimentações. Desse modo apenas iria fazer um insert
>> > com os valores do produto que se esta movimentando. Onde um campo
>> > teria uma flag: D ou C (débito ou credito), e através de uma
>> > trigger disparar uma atualização no campo “EstoqueAtual” da tabela
>> > de produtos, retornando para a mesma o saldo em estoque do produto.
>> >
>> >
>> >
>> > Bom até ai esta muito bonito e legal (pelo menos no meu
>> > pensamento), mas a dúvida que não quer calar:
>> >
>> > - Fazendo desse modo não ficará lento, para computares menos
>> > favorecidos de processador, quando o banco de dados estiver enorme,
>> > digo vários registros nessa tabela?
>> >
>> > - Na minha opinião essa trigger será mais ou menos assim: Executará
>> > um SELECT SUM para todas as flags “D” e outro SELECT SUM para todas
>> > as flags “C”, para o produto movimentado. De posse dos dois
>> > valores, executar um update na tabela de produtos com a diferença
>> > dos dois
>> valores.
>> >
>> > - Caso este modo esteja errado, qual a sugestão que me aponta para
>> > este problema?
>> >
>> >
>> >
>> > Desde já agradeço a todos.
>> >
>> >
>> >
>> > ______________________________________________
>> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>> > Para saber como gerenciar/excluir seu cadastro na lista, use:
>> > http://www.firebase.com.br/fb/artigo.php?id=1107
>> > Para consultar mensagens antigas: http://www.firebase.com.br/
>> > pesquisa_lista.html
>> >
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>> Para saber como gerenciar/excluir seu cadastro na lista, use:
>> http://www.firebase.com.br/fb/artigo.php?id=1107
>> Para consultar mensagens antigas: http://www.firebase.com.br/
>> pesquisa_lista.html
>>
>>
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>> Para saber como gerenciar/excluir seu cadastro na lista, use:
>> http://www.firebase.com.br/fb/artigo.php?id=1107
>> Para consultar mensagens antigas: http://www.firebase.com.br/
>> pesquisa_lista.html
>>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas:
> http://www.firebase.com.br/pesquisa_lista.html
--
Marcelo E. Geyer
Standard Net Tecnologia e Informação
______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
Para consultar mensagens antigas: http://www.firebase.com.br/pesquisa_lista.html
Mais detalhes sobre a lista de discussão lista