Númeromov Saltando Sequência Numérica

[Robinson]

Olá pessoal

Desde que migrei a versão do nosso sistema de 11.20 para 11.52 estamos tendo problema com a sequência numérica da série 0, utilizada nos movimento de emissão de NFe.

Já falamos um monte de vezes com a Totvs e eles não conseguem dar nem uma ideia do que poderemos fazer...

Já reinstalei o BDE, Biblioteca e RM Nucleus no computador de todos os faturistas, conferi se mais alguém mais estava tentando faturar, conferi o LOG de auditoria para saber se alguém estava excluindo movimentos, mas nada está errado e ninguém mais além dos faturistas estão tentando gerar movimento de nota, ou seja, com a série 0.

Alguém já teve este problema e tem alguma ideia do que pode ser?

Estou analisando aplicação e banco de dados, mas continuo no vazio :-(

Ps.: A série 0 (zero) é a principal em todos os movimentos do qual está configurada e a numeração não está como editável, está automático.

Até mais pessoal.

[Nik]

Tem Trigger na tmov? pode ser isso.

NIK

[Jair - Fórmula]

A frequência que tem ocorrido esse problema é grande? ou está bem esporádico ?

Não seria o caso de ativar o log na tabela que controla a numeração (GAUTOINC)?? Assim, vc pode ver a data e hora que em algum momento foi feita atualização para um numero que eventualmente tenha sumido depois, tentando associar isso a algum processo e/ou inclusão de movimentos.

[Robinson]

Olá Nik e Jair

Obrigado pelo contato amigos.

Bom, trigger não tem Nik.

Até pensei nessa possibilidade, mas infelizmente não é.

Conferi a TMOV a TITMMOV e mais algumas outras, mão a única trigger que existe é a do log de auditoria, do próprio sistema.

Jair, até agora eu só procurei armazenar colher logs das tabelas relacionadas ao faturamento, mas não na gautoinc diretamente. Vou configurar isso e vamos ver se tenho mais sorte assim :-).

Quanto a frequência, a coisa não é tão frequente, quer dizer, não acontece todo dia, mas uma ou duas vezes na semana e as vezes salta apenas um número e as vezes 5, 10 ou mais de uma só vez. Também reparei que o usuário que gerou o último número antes do número perdido e o usuário que gerou o movimento posterior variam entre os faturistas, não é sempre o mesmo.

Se tiverem mais alguma sugestão aceitarei, pois minha mente já está ficando oca de ideias....

Grande abraço amigos

[Robinson]

Jair, se você souber, me de uma dica por favor....

Ativei no log de auditoria tudo encontrei referênte a série, mas ainda não encontrei a opção correta, por que não gerou nenhum log da tabela GAUTOINC e também não vi nenhuma trigger criada nesta tabela, o quê acontece quando ativamos o Log de Auditoria.

Se mais alguém souber, ajuda é sempre bem vinda.

Enquanto isso a numeração aqui continua pulando e eu não consegui descobrir nada ainda!

A frequência que tem ocorrido esse problema é grande? ou está bem esporádico ?

Não seria o caso de ativar o log na tabela que controla a numeração (GAUTOINC)?? Assim, vc pode ver a data e hora que em algum momento foi feita atualização para um numero que eventualmente tenha sumido depois, tentando associar isso a algum processo e/ou inclusão de movimentos.

[Jair - Fórmula]

Eu acho que há um bloqueio interno nas procedures do LOG pra não registrar algo da GAUTOINC... sei que há tabelas que não gerencia. Essa pode ser uma delas.

[Robinson]

Poxa vida

Tô na roça!

O sistema continua pulando numeração.

A Totvs não consegue simular o nosso problema e na verdade nem eu, pois o problema acontece a qualquer momento e não consegui descobrir se quer por qual estação ele é causado, quanto mais por qual tipo de movimento, já que a série sempre foi compartilhada, e muito menos em que momento.

Se alguém tiver mais alguma dica, estou precisando muito. Até agora não consegui pensar em mais nada novo....

Até logo pessoal.

[Edson Silva]

Robinson, será que pelo monitor/trace não daria para rastrear em pelo menos uma estação ?

[Robinson]

Até pensei nisso mas fiquei com receio de gerar muita informação e lotar o servidor.

Edson, esse não acontece todo dia.

Na semana passada aconteceu na segunda e na sexta a tarde.

Esta semana aconteceu ontem.

Temos 8 faturistas e não consegui nenhuma evidência que indica-se que em qual deles ou se em todos eles é onde o problema tem origem.

Sinistro!

Sua dica é boa sim e já estou pensando em como rodar o profile para isso.

Valeu e se tiver mais dicas pode mandar

Robinson, será que pelo monitor/trace não daria para rastrear em pelo menos uma estação ?

[Edson Silva]

Que inhaca heim !!! Mas acho que vale apena executar para uma estação e orientar o usuário a limpar o log se não saltar o numero, vai ter que ser na unha mesmo .

[Robinson]

Amigos!

Com a utilização do SQL Profiler consegui pegar o momento do erro e descobri que ele é causado por uma outra falha.

As vezes quando um futurista envia um pedido de venda para o movimento de nota e clica em salvar ou em OK o sistema da erro por que não está conseguindo truncar o campo de observação para mandar somente uma parte deste texto ao lançamento gerado no RM Fluxus e cada vez que o faturista tenta salvar o movimento o sistema envia um Update para a GAUTOINC trocando o número atual pelo mesmo + 1.

Olhem o comando aí:

exec sp_executesql N'--RMSLicenceServer  UPDATE GAUTOINC SET VALAUTOINC = @VALAUTOINC, RECMODIFIEDBY = ''SYSTEM'', RECMODIFIEDON = CONVERT ( DATETIME, CONVERT ( VARCHAR, GETDATE(), 120) )	   WHERE CODCOLIGADA = @CODCOLIGADA AND CODSISTEMA = @CODSISTEMA AND CODAUTOINC = @CODAUTOINC		 AND (VALAUTOINC = @VALAUTOINC2 OR VALAUTOINC IS NULL)',N'@VALAUTOINC int,@CODCOLIGADA smallint,@CODSISTEMA varchar(1),@CODAUTOINC varchar(9),@VALAUTOINC2 int',@VALAUTOINC=49427,@CODCOLIGADA=1,@CODSISTEMA='T',@CODAUTOINC='0  000001',@VALAUTOINC2=49426

Agora estou tentando resolver este problema

Se alguém tiver alguma dica....

Agora estou na versão 1.52.57.163

Até mais pessoal

[Edson Silva]

Que bom que descobriu o erro, mas tente atualizar a biblioteca para 11.52.58 numa estação e monitore.