Tempo de espera para Montagem do Lote de NF-e

[pedro_baroni3]

Olá pessoal.

Estive fazendo algumas alterações nos parâmetros de Configuração do Lote de NF-e com o intuito de obter melhor desempenho durante o Envio de NF-e's à SEFAZ.

Pesquisando aqui no SCN encontrei um documento muito bom do Fernando Ros:

Importância da Configuração de Lote de NF-e - SAP NFE 10.0

Como fiquei com dúvida em relação ao parâmetro de tempo (Max Time), gostaria de expor o meu entendimento e solicitar auxílio na obtenção de uma configuração ideal conforme o Cenário necessita.

Entendi que a cada NF-e que é assinada no SAP GRC, o tempo começa a contar de novo. Exemplificando:

Configuração do Max Time = 30 segundos:

NF-e 001 - Assinada às 14:00:00 - Previsão de Fechamento de Lote definida para 14:00:30

NF-e 002 - Assinada às 14:00:25 - Previsão de Fechamento de Lote adiada   para 14:00:55

NF-e 003 - Assinada às 14:00:50 - Previsão de Fechamento de Lote adiada   para 14:01:20

NF-e 004 - Assinada às 14:01:15 - Previsão de Fechamento de Lote adiada   para 14:01:45

NF-e 005 - Assinada às 14:01:40 - Previsão de Fechamento de Lote adiada   para 14:02:10

Veja que a cada NF-e que entra no GRC e é assinada, a previsão do Fechamento do Lote é adiada.

Em um cenário mais drástico (e muito parecido com o do meu cliente), podemos ter a situação abaixo. Considerando a configuração de Lote recomendada no documento citado acima teríamos:

Max Time (sec)	Max Size (B)	Max. NF-es
30	500.000	50

Se as emissões de NF-e seguirem o seguinte padrão:

- Intervalo médio entre a Emissão de cada NF-e: 25 segundos

- Tamanho Médio de cada NF-e: 10 KB

Considerando os parâmetros acima, o Lote somente seria fechado ao atingir o Tamanho Máximo (500KB) ou o Número Máximo de NF-e's (50).

Então demoraríamos aproximadamente 1200 segundos (20 minutos) para conseguir fechar um único Lote.

Durante as alterações da configuração, o cenário "ideal" encontrado foi enviar apenas 01 (uma) NF-e por Lote. O que não costuma ser recomendado.

Gostaria de saber que alternativas vocês tem utilizados em cenários parecidos com este, onde há a necessidade de emitir NF-e's rapidamente sem sobrecarregar o GRC/PI com muitos Lotes de NF-e.

Abraços a todos.

Pedro Baroni

[henrique_pinto · Accepted solution]

Pedro,

nao existe isso de lote adiado.

Ele fecha a partir do 1o trigger (nota mais antiga, como o Fernando falou).

Vc observou isso?? Lote fechando depois de 20 minutos da nota mais antiga, mesmo com configuração de 30 segundos?

[pedro_baroni3 · Accepted solution]

Pois é Henrique, eu pensava que fosse assim.

Mas acabei de simular uma situação e constatei o "adiamento" dos Lotes, veja:

Pela configuração, era para o Lote fechar a cada 60 segundos.

Entretanto, fui emitindo Notas a cada 30 segundos aproximadamente, e consegui adiar a criação do Lote, que ocorreu apenas 5 minutos (300 segundos) após a Assinatura da primeira Nota:

Lista de Notas:

Dados de Assinatura das Notas:

Dados do Lote:

Dados da Nota mais antiga:

Já constatamos que não é um problema do ProcessReports, pois ao criar apenas uma NF-e, o Lote é criado corretamente, 60 segundo após sua Assinatura.

Este teste foi realizado no SP15, entretanto já me avisaram de situações semelhantes no SP12 (não testei para constatar, mas recebi as informações de outro Consultor).

Eu sempre achei que era diferente, alguém saberia se isso mudou e/ou quando mudou.

Abraços.,

Pedro Baroni

[rhviana · Accepted solution]

Baroni,

Acabei removendo meu post que não sei encaixava muito bem com o que está rolando.

Na Natura como expliquei pelo grande volume, fizemos uma estatísica para definição desses parametrização, porém , pelo que vejo da sua discussão algo "preocupante" está aparecendo.

Realmente nessa última imagem é discrepante o tempo da assinatura para o incluido no lote, 5 min quase.

Abraço !!

[henrique_pinto · Accepted solution]

Sim isso com certeza mudou, parece um "bug" introduzido que ninguém percebeu antes.

, wtf?

[rhviana · Accepted solution]

rsrsrsrsrs !

  explicações meu caro !

[former_member182114 · Accepted solution]

Opa. Vou dar uma olhada nos códigos, pelo que você expôs a cada nova nota ele "reseta" a contagem... talvez um ORDER BY modificado pode causar isso.

1min

[former_member182114 · Accepted solution]

Bom dia Pedro,

Verifiquei aqui e o principal ponto de montagem de lote é o report /XNFE/COLLECT_BATCH e ele não sofre manutenção desde 2010.

Então estou supondo que possa ter algo com locks ou algum cenário não standard.

Poderia dar seguimento ao teste rodando após 1 minuto o /xnfe/collect_batch na mão, e se não coletar as duas notas então fazer o debug?

Aproveite para monitorar locks e outros reports que possam estar em andamento.

Fico no aguardo.

Atenciosamente, Fernando Da Rós

[former_member182114 · Accepted solution]

Bom dia Pedro,

Você comentou que o /xnfe/process_reports está ok.

Independente de erro, o que pode dar um comportamento parecido com este á muitos registros na tabela /xnfe/acknowledg e o check do /xnfe/get_acknowedgment rodando junto ao /xnfe/process_reports.

Monitore SM50, SM66 se à um processo rodando a muito tempo.

Atenciosamente, Fernando Da Rós

[pedro_baroni3 · Accepted solution]

Então Fernando,

Aqui foi feito Decouple do ProcessReports e do GetAcknowledgement. E como o JOB do /xnfe/get_acknowedgment roda a cada 1 minuto, a tabela /xnfe/acknowledg chega a acumular uma média de 60 registros, que são processados assim que o JOB é executado.

SM50 e SM66 normais, sem execuções com tempo alto.

Abs.,

Pedro Baroni

[rhviana · Accepted solution]

Henrique,

Mais só foi visto agora, provavelmente algum keyuser ou cliente que o Baroni está reclamou de lentidão...

Anyway vamos ver as próximas páginas, afinal I don´t have access yet.

Abrs

[pedro_baroni3 · Accepted solution]

Fernando,

Fiz o DEBUG e imagino ter encontrado o Vilão da história:

Na linha 1512 do Report /XNFE/COLLECT_BATCH, existe um SORT na tabela de Lote/NFes, ordenando a tabela por ordem Decrescente (maior para menor) de Data/Hora de Criação (Assinatura). Como a última Nota emitida (mais nova) possui a maior Data/Hora de Criação (Assinatura), ela fica em primeiro lugar na Tabela.

A partir da linha 1522 essa Data/Hora é utilizada para comparar com a Data/Hora Atual e verificar se o intervalo já foi atingido:

Neste momento já temos um problema, pois ao invés de ser verificada a Data/Hora da nota mais antiga, foi verificada a Data/Hora da Nota mais nova. E mais, como o tempo não foi atingido, ele executa um PERFORM na linha 1539 e apaga todos os registros (Notas), finalizando o LOOP sem montar um Lote:

Antes do PERFORM:

Depois do PERFORM:

Isso faz Sentido?

Abraços.

Pedro Baroni

[former_member182114 · Accepted solution]

Bom dia Pedro,

Sim, faz todo o sentido é o que esperava encontrar no primeiro momento... só que olhei um sistema SAP NFE 10.0 de consolidação que não mexem desde 2010.. rsss Desculpe.

Você realmente descobriu um problema e é para abrir chamado para correção.

Atenciosamente, Fernando Da Rós

[pedro_baroni3 · Accepted solution]

Entendi,

No momento estou em uma situação um tanto complicada para a abertura de Chamados.

Seria possível a abertura deste chamado diretamente por vocês?

Abraços.

Pedro Baroni

[former_member182114 · Accepted solution]

Bom dia Pedro,

Sem problemas. Já passei para o time de desenvolvimento, o chamado de cliente seria só para formalizar e acompanhar.

Obrigado pela depuração que fez, ultimamente não tenho tido tempo nem de dar uma passadinha por aqui 😞 Mas fico bem feliz em ver vários colegas mandando brasa nesse fórum.... aproveito para agradeçar aos demais também...

... voltando as sombras até não sei quando

Atenciosamente, Fernando Da Rós

[pedro_baroni3 · Accepted solution]

Muito Obrigado Fernando Ros, Henrique Pinto e Ricardo Viana.

Ficamos no aguardo da SAP Note.

Obrigado também ao Cláudio Shinohara (PI), que me demostrou a existência deste problema.

Abraços a todos!

Pedro Baroni

[henrique_pinto · Accepted solution]

É por essas e outras que eu pago pau pro SCN.

Collaboration FTW!

[pedro_baroni3 · Accepted solution]

Apenas acrescentando:

Esse não é um problema do Support Package 15.

Me avisaram que o problema ocorre também no SP12, e constatamos que é verdade (não sei quanto à SPs anteriores).

Abraços.

Pedro Baroni

[rhviana · Accepted solution]

Boa Baroni !!!

Sensacional !

Elite parabéns !!

[pedro_baroni3 · Accepted solution]

Fernando Ros, boa tarde.

Sei que deveria estar acompanhando isto via chamado, mas como lhe disso, está um tanto quanto complicado!

Você saberia informar se há alguma previsão para resolução deste problema?

Abçs.,

Pedro Baroni

[former_member182114 · Accepted solution]

SAP Note 1944852 "Respecting the oldest NF-e during batch creation" liberada.

Atenciosamente, Fernando Da Rós

[rhviana · Accepted solution]

Boa Fernando da Ros !

[pedro_baroni3 · Accepted solution]

Muito obrigado!

[former_member182114]

Bom dia Pedro,

O max time é contado a partir da nova mais velha, então nessa configuração ele estouraria bem antes do Size e NF-e. Observe que isto é em relação à filial emissora e não a um estabelecimento, no documento também cubro isso.

E quando disparado é jogado todos as NF-es possíveis dentro, então sua tabela fica:

NF-e 001 - Assinada às 14:00:00 - Previsão de Fechamento de Lote definida para 14:00:30

NF-e 002 - Assinada às 14:00:25 - <-- Esta vai esperar 5 segundos e entrar no lote da NF-e 001

NF-e 003 - Assinada às 14:00:50 - Previsão de Fechamento de Lote adiada   para 14:01:20

NF-e 004 - Assinada às 14:01:15 - <-- Esta vai esperar 5 segundos e entrar no lote da NF-e 003

NF-e 005 - Assinada às 14:01:40 - Previsão de Fechamento de Lote adiada   para 14:02:10

Entretanto, se esta é realmente a realidade da empresa pode não valer a pena esperar os 30 segundos daí reduziria este valor para 3 segundos (os outros parâmetros de tamanho/quantidade só devem ser modificados em caso de falha na Sefaz, fora isso mantenha no máximo possível).

Atenciosamente, Fernando Da Rós

[former_member182114]

Complementando... Por que nunca colocar o tamanho como disparador...

Imagina que o sistema ficou fora do ar por 1 hora, e quando retornar o sistema teria umas 100 notas.

Se a configuração for 1 NFe por Lote serão 100 Lotes <-- multiplica pelas 6 filas PI e você vê o gargalo...

Se a configuração estiver como você mostrou ele vai gerar apenas dois lotes.

Atenciosamente, Fernando Da Rós