Renato Rubinho

Não acredito que seja algo tão simples, mas espero seja... Como você disse que no eSocial funciona, já é uma boa notícia. Obs: O problema aparentemente não está no id apenas. A menos que o erro no id (mesmo sem ser acionado) desencadeie erros nas demais propriedades. Qualquer propriedade do EvtTotal apresenta o mesmo problema. Segue outro exemplo, comentei a linha da leitura do id e a próxima também apresentou o mesmo problema. Seguem links sobre o que falei a respeito do problema de cast no Delphi 7: http://hallvards.blogspot.com.br/2004/07/hack-7-interface-to-object-in-delphi.html http://blog.barrkel.com/2011/03/ugly-alternative-to-interface-to-object.html

Bom dia, Efetuei o teste novamente conforme exemplo abaixo e, mesmo atribuindo à variável ( R5001: TR5001) ocorre access violation ao tentar ler as propriedades.

Obrigado pelo retorno Rafael. Eu também havia testado atribuindo à variável conforme seu exemplo, não dá erro para compilar mas também dava access violation ao tentar ler as propriedades. Vi agora que no exemplo que passei não coloquei o índice da collection, mas no meu sistema tenho quase certeza que estava correto senão nem compilaria. Cheguei a encontrar artigos na internet referente a problemas de cast com interface no Delphi 7, dando como solução, funções monstruosas para resolver o problema. Não estou com o ambiente aqui para testar, na segunda-feira eu testo novamente e aviso.

Bom dia Italo, Ok. Vou ver, estou em outro projeto é assim que possível vejo se coloco essa consulta no componente. Quando criei as outras classes, não tinha o 5011 ainda na versão 1_02. Quando puder, só dá uma olhada no cast por favor, para ver se deixamos com a função para retornar o objeto, se substituimos a interface por classe ou se tem alguma forma de fazer o cast como está agora. Pelo que pesquisei, do jeito que tá só vi opção criando uma função.

Só vou consegui testar segunda-feira, mas ainda não fiz nada do 5011. Você pode passar o exemplo que está utilizando?

Boa tarde Italo, Não vi que havia a leitura na 5001 após mudarem o "TEnvioLote.TratarResposta". Desculpe mais uma vez. Por favor, desconsidere as alterações da unit pcnReinfRetEventos, o problema em si é no item (2) para ler as propriedades após o envio. Não consigo fazer o cast sem essa implementação que mandei (gera access violation). Sabe se existe alguma alternativa para conseguir ler as propriedades através da Interface ? Estou mandando a unit do demo junto deste novo fonte com o cenário do problema para você entender, detalhes abaixo Exemplo: if ACBrReinf1.Enviar then begin for i:=0 to ACBrReinf1.WebServices.EnvioLote.RetEnvioLote.evento.Count - 1 do begin // 1. Funcionando: com a implementação da nova função GetEvento // with TR5001( ACBrReinf1.WebServices.EnvioLote.RetEnvioLote.evento.Items.Evento.GetEvento ) do // 2. Não funcionando: com o fonte anterior, fazendo o cast do Evento dá access violation em qualquer propriedade. Ex: EvtTotal.id with TR5001( ACBrReinf1.WebServices.EnvioLote.RetEnvioLote.evento.Items.Evento ) do begin mmoRet.Lines.Add('EvtTotal.id: '+ EvtTotal.id); mmoRet.Lines.Add('cdRetorno: '+ EvtTotal.IdeStatus.cdRetorno); mmoRet.Lines.Add('descRetorno: '+ EvtTotal.IdeStatus.descRetorno); mmoRet.Lines.Add('nrRecArqBase: '+ EvtTotal.InfoTotal.nrRecArqBase); end; end; Obrigado ACBrReinf003.rar

Boa tarde @Italo Jurisato Junior, Desculpe, sempre atualizo os fontes antes de dar manutenção, tinha atualizado segunda-feira e acabei não checando se houveram novas implementações até ontem. 1. Seguem implementações, com o fonte atual, alimentando as propriedades: EvtTotal.id EvtTotal.IdeStatus.cdRetorno EvtTotal.IdeStatus.descRetorno EvtTotal.IdeStatus.regOcorrs.tpOcorr EvtTotal.IdeStatus.regOcorrs.localErroAviso EvtTotal.IdeStatus.regOcorrs.codResp EvtTotal.IdeStatus.regOcorrs.dscResp EvtTotal.infoRecEv.nrProtEntr EvtTotal.infoRecEv.dhProcess EvtTotal.infoRecEv.tpEv EvtTotal.infoRecEv.idEv EvtTotal.infoRecEv.hash EvtTotal.InfoTotal.nrRecArqBase 2. IEventoReinf >>> function GetEvento: TObject; Como a propriedade TeventoCollectionItem.FEvento foi criada como interface não é possível fazer o cast para os respectivos eventos (5001 ou 5011) para poder preencher as propriedades. Para conseguir fazer o cast, criei a função GetEvento para devolver o objeto. A alternativa seria herdar a 5001 e 5011 de uma classe principal e declarar o TeventoCollectionItem.FEvento como a classe principal ao invés da Interface. Att ACBrReinf002.rar

Bom dia @Juliomar Marchetti, Segue novo fonte ( com a alteração inicial do post inclusive ) com implementação de nova propriedade para armazenar o Número de Protocolo quando houver retorno "2-Em Processamento" { TdadosRecepcaoEvento } TdadosRecepcaoEvento = class private FdhProcessamento: TDateTime; FTipoEvento: string; FHash: string; FIDEvento: string; FnrProtEntr: string; public property dhProcessamento: TDateTime read FdhProcessamento write FdhProcessamento; property tipoEvento: string read FTipoEvento write FTipoEvento; property IDEvento: string read FIDEvento write FIDEvento; property Hash: string read FHash write FHash; property nrProtEntr: string read FnrProtEntr write FnrProtEntr; end; !!!!! Obs !!!! Não encontrei documentação a respeito dos códigos de status de retorno. Até o momento eu havia me deparado apenas com "0-Sucesso" ou "1-ERRO" Agora, no envio do R2099, está acusando "2-EM PROCESSAMENTO" e retorna o nrProtEntr ao invés do nrRecArqBase Cacei na net e encontrei algumas pessoas reclamando do mesmo problema na versão 1_03_00. Caso alguém tenha detalhes a respeito, agradeço para poder fazer os testes e eventuais implementações que forem necessárias. Gostaria de saber como consultar o status. 1. Na situação atual, enviei o R2099 e retornou "2-Em Processamento" 1.1. Se tento enviar novamente, acusa <codResp>MS1078</codResp><dscResp>A EFD já foi fechada para o período informado, ou existe um evento de fechamento em processamento</dscResp> 1.2. Se tento enviar R2098, acusa <codResp>MS1060</codResp><dscResp>Não existe evento de fechamento para o período informado.</dscResp> como se não houvesse o R2099 ainda AcbrReinf001.rar

Bom dia, Segue fonte do Reinf com ajustes no tratamento de respostas do webservice: - Novas tags da v1_03_00 conforme destacado no exemplo abaixo - Configurado tratamento para leitura do id da tag evtTotal <evtTotal id="ID1234567890"> <ideEvento> <perApur/> </ideEvento> <ideContri> <tpInsc>1</tpInsc> <nrInsc>98765432</nrInsc> </ideContri> <ideRecRetorno> <ideStatus> <cdRetorno>0</cdRetorno> <descRetorno>SUCESSO</descRetorno> <regOcorrs> <tpOcorr>1</tpOcorr> <localErroAviso> ERRO </localErroAviso> <codResp>MS1234</codResp> <dscResp> TESTE DE ERRO </dscResp> </regOcorrs> </ideStatus> </ideRecRetorno> <infoRecEv> <dhProcess>2018-03-06</dhProcess> <tpEv>1000</tpEv> <idEv>ID1234567890123456789012345678901234</idEv> <hash>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</hash> </infoRecEv> <infoTotal> <nrRecArqBase>12345-67-8901-2345-67890</nrRecArqBase> </infoTotal> </evtTotal> Obs: O evento R2060 está com erro na Receita. Fiz testes em produção restrita e dados fictícios e o problema persistiu. Os demais estão funcionando corretamente. Erro: MS0025 | Falha no processamento. Favor tentar novamente. Identificador : 2890162031 AcbrReinf.rar

Bom dia, Segue o demo. Lembrando que este demo está em desenvolvimento, servirá para você poder testar a assinatura mas os fontes do Reinf não estão finalizados. DEMO.rar

Por desencargo, atualize as dlls das pastas abaixo no System32 / SysWow64 da sua máquina \lib7\ACBr\DLLs\XMLSec \lib7\ACBr\DLLs\OpenSSL\0.9.8.14 Nos meus testes com o Reinf, funcionou com as seguintes configurações:

Testado Reinf e NFe com A1 e A3. Funcionou perfeitamente. Obrigado

Boa tarde @Rafael Dias, A versão do ACBrDFeSSL.pas que foi para o SVN precisa de mais um ajuste, pois as urls tem mais uma diferença além do "-more" rsa-sha256 <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /> rsa-sha1 <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />

Bom dia @Rafael Dias, Testei a assinatura do Reinf (rsa-sha256) e o método GetSignDigestAlgorithm não identifica o digest do xml ( Para rsa-sha1 funcionou perfeitamente ) 1. O "problema" está no "Algorithm" do "SignatureMethod" que possui url diferente entre o rsa-sha1 e o rsa-sha256. 1.1. Ao pesquisar no conteúdo por "Algorithm="http://www.w3.org/2000/09/xmldsig#", retorna a informação do "Transform" (que possui a mesma url) ao invés do "SignatureMethod" 2. Seguem exemplos de ambos os XMLs para exemplificar 2.1. rsa-sha256: Ao pesquisar por "Algorithm="http://www.w3.org/2000/09/xmldsig#" o GetSignDigestAlgorithm retorna "enveloped-signature" da linha 7 e deveria retornar "rsa-sha256" da linha 4 001 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 002 <SignedInfo> 003 <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> 004 <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /> 005 <Reference URI="#ID1599506670000002017120507171200001"> 006 <Transforms> 007 <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> 008 <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> 009 </Transforms> 010 <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /> 011 </Reference> 012 </SignedInfo> 013 </Signature> 2.2. rsa-sha1: O GetSignDigestAlgorithm retorna "rsa-sha1" da linha 4 corretamente 001 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 002 <SignedInfo> 003 <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> 004 <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> 005 <Reference URI="#NFe35171212345678901234550010000008221000008228"> 006 <Transforms> 007 <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> 008 <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> 009 </Transforms> 010 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 011 </Reference> 012 </SignedInfo> 013 </Signature> 3. Segue ajuste que corrigiu essa situação e assinou function TDFeSSLXmlSignClass.GetSignDigestAlgorithm(const ConteudoXML: ansistring): TSSLDgst; var HashAlg: string; begin // Pesquisa por "SignatureMethod Algorithm=" para garantir que está na tag correta HashAlg := LowerCase(RetornarConteudoEntre(ConteudoXML, 'SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#', '"')); // Com a opção abaixo não é necessário mais a de cima, mas mantive a de cima como "padrão" para você o que acha // Caso não encontre com a url, pesquisa do final para o começo do valor até a posição de "#" if HashAlg = '' then begin HashAlg := LowerCase(RetornarConteudoEntre(ConteudoXML, 'SignatureMethod Algorithm="', '"')); HashAlg := ReverseString(RetornarConteudoEntre('!!inicio!!' + ReverseString(HashAlg), '!!inicio!!', '#')); if HashAlg = '' then raise Exception.Create('Não foi possivel recuperar o "Digest Algorithm" do XML'); end; if (HashAlg = 'rsa-sha1') then Result := dgstSHA1 else if (HashAlg = 'rsa-sha256') then Result := dgstSHA256 else if (HashAlg = 'rsa-sha512') then Result := dgstSHA512 else raise EACBrDFeException.Create(ACBrStr('Digest Algorithm, "'+HashAlg +'" não suportado')); end;

@Daniel Simoes, OK, vou acompanhando a implementação com libXML2 ou a opção de carga de DLL de terceiros. Realmente não testei com XP e não sabia que haveria essa limitação da forma como foi feito. Obrigado pelo retorno @juuninho Não fiz nada no e-social ainda, mas se o problema for apenas assinar com URI vazia, passe o terceiro parâmetro infElement em branco que irá gerar o xml com a URI em branco, mas como eu disse, não fiz testes com esse tipo de situação. XmlAss := XmlCryp.AssinarXml(1, AXml, infElement, FpDFeSSL.NumeroSerie, FpDFeSSL.ArquivoPFX, FpDFeSSL.Senha); !! Os demais que estão com erros de ambiente: * Como o Daniel informou, a biblioteca não funciona no XP (se for seu caso) * Olhem os detalhes em _TELAS.pdf - Resumindo: 1. Registrem com _REG_PoliCryp.bat 2. Atualizem ambos os fontes ACBrDFe.rar ACBrReinf.rar 3. Recompilem o ACBr_DFeComum

Bom dia @juuninho, Você deve estar mandando o conteúdo do Xml ao invés do caminho do arquivo. O método ValidarSchema() deve receber o caminho do arquivo XML ( Ex: C:\CAMINHO\TESTE.XML) e não o conteúdo do XML. Veja o exemplo que coloquei no Demo.

Boa tarde, Segue a classe com funções Assinar, Validar Assinatura, Validar Schema ACBrDFe.rar...: Fontes da implementação da nova biblioteca no ACBr ACBrReinf.rar .: Fontes "Beta" do Reinf assinando com a nova biblioteca + Certificado A1, A3 e .pfx, verificando assinatura e validando schema

Boa tarde, @Daniel Simoes @Rafael Dias A validação da assinatura eu já havia feito alguns testes, mas não estava finalizada. Segue o fonte atualizado com: 1. Validação da assinatura string VerificarAssinatura(int GeraLog, string ConteudoXML, string SignatureNode, string CertSerialNumber, string CertArquivoPfx, string CertPassword); 2. Ajuste para assinar com certificado A1 instalado na máquina 3. Implementação da opção de assinar com arquivo .pfx. Publicada nova função aceitando mais um parâmetro para passar o arquivo pfx string AssinarXml(int GeraLog, string ConteudoXML, string ElementID, string CertSerialNumber, string CertArquivoPfx, string CertPassword); *** Pendente (esse não tenho idéia, pois não mexi em nada a respeito ainda em C#) 4. Validar Schema // IMPLEMENTAR // VALIDAR SCHEMA // Retorna "OK" se OK, retorna o erro se False string ValidarSchema(string ConteudoXML, string ArqSchema); ACBrDFe.rar ...: Fontes da implementação da nova biblioteca no ACBr ACBrReinf.rar .: Fontes "Beta" do Reinf assinando com a nova biblioteca + Certificado A1, A3 e .pfx

Ok. Concordo. Fiz testes com Capicom, Indy, DCPCRYPT e LockBox, mas não consegui assinar. Enquanto não houver alternativa, utilizo como método paliativo em fontes paralelos. Obrigado

Boa tarde, @Daniel Simoes @Juliomar Marchetti Preciso disponibilizar para os meus clientes o Reinf com a assinatura utilizando o A3. Procurei / testei alternativas de bibliotecas e componentes, mas não encontrei nada (open) que eu conseguisse fazer funcionar no Delphi para poder incorporar no ACBr. Desenvolvi uma biblioteca em C# e gostaria de saber se podemos incorporá-la no ACBr (com os fontes) como alternativa para a assinatura. Segue minha sugestão com os respectivos fontes: Fontes separados: ACBrDFe.rar ...: Fontes da implementação da nova biblioteca no ACBr ACBrReinf.rar .: Fontes "Beta" do Reinf assinando com a nova biblioteca + Certificado A3 _TELAS.pdf ....: Detalhes da implementação

Legal @Daniel Simoes Imagina eu tentando explicar isso por escrito para conseguir passar a informação ?... rsrs Obrigado pelo retorno

@fidel, Esse é exatamente o problema que foi corrigido. O xmlParseDoc retorna em branco, porque o xml está inválido. Veja o xml contido em ConteudoXML. Irá existir um texto "id" perdido dentro de Sgnature, conforme abaixo: <Signature xmlns="1234567890"id> Você disse que atualizou o Reinf e recompilou o ACBr_DFeComum. Veja que são dois fontes separados. Se você não atualizou o ACBrDFe.rar, não vai adiantar recompilar. 1. Primeiro atualize o fonte ACBrDFe.rar e recompile o ACBr_DFeComum 2. Atualize o ACBrReinf.rar E, por fim, confirme realmente se está com o fonte correto, pois foi dito anteriormente que tiraram um dos parâmetros vazios na chamada abaixo. Essa chamada recebe agora 7 parâmetros. Se você passar o "id" no sexto parâmetro, acontecerá o problema que mencionou. Se passar no sétimo, funcionará: 4. A linha correta de ACBrReinfEventosBase->TEventoReinf.Assinar( é XMLAss := SSL.Assinar(ArqXML, 'Reinf', String(ANomeEvento), '', '', '', 'id');

@fidel e @Adilson Pereira, Conforme informei acima, sigam estes passos: 1. Primeiro atualize o fonte ACBrDFe.rar e recompile o ACBr_DFeComum, pois existem alterações que se não gerar novamente as dcus vão ter problemas de incompatibilidade entra as classes 2. Atualize o ACBrReinf.rar 3. Após recompilar o ACBr_DFeComum, a função SSL.Assinar receberá o sétimo parâmetro sem ocorrer o erro que mencionaram. 4. A linha correta de ACBrReinfEventosBase->TEventoReinf.Assinar( é XMLAss := SSL.Assinar(ArqXML, 'Reinf', String(ANomeEvento), '', '', '', 'id'); O erro "Erro: Falha ao interpretar o XML "xmlParseDoc" ocorre porque algum dos passos acima não foi feito

@Daniel Simoes, pelo que entendi nas reviões o IdSignature foi criado prevendo um atributo para concatenar seu valor em ACBrDFeUtil.SignatureElement, na linha: '<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"' + IdSignature + '>' + Se passarmos algum valor que não seja um atributo neste parâmetro ( 'id' no caso do Reinf ), esse valor será concatenado na linha acima destacada, gerando erro "Erro: Falha ao interpretar o XML "xmlParseDoc" porque o "Signature" ficará errado. -- ACBrDFeUtil function SignatureElement(const URI: String; AddX509Data: Boolean; IdSignature: String = ''; Asha256: Boolean = False): String; begin if Asha256 then Result := '<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"' + IdSignature + '>' + '<SignedInfo>' + '<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />' + '<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />' + '<Reference URI="' + IfThen(URI = '', '', '#' + URI) + '">' + '<Transforms>' + '<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />' + '<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />' + '</Transforms>' + '<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />' + '<DigestValue></DigestValue>' + '</Reference>' + '</SignedInfo>' + '<SignatureValue></SignatureValue>' + '<KeyInfo>' + IfThen(AddX509Data, '<X509Data>' + '<X509Certificate></X509Certificate>'+ '</X509Data>', '')+ '</KeyInfo>'+ '</Signature>' else Result := '<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"' + IdSignature + '>' + '<SignedInfo>' + O problema se origina no ACBrDFeSSL->TDFeSSLXmlSignClass.AdicionarSignatureElement , pois na linha que destaquei abaixo, é previsto receber o IdSignature como o nome do atributo ( apenas 'id', por exemplo ) URI := ExtraiURI(ConteudoXML, IdSignature); Mas na linha que destaquei abaixo, o mesmo IdSignature é passado para a SignatureElement, gerando o erro no xml Result := copy(ConteudoXML, 1, I - 1) + SignatureElement(URI, AddX509Data, IdSignature, FpDFeSSL.SSLDgst) + TagEndDocElement; function TDFeSSLXmlSignClass.AdicionarSignatureElement(ConteudoXML: String; AddX509Data: Boolean; docElement, IdSignature: String): String; var URI, TagEndDocElement: String; I: Integer; begin URI := ExtraiURI(ConteudoXML, IdSignature); TagEndDocElement := '</' + docElement + '>'; I := PosLast(TagEndDocElement, ConteudoXML); if I = 0 then raise EACBrDFeException.Create('Não encontrei final do elemento: ' + TagEndDocElement); Result := copy(ConteudoXML, 1, I - 1) + SignatureElement(URI, AddX509Data, IdSignature, FpDFeSSL.SSLDgst) + TagEndDocElement; end; Espero que tenha conseguido explicar, pois como envolve uma cadeia de chamadas de funções pode ser um pouco confuso. Me avise se ficou alguma dúvida.

@Juliomar Marchetti, apenas confirmando, para implantarem as alterações que fiz no DFeComum abro um tópico com o fonte ou esse aqui será utilizado ? ACBrDFe.rar @fidel, - Primeiro atualize o fonte ACBrDFe.rar e recompile o ACBr_DFeComum - Atualize o ACBrReinf.rar A linha que você postou que está dando erro do Reinf: XMLAss := SSL.Assinar(ArqXML, 'Reinf', String(ANomeEvento)); conforme meu exemplo, foi substituída por: XMLAss := SSL.Assinar(ArqXML, 'Reinf', String(ANomeEvento), '', '', '', 'id');