Gap Monitor/report (Monitor/Relatório de lacuna) – usuário de execução
O objetivo deste post é demonstrar como localizar o usuário que gerou a solicitação de inutilização no Report de lacuna, visto que esta informação não está na tabela onde os registros são gravados.
Tivemos um caso desastrado de uso do gap report 
(programa J_1BNFE_GAPMONITOR, acessado via J1BNFE) onde um usuário solicitou inadvertidamente a inutilização de 2 séries de uma filial. Como até semana passada a operação desta filial era fora do SAP, tem +-30.000 notas de cada série emitidas fora do SAP, assim, ao verificar o gap de numeração, foram identificados praticamente 60k números.
Como o report vem por default com a opção “Exec.teste (s/execução RFC)” 
desmarcada (ou seja, vai enviar as solicitações), é fácil fazer a operação, visto que não há qualquer alerta ou confirmação após mandar executar.
No cliente onde isso ocorreu foram geradas perto de 60k mensagens de inutilização, gerando uma fila de processamento gigante no PI e fazendo com que as demais solicitações de inutilização ficassem represadas (a média de tempo de processamento ficou perto de 1000/hora, ou seja, quase 3 dias processando isso tudo).
Tirando o problema em si, tentamos identificar quem gerou esta solicitação, porém verificamos que na tabela J_1BNFENUMGAP não existe campo identificando o usuário de criação dos registros. No monitor de inutilização no GRC tampouco temos o usuário identificado, apenas o usuário da RFC aparece.
Fazendo um trace na execução do report podemos observar que é feito um insert na tabela DBTABLOG, com o campo TABNAME = J_1BNFENUMCHECK. Consultando as entradas nesta tabela com este TABNAME foi possível identificar o usuário e posteriormente orientá-lo a executar com mais critério este report.
Exemplo de resultado, mostrando que podemos ver a chave da execução (LOGKEY) e o usuário (USERNAME):
Adicionalmente, ficam alguns alertas:
1) Não há confirmação de execução do report, mesmo com a opção de teste desmarcada;
2) Não verifiquei os detalhes de objeto de autorização, porém mesmo com perfil sem autorização de numeração, cancelamento, etc. foi possível executar o report;
Se alguém teve mais experiências positivas ou negativas e/ou dificuldades no uso desta ferramenta, pode comentar para compartilharmos e dar um feedback para melhoria da ferramenta.
Abs,
Eduardo Hartmann
Oi Eduardo,
Eu já vi pelo menos uns 10 desastres desses ocorrendo ( com mais de 60 mil gaps gerados em um dos casos ).
O que você acha que poderia ter de melhoria no relatório para evitar esse tipo de situação?
att,
Renan Correa
Eu sugiro que a opção de execução de testes, venha marcada por default.. e se possível adicionar um objeto de autorização
Silvio, pensei a mesma coisa quando li este blog, otima sugestão!!!!
Renan, Silvio,
Certamente a principal necessidade é do check de autorização, mas o flag de execução em teste também é muito importante.
Adicionalmente poderíamos colocar melhorias funcionais:
1) Limitar o envio de um X de mensagens de cada vez (ex.: 500). Eventualmente bloquear novo envio se tiver Y mensagens sem retorno (assim evita rodar diversas vezes em sequencia);
2) Opção de criar as solicitações por ranges (atuamente é 1 a 1). No caso se fosse por range teríamos enviado menos de 10 mensagens, pois para cada série temos desde a 1 até o número inicial que foi criado no SAP, para essas apenas 2 mensagens seriam suficientes, desde que abrangendo o range inteiro.
3) Incluir uma mensagem (popup) de confirmação da execução (se clicar por engano não executa antes de confirmar);
4) Incluir usuário de criação da solicitação;
5) Incluir data e hora da criação da solicitação (atualmente temos o campo Data Criação que pega da primeira nota posterior ao intervalo, o que confunde demais);
6) Formatar melhor a tela que mostra as solicitações criadas, informando em algum lugar que foram geradas as solicitações (atualmente aparecem os registros listados, porém fica confuso de entender que aquelas foram efetivamente solicitações criadas e enviadas);
7) Semáforo de processamento;
8) Poderia ter um warning no processamento caso não tenha sido preenchida a informação de último número verificado, ou então poderia processar apenas as séries que tenham sido cadastradas nessa listagem, impedindo uma execução acidental (força um pré-work);
9) Tive um retorno de que o nome "Gap Report" gera confusão, dando a entender que esse report mostraria o que tem problemas. O título da tela está como "Check Number Range Gaps", não informando a correta função (e.g.:"Number Gap Skip request"). Poderia trocar a entrada de menu para "Gap Skip Request" ou "Number Gap Skip request", e a do monitor para "Number Gap Monitor".
Foi o que pensei até agora 🙂
Se conseguir mais um tempinho vou registrar isso no Idea Place (se alguém quiser adiantar, agradeço hehehe).
Abs,
Eduardo Hartmann
Eduardo,
excelente blog! Já passei por problemas em um cliente com este report justamente por conta da opção padrão não ser a de teste. Por sorte o estrago foi pequeno, se comparado com o seu rs.
Renan, acredito que o que foi sugerido pelo Silvio Miranda já reduza a probabilidade de ocorrer esse tipo de problema.
[]'s
JN
Muito bom Eduardo!!!
Ainda não passei por este sufoco...agora quero ver o cliente resolver esta hein!!!!
Abraço,
Karen Rodrigues
Bom Dia, Eduardo
Eu executei essa função, e somente depois que vi seu post..
Nesse caso o que poderia fazer pra retorna esse problema, ou temos que deixar dessa forma mesmo agora.
segue abaixo um print da execução..
Olá Denis,
Desculpe, mas não entendi bem o seu questionamento.
Você quer saber sobre as alternativas para cancelar/eliminar as mensagens?
Se for isso, você pode verificar no PI em qual das filas estão as mensagens e eliminar tudo o que tem na fila, porém pode ser que tenha outras mensagens que não sejam do "acidente", podendo gerar efeitos colaterais. Daí fica a seu critério se vai assumir o risco - aqui não conseguimos achar um jeito de eliminar apenas as mensagens específicas da fila, mesmo tendo conseguido identificar todas as mensagens. Também não conseguimos cancelá-las na SXI_MONITOR, pois elas já foram scheduladas.
Se alguém tiver outras ideias, são bem vindas 🙂
Obrigado,
Eduardo Hartmann
Ola, Eduardo
obrigado pelo contato
Na verdade as mensagens já foram geradas, e não tínhamos muitas notas, foram apenas 800, e que já foram enviadas ao Sefaz para inutilização. Pelo que entendi, se o sistema gerou essas notas e o Sefaz aceitou, é porque realmente tínhamos um problema de lacuna correto?
E o ajuste realizado pelo sistema não seria um problema!! Essa é a minha preocupação.
Pois como vcs mencionaram acima, a transação confunde muito, por dizer que é um relatório..
Atenciosamente
Denis