NFe 2.0: Mensagem "Atualização correspondente cancelada" na SM14 / SM58

[Former Member]

Olá amigos,

Estamos tentando reenviar uma NFe espefícica através do monitor J1BNFE.

Selecionamos a nota e vamos no menu NFe -> Enviar, e ao atualizar o monitor, é apresentada mensagem do SAPOffice (SBWP) "Documento Expresso "Atualização Cancelada" recebido do autor <usuário>".

Na SM14 e SM58 encontramos o seguinte log:

1	J_1B_NF_DOCUMENT_UPDATE	V1	Erro
2	J_1B_NFE_UPDATE_ACTIVE	V1	Inicializ.
3	ARFC_END_VB	RFC assíncrono	Inicializ.

Reparem que a FM J_1B_NF_DOCUMENT_UPDATE está com Erro no Código Retorno

Isso está acontecendo para um Docnum específico em Produção, as outras NFe's não apresentam problema.

Na J1BNFE a Nota permanece com Etapa do Processo = 3 e Status comunicação sistema = Não enviado.

A Nota não é enviada para a mensageria.

Vocês tem alguma idéia do que possa estar acontecendo??

Obrigada,

Daniela

[Former Member]

Olá Daniela.

Isso ocorre somente quando você envia? Ou ocorre também quando você clica no botão Set NF-e number?

Abraço

Eduardo Chagas

[Former Member]

Olá Eduardo,

Não temos esse procedimento aqui no cliente de utilizar o Set NF-e number.

O problema ocorre apenas pela opção de Envio mesmo.

Att,

Daniela

[former_member182114]

Bom dia Daniela,

Aconteceu algum problema, e este está descrito no texto do erro na SM14, verifique e poste aqui. Tem algumas notas relacionadas a esta gravação.

Sobre o Set NF-e Number que o Eduardo comentou, significa que você está sem o decouple. Cada erro deste provoca perda de numeração (gap) que deverá ser ajustado. Implemente ele pois independe de você estar utilizando uma mensageria não standard, é necessidade do ERP mesmo.

Atenciosamente, Fernando Da Ró

[Former Member]

Pessoal,

Conseguimos debugar a função J_1B_NF_DOCUMENT_UPDATE que é chamada em update task e descobrimos que ocorre erro no INSERT da tabela J1BNFLIN por consequencia de uma sujeira na tabela WK_ITEM gerada por um ponteiro com ASSIGN no metodo FILL_HEADER.

Agora estamos analizando a necessidade desse código, já que poderia ter sido feito na FILL_ITEM sem necessidade de uso de ponteiro e ASSIGN na WK_ITEM já que o metodo tem a estrutura da J1BNFLIN como parâmetro.

Eu darei um feedback para o fórum e fecharei a thread quando ajustarmos o código do metodo FILL_HEADER e comprovarmos que o problema era o ponteiro mesmo.

Obrigada a todos,

Daniela

[Former Member]

Pessoal,

Apenas para dar um feedback, o problema era um loop num ponteiro da WK_ITEM com INTO ao invés de ASSIGNING, que fazia com que conteúdo da tabela ficasse errado.

Ajustamos o código e o problema foi solucionado.

Att,

Daniela

[former_member182114]

Show de Bola Daniela,

Obrigado pelo feedback ao fórum.

Atenciosamente, Fernando Da Ró

[Former Member]

Daniela,

Estamos com o mesmo problema aqui na empresa, você poderia me passar o ponto que vocês alteraram, ou se foi aplicação de nota (e qual nota foi)?

Wellington Peres

[Former Member]

Olá Wellington,

O problema era código Z no método FILL_HEADER, não foi necessária a aplicação de OSS.

Você deve verificar o seguinte:

1) Nos métodos FILL_HEADER e FILL_ITEM se existe algum ponteiro (field symbol) para acessar área de memória;

2) Caso afirmativo, verifique se em algum ponto é dado um "LOOP" nesse ponteiro;

3) Caso afirmativo, o LOOP deve ser com ASSIGNING.

No meu caso estava sendo feito com INTO TABLE, e com isso o conteúdo da tabela da área de memória, nesse caso a WK_ITEM (com os itens da nota) duplicava um item, e mais na frente o standard usa essa tabela para inserir os dados, ocasionando erro de chave duplicada ao dar o INSERT na J_1BNFLIN.

Mas pode ser qualquer outra tabela que você esteja manipulando via ponteiro.

Espero que ajude,

Daniela