Atualização de dados

Aqui você poderá oferecer suas Contribuições, Dicas e Tutoriais (Texto ou Vídeo) que sejam de interesse de todos.

Moderador: Moderadores

jelias
Usuário Nível 3
Usuário Nível 3
Mensagens: 260
Registrado em: 27 Ago 2008 11:32
Localização: Minas Gerais

Atualização de dados

Mensagem por jelias »

Amiguinhos,

Quero compartilhar com vocês algo que aconteceu comigo e gastei muito tempo procurando "fantasmas" nas linhas de códigos tentando entender o ocorrido. Um cliente me relatou que um item do estoque após uma emissão bem sucedida de uma NF-e de venda, não fez os procedimentos de baixa nos campos de quantidade, girando e não atualizou o campo de última saída e úlitima NF-e. Para completar a estranheza, tenho um arquivo onde salvo todas os movimentações do estoque, tanto de entrada como de saída, e neste arquivo consta a emissão do referido item. O registro só é adicionado no arquivo de movimentação após o sucesso da baixa no arquivo de estoque.
Era como se tivesse executado um rollback no arquivo de estoque.
No ato da baixa no estoque eu faço o seguinte: Vale ressaltar que em todos os processos faço, o travamento de rede. DBAPPEND(), DBRLOCK(), DBUNLOCK(), DBCOMMIT(). Sempre funcionou durante doze anos sem erros.

1 - Salvo em uma variável o saldo do estoque antes da venda
vQtdAnt = AL_ESTOQ->quanti
2 - Realizo a baixa no estoque.
repl quanti with (quanti - Quantidade Vendida)
repl ultnot with (Número da NF-e)
repl ultsai with (Data da Emissão da NF-e)
3 - No arquivo de movimentação, gero um novo registro onde salvo o processo ocorrido.
repl qtdant with vQtdAnt
repl qtdmov with Quantidade Vendida
repl qtdatu with AL_ESTOQ->quanti

Acontece que, eu entrei no arquivo AL_ESTOQ e os campos estavam com o saldo antes da baixa, entendo que não seria possível, pois o saldo atual (após a baixa) eu pego direto do bando de dados.
Eu fiquei frustado por não encontrar o que estava ocorrendo, é um caso único, mais estava me incomodando muito. Foi quando subitamente, me veio a mente a seguinte falha de processo:
Neste clientes eles entram muito no cadastro do item para corrigir novas descrições, mudança de linha, colocar quantidades promocionais, etc.
O usuário pode entrar em um item e o que o programa faz, localiza o item DBSEEK(), passa o conteúdo do item para variáveis e ele começa a alterar alguns dados como um novo termo que precisa ter na descrição, exemplo BUCHA PARA MB1113 e agora precisa ser BUCHA para MB1113/MB1114, o que ocorre é que ele sai para atender um mecânio que precisa de encontrar uma peça no estoque e demora duas horas para voltar. Quando ele volta a variáveis estão desatualizadas, pois digamos que já houve vendas e consequentemente os campos quanti, ultnot, ultsai já estão diferentes das variáveis e quando salvar as variáveis no bando de dados irá causar uma falha neste campos que são importantíssimos para a saúde do sistema.
O que eu fiz, no cadastro de itens do estoque eu não deixo atualizar os campos: quantidade, girando, última saída, última NF-e de saída, dentre outros.
Eu acho que foi este o problema ocorrido no sistema.

Sei que os muitos dos nobres amigos aqui já fazem a coisa certa e não permitem que uma falha deste nível passe batida "como eu deixei". A todos segue minha adimiração . Todavia, como demandou muito tempo para encontrar esta falha, quero compartilhar para que possa servir "alerta/orientação" para aqueles que precisam.

Saudações,

Júlio.
xHarbour 1.2.1 (simplex) + BCC 5.8.2 + Hwgui + SQLRDD
Clipper 5.2e / Blinker 7
Júlio Cézar Elias
e-mail: jelias@tpnet.psi.br
Avatar do usuário
fladimir
Colaborador
Colaborador
Mensagens: 2445
Registrado em: 15 Nov 2006 20:21

Atualização de dados

Mensagem por fladimir »

Obrigado Júlio pela sua informação e experiência...

[]´s
Sun Tzu há mais de três mil anos cita nas epígrafes de seu livro “A Arte da Guerra“:

“Concentre-se nos pontos fortes, reconheça as fraquezas, agarre as oportunidades e proteja-se contra as ameaças”.
“Se não é vantajoso, nunca envie suas tropas; se não lhe rende ganhos, nunca utilize seus homens; se não é uma situação perigosa, nunca lute uma batalha precipitada”
.


Até 2017    Desktop Console [ Legado ] Harbour | MinGW | DBF | CDX | FastReport | MySQL


Novos Projetos:

   Desktop Visual           Windev Desktop
   Celular Android/iOS   Windev Mobile
   WEB                            Windev Web


Sejamos gratos a Deus.
Avatar do usuário
rochinha
Administrador
Administrador
Mensagens: 4664
Registrado em: 18 Ago 2003 20:43
Localização: São Paulo - Brasil
Contato:

Atualização de dados

Mensagem por rochinha »

Amiguinho,

Um controle de estoque funciona identicamente a um controle de caixa ou contas corrente. E como visto nenhum deles pode apresentar falhas. Somente falhas de usuário são aceitas e uma forma de estorno deve ser incrementada.

O controle de estoque geralmente tem atrelado a ele o arquivo de movimentações, entradas e saídas portanto de vez em quando você deve executar uma rotina que faça um recalculo das entradas e saídas e devolva o saldo aproximado.

O fato de você limitar a alteração dos campos quantitativos é o primeiro passo para "o controle".

Eu tenho em meu sistema, no controle de estoque as rotinas de auditoria.

Como funciona?

Auditoria - Ao ser executada ela verifica se o item ja tem auditoria em andamento.
- Se já esta em andamento só permite movimentos de entrada, saida, transferencia e ajuste.
- Se não está em andamento pede a quantidade levantada do item e cadastra a quantidade, data e hora do lançamento.
Neste momento a vida do item começa a se desenrolar.

Qual a finalidade deste processo.

1-A partir da data de auditoria voce poderá fazer um levantamento dos movimentos feitos no item até a data atual.
2-Voce pode reiniciar a auditoria outras vezes, e os movimentos anteriores não entram no levantamento.
3-Voce pode fazer a auditoria do estoque sem a necessidade de baixar as portas do estabelecimento.

O controle fica por conta das rotinas permitidas para o movimento do estoque, ou seja, qualquer movimento no campo quantidade só será realizado mediante a um lançamento feito no arquivo de movimentos, seja de saída, entrada, transferencia(neste caso quando se tem multiplos locais de estocagem) e ajuste.

Um fator interessante é:

Só deverá existir um registro de auditoria na listagem da vida do item, mas cada ajuste reinicia o calculo do saldo.

Exemplo:

Código: Selecionar todos

DATA_|_MOVIMENTO_|_DESCRICAO_|_QUANTIDADE_|_SALDO
10-10-2011_|_Auditoria_|_Produto A_|_100_|_100
11-10-2011_|_Saida_|_Produto A_|_10_|_90
12-10-2011_|_Saida_|_Produto A_|_10_|_80
12-10-2011_|_Entrada_|_Produto A_|_8_|_88
12-10-2011_|_Saida_|_Produto A_|_5_|_83
13-10-2011_|_Saida_|_Produto A_|_8_|_75
13-10-2011_|_Saida_|_Produto A_|_2_|_73
14-10-2011_|_Ajuste_|_Produto A_|_80_|_80
15-10-2011_|_Saida_|_Produto A_|_10_|_70
16-10-2011_|_Entrada_|_Produto A_|_100_|_170
...
Para entender qual o valor do saldo final voce tera de relacionar todos os registros a partir da data de auditoria e ir calculando, entrada e saida, caso encontre um ajuste no meio do caminho o valor inicial é zerado e continua o recalculo a partir do ajuste. Cada ajuste zera o contador.

Outra fator interessante na listagem do levantamento é relacionado a transferência. Apesar de ser um único tipo de movimento ele pode ser de entrada ou saída ou seja, transferência do estoque para loja ou da loja para o estoque.

Com estas dicas voce poderá formar as rotinas de controle do estoque com mais segurança, já que o levantamento funcionará como um log de acontecimentos.
OPS! LINK QUEBRADO? Veja ESTE TOPICO antes e caso não encontre ENVIE seu email com link do tópico para [url=mailto://fivolution@hotmail.com]fivolution@hotmail.com[/url]. Agradecido.

@braços : ? )

A justiça divina tarda mas não falha, enquanto que a justiça dos homens falha porque tarda.
Responder