cancel
Showing results for 
Search instead for 
Did you mean: 

Não altera status NFe para 101 no monitor J1BNFE no processo Cancelamento!

Former Member
0 Kudos

Boa noite forum,

Fiz o seguinte processo:

Criei uma NFe no ERP, enviei ao Sefaz e recebi status 100, ate aqui tudo legal, tanto no monitor do GRC quanto na J1BNFE.

Ao tentar cancelar a NFe via J1BNFE, enviou ao SEFAZ retornou o status 101 no monitor do GRC, porem não atualizou status na J1BNE para 101 e ficou com engrenagem e com status antigo 100.

No GRC dentro da tabela /XNFE/BACKSTATUS a NF estava lá com campo error = X.

Bem, ao depurar o pgm /XNFE/UPDATE_ERP_STATUS notei que quando vai para o ERP tentar fazer o processo de cancelamento, ocorre um erro de batch-input na transação /MBST.

Alguem sabe o que ocorre? Estou procurando notas OSS, creio que seja o caminho.

Outra questão no Monitor /J1BNFE, deveria ficar com uma mensagem mais explicita, concordam, não consigo ver mensagem alguma apenas engrenagem com status antigo (100).

Obrigado,

Marco

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Boa noite Marco

Quando o monitor recebe a autorização para cancelar o SAP vai fazer o estorno da transação que gerou a Nota Fiscal. Se foi um faturamento , faz a VF11. Se foi writer faz a J1B3n cancelar, se foi um movimento de MM, faz a transação MBST que é a de estorno.

O que aconteceu foi algum erro na transacao standard MBST. Isso ja aconteceu em um cliente que fez um nota writer em um programa Z e atualizou o campo referencia doc origem com um movimento de mercadoria. Neste caso o SAP pensa que a nota foi gerada por MM e tenta fazer a MBST.

Peca para um abap colocar um stop na funcao J_1B_NFE_CANCEL e veja o que esta acontecendo.

Renata Hopp

Former Member
0 Kudos

Oi Renata,

Obrigado pela atenção, existe um problema de sequencia de tela no batch-input ao executar a /MBST, ao tentar estornar esse movimento de MM, estou verificando como solucionar e verificando se existe algum erro de processo, outro problema e que creio que o monitor /J1BNFE deveria ficar com alguma mensagem que desse alguma mensagem apontando para esse erro, porem, creio que uma melhor avaliação vou ter depois de analisar tudo, pode ser o caso de aplicação de alguma nota oss, vamos ver.

Obrigado,

Marco

henrique_pinto
Active Contributor
0 Kudos

Pode ser o idioma da RFC Destination também (do GRC q aponta pro ERP).

Se a configuracao do sistema só tiver feita p/ PT e a Dest estiver EN, pode dar problemas.

Abs,

Henrique.

Former Member
0 Kudos

Henrique,

Identificamos 2 problemas, 1 realmente ainda é de configuração, após um dar um "chapeu" no problema, aí sim sua dica caiu como uma luva, começei a ter problema de idioma por causa da RFC GRC_PARA_ECC, estava com EN e minha configuração no ECC apenas em PT, mudei para PT e começou a atualiar o monitor corretamente, creio que não tem maiores problemas em trabalhar com essa RFC com idioma PT, vê algum problema em ficar com PT apenas nessa RFC?

Abs

Marco

henrique_pinto
Active Contributor
0 Kudos

Marco,

nao há nenhum problema.

Em geral, o pessoal de Basis cria em EN por default por remontar aos antigos processos que usavam o usuario ALE_REMOTE (comunicacao remota de IDOCs). Como eram processos técnicos de Batch Input, nao necessitavam nenhuma configuracao especifica.

No caso de NFE, o usuario RFC vai simular um usuario real executando a funcao de cancelamento no retorno da aprovacao do cancelamento pela SEFAZ. Se for vendas, vai fazer Batch Input na VF11, se for transferencia, MBST ou VL09, etc. Por isso precisa ter as mesmas condicoes de configuracao de um usuario real, e o idioma é determinante neste fator.

Abs,

Henrique.

Former Member
0 Kudos

Obrigado Henrique,

Abs

Marco

Answers (1)

Answers (1)

former_member182114
Active Contributor
0 Kudos

Perfeito Renata, Marco o ponto de chamada para começar o debug é a função J_1BNFE_XML_IN_TAB (chamada pelo GRC) e os dados estão na /xnfe/backstatus no GRC. Na hora do call transaction mude o lv_mode para E (irá parar no ponto que acontece erro), se desejar pode mudar para A (visível):

OBSERVAÇÃO IMPORTANTE: Após voltar do call transaction reinicie o processo com /n, para que não atualize os status na ACTIVE sem ter terminado com sucesso o call transaction.

Quanto a solução, podem estar em:

- notas faltando, este processo de cancelamento veja estas: 1144194, 1165746, 1172677, 1247602, 1293944 e também 1160760, 1174923

- erro de negócio - pode realmente não ser possível cancelar esta nota ou já esteja cancelado

- erro de programa - em alguns casos o erro de negócio pode ser evitado por programação, avalie cada caso

Outra explicação: Antigamente o processo de cancelamento era feito na chave do usuário e toda mensagem de erro já dava no mesmo momento em que ele requisitava. Com NF-e acontece uma separação entre o pedido de cancelamento e o efetivo cancelamento pois deve-se aguardar autorização da Sefaz.

Sendo assim, deve-se verificar situações de negócio e colocar REGRAS de cancelamento na BADI CL_NFE_PRINT->CHECK_SUBSEQUENT_DOCUMENTS para evitar sair do R/3 um pedido de cancelamento que não poderá ser efetivado.

Atenciosamente, Fernando Da Ró