Vanessinha Mocellin

Boa tarde Italo, eu não converti para Hexa. Oque você mencionou para fazer, foi exatamente isso que eu fiz. No exemplo que citei em um dos posts anteriores, tem os DigestValues obtidos através do SHA1 e da assinatura digital sem conversão, assim como os XML's anexados, se quiser realizar os testes ai. DigestValue function SHA1 = 7671ed3a9e47e32ee249279e0ace1224e33e2702 Convertido para Base64 = NzY3MWVkM2E5ZTQ3ZTMyZWUyNDkyNzllMGFjZTEyMjRlMzNlMjcwMg== DigestValue Assinado = FIOfehD6kJpNMrZ5ehn/dO7r8qo= Convertido para Hexa = 46494f66656844366b4a704e4d725a3565686e2f644f377238716f3d

Sim, se convertido para Hexa fica 56, porém ao consultar o QR-Code consta que o DigestValue é inválido. Segundo consta no manual os DigestValues deveriam ser iguais. O DigestValue gerado no QRCode deve ser o mesmo que o DigestValue gerado na assinatura. O problema que já tenho questionado desde o inicio, é que Sha1 gera 40 caracteres e o DigestValue da assinatura 28, não vejo como eles serem iguais.

Bom dia Italo, segue teste realizado. DigestValue function SHA1 = 7671ed3a9e47e32ee249279e0ace1224e33e2702 DigestValue Assinado = FIOfehD6kJpNMrZ5ehn/dO7r8qo= Em anexo os XML's sem assinatura e com assinatura Obs: Lembrando que o DigestValue deve conter exatamente 56 caracteres referente ao QRCode. xml.xml xml-assinado.xml

Bom dia Rômulo Já me deparei com essa situação, o Italo fez a atualização do fonte com a alteração que sugeri. Verifica se os seus fontes estão atualizados e se a alteração corrige oque você precisa.

Bom dia Sérgio. Existe uma possibilidade onde a ACBr altera a versão para 3.00, já tive esse problema no inicio das implementações. Isso ocorre quando atribuo valor primeiro a property versão (VersaoDF) e depois a property modelo (ModeloDF). Mas a principio pelo que passou você esta atribuindo os valores na ordem correta, verifique se em algum lugar você não esta atribuindo o modelo novamente após ser atribuido a versão. Tente debuggar o método SetModeloDF da unit ACBrNFeConfiguracoes, nesse método é alterado a versão para 3.00.

Não cheguei a ver os posts anteriores Sérgio. Estou conseguindo transmitir NFC-e para RS e MT com sucesso. Eu atribuo essa informação no inicio quando estou adicionando a NFCe, logo após atribuir a chave da NFC-e, dessa forma: with ( ACBrNFe.NotasFiscais.Add.NFe ) do begin infNFe.ID := 'NFe' + ANotaFiscalEletronica.Chave; infNFe.Versao := 3.1; end; Nada!

Boa tarde Sérgio Além de configurar os parâmetros das configurações da ACBrNFe deve ser atribuido também a versão nas informações da NFe. ACBrNFe.NotasFiscais.Items[ 0 ].NFe.infNFe.Versao := 3.1

Como o cancelamento não é algo que tenha muito processamento, costumo consultar a NFC-e antes de cancelar, evitando assim esses problemas de perda de informações. Você pode estar utilizando o método ACBrNFe.Consultar Com isso você consegue todas as informações de autorização e cancelamento. Após consultar, verifique se já não existe um evento registrado a consulta que realizou dessa forma: ACBrNFe.WebServices.Consulta.procEventoNFe.Count > 0 Caso exista evento a NFC-e já esta cancelada, você pode estar utilizando as informações de cancelamento abaixo, para recuperar: ACBrNFe.WebServices.Consulta.procEventoNFe.Items[ 0 ].RetEventoNFe.XML ACBrNFe.WebServices.Consulta.procEventoNFe.Items[ 0 ].RetEventoNFe.cStat ACBrNFe.WebServices.Consulta.procEventoNFe.Items[ 0 ].RetEventoNFe.xMotivo ACBrNFe.WebServices.Consulta.procEventoNFe.Items[ 0 ].RetEventoNFe.InfEvento.dhEvento ACBrNFe.WebServices.Consulta.procEventoNFe.Items[ 0 ].RetEventoNFe.InfEvento.DetEvento.xJust ACBrNFe.WebServices.Consulta.Protocolo Caso não exista evento de cancelamento você pode obter as informações de autorização abaixo: ACBrNFe.NotasFiscais.Items[ 0 ].XML ACBrNFe.NotasFiscais.Items[ 0 ].NFe.procNFe.cStat ACBrNFe.NotasFiscais.Items[ 0 ].NFe.procNFe.xMotivo ACBrNFe.NotasFiscais.Items[ 0 ].NFe.procNFe.dhRecbto ACBrNFe.NotasFiscais.Items[ 0 ].NFe.procNFe.nProt

Bom dia Italo, Então, meu ambiente seria exatamente esse que você exemplificou. Na situação em que o PDV tem acesso ao servidor e o servidor não tem acesso ao SEFAZ, poderia sim utilizar o DigestValue gerado na assinatura do XML. Dessa forma o QR-Code é gerado sem erros, apesar de constar no manual que quando for contingência (tpEmi = offline) o DigestValue deveria ser gerado a partir do SHA1 sobre o XML. Porém o problema seria exatamente esse, quando o PDV não tem comunicação com o servidor, e essa situação irá ocorrer, pois em empresas de porte o servidor não esta na mesma rede das filiais. Nessa situação o DigestValue gerado da forma que consta no manual é inválido. Mandei e-mail para a SEFAZ do MT, não souberam me responder, na verdade sabem menos que eu, apenas mencionaram algumas partes que constam no manual, sem comentários. Mandei e-mail para a SEFAZ do RS, não entenderam minha dúvida, então mandei novamente mais elucidado, porém ainda não responderam, isso já faz alguns dias.

Jair, o Italo corrigiu essa situação conforme sugeri, se atualizar os fontes, já vai estar corrigido. Caso seja informado um token de homologação, ele pega o token informado, não realiza mais o cálculo, ou seja, a função esta considerando agora o token que for passado de parâmetro independente do ambiente.

O ID token deve possuir 6 caracteres, no seu caso se é o primeiro token gerado então o ID token deve utilizar assim: 000001 Se você criou uma função exatamente igual a da ACBr, me passe os parâmetros que esta passando para a função, dessa forma posso analisar. Observação: Se certifique de ter copiado a função atualizada.

A ACBr tem um método disponibilizado que realizada oque você precisa. Na unit ACBrNFeUtil.pas tem o método GetURLQRCode, você pode estar utilizando essa função ou caso ainda queira gerar por conta mesmo, analise essa função e verifique oque tem de diferente da sua, pois é um método bem simples.

Boa tarde Italo, No meu caso pode acontecer de ser realizado a inutilização de um número e posteriormente por alguma adversidade não consiga gravar essa inutilização. Como você disse uma rara exceção, porém preciso garantir um controle supremo referente a falhas, essa possibilidade dificilmente ira ocorrer, porém existe e preciso tratar caso ocorra. Solução: Em virtude da inexistência de um webservice de consulta referente a inutilização, pode-se contornar essa situação tratando o erro 563 - Já existe pedido de Inutilização com a mesma faixa de inutilização. Caso o número que estamos tentando inutilizar já foi inutilizado, retornar o erro 563, conforme o Carlos Marian menciona anteriormente. Nesse caso temos todas as informações necessárias da inutilização, inclusive o XML completo, porém seria necessário fazer um pequeno ajuste para gerar o XML completo quando o retorno for 563, pois esta gerando apenas quando o retorno for 102 - Inutilização de número homologado. Partindo da seguinte lógica, que após inutilizar uma numeração não tem mais oque fazer com aquele numero, não vejo problemas em gerar o XML quando o número já esta inutilizado. Dessa forma conseguimos contornar essa situação, se tornando assim um meio de consultar as informações de inutilização. Em anexo segue fonte com alteração sugerida. Observação: Aproveitando o gancho, estou mandando juntamente uma alteração para considerar o retorno 155-Cancelamento homologado fora de prazo, referente ao processo de cancelamento. ACBrNFeWebServices.pas

Bom dia Carlos Para conseguir esse retorno 563, você tentou inutilizar novamente? Ou que método utilizou para conseguir? Obrigado

Essa canonização C14N XML que você cita, seria oque os métodos AssinarLibXML e AssinarMSXML da unit ACBrNFeUtil fazem?

Boa tarde Italo, Fiz os testes com a função que passou, abaixo valores apresentados para analise: Função DigestValue ( método que passou ) = '53BB5D9649587F8C8D408419043E476E537692FC' Função CalcularHash = '80B94CCA98CB8703E16935707CE4DAE3D808219F' DigestValue gerado no XML após ser assinado = 'btK9KvFLa4YtuoewJAK8iHxHUrw=' A função que passou gera um número diferente do gerado pelo CalcularHash, porém gera com 40 caracteres também. Ficando dessa forma o DigestValue inválido. Não sei, talvez teria que converter para alguma coisa o valor obtido, pois são muito diferente do DigestValue gerado após o XML ser assinado. A questão é que no manual consta que o DigestValue deve possuir 56 caracteres e o SHA1 resulta em 40, já não fecha de cara.

Italo, Não seria algo tão simples, eles não estão nem perto de serem iguais kkkkkkk essa é minha grande preocupação, porque dessa forma quebra com a assinatura digital... Vou te explicar passo a passo, para você entender melhor como estou procedendo, caso esteja fazendo algo errado: 1º - No PDV gero uma NFC-e em contingência, e de acordo com o seu XML (anexo xml.xml) gero o DigestValue conforme código abaixo: sDigestValue := CalcularHash(oACBrNFe.NotasFiscais.Items[ 0 ].XML, dgstSHA1); O SHA1 gerado a partir do XML = 93922644CECEE6988CF28CC5F0E885F5D441ADD3 (40 caracteres) Segundo exemplos encontrados no link: http://pt.wikipedia.org/wiki/SHA1 sempre é gerado 40 caracteres para o SHA1 Utilizo o método NotaUtil.GetURLQRCode, passando de parâmetro o DigestValue gerado. No método NotaUtil.GetURLQRCode, após converter o DigestValue para hexa fica com 80 caracteres: 39333932323634344345434545363938384346323843433546304538383546354434343141444433 QR-Code gerado: https://www.sefaz.rs.gov.br/NFCE/NFCE-COM.aspx?chNFe=43140690180621000197650550000001229000001221&nVersao=100&tpAmb=2&dhEmi=323031342D30362D32305431343A35363A30332D30333A3030&vNF=0.50&vICMS=0.09&digVal=39333932323634344345434545363938384346323843433546304538383546354434343141444433&cIdToken=000001&cHashQRCode=D06B7FC810E41E2B220170631F913F119A58EAEB Obs: Se gerar o SHA1 do xml em anexo no site http://www.convertstring.com/pt_PT/Hash/SHA1 se obtém o mesmo valor, ou seja, o método CalcularHash esta de acordo. 2º - Quando estabelecer comunicação com o Servidor essa NFC-e é assinada e transmitida, nesse momento o DigestValue gerado é: AJ5CxasySMKMI8exBXxh1lwOlSM= (28 caracteres) Em anexo para comparativo o arquivo xml-assinado.xml. Após converter o DigestValue para hexa fica com 56 caracteres: 414a354378617379534d4b4d4938657842587868316c774f6c534d3d Obs: Mesma situação ocorre no estado do MT. xml.xml xml-assinado.xml

Bom dia Italo, 1 - Estou passando o XML inteiro, sem assinatura. Estou realizado esse procedimento no PDV onde não tenho certificado. 2 - Os tamanhos dos retornos são diferentes, quando é transmissão NORMAL o DigestValue tem 28 caracteres, que posteriormente ( na função NotaUtil.GetURLQRCode ) é convertido para hexa ficando com 56 caracteres, o tamanho correto solicitado pelo manual. Quando transmissão CONTINGÊNCIA o DigestValue fica com 40 caracteres e posteriormente após a conversão para hexa fica com 80 caracteres. Obs: Testei também sem a conversão para hexa, pois no manual não esta especificado que para esse caso necessite da conversão, porém ocorreu o mesmo erro. Segundo consta no manual o tamanho do DigestValue deve ser exatamente 56 caracteres.

Bom dia André, Quando contingência, a SEFAZ da a possibilidade de gerar o DigestValue de forma diferenciada, com o objetivo de não obrigar o contribuinte ter que instalar o certificado em todos os PDV's (motivo pelo qual existe o token). Isso seria apenas uma forma de auxiliar a implantação de empresas grandes, mas isso não impede que empresas de pequeno porte (com poucos terminais) tenham instalado o certificado em todas as máquinas. Como mencionei anteriormente no post , nos testes efetuados tentei gerar o DigestValue a partir do arquivo XML conforme me orientou, porém retorna Erro: Msg: 370 - QR-Code Inválido (Digest Value) Não consigo gerar um DigestValue válido. Pode ser que tenha me passado em alguma coisa, abaixo codificação utilizada para gerar o DigestValue: if ( TipoTransmissao = 'N' ) then sDigestValue := oACBrNFe.NotasFiscais.Items[ 0 ].NFe.signature.DigestValue; else begin with ( TACBrEAD.Create( nil )) do try sDigestValue := CalcularHash(oACBrNFe.NotasFiscais.Items[ 0 ].XML, dgstSHA1); finally Free; end; end; Seria esse método CalcularHash que me orientou a usar para gerar o DigestValue?

Certo Italo, qualquer coisa estou a disposição se precisar de algo. Obrigado

Boa tarde André, Enfrentei o mesmo problema que o Carlos. O erro realmente ocorre quando executado o método GetCertificado dentro de uma Thread. A Thread necessita que o comando CoInitialize(nil) seja executado, para processar corretamente a API do ActiveX. Para resolver esse problema criei uma condição de compilação, segue em anexo o fonte para ser analisado. ACBrNFeConfiguracoes.pas ACBrNFeConfiguracoes.pas

Boa tarde Italo, Meu cenário é o seguinte: Tenho um servidor de aplicação responsável por realizar a transmissão das NFC-e para SEFAZ (que possui o certificado instalado). E tenho estações (PDV's) que realizam comunicação com o servidor (que possui o token). Quando o PDV (frente de caixa) não consegue realizar comunicação com o servidor, ele gera uma NFC-e em contingência. Então no meu caso, eu não teria como assinar o XML nesse momento. Partindo da seguinte lógica, que quando a emissão é do tipo contingência ela é realizada nos PDV's, onde não tenho o certificado instalado, tenho apenas o token. Onde o objetivo do token é justamente essa, de evitar ter que instalar o certificado em todos as estações. Pelo que da para entender no manual ( item 3.5 penúltimo paragrafo da página 18 ) deverá ter um tratamento diferenciado para o DigestValue quando for contingência, já prevendo que esse campo não terá valor, devido não ter assinatura no momento da geração. E ainda pelo que se entende, depois quando o documento for assinado e transmitido o DigestValue gerado deverá ser o mesmo que foi gerado no QR-Code. Porém seguindo o que consta no manual, 'da forma que entendi' não consegui gerar um DigestValue válido com 56 caracteres.

Boa tarde pessoal Estou enfrentando um problema para gerar o QR-Code de uma NFC-e em contingência referente ao estado do RS. Ao consultar o QR-Code retorna os seguintes erros: Msg: 361 - QR-Code Inválido (Digest Value) Msg: 401 - QR-Code Inválido (Hash do QR-Code) Segundo o manual: Para o caso da emissão em contingência off-line (tpEmis=9) o digest value corresponde ao algoritmo SHA1 sobre o arquivo XML da NFCe. Pelo que entendi quando for uma NFC-e em contingência em virtude de o XML ainda não estar assinado, o DigestValue é branco, dessa forma eles exigem que o campo DigestValue utilizado para geração do QR-Code, seja o SHA1 do XML da NFC-e. Ainda segundo o manual: Ao se efetuar a assinatura digital da NFCe emitida em contingência off-line, o campo digest value constante da XMl Signature deve obrigatoriamente ser idêntico ao encontrado quando da geração do digest value para a montagem QR Code. Pelo que se entende então, que ao realizar a transmissão da NFC-e em contingência o DigestValue após ser assinada deve receber o valor que foi informado na geração do QR-Code (SHA1 do XML). Testes efetuados NFC-e Contingência: 1º - Passado o SHA1 do XML no parâmetro DigestValue do método GetURLQRCode, retornar apenas um erro dessa forma. Erro: Msg: 370 - QR-Code Inválido (Digest Value) 1º - Passado o SHA1 do XML no parâmetro DigestValue do método GetURLQRCode, e alterado para não converter para hexa (pelo que se entende no manual, não deveria converter para hexa o DigestValue quando for contingência), retornar o mesmo erro dessa forma também. Erro: Msg: 370 - QR-Code Inválido (Digest Value) Obs: SHA1 do XML retorna 40 caracteres, após ser convertido para Hexa dentro do método GetURLQRCode o DigestValue fica com 80 caracteres. Segundo o manual esse campo obrigatóriamente deve ter 56 caracteres. Alguém por acaso já enfrentou esse problema ou conseguiu gerar o QR-Code em contingência sem erros?

Segue em anexo solução para resolver os impostos de produtos serviço na versão 3.1 devido não existir mais o campo cSitTrib. pcnNFeW.pas

Boa tarde De acordo com a situação citada pelo Newton, referente ao campo cSitTrib do grupo ISSQN, na versão 3.01 não existe mais, foi removido. Dessa forma ao executar o comando: ACBrNFe.NotasFiscais.LoadFromString( XML ), pelo fato desse campo não existir mais no XML será atribuido o valor default ISSQNcSitTribVazio referente a versão 3.01. Na unit pcnNFeW procedimento GerarDetImposto é realizado a verificação se a situação tributária for diferente de ISSQNcSitTribVazio para atribuir os impostos de ISSQN, porém esse campo sempre estará com o default vazio na versão 3.01 independente se for produto mercadoria ou produto serviço e dessa forma nunca será atribuído impostos de ISSQN para produtos serviços. Sugiro para resolver essa situação alterar a condição, passar a verificar se versão for maior que 3 a possuir informação da lista de serviço então se considera um produto serviço. De: if nfe.Det.Imposto.ISSQN.cSitTrib <> ISSQNcSitTribVazio then Para: if (( NFe.Det.Imposto.ISSQN.cSitTrib <> ISSQNcSitTribVazio ) or (( NFe.infNFe.Versao > 3 ) and ( nfe.Det.Imposto.ISSQN.cListServ <> '' ))) then Obs: Verificado pela lista de serviço em virtude de que os outros campos que são obrigatórios podem receber valor zero ( exemplo vISSQN ). Dessa forma garantimos que se tiver lista de serviço informado ( que é obrigatório para serviço ) então é considerado de fato um produto serviço.