on 02-28-2013 7:47 PM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
User | Count |
---|---|
15 | |
4 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.