Renato Rubinho

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');

Segunda parte - ACBrReinf, Segue o fonte do Reinf após implementação do IdAttr no DFeComum, passando "id" no novo parâmetro: -- ACBrReinfEventosBase TEventoReinf.Assinar( XMLAss := SSL.Assinar(ArqXML, 'Reinf', String(ANomeEvento), '', '', '', 'id'); @Sandro Felipe Adad e @Leivio Fontenele Quando puderem, vejam se ficou OK para vocês. Estou com um Certificado A3 e não estou conseguindo, pois parece que o Crypt SHA 256 apenas funciona com o OpenSSL, mas ao tentar utilizar o OpenSSL dá erro. Preciso fazer mais testes com o A3, caso alguém tenha uma dica, agradeço. ACBrReinf.rar E_Reinf_Soap-85424_585.xml

Buenos, Segue a correção do DFeComum (Estou mandando separado o fonte do DFeComum do fonte do Reinf, devido ao Reinf ainda não fazer parte do componente) - Adicionado novo parâmetro IdAttr para receber o nome do atributo de identificação da assinatura quando for diferente de "Id" - Com a criação do novo parâmetro, mantido o parâmetro IdSignature para receber uma identificação de assinatura completa, que é utilizada em ACBrDFeUtil.SignatureElement Implementações do IdAttr: -- ACBrDFeSSL TDFeSSLXmlSignClass.AdicionarSignatureElement TDFeSSLXmlSignClass.Assinar TDFeSSLXmlSignClass.VerificarAssinatura TDFeSSL.Assinar TDFeSSL.VerificarAssinatura -- ACBrDFeXsXmlSec TDFeSSLXmlSignXmlSec.Assinar TDFeSSLXmlSignXmlSec.VerificarAssinatura -- ACBrDFeXsMsXmlCapicom TDFeSSLXmlSignMsXmlCapicom.Assinar -- ACBrDFeXsMsXml TDFeSSLXmlSignMsXml.Assinar TDFeSSLXmlSignMsXml.VerificarAssinatura -- ACBrDFeUtil ExtraiURI // ################## Pelo que vi, o problema ocorreu na revisão 13850, de acordo com as descrições abaixo: -- ACBrDFeSSL, ACBrDFeXsMsXml, ACBrDFeXsXmlSec -- [*] Método "TDFeSSLXmlSignClass.VerificarAssinatura", modificado para receber como parâmetro: IdSignature: String = '' (ficando igual ao método "Assinar") Isso permitirá a verificação de assinaturas que usa um padrão de ID diferente de "Id" -- ACBrDFeXsXmlSec -- [*] Métodos "Assinar" e "VerificarAssinatura" modificados para fazer uso do parâmetro "IdSignature". -- ACBrDFeUtil -- [*] Método "ExtraiURI" modificado para receber como parâmetro extra "IdSignature: String = ''". Isso permite diferente tipos de ID como por exemplo: "Id", "id", etc (por: DSA)ACBrDFe.rar // ##################

Buenas, Encontrei o problema e fiz todos os testes possíveis (até onde entendo), mas aparentemente existe um "conflito" no fonte Pelo que vi nos históricos, o problema ocorreu no item 2 (descrito abaixo). Estou fazeno mais testes e até amanhã passo a solução completa. Vamos lá, do final para o começo: 1. O erro no Reinf acontece aqui: //####### ACBrDFeUtil->SignatureElement( . . . '<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"' + IdSignature + '>' + //####### 1.1. Por que ? - Nesta linha, a função utiliza o conteúdo do parâmetro IdSignature como se fosse um atributo de "Signature" 1.2. IdSignature está recebendo o conteúdo 'id', o que gera o erro, pois era previsto um atributo (Ex: 'id="1234"' ao invés de 'id' ). 2. Onde está o "Conflito" ? //####### ACBrDFeSSL->TDFeSSLXmlSignClass.AdicionarSignatureElement( . . . URI := ExtraiURI(ConteudoXML, IdSignature); //####### 2.1. Nesta linha, foi previsto que IdSignature receberia apenas o nome do atributo "id" para "Extrair" o valor e alimentar na variável "URI" 3. Como simular o erro ? //####### ACBrReinfEventosBase->TEventoReinf.Assinar( . . . XMLAss := SSL.Assinar(ArqXML, 'Reinf', String(ANomeEvento), '', '', 'id'); //####### Preencher o parâmetro IdSignature da função SSL.Assinar com 'id', com isso, a função ACBrDFeSSL->TDFeSSLXmlSignClass.AdicionarSignatureElement conseguirá extrar o valor da URI, mas a função ACBrDFeUtil->SignatureElement irá gerar o atributo incorreto em Signature.

Boa tarde, @Juliomar Marchetti, segue o fonte sem os IFDefs e incorporado no projeto de exemplo o controle dos parâmetros via .ini "clonado" do Demo de NFe @Leivio Fontenele, consegue fazer uma teste para validar ? Não sei se é meu ambiente, mas na geração do XML o valor de "URI" da tag "Reference" fica em branco conforme exemplo que estou enviando (E_Reinf_Soap-15045_111.xml). É a única diferença perante o seu exemplo (E_Reinf_Soap-175429_9.xml) que indicou que funcionou. ACBrReinfD7.rar

Ok @Juliomar Marchetti Utilizo D7 ainda, fiz com os ifdefs para não atropelar o original do @Leivio Fontenele, mas está bem simples para tirar.

Boa tarde @Leivio Fontenele e @Juliomar Marchetti, Compatibilizei o fonte com o Delphi 7 para iniciar o desenvolvimento e testes aqui no sistema. Falta testar a transmissão porque estou sem certificado no momento. 1. Mantidos os códigos originais utilizando {$IFDEF COMPILER14_UP}; 2. Criadas classes com TObjectList, no padrão do ACBr, para suprir as situações das listas com Generics; 3. No ACBrReinfWebServices, não encontrei alternativa ainda para o ISO8601ToDate. Para o UTF8ToString, utilizei o UTF8ToAnsi; Abraççç, ACBrReinfD7UP.rar