Ir para conteúdo
  • Cadastre-se

dev botao

  • Este tópico foi criado há 3323 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

  • Membros Pro
Postado

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?

  • Membros Pro
Postado

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

  • Membros Pro
Postado
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.

  • Moderadores
Postado

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.

Equipe ACBr

Régys Borges da Silveira

http://www.regys.com.br

certificacao delphicertificacao delphi
  • Membros Pro
Postado

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.

×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...