PC Toledo

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.

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

[]´s

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: 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.