Erro de validação: campo Chave de acesso de 44 caracteres

[Former Member]

Caros, bom dia!

Entramos na versão 2.0 em 01.11

Ocorre que em alguns casos de entrada (devolução de nota de saída) o R/3 está se perdendo, e gerando a nota no formato da versão 1.10. Quando isso vai para o GRC acusa "Erro de validação: campo Chave de acesso de 44 caracteres", pois no GRC a recepção é feita na versão 2.0

Pior que isso, a nota de entrada gerada na versão 1,10 está vindo com a númeração da nota de saída referenciada, isto é, não está respeitando nosso range de numeração sequencial.

Isso só ocorre as vezes, sempre em nota referenciada de entrada, e não estamos visualizando se pode estar faltando alguma parametrização, ou se é bug mesmo, pelo fato de ocorrer esporadicamente. Para corrigir estas notas, temos que fazer a "manobra" de renumerar, para então conseguir enviar na versão/numeração correta.

Alguma idéia sobre onde está o problema? Estamos utilizando Decouple (RFC Call = 3), pode ser ausencia de aplicação de nota em algo relacionado a isso?

Obrigada

Fernanda

[Former Member]

Olá Fernanda

Você está gerando/emitindo uma nota fiscal de entrada de MM ou SD? Você consegue simular o problema no ambiente de homologação?

Abraço

Eduardo Chagas

[Former Member]

Olá Eduardo,

A nota está sendo gerada através de SD, e já fizemos um processo identico em homolagação, e o erro não ocorre.

Como lhe falei, é um problema esporádico... temos outras 20 filiais rodando com a mesma configuração, e desde o go-live tivemos 4 casos como este.

Obrigada,

Fernanda

[Former Member]

Fernanda,

Onde que você viu que a nota foi gerada com na versão 1.1? Quando você visualiza na J1B3N?

Abraço

Eduardo Chagas

[Former Member]

Exato, na J1B3N campo Versão XML.

[Former Member]

Caros,

Descobri a "arte" que o usuário estava fazendo....

Como comentei, estamos usando o Decouple e o job somente coleta as notas de 1 em 1 minuto. O usuário confundiu a nota de entrada emissão própria, com uma nota de entrada terceiros onde é necessário informar os dados de Log, N. Aleatório e agora na versão 2.0 a VERSÃO DO XML.

Então, enquanto o Decouple não passou para numerar a nota, o usuário entrou na J1B2N e informou incorretamente os dados da nota referenciada, inclusive número, e gravou. Quando o Decouple tentou enviar a nota para o GRC, o erro ocorreu...

Agora, pergunto: o R/3 não deveria travar o acesso à J1B2N enquanto o Decouple não faz a numeração da nota através do job?

Obrigada,

Fernanda

[Former Member]

Oi

Entendo que você deve mexer no controle de tela para bloquear alterações nos campos.

Para isso, faça manutenção via SM30 nas tabelas abaixo...

J_1BAMV

J_1BALV

Abraço

Eduardo Chagas

Edited by: Eduardo Chagas on Nov 17, 2010 7:18 PM

[former_member182114]

Bom dia Fernanda,

Agora, pergunto: o R/3 não deveria travar o acesso à J1B2N enquanto o Decouple não faz a numeração da nota através do job?

Interessante "descoberta", por favor abra um chamado para XX-CSC-BR-NFE para avaliação.

No meu ponto de vista também imagino que deveria ser evitada a edição neste caso em que o status é "esperando o decouple passar"... Pelo menos para CALLRFC=3

Atenciosamente, Fernando Da Ró

[Former Member]

Fernando, chamado aberto!

Eduardo, não podemos bloquear os campos pois nos casos de entrada com nota de terceiros (ex: devolução compra do cliente) as informações da NF-e (N. aleatorio, Protocolo, Versão...) precisam ser inseridas manualmente na J1B2N.

Obrigada,

Fernanda Gruer