Rejeicao: Assinatura difere do calculado

[bnobre]

Olá a todos,

Sou do RJ, desde ontem as 15:00 em um cliente estou com um NFC-e em contingência preso, ao tentar enviar ele retorna "Rejeicao: Assinatura difere do calculado". Após emitir tal nota, de ontem para hoje ele só emitiu mais 2 notas em contingência e todas apresentaram o mesmo defeito e não consigo enviar.

Os envios em modo normal estão perfeitos. Não existe nenhum caracter especial nas notas. Estou perdendo o prazo de 24 horas da primeira e daqui a pouco vou perder das outras, o que poderia ser?

[bnobre]

Olá a todos, descobri o que ocorre...

Eu meu aplicativo no ato da venda, conforme o usuário vai inserindo os itens, o software vai adicionando a numeração referente ao número do item... Por exemplo:

• 1 - Produto 1
• 2 - Produto 2
• 3 - Produto 3

Durante a venda, ele pode excluir um dos itens, e a numeração fica "pulada", como no exemplo abaixo onde ele exclui o item 2:

• 1 - Produto 1
• 3 - Produto 3

Eu sempe usei essa numeração "pulada" na tag <det nItem="X"> de cada produto e até ontem nunca tive problema. Observando agora os XMLs do dia 17-11-15 para trás, observei que as notas emitidas ONLINE gravam no XML a numeração do item pulada mesmo (conforme eu programei) e sempre passaram normal. Mas eu tive uma surpresa ao observar os XMLs de notas emitidas OFFLINE, vi que a numeração dos itens não pulou mesmo eu programando para pular (creio que o componente fez isso automaticamente ao ver que era emissão OFFLINE) e também nunca tive problema.

No dia 18-11-15 atualizei o componente e meu aplicativo. Após isso que comecei a receber o tal erro "Rejeicao: Assinatura difere do calculado" em algumas notas emitidas OFFLINE apenas. Como não vi nenhuma outra anormalidade além da numeração do item "pulada", resolvi testar "sem pular" pois agora observei que no caso da CONTINGÊNCIA ele parou de ignorar minha programação e "pulou". Ao seguir a sequência corretamente o problema foi sanado. Mas as notas emitidas ONLINE, que sempre pularam, não estão apresentando erro nenhum até o momento.

Depois de toda essa análise, me surgiram as seguintes dúvidas:

1º - O componente realmente gera o erro "Rejeicao: Assinatura difere do calculado" em emissão OFFLINE quando a sequencia da numeração dos itens é "pulada"?

2º - Se sim para a pergunta anterior, porque em emissão ONLINE não ocorre tal problema?

3º - Porque antes o componente sequenciava a numeração (ignorando a minha programação) apenas nas emissões OFFLINE e agora não mais o faz?

Desde já agradeço a atenção

[Régys Silveira]

Este erro em particular só ocorre quando você altera o XML após a geração. O ACBr não renumera ou troca informações passadas ao componente. 

[bnobre]

1 hora atrás, Régys Silveira disse:

Este erro em particular só ocorre quando você altera o XML após a geração. O ACBr não renumera ou troca informações passadas ao componente. 

Entendo Regys, mas pode ter certeza quanto as afirmações que fiz acima... Eu testei e retestei isso o dia todo... Só não sei exatamente qual revision estava usando anteriormente no momento em que o componente ignorava a minha programação ao gerar o XML OFFLINE.

E atualmente está como eu falei, se gerar o XML OFFLINE e apenas nesse caso, pulando a numeração, o componente assina errado, gerando o erro Rejeicao: "Assinatura difere do calculado". Seguiu a sequência, assina certo. Pode testar ai.

[Régys Silveira]

Vamos ao código que é responsável por gerar o nItem no XML:

procedure TNFeW.GerarDet;
var
  i: Integer;
begin
  for i := 0 to nfe.Det.Count - 1 do
  begin
    Gerador.wGrupo('det nItem="' + IntToStr(nfe.Det[i].Prod.nItem) + '"', 'H01');
    Gerador.gtCampo('nItem', IntToStr(nfe.Det[i].Prod.nItem));
    (**)GerarDetProd(i);
    (**)GerarDetImposto(i);

    if nfe.Det[i].pDevol > 0 then
      (**)GerarDetDevol(i);

    Gerador.IDNivel := 'H01';
    Gerador.wCampo(tcStr, 'V01', 'infAdProd', 01, 500, 0, nfe.Det[i].infAdProd, DSC_INFADPROD);
    Gerador.wGrupo('/det');
  end;
  if nfe.Det.Count > 990 then
    Gerador.wAlerta('H02', 'nItem', DSC_NITEM, ERR_MSG_MAIOR_MAXIMO + '990');
end;

Veja que em momento algum o nItem é alterado e não existe distinção nenhum entre on-line ou off-line, mas somente lido.

Como eu disse antes, algo ai está alterando isso, e é provavelmente a causa da divergência na assinatura.

O XML enviado Off-Line não deve ser alterado, você deve apenas lê-lo utilizando o ACBrNFe1.NotasFiscais.LoadFromFile, ACBrNFe1.NotasFiscais.LoadFromString ou ACBrNFe1.NotasFiscais.LoadFromStream, todos estes métodos utilizarão o mesmo método "LerXML" que simplesmente abre o XML lido e copia as informações, isso pode ser visto nos fontes de forma totalmente transparente.

[bnobre]

Entendi Régys...

Eu faço exatamente isso, só leio o XML (que fica gravado em minha base) pelo  ACBrNFe1.NotasFiscais.LoadFromString.

O "interessante" disso tudo é que como falei, se eu gerar sem pular o nItem ele assina normal, passa normal no Validar Assinatura do projeto de exemplo do ACBR. Mas se eu, com o mesmo código, pular o item, aí já era, ele dá erro na assinatura, testado no Validar Assinatura.

Enfatizando, só em emissões OFFLINE, ONLINE tanto faz pular ou não.

A única coisa que mudei no meu código foi isso, ao invés de:

• Prod.nItem     :=  dtm_banco.z_produtos_itensitem.AsInteger; //podendo pegar um valor "pulado"

Agora faço

• Prod.nItem     := x; // Número sequencial, para cada item deve ser incrementado

Só isso bastou para parar de dar erro.

[Régys Silveira]

Correto, eu vou tentar simular baseado no seu relato e verificar se alguma coisa pode estar meio torta no código.

[bnobre]

Agradeço Régys