Lucas Rutkoski

Rafael, Posso afirmar a colocação do André de que o ACBr não altera o logradouro do destinatário/remetente do documento durante o processo de emissão. Você já tentou capturar o arquivo antes de carrega-lo no componente para ver como está o endereço?

igcastro, Este erro acontece porque os pacotes BDE não vem inclusos na instalação padrão do Delphi XE7. Você precisa verificar na página do seu produto no site da Embarcadero se está disponível o pacote BDE para a sua versão do Delphi, seja ela Professional, Enterprise ou Architect. Sem estes pacotes, o DANFE em QuickReport do ACBr não irá funcionar.

Boa tarde! Pessoal, fui atualizar a minha base de testes do ACBr hoje para fazer um merge com a versão que utilizamos aqui na empresa e identifiquei que as modificações presentes neste tópico não foram incluídas no versionamento do DANFE em FortesReport. Vocês tem alguma posição atualizada sobre estas modificações, se serão incluídas ou não? Abraço!

Régys, entendo a sua posição. Estávamos lendo o XML o programa que está esperando o retorno não é o mesmo que realiza a consulta, mas conseguimos alterar o funcionamento do nosso software e resolver o problema. Obrigado!

Desculpem a demora para atualizar este tópico... Régys, fiz alguns testes e o CNPJ agora vem corretamente da consulta. Alteramos nossa forma de consumir os dados e tudo está funcionando. Obrigado pela ajuda!

Régys, Segue anexo abaixo os arquivos de retorno da SEFAZ de uma consulta de cadastro com caracteres especiais na razão social da empresa. Arquivos XML - Caracteres especiais.zip

Régys, Se você realizar a consulta utilizando o CNPJ "00853587000181" e a UF "RS", terá os retornos anexos abaixo. Nos arquivos, conseguirá verificar que o arquivo de requisição gerado pelo ACBr possui os zeros à esquerda, mas o arquivo de resposta da SEFAZ não. Arquivos xml.zip

Boa tarde! Estávamos realizando alguns testes e descobrimos que em alguns casos a SEFAZ não está devolvendo um arquivo XML válido no retorno de um WebService. Realizamos um teste no WebService de consulta de cadastro de contribuintes e, no arquivo de retorno, a razão social da empresa veio com um caractere especial ("&"). Como a unit que recebe e salva o retorno do WebService não está tratando o arquivo, o XML de retorno acaba ficando "inválido", pois nem um navegador de internet consegue realizar a sua leitura. Tentamos resolver este problema utilizando a rotina "FiltrarTextoXML" que existe hoje dentro da unit "pcnAuxiliar", mas ela acaba substituindo os caracteres "<" e ">" da estrutura do XML também, o que invalida o arquivo de retorno do mesmo jeito. Queria então verificar com vocês se alguém já passou por esse problema e como resolveu, ou então como podemos fazer para solucionar este problema de forma global, pois acredito que os outros arquivos devolvidos pela SEFAZ também podem estar com o mesmo problema.

Pessoal, Alguém conseguiu analisar esta modificação? Ou então, podem nos dar um retorno se a mesma não será implementada no SVN para criarmos um fork interno dos componentes?

Olá pessoal, Estávamos testando o WebService de consulta de cadastrados pelo ACBr e vimos que, quando o CPF/CNPJ possui zeros a esquerda, a SEFAZ está devolvendo o número sem os zeros à esquerda, o que faz com que o arquivo XML salvo pelo componente fique com um número diferente do consultado. Modificamos então a unit “ACBrNFeWebServices.pas” e criamos um método que normaliza estes dois campos após receber o retorno da SEFAZ, facilitando a utilização do arquivo XML pelo programa que realizou a consulta. Vou postar o fonte que alteramos abaixo, para vocês analisarem se é viável implementar esta modificação nos fontes do SVN. Para testarem este erro, podem utilizar os dados abaixo: CNPJ: 00.905.849/0002-95 UF: RS Abraço! ACBrNFeWebServices.zip ACBrNFeWebServices.zip

Pessoal, Estava realizando alguns testes no DANFE de eventos em fortes e notei que ele estava imprimindo apenas o código de retorno do evento, e não a descrição. Debugando o código, vi que na rotina "Executar" da classe "TNFeEnvEvento", o componente está lendo apenas o campo "cStat" do retorno, mas não o "xMotivo". Realizei a alteração no fonte para incluir a leitura deste campo e, após emitir algumas cartas de correção e alguns cancelamentos, vi que agora o processo está ok. Vou anexar o fonte do "ACBrNFeWebServices.pas" com o ajuste abaixo para analisarem se a modificação procede e a aplicarem no SVN. Abraço! ACBrNFeWebServices.zip

Juliomar, Sem pressa, na verdade agora estou mais preocupado em ter certeza de que as modificações estão funcionando corretamente no lazarus do que em subir elas para o repositório oficial.

Pessoal, Instalei em uma VM o Lazarus V1.2.4 e o Fortes Report V3.2.4 e consegui utilizar as funcionalidades que implementamos. Como nunca havia utilizado o Lazarus antes, não tenho certeza se fiz os testes corretamente, pois quando abri o lpk do DANFE, o Lazarus carregou o arquivo "dfm", então não consegui visualizar/alterar o arquivo "lrs". Minha dúvida então é: Preciso fazer alguma alteração nestes arquivos ou o Lazarus sempre irá utilizar os arquivos "dfm" para gerar o DANFE?

A impressão do qrCode se dá em qual formato de DANFE Dércio? Verifiquei a DANFE em retrato e paisagem, mas não encontrei nada referente ao código de barras. Se você está se referindo ao DANFE simplificado, assim que concluirmos as modificações nos modelos deste tópico, vamos testar o simplificado, e assim poderemos verificar o erro e tentar corrigi-lo. Boa noite Lucas. Testei a impressão só da NFe e aparentemente está tudo OK. Só aproveitando as imagens anexas, nota-se que a impressão dos textos na vertical no Fortes fica meio distorcida (o que já acontecia antes, não tendo nada a ver com as suas alterações). Eu já fiz um teste trocando a fonte desses labels para "small fonts", o que na pré-visualização até fica melhor, mas na impressão não muda nada. Alguém teria uma outra sugestão do que poderia ser feito para melhorar isso? Posso dar uma olhada nesta questão. Nós também achamos estranha a impressão destes labels. Vou realizar alguns testes e ver se encontro uma solução para este problema...

Este assunto foi resolvido neste Agora é possível utilizar um evento do Registro C170 para alterar a linha gerada pelo componente e limpar o campo da alíquota de IPI quando necessário.