Jump to content

Embarcadero Conference 2019

22/10 - Visite o Stand do ACBr
Saiba mais

Nova Loja Oficial
loja.projetoacbr.com.br
Ajude o projeto a crescer, com estilo

Comprar

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

tdpsistemas

ANSWERED Emissão de NFe com Certificado na Nuvem RemoteID

Recommended Posts

Boa tarde.

Um cliente nosso adquiriu um certificado A3 da Certisign na nuvem chamado RemoteID (https://www.certisign.com.br/certificado-digital/remoteid). Configuramos no sistema, ele consegue validar a NFe, porém ao transmitir ele retorna o seguinte erro: Rejeição: Assinatura difere do calculado. Cstat: 297

Em conversa com o suporte da Certisign, ele nos informaram que ele trabalha igual ao A3. Teoricamente era para funcionar normal no sistema com o Acbr.

Alguém já passou por isso? Alguma dica?

Obrigado.


Atenciosamente,

 

 Assinatura.png

Share this post


Link to post
Share on other sites

Forneça para gente o XML da NF-e se possível. Esse erro pode ser ocasionado por espaço no início e ou fim de informações do XML, como por exemplo, espaço na razão social do cliente, ou na descrição do produto.

  • Like 1

Share this post


Link to post
Share on other sites

Bom dia.

Seu problema foi resolvido com o post do Breno?

Att.


Consultora SAC ACBr

Juliana Tamizou
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil

Share this post


Link to post
Share on other sites
Em 22/01/2019 at 16:52, tdpsistemas disse:

Boa tarde.

Um cliente nosso adquiriu um certificado A3 da Certisign na nuvem chamado RemoteID (https://www.certisign.com.br/certificado-digital/remoteid). Configuramos no sistema, ele consegue validar a NFe, porém ao transmitir ele retorna o seguinte erro: Rejeição: Assinatura difere do calculado. Cstat: 297

Em conversa com o suporte da Certisign, ele nos informaram que ele trabalha igual ao A3. Teoricamente era para funcionar normal no sistema com o Acbr.

Alguém já passou por isso? Alguma dica?

Obrigado.

Olá... estou com mesmo problema. Já verifique e removi tudo que poderia ocasionar o mesmo cstat.

Anexo todos os logs...

3-env-lot.xml

3-rec.xml

351005282376018-ped-rec.xml

351005282376018-pro-rec.xml

Share this post


Link to post
Share on other sites
2 horas atrás, Marcelo Calvi Belanga disse:

Olá... estou com mesmo problema. Já verifique e removi tudo que poderia ocasionar o mesmo cstat.

Também está usando o certificado digital "RemoteID"?

2 horas atrás, Marcelo Calvi Belanga disse:

O campo SignatureValue do XML está realmente estranho, com uma sequência gigante de "AAAAAAA...", estranho que removendo essa sequência o validador acusa a assinatura como válida.


Equipe ACBr BigWings
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

 

 

Share this post


Link to post
Share on other sites
Em 15/02/2019 at 18:14, Marcelo Calvi Belanga disse:

Olá... estou com mesmo problema. Já verifique e removi tudo que poderia ocasionar o mesmo cstat.

Anexo todos os logs...

3-env-lot.xml

3-rec.xml

351005282376018-ped-rec.xml

351005282376018-pro-rec.xml

Olá Marcelo. Antes de prosseguir com o problema, vamos corrigir alguns outros probleminhas da nota, ( que talvez possam ocasionar o erro de assinatura ). Veja que a finalidade da sua NF-e está como devolução, porém não foi referenciada nenhuma NF-e de devolução, e também não foi utilizado nenhum CFOP de devolução.

Share this post


Link to post
Share on other sites
2 horas atrás, Breno Luiz disse:

Olá Marcelo. Antes de prosseguir com o problema, vamos corrigir alguns outros probleminhas da nota, ( que talvez possam ocasionar o erro de assinatura ). Veja que a finalidade da sua NF-e está como devolução, porém não foi referenciada nenhuma NF-e de devolução, e também não foi utilizado nenhum CFOP de devolução.

Eu já havia verificado isso, mas para tirarmos a dúvida, segue os novos XML com a emissão normal.

A rejeição 297 continua.

Não estou com o ACBr atualizado, a última atualização foi em 28/11/2018 15968, será que pode ser isso?

Estou protelando a atualização por causa dos refactorys que foram feitos, estou com tempo meio curto.

3-env-lot.xml

3-rec.xml

351005285224766-ped-rec.xml

351005285224766-pro-rec.xml

Share this post


Link to post
Share on other sites

Boa tarde.

É interessante que você atualize seus fontes e  refaça o teste.

Att.


Consultora SAC ACBr

Juliana Tamizou
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil

Share this post


Link to post
Share on other sites

Boa tarde,

O cliente acabou trocando o certificado digital para A1 normal de arquivo. Com isso não consegui testar mais nada, se aparecer outro certificado deste tipo vamos testar, mas estamos orientando a não usar este modelo de certificado.

Obrigado. 


Atenciosamente,

 

 Assinatura.png

Share this post


Link to post
Share on other sites
1 hora atrás, Juliana Tamizou disse:

Boa tarde.

É interessante que você atualize seus fontes e  refaça o teste.

Att.

Boa tarde Juliana.

Atualizado os fontes até a revisão atual 16570, ajustado todos os itens que foram refatorados.

E a rejeição 297, com certificado RemoteID continua.

Olha que estranho a assinatura em <SignatureValue>

3-env-lot.xml

3-rec.xml

351005285676938-ped-rec.xml

351005285676938-pro-rec.xml

1 hora atrás, tdpsistemas disse:

Boa tarde,

O cliente acabou trocando o certificado digital para A1 normal de arquivo. Com isso não consegui testar mais nada, se aparecer outro certificado deste tipo vamos testar, mas estamos orientando a não usar este modelo de certificado.

Obrigado. 

Vou propor para o cliente fazer isso também.

Share this post


Link to post
Share on other sites

Boa tarde a todos!!!!

Devido a urgência do cliente, indiquei ao mesmo comprar o certificado A1 e no memo momento após a instalação, sem nenhuma configuração adicional a NFe foi transmitida e autorizada, ou seja, esse certificado RemoteID não funciona para emissão de NFe com ACBr pelo menos até o momento.

Se houver interesse por parte dos desenvolvedores (moderadores), posso doar o valor para aquisição do mesmo para testes e ajustes!

  • Like 3

Share this post


Link to post
Share on other sites

Olá Marcelo,

Obrigado por se dispor a ajudar... vou analisar a questão...

  • Like 3

Consultor SAC ACBr

Daniel Simões de Almeida
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Share this post


Link to post
Share on other sites

@Rafael Dias e @EMBarbosa... notaram que a existência de exatos 1024 bytes de "NUL",  no inicio da String da assinatura...  Pode ser algo no retorno do driver WinCrypt desse certificado...

Por favor substitua a Unit em Anexo, (rode novamente o ACBrInstall)... e verifique se a assinatura ficou correta  

Você pode gerar um XML e testar a assinatura do mesmo, usando o Demo do  ACBrNFe

 

ACBrDFeWinCrypt.pas

  • Like 1

Consultor SAC ACBr

Daniel Simões de Almeida
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Share this post


Link to post
Share on other sites
13 horas atrás, Daniel Simoes disse:

@Rafael Dias e @EMBarbosa... notaram que a existência de exatos 1024 bytes de "NUL",  no inicio da String da assinatura...  Pode ser algo no retorno do driver WinCrypt desse certificado...

Por favor substitua a Unit em Anexo, (rode novamente o ACBrInstall)... e verifique se a assinatura ficou correta  

Você pode gerar um XML e testar a assinatura do mesmo, usando o Demo do  ACBrNFe

 

ACBrDFeWinCrypt.pas 48 kB · 0 downloads

Olá @Daniel Simoes, vou verificar com o cliente se ainda está com o certificado em mãos, pois, o mesmo disse que havia conseguido estornar a compra.

Se estiver efetuarei o teste no Demo e em minha aplicação.

Share this post


Link to post
Share on other sites

@Daniel Simoes, infelizmente meu cliente já cancelou o certificado.

Se forem prosseguir com os testes fim de homologar o ACBr nessa plataforma, estou à disposição para o investimento, seja a doação do valor para a compra ou a compra em meu nome para testes.

Aguardo um posicionamento.

Share this post


Link to post
Share on other sites

Eu acho que o problema foi sanado, com o ajustes proposto... pois removendo os 1024 bytes "NUL", no inicio da String da Assinatura, ela ficava válida... vou subir para o SVN...

  • Like 2

Consultor SAC ACBr

Daniel Simões de Almeida
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Share this post


Link to post
Share on other sites

Creio que esse Bug foi morto... ;)

cockroach GIF by Animation Domination High-Def

  • Haha 1
  • Sad 1

Consultor SAC ACBr

Daniel Simões de Almeida
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Share this post


Link to post
Share on other sites

Bom dia Sr's,

Após a atualização dos fontes do ACBR no dia 21/02/2019 aleatoriamente meu sistema passou a apresentar a rejeição 297: Assinatura difere do calculado, como o cliente fatura a noite foi difícil simular a situação em um ambiente com o problema, porém após muitos testes nos deparamos com o cenário e podemos enfim debugar. Observamos que a rejeição se dava por ocorrência de problema na unit trunk2\Fontes\ACBrDFe\ACBrDFeWinCrypt.pas. Vimos no log de alteração do SVN, uma implementação para atender a este tópico, como antes nunca havia ocorrido isso, comentamos o código implementado e a nota parou de apresentar o problema. Aparentemente o problema se originou com a implementação  deste código:

  function TDFeWinCrypt.CalcHash(const AStream: TStream; const Digest: TSSLDgst;
  const Assina: Boolean): AnsiString;

        ...

        if Assina then
        begin
          if CryptSignHash(mHash, dwKeySpec, Nil, 0, @mHashBuffer, mBytesLen ) then
          begin
            // MS CryptoAPI retorna assinatura em "Little Endian bit string", invertendo...
            Result := '';
            {while (mBytesLen > 0) and (mHashBuffer[mBytesLen-1] = #0) do
              Dec(mBytesLen);} 

            for I := mBytesLen downto 1 do
              Result := Result + mHashBuffer[I-1];
          end
          else
            raise Exception.Create('CryptSignHash');
        end

Estou anexando o XML com o erro para mais detalhes. Se alguém tiver alguma ideia do porque do surgimento deste problema, favor nos ajudar.

Interagi neste tópico para evitar abrir outro visto que esta ainda está em aberto.

Desde já agradeço.

Assintaura.xml

Share this post


Link to post
Share on other sites
3 horas atrás, Paulo R G Oliveira disse:

Estou anexando o XML com o erro para mais detalhes. Se alguém tiver alguma ideia do porque do surgimento deste problema, favor nos ajudar.

Verificando...


Consultor SAC ACBr

Daniel Simões de Almeida
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Share this post


Link to post
Share on other sites

Apliquei um pequeno ajuste, para evitar que o Hash computado não fique com menos de 256 bytes

Rev. 16716, no SVN

  • Like 1

Consultor SAC ACBr

Daniel Simões de Almeida
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...