GRC morto por causa do SKIPR

[Former Member]

Olá amigos

nós estamos tendo um grande problema com milhares de pedidos SKIPR abrandar o nosso sistema para que nada pode passar. Estamos em GRCsp14.

Você tem alguma idéia para nós?

MUITO OBRIGADO!

[former_member182114 · Accepted solution]

Bom dia Aaron,

Faça o seguinte.

Pare o endless job /xnfe/process_reports na SM37.

Escalone ele novamente porém sem o flag "check acknowledgments".

E crie um novo job para o programa /xnfe/get_acknowledgment com intervalo de 1 minuto.

Isto resolverá o problema de emissão.

As inutilizações continuarão ser processadas sem problemas maiores. Exceto que algum usuário precise inutilizar uma nota, aí vai no fim da fila grande.

Atenciosamente, Fernando Da Rós

[Former Member · Accepted solution]

Obrigado Fernando.

Fizemos essa mudança e isso não ajuda imediatamente. Chamamos SAP e eles sugeriram o mesmo. No entanto, as mensagens só começou a processar novamente após um reinício completo.

Até agora, desde então, ele está OK, o número de confirmações na tabela "/ xnfe / acknowledge" não ter crescido novamente.

No entanto, eu acho que ainda é um problema em algum lugar, eu não sei por que estamos recebendo milhares de transações SKIPR no monitor PI todos os dias.

O que é uma quantidade normal de Skip transações a serem enviados para uma única solicitação SKIP?

[former_member182114 · Accepted solution]

Bom dia Aaron,

A quantidade de SKIP "normal" depende do número de cancelamentos pedidos pelos usuários quanto uma nota fiscal eletrônica não pode ser autorizada no monitor. Este número pode até ser um pouco maior na implementação, mas à medida que o cadastro dos clientes/parceiros é limpo e os processos/usuários se adaptam à NF-e isso tente a próximo de zero.

Você disse que continuam chegando, então provavelmente você tem fila de requisições no ERP (veja transação SM58, procure pela função /XNFE/NFE_SKIP)

A propósito, se foi necessário um restart para o sistema funcionar corretamente é que muito provavelmente não conseguiram cancelar o job via SM37, tem casos em que só via SM50 que dá para cancelá-lo.

Atenciosamente, Fernando Da Rós

[Former Member]

Isso aconteceu com a gente de novo hoje, quando alguém tentou executar o Relatório GAP em J1BNFE

Não temos certeza de como parar o dilúvio de pedidos SKIPR.

Acabamos sessão do usuário em ERP e também as funções / XNFE / NFE_SKIP (pelo mesmo usuário) em SM58.

No entanto, as transações SKIPR ainda tenta inundar o sistema de PI. Qualquer conselhos sobre como acabar com esses pedidos de GRC sem reiniciar?

[Former Member]

Pode ser erro de parametrização (customizing), fazendo com que o Relatório do GAP detecte centenas de GAPs que não deveriam existir.

Sugiro executar o relatório de GAP manualmente em modo TESTE e analisar se os GAPs encontrados procedem ou não (intervalo de numeração, formulário, grupo, serie e número - se estão todos corretos).

Já vi parametrizações que iniciaram a numeração de NF-e de uma filial em 300000. Ai quando foi rodar o relatório de GAP em modo TESTE (background), encontrou 299999 inutilizações (SKIP).

Outros casos foram problemas de grupo/formulário.

obs.: Se realmente tiver milhares de GAPS, sugiro programar a execução do JOB para um horário mais propício e também aumentar a quantidade de filas para processamento do SKIP pela transação do PI SWF_INB_CONF (SKIPR_SkippingRequestProcess) durante a execução do relatório de GAP.

At.,

Bernardo Braga