cancel
Showing results for 
Search instead for 
Did you mean: 

Definir Nro NF-e

Former Member
0 Kudos

Bom dia,

Tenho uma nota parada na j1bnfe sem o numero da NF-e, e quando clico em definir Nro da NFe, ele aparece no monitor, mas nao grava na tabela, se tento enviar ao GRC ela vai sem o Nro ou da erro por estar sem o numero, e se faco um refresh no monitor o numero da NFe desaparece.

O que pode ser?

Josue Neto

Accepted Solutions (0)

Answers (2)

Answers (2)

Renan_Correa
Active Contributor
0 Kudos

Oi,

Minha última sugestão: Você já tentou ativar o "update debugging" e debugar o update task para verificar o que está ocorrendo em background?

att,

Renan

Renan_Correa
Active Contributor
0 Kudos

Oi Josué,

Você pode verificar se quando você executa o passo para numerar a nota algum update termination aparece na transação SM13. Isto poderia indicar uma razão para este erro acontecer.

TAmbém pode se colocar um breakpoint na função J_1B_NFE_SET_NUMBER e debugar o programa para ver o que está ocorrendo. É interessante verificar se as funções J_1B_NF_DOCUMENT_UPDATE e J_1B_NFE_UPDATE_ACTIVE estão sendo chamadas e executadas corretamente. Algum erro ocorrido nessas duas funções poderia causar este tipo de incidente ( considerando que elas fazem o update das tabelas J_1bnfdoc e J_1bnfe_active com os dados da nota ).

Regards,

Renan Corrê

Former Member
0 Kudos

Ola Renan, obrigado pelo retorno, verifiquei na sm13 e nao ta parando nada la o engracado é que tambem nao esta gravando o numero da NFe, vi que as funcoes J_1B_NF_DOCUMENT_UPDATE e J_1B_NFE_UPDATE_ACTIVE estao sendo chamadas em update task, entao tirei o update task para poder debugar, e em modo normal gravou o nro normalmente... O que poderia ser entao? Porque em update task nao grava?

Regards,

Josue Neto

Former Member
0 Kudos

Olá Josue!

E, não aparece nenhuma msg de erro? Veja se existe algum tratamento na badi que possa estar abortando a operação.

Abraço

Eduardo Chagas

Former Member
0 Kudos

Ola Eduardo,

Pior que nao aparece nenhum erro, nem para nada na sm13, olhei a badi tambem e nao tem nada que poderia estar abortando o processo, o que achei curioso é que usando in update task nao grava, ja se chamar a funcao direto sem in update task funciona.

Abraco,

Josue Neto

former_member182114
Active Contributor
0 Kudos

Bom dia Josue,

Tem algumas coisas estranhas nas suas descrições.

Você disse que retirou o update task... Como ? modificou o standard ou rodou direto na SE37?

Este update fail normalmente deveria ser visível na SM13/SM14, será que chegou num COMMIT WORK?

Atenciosamente, Fernando Da Ró

Former Member
0 Kudos

Bom dia Fernando,

Entao, eu modifiquei o standard comentando " IN UPDATE TASK, entao executei debugando, desta forma não tem nenhum problema, e ele grava o nro da NFe, quando volto ao normal (IN UPDATE TASK) ele nao grava. Concordo que deveria gerar um update error, porem debugando com o UPDATE TASK o debug passa direto e nao debuga a funcao, e o pior é que dá sysubrc 0 nao retorna erro nenhum mas nao grava, eu nao estou conseguindo debugar o update.

Abraco,

Josue Neto

former_member182114
Active Contributor
0 Kudos

Bom dia Josue,

Evite a todo custo modificar o standard, principalmente se é apenas para teste.

Em debug, quando você passa por um CALL ... IN UPDATE TASK ele não é executado naquele momento, ele entra na fila update task que apenas após o COMMIT WORK serão iniciadas todas as funções que foram chamadas IN UPDATE TASK no contexto de sua sessão/transação.

Para debugar o canal update task você deve encontrar no momento do debug, selecionar a opção Settings -> Change Debugger Profile/Settings e marcar Update Debugging.

Como não está gerando erro, é provável que algum código esteja "parando" a execução antes de realizar o commit work...

Atenciosamente, Fernando Da Ró

Former Member
0 Kudos

Bom dia Fernando, obrigado pelo apoio, eu realmente evito fazer este tipo de coisa, so fiz desta vez pois estava realmente me intrigando, entendo o que vc disse sobre fila das update tasks, ontem verifiquei a quantidade de wp de update, e fiquei espantando, pois vi que tinha apenas 1 wp de update, para atender 100 wp de dialogo e mais uns 20 de Background, acredito que seja este uma parte do problema, pois ocorre que no momento da criacao da nota, é enviada uma nota sem nro de nfe ao GRC e depois e enviada a mesma nota (mesmo docnum) com numero de nfe, acredito que devido ao fato de todos processos que utilizam update task ter somente 1 wp para isso, ja solicitei ao cliente uma janela para fazer um stop/start do ambiente aumentanto esses wp de update, acredito que uma parte do problema se resolvera, fiz esse aumento de wp de update no homologacao, porem ele ainda nao grava o nro da nfe.

Att,

Josue Neto

former_member182114
Active Contributor
0 Kudos

Bom dia João Alberto,

Esta numeração / transmissão está sendo feita pelo monitor J1BNFE ou pelo decouple job J_BNFECALLRFC?

Para o programa J_BNFECALLRFC a "muito tempo atrás" o código numerava, fazia um COMMIT WORK e enviava.... em sistemas com delay de update tasks podia acontecer da nota ser enviada sem estar numerada. Atualmente o programa conta com um COMMIT WORK AND WAIT após a numeração, para que só seja enviado se está efetivamente salvo e comitado no database.

Sugiro procurar por todas as notas deste programa e aplicar.

A propósito, cole aqui o conteúdo do box HISTORY (campos importantes: DOCSTA,MSSSTA,SCSSTA,CALLRFC, NUMNFE,DATA, HORA,USER)

Atenciosamente, Fernando Da Ró

Former Member
0 Kudos

Boa noite senhores, demorou um pouco mas acredito que o problema foi solucionado. Acredito que seja um erro no codigo standard da funcao J_1B_NFE_SET_NUMBER, pois verifiquei este codigo em um cliente que nao tem nfe implementada, e o codigo esta igual, trata-se do comando COMMIT WORK AND WAIT que esta dentro do CASE lv_callrfc. apos o WHEN ele eh 1 ou 3, enquanto deveria estar fora deste case, para no caso do lv_callrfc estar em branco, ele fazer o commit work.

Obrigado a todos pela ajuda.

Josue Neto

Edited by: Joao Alberto Vreeswijk on Feb 8, 2012 3:05 AM

former_member182114
Active Contributor
0 Kudos

Boa noite senhores, demorou um pouco mas acredito que o problema foi solucionado.

- dê detalhes de como ele foi solucionado

Acredito que seja um erro no codigo standard da funcao J_1B_NFE_SET_NUMBER, pois verifiquei este codigo em um cliente que nao tem nfe implementada, e o codigo esta igual, trata-se do comando COMMIT WORK AND WAIT que esta dentro do CASE lv_callrfc. apos o WHEN ele eh 1 ou 3, enquanto deveria estar fora deste case, para no caso do lv_callrfc estar em branco, ele fazer o commit work.

- vocês estavam ou não com decouple?

- não seria um erro mas é justamente o comportamento que pode acontecer caso não se tenha o decouple devidamente configurado (preferenciamente para o modo 3), antes quando callrfc=vazio o commit nem poderia ser disparado pois não era apenas a numeração mas todo o processo de criação/gravação da nota que estava em andamento... com o decouple isto foi dividido:

1) grava-se 100%

2) numera-se e transmite

Atenciosamente, Fernando Da Ró

Former Member
0 Kudos

Boa Noite Fernando,

Desculpe a demora em responder, entao, a maneira como foi solucionado foi esta que mencionei na msg anterior, movendo o commit work que existia imediatamente apos o codigo da funcao J_1B_NFE_SET_NUMBER:

CASE lv_callrfc. "1300000

*

  • numbering and RFC call

  • C_1 from Monitor

  • C_3 from batch Report

  • DB update must be completeted before RFC is called

WHEN c_1 OR c_3.

para antes do CASE lv_callrfc, pois percebi que apos este commit work, no final do case havia outro commit work, sendo que o meu problema era justamente quando eu clicava no botao definir nro da nfe, ele aparecia no monitor mas se eu executasse um refresh, ele desaparecia, ou seja pelo jeito faltava um commit work.

Abs,

Josue Neto