Allan Wolski

O XML fica com caracteres inválidos, igual o exemplo enviado na outra postagem que motivou estas alterações. Para gravar corretamente no banco de dados eu uso a função ConverteXMLtoNativeString, porém ela remove a declaração do XML. A codificação fica correta utilizando a função DecodeToString sem remover a declaração do XML.

Bom dia, @Daniel Simoes Com este ajuste os valores são carregados corretamente nas propriedades do componente, porém ainda é necessário converter o XML para gravar no banco de dados. Pensei em usar a função DecodeToString ao invés do ParseText para setar a variável StrDecod. StrDecod := DecodeToString(UnZip(DecodeBase64(StrAux)), True); O que você acha Daniel?

Boa tarde! Estamos enfrentando o mesmo problema aqui na empresa após atualização dos fontes do ACBr. O XML fica inválido devido a função ParseText substituir entidades de referência pelo seu respectivo operador, como por exemplo &lt; para <. A motivação desta alteração pode ser visualizada na postagem abaixo. Não sei qual seria a melhor opção neste caso. Talvez o @Daniel Simoes possa nos auxiliar.

Bom dia, @Juliana Tamizou Foi possível analisar as alterações propostas?

Segue correção para carregar o logotipo do DACTe em FastReport a partir de um Stream. DACTE_Ve300.fr3 DACTE.fr3 DACTE_OS.fr3

Ok, fico no aguardo.

Bom dia. Foi possível analisar as alterações propostas?

Bom dia. A função Split é utilizada também nas impressões em FR de CT-e e MDF-e, causando o mesmo problema relatado aqui ao compilar em 64 bits. Para facilitar a manutenção, movi a função para o ACBrUtil.pas, juntamente com o tipo TSplitResult retornado pela mesma. Como sugestão para remover Hints e Warnings, aposentei as funções SubstrCount e Explode nas units modificadas, além da função CollateBr na unit ACBrGNREGuiaFRDM, as quais não são utilizadas. Segue fontes modificados para avaliação. Testado no Delphi 7 e 10.1 Berlin. Fontes.zip

Após reinstalar e recompilar os componentes, a assinatura passou a ser gerada corretamente, mesmo sem setar a propriedade GerarTagAssinatura. Portanto peço que desconsidere o pedido para reverter a alteração para read-only. Obrigado.

Boa tarde. Na revisão 14673, a propriedade GerarTagAssinatura foi alterada para somente leitura, causando erro de compilação em uma aplicação que gera o XML da NF-e com base no HTML da página de consulta pública do portal nacional da NF-e. Esta propriedade era setada com o valor "taSempre". Não encontrei no log um motivo específico para esta propriedade ter sido alterada para read-only, e a meu ver não traria nenhum problema se ela voltasse a poder ser escrita. É possível reverter esta alteração? Obrigado.

Boa tarde, @Felipe l. O site https://www.ixml.com.br possui uma API para consulta de NF-e, NFC-e, CT-e, CNPJ e Simples Nacional, sem a necessidade de digitação do Captcha. A consulta é extremamente rápida e retorna o XML pronto pra uso, conforme sua necessidade. O serviço é pago, porém o custo é baixo se comparado com as demais soluções que temos no mercado. Além disso existe um plano gratuito com limite de 15 consultas mensais.

Boa tarde. Pra quem tiver interesse, o https://www.ixml.com.br possui uma API para consulta de NF-e, CT-e, CNPJ e Simples Nacional, sem a necessidade de digitação do Captcha. O serviço é pago, porém o custo é baixo se comparado com as demais soluções que temos no mercado. Além disso existe um plano gratuito com limite de 15 consultas mensais.

Obrigado pela explicação, Italo. Vou analisar aqui como proceder neste caso, pois como a aplicação deve trabalhar com todas as versões do CT-e, não será possível utilizar a diretiva de compilação. De qualquer forma foi muito esclarecedor e mais uma vez agradeço pela atenção. Att.

Boa tarde, Italo. Esta situação que mencionei não é para emissão de CT-e na versão 1.04, mas apenas para "gerar" um XML com base nas informações alimentadas no componente. Temos um sistema que recupera os XMLs através da consulta via Chave de Acesso no portal da Sefaz. Att.

Boa tarde. Uma modificação recente na unit pcteCTeW.pas removeu a geração das Informações de Seguro da Carga (infCTeNorm.seg) para CT-es emitidos na versão 1.04. Estas informações estão previstas no manual de orientações do contribuinte desta versão. if CTe.infCTe.versao = 2 then GerarInfSeg; Seria possível remover esta condição? No aguardo. Att. Allan

Daniel, obrigado pelo retorno rápido. O cenário é o seguinte: - Serviço do Windows para Pesquisa e Manifestação do Destinatário com agendamentos. - O Certificado é carregado diretamente do banco de dados através da propriedade DadosPFX. - Até então utilizava OpenSSL, porém recebia muitos erros de conexão com o WS. WebService Distribuição de DFe: - Inativo ou Inoperante tente novamente. Erro Interno: 0 Erro HTTP: 403 WebService Distribuição de DFe: - Inativo ou Inoperante tente novamente. Erro Interno: 10091 Erro HTTP: 0 WebService Distribuição de DFe: - Inativo ou Inoperante tente novamente. Erro Interno: 10091 Erro HTTP: 500 WebService Distribuição de DFe: - Inativo ou Inoperante tente novamente. Erro Interno: 11001 Erro HTTP: 500 WebService Distribuição de DFe: - Inativo ou Inoperante tente novamente. Erro Interno: 10091 Erro HTTP: 0 Com a libWinCrypt não recebo nenhum desses erros, porém encontrei o problema mencionado acima com a assinatura dos eventos.

Bom dia. Quando defino a propriedade SSLLib com a opção libWinCrypt, recebo o seguinte erro ao assinar o XML: Falha ao assinar o Envio de Evento Falha ao obter a Chave Privada do Certificado para Assinatura. O erro é disparado na unit ACBrDFeXsMsXml.pas, linha 166: dsigKey := Nil; xmldsig.setStoreHandle( PCCERT_CONTEXT(FpDFeSSL.CertContextWinApi)^.hCertStore ); xmldsig.createKeyFromCertContext( FpDFeSSL.CertContextWinApi, dsigKey); {GetProviderInfo( PCCERT_CONTEXT(FpDFeSSL.CertContextWinApi), ProviderType, ProviderName, ContainerName); dsigKey := xmldsig.createKeyFromCSP( ProviderType, WideString(ProviderName), WideString(ContainerName), 0);} if (dsigKey = nil) then raise EACBrDFeException.Create('Falha ao obter a Chave Privada do Certificado para Assinatura.'); Provisoriamente estou utilizando: SSLLib := libWinCrypt; SSLXmlSignLib := xsXmlSec; Obs.: O erro ocorre com certificados modelo A1 emitidos pela AC VALID RFB e AC BOA VISTA CERTIFICADORA.

O problema do instalador resolvi instalando o ACBr manualmente. Com relação à unit ACBr_WinHttp, ainda não precisei recompilar em 64bits, portanto o erro persiste.

Boa tarde, Juliomar. Desculpa, mas não entendi exatamente o que quis dizer com "não está funcionando o ACBr 100% no delphi". Antes desta atualização já compilava o projeto em 64 bits sem problemas. Utilizo o ACBr neste projeto apenas para consumir o WS DistribuicaoDFe.

Instalando o ACBr manualmente, recebo erro ao compilar a unit ACBr_WinHttp.pas em 64bits. {$IFNDEF FPC} {$IFDEF CPU64} PtrUInt = QWord; {$ELSE} PtrUInt = DWord; {$ENDIF} DWORD_PTR = PtrUInt; USHORT = word; {$ENDIF} O tipo QWord não é reconhecido pelo Delphi.

Boa tarde. Após atualizar meu repositório do Trunk2 da revisão 12756 para a 13162, não estou conseguindo instalar o ACBr com o ACBrInstall_Trunk2.exe. Sempre recebo o erro: Compilation failure Erro ao compilar o pacote "ACBr_synapse.dpk". Segue log em anexo. log_Delphi_10.1_Berlin.txt Efetuando uma instalação manual, todos os packages são compilados e instalados sem erros.

Marcos, para compilação em 32 bits não há necessidade de alteração alguma. Pode continuar utilizando da forma como vinha fazendo. Para compilação em 64 bits o ACBr irá definir a diretiva USE_MINGW automaticamente.

Que ótima notícia, Daniel. Testei no Windows com Delphi 10.1 Berlin e consegui assinar o XML com sucesso. Compilando em 32 bits tudo continua funcionando normalmente também. Muito obrigado Daniel e os demais colegas que contribuíram para este resultado. Att.

Instalei o Microsoft Build Tools 2015 e recompilei a DLL, porém mesmo depois de muitas tentativas ainda não tenho uma versão funcional da XMLSec em 64 bits. O maior problema são os erros de compilação e as várias dependências que a DLL possui. Enviei um e-mail ao responsável pelos binários do Libxml e a resposta foi curta e direta.

Bom dia, Italo. É exatamente desta forma que resgato o XML do evento (*-procEventoNFe.xml), acessando a propriedade XML. ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[x].RetInfEvento.XML; O Problema com a propriedade RetWS é que a mesma não pode ser acessada individualmente. Não poderia manter o comportamento do componente como era antes, deixando que a aplicação resolva como deve tratar as situações de rejeição? Estaria seguindo o mesmo princípio do WebService da Sefaz, onde mesmo o evento sendo rejeitado, temos o XML com o motivo da rejeição. Obrigado. Att.