Falta de atualização no ECC

[Former Member]

Bom dia pessoal,

Estou tendo um problema com NFe, e após muito DEBUG não consegui identificar o problema.

O que está acontecendo é o seguinte: Ao tentar cancelar uma nota, o sistema ECC dispara a request para o GRC/SEFAZ e consegue a autorização para cancelar a nota.

Quando o GRC vai retornar essa informação para o ECC, no ECC só ocorre a atualização da tabela j_1bnfe_active e a tabela j_1bnfdoc não atualiza. Sendo assim a nota só fica cancelada no monitor, mas na transação de nota fiscal o mesmo está com o flag vazio. O interessante que para notas manuais o processo ocorre normalmente.

Desde já meu muito obrigado a todos.

Att,

Zoreck

[former_member182114 · Accepted solution]

Bom dia Zoreck,

Ao receber do GRC a autorização para cancelar na função J_1B_NFE_XML_IN_TAB, o ERP irá proceder além de atualização de status de NF-e os cancelamentos que é comandado pela função J_1B_NFE_CANCEL, dependendo do processo ele irá chamar a transação correspondente (ex.: writer, VF11, MR8M, VL09, MBST), devido aos diferentes cenários o resultado pode ser diferente.

De qualquer forma para o cenário do problema não deveria fazer pela metade.

Sugiro que você coloque um break point no início da função J_1B_NFE_CANCEL, e comece o debug a partir da J_1B_NFE_XML_IN e observe como é tratada a questão no cancelamento.

Como o ECC tem que estar "em posição" de receber e processar, sugiro iniciar o debug imediatamente após pedir o cancelamento ao GRC.

Sobre muito debug, poste também o que você já encontrou.

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Olá Fernando,

Inicialmente desculpe, faltou informar que tentei gerar o cancelamento pelo monitor do ECC.

Então, o que consegui descobrir precariamente pelo debug (ainda não consegui autorização para debug RFC) foi que o pedido a SEFAZ foi disparado pelo ECC com a função J_1B_NFE_SEND_REQUESTS. Dentro dessa função ele faz as chamadas da BADi, identifica a operação que você está fazendo, e no final dispara a função /XNFE/NFE_CANCEL.

Nesse ponto, como não conseguia seguir com o debug peguei os dados de chamada e preenchi a função no GRC, e executei a mesma. Lá constatei que ela dispara a chamada para a SEFAZ e a mesma autoriza o cancelamento. Quando o GRC vai mandar a info para o ECC, ele utiliza a função J_1B_NFE_SET_STATUS_IN_BACKEND. Meu problema nesse ponto, é que a parte do código que permitiria executar a função sem ser em background task está comentada.

Dai me lembrei do report no GRC que atualiza o ECC. Executei o mesmo, e consegui debugar a chamada da função J_1B_NFE_SET_STATUS_IN_BACKEND na rfc. Fui debugando e verifiquei que as atualizações da ACTIVE ocorrem dentro da função J_1B_NFE_UPDATE_ACTIVE. Lá dentro tambem existe uma atualização da DOC, mas a estrutura DOC está comentada na entrada, e a idéia não é atualizar só a DOC, mas tambem gerar os estornos de processo.

Sei que o outro ABAP aqui no projeto andou aplicando várias notas referentes a NFe, mas não sei precisar se falta alguma nota, ou sobra alguma, pois foi a primeira vez que me deparei com um erro assim. O SP aqui é o 17.

Att,

Zoreck

[former_member182114 · Accepted solution]

Bom dia Zoreck,

Este debug deve ser feito no retorno da informação, como você mesmo descobriu.

A informação chega pela J_1BNFE_XML_IN_TAB e esta que é importante para você debugar.

Observação: Demora um pouco a se familiarizar com estas funções, depois que você pegar o jeito só de olhar pros status você já vai entender o que está acontecendo.

Boa Sorte.

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Fernando,

Sabe com que nota e/ou em que SP veio essa função?

Aqui no cliente ela não existe.

Att,

Zoreck

[henrique_pinto · Accepted solution]

Faltou um underline:

J_1B_NFE_XML_IN_TAB.

Abs,

Henrique.

[Former Member · Accepted solution]

Fernando,

Me desculpe. Encontrei a função.

Vou debuga-la e ver o que ocorre.

Att,

Zoreck

[Former Member · Accepted solution]

Olá,

Debuguei novamente, e conseguir colocar um ponto de parada externo após conseguir a permissão para utilizar o usuário remoto.

Verifiquei que o erro ocorre mesmo dentro da função J_1B_NFE_UPDATE_ACTIVE.

Creio eu que o problema ocorra na parte responsável pela atualização da J_1BNFDOC, já que as outras duas tabelas atualizam sem problemas, mas não consigo confirmar essa informação, pois não consegui com nenhum break depurar a função em update task.

Alguem sabe me dizer se o sistema diferenciaria o update por causa do processo? Ou se faltaria alguma role para os processos automáticos?

Att,

Zoreck

[Former Member · Accepted solution]

Oi

Sim, diferencia e muitas vezes é problema de acesso. O usuário da interface precisa ter acesso no centro, para o movimento usado, etc.

Abraço

Eduardo

[former_member182114 · Accepted solution]

Bom dia Zoreck,

Esta thread está tomando dois caminhos... Um o apoio ao debug que acho estamos evoluindo, e outro quanto ao problema de atualização em si... então vamos tratar diferentemente.

Quanto ao debug, quando você deve ativar o debug de update task quando estiver debugando, daí no COMMIT WORK (ao final da J_1BNFE_XML_IN) será aberta outra sessão para este debug específico.

Obs.: Este erro de cancelamento normalmente não é na J_1B_NFE_UPDATE_ACTIVE, como ela é para update task não faz muita coisa, normalmente o problema está na preparação para ela. As mensagens de erro podem ajudar.

Quanto ao cancelamento, vamos esclarecer alguns pontos:

- Para se cancelar uma NF-e o usuário pede na J1BNFE o cancelamento, e vai ao GRC. Quando autorizado volta ao ERP através desta função e o usuário do serviço (SM59 GRC --> ERP) deverá ter os direitos de cancelamento de todas aquelas transações

- Além disso esta RFC tem que estar chamando no idioma em que os usuários normalmente fazem login, pois existem customizing específico por idioma (language dependent) que pode estar ausente no idioma da RFC (é um hábito dos Basis fazer sempre as interfaces em inglês, mas neste caso deve-se logar no idioma da empresa, normalmente PT).

- Não ficou claro que mensagem de erro você está enfrentando, existe algum log na J1BNFE? Você encontrou o erro de cancelamento na SM13/SM14 referente ao processo? poderia nos dar mais detalhes? Dê tudo que tiver de mensagens de erro no GRC e no ERP.

Próximos passos:

- verifique o idioma na RFC de retorno

- verifique o usuário de serviço no ERP se tem direitos suficientes para o cancelamento

- nos poste os resultados e as mensagens de erro

- nos dê também alguma informação sobre o processo? É SD/MM ? Acontece pra todos?

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Olá Fernando,

Encontrei uma coisa muito importante. Resolvi debugar a função J_1B_NFE_CANCEL que é chamada dentro de uma das várias funções do retorno, e mesmo a função me retornando sy-subrc = 0 e a VF11 (chamada via call) dentro dessa mesma função tambem me retornando sucesso, a mesma não criou o estorno. Pedi para a funcional verificar as roles dessa transção estão contidas no usuário.

Uma outra coisa que reparei, foi que a J_1B_NFE_UPDATE_ACTIVE não faz o update desse processo, e portanto o sy-subrc = 1 na saíde dela não seja o problema do meu processo.

Quanto as mensagens de erro, eu não tomo nenhuma mensagem, pois como falei, ele atualiza tudo com sucesso, e somente não faz o estorno do ECC, e tambem com isso não retorna nada.

Não havia me atentado ao fato da autorização na VF11, pois o funcional alegou que no cenário de contigencia, ele havia conseguido cancelar o faturamento.

Att,

Zoreck

[former_member182114 · Accepted solution]

Bom dia Zoreck,

Show de bola, outra dica (quanto ao debug), na hora de chamar a tx VF11, tem um parm que é lv_mode normalmente = P (pelo que me lembro agora), mudando este valor para A toda a execução dar-se-á visível (então você pode acompanhar 100% da execução e verificar caso aconteça algum warning que não é erro de fato).

Observação para o fórum: Estes debugs são complicados mesmo, caso a VF11 termine cancelando, então não se deve parar o debug... deve-se dar um F8 para ir até o final e ficar íntegro.... Se por ventura via debug na VF11 (ou qq outra), foi feito por debug deve-se PARAR o debug logo após a verificação da VF11. Motivo: O código após o retorno da VF11 irá entender que a transação terminou com "sucesso", e atualizará os status somente de NF-e.

Atenciosamente, Fernando Da Rós

-

-

---

No retorno da VF11, o sy-subrc pode até ser zero, mas verifique o conteúdo da tabela interna itab, talvez você encontre algo que o standard não trate.

Edited by: Fernando Ros on Jul 4, 2010 2:04 PM

[Former Member · Accepted solution]

Fernando,

Inicialmente, somente para lembrar, que como a função é chamada em background, se vc mudar o call para visivel, o debug dá erro, pois partiu de uma função background.

Uma coisa que acabei descobrindo, é que mais pessoas sofreram esse erro, então já fico mais calmo que não é só aqui.

Acho que descobri o que acontece, mas não consegui simular a situação devido a forma como o código está no standard. Só consegui simular via SHDB com sucesso.

Algumas transações standard não funcionam corretamente quando são chamadas via call transaction, necessitando que sejam passados alguns parâmetros no options do call transaction para que as mesmas funcionem. Creio que é isso que esteja acontecendo nesse caso, pois quando é executada a VF11 via shdb ou pelo programa a mesma retorna como sucesso mas não gera o estorno e na mão após o processamento normal, a transação executa os estornos.

O que acredito estar acontecendo é algum commit estar dando erro pela chamada via SHDB ou algum lugar diferenciar a chamada via bacth, e para isso teria de ser passado o parametro de batch e o de commit como 'X' na hora do call. Testei via SHDB preenchendo esses valores e funcionou. Vou ter de abrir chamado na SAP para alterar isso do SHDB.

Att,

Zoreck

Edited by: Fernando Zoreck on Jul 5, 2010 6:12 PM

[former_member182114 · Accepted solution]

Bom dia Zoreck,

Realmente existem transações que funcionam de forma diferente, mas a VF11 não "costuma" ter esse comportamento que você descreve, pode ser alguma nota ausente ou até EXIT / BAdI no ambiente que faça o tratamento.

Como você já adiantou bem a coisa, sugiro você abrir um chamado para XX-CSC-BR-NFE sobre o problema original de não conseguir o cancelamento. E anexe um .DOC com toda sua investigação, inclusive o SHDB daí o pessoal do desenv pode seguir nesta linha de investigação.

Observação: Esta função não é chamada em background. É chamado pela RFC em modo DIALOGO, porém não visível... mas é diferente de background. Ao mudar o lv_mode para A o torna 100% visível, outra opção é mudar para E que é "visível se acontecer erro".

Atenciosamente, Fernando Da Rós

Ahhh, E PARABÉNS pelo esforço, como deve ter percebido, não é algo trivial..rsss

Edited by: Fernando Ros on Jul 5, 2010 7:01 PM

[Former Member · Accepted solution]

Vlw Fernadno e sim, com certeza não é algo trivial... rs

Só comentei da chamada em Background porque tentei chamar nos dois modos de depuração citado e o mesmo me retornou o erro alegando que era por estar em background. Como o GRC dispara em background, achei que o ECC assumisse tal função a partir disso.

Somente como paleativo, e para dar continuidade nos testes no DEV, criei um ENHANCEMENT POINT dentro do form da chamada da VF11, após execução da mesma, e re-executei a VF11 com os parâmetros que falei, e com um popup que aparece quando ativo essas opções. Por enquanto isso serve para dar continuidade nos testes.

Muito obrigado pelo apoio Fernando.

Abs,

Zoreck

[former_member182114 · Accepted solution]

Show de Bola.

Crie o mais rápido possível o chamado, se vc tem um enhancement que corrige é provável que ou falte nota, algo falta no standard ou é um cenário novo não previsto que o standard também não trate.

De qualquer forma o enhancement deve ser apenas temporário.

Abraços, Fernando Da Rós

Edited by: Fernando Ros on Jul 5, 2010 8:10 PM

[Former Member · Accepted solution]

Fernando, bom dia!

Por favor, qual foi a OSS notes utilizada para correção?

Estou exatamente com a mesma situação, ou seja, todos os cancelamentos por evento não estão gerando as atualizações na

J_1BNFDOC , apenas a J_1BNFE_ACTIVE .

Grato,

Rodrigo Alves

[former_member182114 · Accepted solution]

Bom dia Rodrigo,

Por favor crie uma nova thread demonstrando como está a situação ("fotos" são legais) e o que já fez para resolver.

Esta thread é de 2010 e está respondida.

Atenciosamente, Fernando Da Rós

[Former Member · Accepted solution]

Fernando!

A SAP respondeu o chamado e gostaria apenas de compartilhar o que foi mencionado na solução:

Regarding your issue, please check the bellow notes that are relevant to the error you are facing:

1779240 Cancel billing document connected to nota fiscal electrônica

1809523 NF-e Monitor: Cancel Source Document not possible

1810694 NF-e: Cancellation Synchr. fails after Validation Error

1776965 Cancel prior to author. impossible for batch author. request

1767815 NF-e: Auth. to Cancel manually created NF-e in C.P.A. fails

In case the issue persists, please check your badi implementation CL_NFE_PRINT, if there is no lock being done twice inside, this is a common issue and leads to the error you are facing.

Muito obrigado!

Rodrigo Alves