-
Total de ítens
3.895 -
Registro em
-
Última visita
-
Days Won
67
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Tudo que Renato Rubinho postou
-
@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
-
Bom dia, Efetuados os testes nos fontes e estão OK. Obrigado, Renato Rubinho Analista de Sistemas http://linkedin.com.br/in/renatorubinho
-
Bom dia, Seguem mais dois ajustes (Um deles é no ECD): 1. ECF Y640, mesma situação dos itens do post anterior procedure TBloco_Y.WriteRegistroY640; LFill(COND_DECL, 1) 2. ECD K001 O validador acusa que o registro K001 é inválido para o tipo de escrituração quando Registro0000.IND_ESC_CONS = "N". Adicionado tratamento para gerá-lo apenas quando Registro0000.IND_ESC_CONS também estiver preenchido com "S". Abraççç, Renato Rubinho Analista de Sistemas http://linkedin.com.br/in/renatorubinho ACBr002.rar
-
Boa tarde, Na geração do arquivo do ECF, alguns campos inteiros estão entrando no LFill de Data, gerando a informação errada. Verifiquei neste post LFill Integer x Data que isso já ocorreu em alguns situações. Para corrigir, passei o tamanho do campo no segundo parâmetro do LFill e garantiu a utilização da função correta nos itens a seguir: 1. 0020 procedure TBloco_0.WriteRegistro0020; LFill(IND_QTE_SCP, 3) 2. Y620 procedure TBloco_Y.WriteRegistroY620; LFill(IND_RELAC, 1) LFill(PAIS, 3) 3. M010 procedure TBloco_M.WriteRegistroM010(RegM001: TRegistroM001); LFill(COD_LAN_ORIG, 6) 4. L100 procedure TBloco_L.WriteRegistroL100(RegL030: TRegistroL030); LFill(NIVEL, 3) 5. L300 procedure TBloco_L.WriteRegistroL300(RegL030: TRegistroL030); LFill(NIVEL, 3) Seguem os fontes em ACBr.rar. Renato Rubinho Analista de Sistemas http://linkedin.com.br/in/renatorubinho ACBr.rar
-
Boa tarde, Seguem ajustes no ECF. 1. ACBrECFBloco_C.pas 1.1. TRegistroC040 - NIRE: alterado para Int64, para aceitar códigos acima de 2147483647 - Create/Destroy: Criados e destruídos registros filhos C100, C150 e C350 2. ACBrECFBloco_0_Class 2.1. WriteRegistro0010; - COD_QUALIF_PJ: Formatado com LFill( , 2) 3. ACBrECFBloco_Y_Class 3.1. WriteRegistroY672 - IND_REG_APUR: Removido na versão 3 4. ACBrECFBloco_K_Class 3.1. WriteRegistroK355 - REG: gerava "k355", com a letra em minúscula Renato Rubinho Analista de Sistemas http://linkedin.com.br/in/renatorubinho ACBrECFBloco_K_Class.pas ACBrECFBloco_Y_Class.pas ACBrECFBloco_0_Class.pas ACBrECFBloco_C.pas
-
Bom dia, Testado. OK. Obrigado, Renato Rubinho Analista de Sistemas http://linkedin.com.br/in/renatorubinho
- 2 replies
-
- 1
-
- sped contabil
- ecd
-
(e 1 mais)
Tags:
-
LFD - Registros A025, B430, B440, B450 e B490
Renato Rubinho replied to Renato Rubinho's tópico in Outros (ACBrLFD, ACBrSEF2, etc)
Boa tarde, Corrigido Registro 0005, pois sobrescrevia NOMERESP fixo como "TESTE". Renato Rubinho Analista de Sistemas http://linkedin.com.br/in/renatorubinho ACBrLFDBloco_0_Class.pas -
Boa tarde, Desenvolvido Bloco_K. Obs: Atenção, pois nos manuais da v5 disponibilizados até 05/2017, os Registros K200 e K210 estão com o nível hierárquico errado. CERTO - VALIDADOR ------------------- 1:K001 2: K030 3: K100 4: K110 5: K115 3: K200 -- NIVEL 3 CERTO 4: K210 -- NIVEL 4 CERTO 3: K300 4: K310 5: K315 1:K990 ERRADO - MANUAL ---------------- 1:K001 2: K030 3: K100 4: K110 5: K115 2: K200 -- NIVEL 2 ERRADO 3: K210 -- NIVEL 3 ERRADO 3: K300 4: K310 5: K315 K990 Renato Rubinho Analista de Sistemas http://linkedin.com.br/in/renatorubinho ACBrSpedContabil.pas ACBrECDBloco_K_Class.pas ACBrECDBloco_K.pas
- 2 replies
-
- 2
-
- sped contabil
- ecd
-
(e 1 mais)
Tags:
-
LFD - Registros A025, B430, B440, B450 e B490
um tópico no fórum postou Renato Rubinho Outros (ACBrLFD, ACBrSEF2, etc)
Boa tarde, Desenvolvida geração dos Registros A025, B440, B450 e B490. Corrigido B430. ACBrLFDBloco_B_Class.pas ACBrLFDBloco_A.pas ACBrLFDBloco_A_Class.pas ACBrLFD.pas