Performance/Funcionamento J_1BNFECHECKNUMBERRANGES

[Former Member]

Bom dia.

Estou programando a execução do programa J_1BNFECHECKNUMBERRANGES filial por filial aqui na empresa.

Estou com uma dúvida: Se executar o programa no modo "Assíncrono" ele irá enviar todas as notas de uma vez e caso tenha gaps muito grande poderá inundar o GRC de notas?

A execução no modo "Síncrono" evita este problema? Neste modo as notas são enviadas uma a uma evitando a geração de milhares de notas de uma vez?

At.,

Bernardo Braga

[former_member193386 · Accepted solution]

Bernardo

Uma duvida, vc esta tendo pulos de numeracao em cada uma das suas filiais que irao gerar tantas chamadas de inutilização assim?

[Former Member · Accepted solution]

O história é a seguinte.

Estava bem tranquilo sentado em minha mesa quando de repente reparo um aumento significativo das mensagens na SMQ2, ai reparei que eram as filas de NF-e.....de repente tinha 97.000 mensagens...o resto da para imaginar...rs.

Descobrimos que alguem executou o programa J_1BNFECHECKNUMBERRANGES para 1 filial que gerou mais de 90.000 notas fiscais de inutilização (mesmo BASIS tendo cancelado o JOB no meio do caminho para tentar conter a inundação).

Unico jeito de normalizar a situação em tampo hábil foi e exclusão das mensagens da SMQ2 e limpar a tabela /XNFE/ACKNOWLEDG (que não estava deixando o programa /XNFE/PROCESS_REPORTS funcionar corretamente).

Problema é que de um jeito ou de outro teremos que executar novamente este programa para esta filial (e para as outras). Mas se for gerar este tanto de notas, nem agendando para 1 da manhã de domingo conseguirei limpar as filas até o dia seguinte.

Gostei da idéia de configurar uma única fila para o processo de skip (SWF_INB_CONF). Porem com 1 fila apenas vai levar dias, certo?

At.,

Bernardo Braga

[former_member182114 · Accepted solution]

Ow.. Que quantidade... Pode ser gap falso isso, tem que pedir ao usuário para rodar em teste até ter certeza que os números realmente não existem.

O default é estar configurado para 1 fila apenas, mas você me lembrou de outra coisa que é a tabela de acknowledgments que fará o fechamento/consulta de lote dar problema, o que pode gerar um delay enorme na geração/consulta de lotes.

Para não cair no problema do ACK dar lentidão (imensa lentidão), você pode criar um job novo de intervalo 1 minuto com dois passos:

/xnfe/collect_batch

/xnfe/request_batch

Estes são os subprogramas do /xnfe/process_reports. Colocando desta forma você pode cancelar a qualquer momento e o problema seria somente 1 skip individual ficar nesta fila de 97000.

Para esta quantidade pode ser melhor aumentar o paralelismo para pelo menos 3 (depende do número de WP's disponíveis no seu sistema).

Atenciosamente, Fernando Da Rós

Edited by: Fernando Ros on Aug 15, 2010 1:01 AM

[Former Member]

Bernardo boa tarde,

Você conseguiu executar o processamento das mais de 90.000 notas? Se sim, por favor, dê mais detalhes do que foi feito pois temos um cenário muito parecido e com uma janela reduzida para processamento,

Atenciosamente,

André Luiz

[Former Member]

Boa tarde.

Ainda não. Na verdade indentificamos que devido a problemas de customizing, foi criado a falsa impressao de GAPs (os GAPs falsos citados pelo Fernando). Exemplo: criaram sem querer uma customizacao/nota de um formulario/intervalo que nao era para existir com numero 1000 (gerando assim um falso GAP de 999).

Vimos duas possibilidades (ainda será analisado pela equipe de SD):

1a) Fazer uma cópia do programa e adapta-lo;

2a) Alterar os registros da tabela que consta o ultimo numero verificado (toda vez que o programa é executado ele grava em uma tabela qual foi o último numero verificado. Assim, da proxima vez que for executado ele só verifica a partir deste numero);

Deve ser analisado o risco e impacto de cada solução. E qual melhor atende as suas necessidades.

At.,

Bernardo

[Former Member]

Bernardo boa tarde,

Obrigado pelo rápido retorno, no nosso caso teremos que executar o processamento mesmo, assim que tivermos uma estratégia definida informo pra você o que foi feito, dúvida, no seu caso se a alternativa 2 foi adotada a Sefaz não tem que ser informada sobre este intervalo que a empresa não irá utilizar?

Atenciosamente,

André Luiz

[Former Member]

Na verdade foi utilizado.

O problema foi a customizacao que criou uma nota para um outro formulario de uma empresa que estava faturando normalmente. Esta nota nao deveria ter sido criada.

Como o programa busca por intervalo/formulario/empresa, ele vai considerar um GAP do 1 até o numero que a nota foi criada.

At.,

Bernardo Braga

[Former Member]

Boa.

Vou tentar isso. Alterar SWF_INB_CONF e criar outro JOB paralelo.

Vou ter que programar esta execução com possível impacto, então deve levar alguns dias até conseguir as devidas autorizações.

Obrigado pelas dicas. Boa sorte para mim.

Depois que executar posto aqui o resultado.

At.,

Bernardo Braga

[former_member182114]

Bom dia Bernardo,

O sincrono e assincrono neste caso é quando à entrega ao GRC, não o processamento do GRC. Entregar assincrono vai colocalos em fila visível na SM58.

De um jeito ou de outro o GRC receberá todos os pedidos de inutilização e processará conforme está definido o paralelismo de filas no GRC.

Se por exemplo, não foi configurada multiplas filhas para o processo de skip (SWF_INB_CONF) então o problema que pode afetar o negócio é você ter uma nota individual a ser inutilizada no momento em que estiver processando os gaps.

Sugestão: Rode como teste diuturnamente e programe em background para a rodada definitiva. Isto claro, se for uma quantidade grraaande de gaps.

Atenciosamente, Fernando Da Ró

[henrique_pinto]

Bernardo,

vc tem a possibilidade de rodar o report em modo de simulacao, e verificar quantos gaps vc vai ter de fato.

Ao final vc consegue verificar melhor se vao ser muitos ou nao.

Um outro ponto, talvez valha a pena, ao menos temporariamente, aumentar o numero de filas para o BPM de inutilizacao.

Abs,

Henrique.