Estorno em Massa

[ricardosantoro_scofano]

Boa noite pessoal!

Seguinte questão...

Estamos encontrando um problema para o estorno em massa de algumas faturas derivadas de "split" no faturamento.

Exemplo:

No faturamento da remessa X, ocorre o split em 3 faturas e, consequentemente em 3 notas fiscais. Na necessidade de estornar as 3 notas, quando isso é feito em massa (as 3 de uma vez), no retorno da aprovaçao dos cancelamentos do GRC para o ERP a função J_1B_NFE_XML_IN_TAB é executada com os 3 documentos e no momento da VF11, o primeiro estorno acontece normalmente mas impede o estorno das demais faturas pois a remessa X ainda está sendo atualizada quando o o estorno dos demais documentos é executado.

Como o erro que ocorre é no call transaction da VF11, as notas saem da tabela /XNFE/BACKSTATUS e o GRC não tenta atualizá-las novamente no ERP.

Provisoriamente, estamos forçando a atualização depois com o programa /XNFE/UPDATE_ERP_STATUS_DIAL no GRC, mas se houver uma alternativa mais "dinâmica" será bem-vinda.

Abçs,

[former_member182114 · Accepted solution]

Bom dia Ricardo,

Muito bem levantado o problema. Encontrei apenas a SAP Note 1451739 mas ele faz um tratamento na solicitação de cancelamento, ao invés de tratar no processamento do cancelamento. Essa nota tem um erro corrigido na SAP Note 1474277.

Sobre a causa raiz: Acredito que trata-se de uma falta de tratamento no cancelamento da Nota devido ao lock da remssa/billing document na tx VF11, neste caso a função deveria considerar este lock e não chamar ou então responder ao GRC como um lock (103 se não me engano) e não 109. Melhor abrir um chamado no XX-CSC-BR-NFE com estes detalhes que você passou.

Sobre o tratamento, não vejo como possível algo automático visto que tem um erro não tratado nos códigos do ERP, como sugestão você poderia usar ERP Update Status no monitor do GRC que também "limpa" o 109 se funcionou certinho.

Um report Z poderia ser feito para identificar este caso específico de 109, para cancelamento e jogar na backstatus por exemplo daí o /xnfe/update_erp_status cuida do resto, porém só faça isso em último caso se não o paliativo vira definitivo. Abra um chamado primeiro e insista na solução defintiva.

Atenciosamente, Fernando Da Ró

[ricardosantoro_scofano · Accepted solution]

Oi Fernando,

Obrigado pelas dicas. Estive analisando as notas que vc mencionou (ainda bem que já tem a nota 1474277) e como o cliente só entrará em PRD dia 01/07, vamos adotar a aplicação delas pois resolverá o problema já no momento da solicitação de cancelamento. Os pré-requisitos já estão aplicados por aqui, então creio que não teremos problemas.

Mais uma vez obrigado!

Att.