Allan Wolski

Boa tarde. A modificação realizada pelo @Italo Jurisato Junior na revisão 12405 do SVN causou um efeito inesperado em nossos sistemas, fazendo com que o XML dos eventos rejeitados fiquem em branco, não gravando as informações corretamente no banco de dados. O problema ocorre porque independente do retorno eu envio o XML para o banco de dados, e a partir dele eu extraio as informações para os respectivos campos da tabela. Não considero esta modificação um erro, pois deve ter sido prevista pelo Italo, portanto gostaria de saber o que motivou esse ajuste, visto que o XML deve sempre ser retornado para à aplicação, mesmo em casos de rejeição. Att. Allan

Pesquisando mais um pouco encontrei no stackoverflow um relato do mesmo problema com Python. Mais uma vez a solução está relacionada ao flag XMLSEC_NO_SIZE_T, porém não faço ideia se isso pode ser passado através de alguma função para a DLL ou se seria apenas uma diretiva de compilação. http://stackoverflow.com/questions/13071246/xmlsec1-sign-works-on-command-line-but-fails-on-python-code https://github.com/aricaldeira/pyxmlsec Acredito que esta bandeira precisa ser desativada pra compilação das DLL. Avancei um pouco nos meus testes, conseguindo preencher a tag <DigestValue>, porém o <SignatureValue> e <X509Certificate> ainda ficam em branco. <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#ID2102104116071066568600019355000000000530100015312701"> <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/2000/09/xmldsig#sha1"/> <DigestValue>yvhVfl3NaLjH6hKThpde0bTN3nw=</DigestValue> </Reference> </SignedInfo> <SignatureValue/> <KeyInfo> <X509Data> <X509Certificate/> </X509Data> </KeyInfo> </Signature> Pra este teste eu criei um projeto novo e chamei os métodos do XMLSec diretamente, sem passar pelo ACBr. Além disso carreguei o certificado com xmlSecCryptoAppKeyLoad ao invés de xmlSecCryptoAppKeyLoadMemory. Aguardo resultado dos seus testes Daniel e demais colegas. Att.

Outro detalhe importante, pelo menos em Delphi, seriam os Pointer operations: http://docwiki.embarcadero.com/RADStudio/Berlin/en/Converting_32-bit_Delphi_Applications_to_64-bit_Windows http://docwiki.embarcadero.com/RADStudio/Berlin/en/64-bit_Windows_Data_Types_Compared_to_32-bit_Windows_Data_Types Segue cópia dos meus fontes modificados com base nas alterações propostas pelo André. ACBr x64.zip

Boa tarde, André. Testei conforme sua orientação, porém sem sucesso. Se tiver mais alguma sugestão, pode falar que eu testo aqui. Att.

Boa tarde. Em testes realizados com os fontes do André Medeiros no Delphi 10.1 Berlin em ambiente x64, consegui passar pela assinatura modificando os tipos Cardinal para UInt64 e LongInt para Int64. {$IFNDEF FPC} {$IFDEF CPU64} ValUInt = UInt64; SizeInt = Int64; {$ELSE} ValUInt = Cardinal; SizeInt = LongInt; {$ENDIF} PSizeInt = ^SizeInt; TLibHandle = THandle; {$ENDIF} Porém o XML não é assinado corretamente, ficando com as tags DigestValue, SignatureValue e X509Certificate em branco. Pesquisando sobre o assunto encontrei alguns links interessantes, que podem fazer mais sentido para vocês que conhecem bem o Linux. https://www.aleksey.com/pipermail/xmlsec/2007/008005.html https://www.mail-archive.com/[email protected]/msg04837.html http://www.forum.hr/showthread.php?p=43283545 Basicamente xmlSecSize deve ser um "unsigned int" definido com 4 bytes, porém não obtive sucesso nos meus testes. Se precisar de algo estou a disposição. Att.

Eu que agradeço pela atenção, Daniel.

Boa tarde. Atualmente existe uma verificação no TACBrECF.FechaCupom que limita a observação do rodapé em no máximo 8 linhas. { Todos ECFs suportam no máximo 8 Linhas no Rodapé. Ajusta se necessário, para evitar erro na Impressão, no caso de mais linhas serem enviadas } Observacao:= AjustaLinhas(Observacao, Colunas, 8); Gostaria de saber se essa limitação faz-se necessário também quando utilizado o modelo ecfECFVirtual? Adicionei uma condição para limitar a observação somente se o modelo for diferente de ecfECFVirtual. Segue fonte alterado para análise. Obrigado. ACBrECF.pas

Atribuir o conteúdo do arquivo nesta propriedade em run-time não é viável, pois ter todo o conteúdo do fr3 no meio do código fonte dificulta a manutenção. E para trabalhar passando apenas a localização do fr3 também não é viável, pois precisa ficar disponibilizando e atualizando o arquivo para todos os clientes. A vantagem deste formato que sugeri é que o fr3 ficará embutido no dfm, facilitando a manutenção e dispensando a necessidade de distribuição do arquivo junto com o executável, além de compatibilizar melhor a propriedade com sua finalidade, visto que ambos os formatos são aceitos. Além disso esta alteração não vai impossibilitar de se trabalhar com o formato atual, pois basta colar o diretório do arquivo na propriedade FastFile caso seja optado pela atribuição em modo design. Para quem já faz a atribuição em run-time não vai afetar em nada. Peço que reavalie minha proposta. Obrigado.

Boa tarde, Juliomar. Segue ACBrNFeDANFEFRReg.pas com as modificações propostas. É necessário reinstalar o componente ACBrNFeDANFEFR para que as alterações tenham efeito. Obrigado. ACBrNFeDANFEFRReg.pas

De acordo. Obrigado Daniel.

Juliomar, acredito que não seria o caso de eu instalar o Lazarus aqui, visto que o problema ocorre nos fontes do ACBrECF, e não na aplicação demo. De qualquer forma, acredito que os passos para reprodução do problema no Demo ECFTeste do Lazarus serão os mesmos que descrevi para o Delphi.

Boa tarde, Daniel Infelizmente não tenho o Lazarus instalado aqui e nem mesmo conhecimento sobre a IDE. Para reproduzir o problema no Demo ECFTeste do Delphi, basta atribuir as propriedades conforme mencionei e executar a aplicação. ACBrECF1.Modelo = ecfECFVirtual ACBrECF1.ECFVirtual = ACBrECFVirtualNaoFiscal1 O exception é disparado na procedure TACBrECF.SetModelo devido fsECFVirtual ser = nil quando o componente é inicializado com o modelo ecfECFVirtual. if (AValue = ecfECFVirtual) and (not Assigned( fsECFVirtual) ) then raise EACBrECFErro.Create( ACBrStr(cACBrECFSemECFVirtualException)); Lembrando que o problema ocorre apenas quando o modelo ecfECFVirtual é atribuído em modo design. O exception é lançado já na inicialização da aplicação.

Bom dia, Juliomar. Sim, até encontrei algumas postagens onde foi mencionado que era necessário atribuir essas propriedades em tempo de execução, pois em modo design disparavam um erro ao tentar localizar os arquivos fr3. Porém isso deve ter sido resolvido, pois estou utilizando normalmente aqui. Apenas tive que realizar as alterações na unit ACBrNFeDANFEFRReg.pas conforme mencionei anteriormente. Obrigado pela atenção.

Bom dia. Gostaria de propor uma alteração na unit ACBrNFeDANFEFRReg.pas para não inicializar as propriedades FastFile e FastFileEvento como OpenDialog, pois além dos diretórios para os arquivos *.fr3, podemos configurar diretamente o conteúdo dos mesmos nestas propriedades. Na function TACBrNFeDANFEFR.PrepareReport e PrepareReportEvento existe o tratamento adequado para o conteúdo destas propriedades, porém para funcionar corretamente tive que inicializa-las como texto e carregar o conteúdo dos arquivos fr3 através da opção "Import From Text File" do editor do Delphi. Obrigado.

Bom dia, Daniel Também recebo este exception no demo do ACBrECF ao inicializar a aplicação com as propriedades definidas em modo design. Modelo: ecfECFVirtual ECFVirtual: ACBrECFVirtualNaoFiscal1 --------------------------- Application Error --------------------------- Exception EReadError in module ECFTeste.exe at 0001F043. Error reading ACBrECF1.Modelo: ACBrECF.ECFVirtual não foi atribuido. --------------------------- OK --------------------------- Se configurar em tempo de execução funciona corretamente.

Eu que agradeço pela atenção.

Esse ajuste resolve o problema do Consumidor estar aparecendo 2x. Já dei um revert na unit ACBrECFVirtual.pas.

As modificações em TACBrECFVirtualBufferClass.AbreCupom são para que o Cabeçalho dos Itens (Qtd, descrição, valor, etc) não seja impresso antes da identificação do consumidor no cabeçalho do cupom, conforme demonstrado nos exemplos em anexo. Qual flag você se refere para evitar a impressão repetida do Consumidor? Devo tratar isso na minha aplicação ou seria um flag interno do ACBr? Obrigado.

Daniel, realizei um novo ajuste no código, pois as alterações anteriores estavam afetando outros documentos, como Relatório Gerencial por exemplo. ACBrECFVirtualBuffer.pas

Bom dia, Daniel. Segue fontes alterados para análise. Além das alterações mencionadas, adicionei uma linha simples após o Cabeçalho dos Itens e antes do SubtotalizaCupom. Segue imagem do Cupom com as alterações realizadas. Obrigado. ACBrECFVirtualBuffer.pas ACBrECFVirtual.pas

A identificação do consumidor entre o cabeçalho dos itens e os itens do cupom; e a identificação repetida do consumidor no rodapé do cupom. Acho que deveria ser igual quando utilizado o modelo ecfNaoFiscal, onde o consumidor é identificado apenas no cabeçalho do cupom e o cabeçalho dos itens é impresso após a identificação do consumidor. Desde já agradeço pela atenção Daniel.

Certo, mas estaria correto estas diferenças? Pois o cupom ficou um pouco estranho assim...

Boa tarde. Estou atualizando minha aplicação para utilizar o ACBrECFVirtualNaoFiscal, porém o comprovante impresso está apresentando algumas divergências com relação ao ecfNaoFiscal, como por exemplo: - Consumidor é impresso duas vezes; - Cabeçalho do item é impresso antes do Consumidor; Para facilitar, estou encaminhando dois modelos em anexo. Obrigado.

Boa tarde, Italo Realmente essa rotina estava errada. Já realizei os ajustes necessários. Obrigado pelas dicas. Att

Boa tarde, Italo Não sei exatamente qual rotina está com problema. Eu gero o XML da seguinte forma: ACBrNFe.NotasFiscais.Clear; ACBrNFe.NotasFiscais.LoadFromString(XML); //NFeProc case dm3.nfeCOD_STATUS.AsInteger of 101: ACBrNFe.NotasFiscais.Items[0].NFe.procNFe.nProt := dm3.nfeNUM_PROTOCOLO_CANCELAMENTO.AsString; 102: ACBrNFe.NotasFiscais.Items[0].NFe.procNFe.nProt := dm3.nfeNUM_PROTOCOLO_INUTILIZACAO.AsString; else ACBrNFe.NotasFiscais.Items[0].NFe.procNFe.nProt:= dm3.nfePROTOCOLO.AsString; end; ACBrNFe.NotasFiscais.Items[0].NFe.procNFe.cStat := dm3.nfeCOD_STATUS.AsInteger; ACBrNFe.NotasFiscais.Items[0].NFe.procNFe.chNFe := dm3.nfeCHAVE_ACESSO.AsString; ACBrNFe.NotasFiscais.Items[0].NFe.procNFe.verAplic:= RetornarConteudoEntre(dm3.nfeXML_PROTNFE.AsString, '<verAplic>', '</verAplic>'); ACBrNFe.NotasFiscais.Items[0].NFe.procNFe.xMotivo := dm3.nfeRESPOSTA_SEFAZ.AsString; ACBrNFe.NotasFiscais.Items[0].NFe.procNFe.digVal := RetornarConteudoEntre(dm3.nfeXML_PROTNFE.AsString, '<digVal>', '</digVal>'); ACBrNFe.NotasFiscais.Items[0].NFe.procNFe.dhRecbto:= dm3.nfeDATA_PROCESSAMENTO.AsDateTime; ACBrNFe.NotasFiscais.Validar; ACBrNFe.NotasFiscais.GravarXML(sLocalGravacao); Aparentemente seria a TACBrDFe.Gravar, mas debugando este código não chega nesta rotina. Estou migrando agora para o Trunk2, e o estranho é que funcionava perfeitamente no Trunk1.