cancel
Showing results for 
Search instead for 
Did you mean: 

J_1BNFECHECKNUMBERRANGES com decouple - não gera lote

former_member550977
Participant
0 Kudos

Boa tarde,

Estou com um problema no processamento dos XMLs de inutilização de numerção gerados pelo programa J_1BNFECHECKNUMBERRANGES de uma de das divisões da empresa. Essa divisão é a única que utiliza o decouple (não sei se é coincidencia) e após o inicio do processamento pelo GRC o processo para antes da geração do lote.

A tabela /XNFE/NFE_HIST fica com apenas duas entradas "Recebido do sistema back end" e "Enviado ao serviço de assinatura digital".

Dentro do GRC procuro na tela onde são mostrados os erros no processo de assinatura digital e não aparece nada.

Também no SXI_MONITOR não aparece nenhum erro relacionado ao processo de inutilização de numeração.

Menciono a questão do decouple porque nas outras divisões onde o decouple não é utilizado, a geração e processamento dos XML de inutilização de números esta OK.

Agradeço se alguém tiver alguma ajuda a respeito.

Obrigado

Helio

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member182114
Active Contributor
0 Kudos

Bom dia Helio,

Verifique as filas na SMQ2.

É bem provável ter uma fila grande de SKIP request, isto aumenta o volume nas outras filas.

Outro ponto é que a tabela de acknowledgment pode estar com muitos registros.

Agora a lentidão.... O programa /xnfe/process_reports faz por default 3 coisas:

- verificar acknowledgments

- criar lotes (das notas assinadas)

- consultar lotes entregues

Se a tabela de acknowledgment estiver cheia então demora muito no ponto 1 e o sistema fica como não criando lotes.... (NOTAS COM EXTREMA DEMORA). Já vi casos de até 2 horas para uma NF-e...

O /xnfe/process_reports já tem a opção de não fazer verificação de acknowlegments (flag).

Se for isso mesmo então você tem duas opções:

a) escalonar de minuto em minuto os jobs /xnfe/collect_batch e /xnfe/batch_request

b) rescalonar o /xnfe/process_reports com o flag de não checar acknowledgments e escalonar um segundo job minuto a minuto do /xnfe/get_acknkowledgment

Atenciosamente, Fernando Da Rós

former_member550977
Participant
0 Kudos

Obrigado Fernando pela pronta resposta.

No caso não há uma lentidão, ele simplesmente não gera o lote para as entradas de inutilização de numeração de uma das divisões (justamente a que usa decouple)..

Verifiquei a SMQ2 e a fila tinha somente umas poucas entradas referentes às notas normais que estão em processamento.

A tabela /XNFE/ACKNOWLEDG também esta zerada (me lembro que quando iniciamos a utilização do GRC, há 4 anos atrás, tivemos esse problema, abri uma thread e voce me passou a instrução de que o normal dessa tabela é ficar zerada).

Quanto ao job /xnfe/process_reports o flag esta ativo, mas como a tabela esta zerada não estamos tendo problema.

At.

Helio

former_member182114
Active Contributor
0 Kudos

Bom dia Helio,

Desculpe, me confundi. Você citou que não gerava lotes. SKIP request não tem lote...

Se na /xnfe/nfe_hist você encontra o status 02 enviado ao serviço assinador e nada mais... Estaria por conta do PI (se SAP NFE 1.0, ou 10.0 com assinatura externa).

Se estiver com o SAP NFE 1.0, procure no PI onde esta mensagem foi parar (veja data/hora), ou voltou, ou está parado, cancelado, deletado....

Se for SAP NFE 10.0, por abra chamado em SLL-NFE.

Atenciosamente, Fernando Da Rós

former_member550977
Participant
0 Kudos

O nosso é 10.0, vou abrir chamado.

Obrigado Fernando