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.

Boa tarde pessoal! Estou fora do tempo planejado mas com os testes realizados. Atualizamos os nossos fontes e o evento criado na geração do registro C170 atende perfeitamente nossas necessidades. Utilizando o campo "COD_ENQ" para indicar quando o produto é tributado por quantidade e, no evento, limpando o campo e ajustando o campo da alíquota. Vou marcar a interação do Isaque como resposta e acredito que podemos concluir este assunto, pelo menos até a SEFAZ dar uma finalidade para o campo "COD_ENQ". Peço desculpas pela demora entre as interações e agradeço o apoio da comunidade!

Boa tarde Pessoal, Adotamos aqui na empresa a geração do DANFE da NF-e utilizando o componente do ACBr com o Fortes Report e, após alguns testes, detectamos algumas modificações que seriam necessárias para atender nossos clientes. Visando contribuir com a comunidade, realizamos as modificações de forma a não impactar o funcionamento atual do DANFE, para que seja possível integrar as modificações nos fontes do ACBr, se os moderadores acharem as modificações adequadas. Vou listar abaixo então todas as modificações que realizamos com exemplos e imagens, quando possível: 1. Ajuste na impressão do título das faturas no DANFE em formato paisagem para que o mesmo não saia cortado Modificamos a rotina que calculava o tamanho da banda de duplicatas para definir um tamanho mínimo. Desta forma, o título da banda sempre é impresso de forma completa. Para não deixar a banda com muito espaço em branco, alinhamos os campos do detalhe para o centro da banda. Imagem da versão atual: Imagem da nova versão: 2. Criação de um grupo específico para a impressão da forma de pagamento da NF-e Esta modificação foi realizada pois no DANFE que nossos clientes utilizam hoje, a forma de pagamento sempre é impressa, independente do seu tipo e da existência de duplicatas na NF-e. Como o ACBr só imprimia a forma quando não existiam duplicatas, criamos uma nova propriedade no componente “ACBrNFeDANFeRL” chamada “SempreImprimirIndPag” que, quando for verdadeira, fará com que a forma seja impressa sempre. O valor padrão desta nova propriedade é “False”, para não alterar o funcionamento do componente para as empresas que já o utilizam hoje. Exemplo de DANFE com forma de pagamento e débitos em formato retrato: Exemplo de DANFE com forma de pagamento e débitos em formato paisagem: 3. Impressão de duplicatas na forma de pagamento “Outros” Novamente, atendendo uma funcionalidade que nossos clientes já possuem, modificamos a geração do DANFE para que o componente imprima as duplicatas no DANFE quando o campo “IndPag” for igual a “Outros”. Para isto, criamos uma nova propriedade no componente “ACBrNFeDANFeRL” chamada “SempreImprimirDup”. O valor padrão desta nova propriedade é “False”, para não alterar o funcionamento do componente para as empresas que já o utilizam hoje. 4. Remoção dos Warnings e Hints do compilador sobre variáveis declaradas mas não utilizadas Esta modificação foi realizada apenas para deixar o código mais “limpo”. Como os avisos eram de variáveis declaradas e não utilizadas, não vou postar aqui todas as linhas que foram alteradas. Se alguém quiser conferir, pode baixar os fontes e executar uma ferramenta de verificação de diferenças. 5. Otimização da rotina de geração das duplicatas Esta modificação foi possível porque adicionamos a banda específica para a apresentação da forma de pagamento. Conseguimos mover o loop que o componente fazia no começo da geração das duplicadas para o IF de geração delas, acelerando assim a impressão do DANFE quando a nota não possui duplicatas. Não testamos estas modificações no Lazarus porque não o temos instalado aqui, mas se ninguém conseguir testar estas modificações para nós, posso preparar uma VM e testar as modificações também. Se precisamos adaptar alguma coisa para que as modificações sejam incluídas no fonte do componente, estamos abertos a sugestões. Anexamos abaixo junto com os fontes, os arquivos XML que utilizamos para testar as modificações, assim quem quiser baixar e verificar como as modificações ficaram, pode fazê-lo de forma mais rápida. Arquivos XML.zip Fontes modificados.zip Arquivos XML.zip Fontes modificados.zip

Bom dia Isaque! Desculpe a demora em atualizar este ticket, infelizmente estamos sempre correndo atrás do relógio... Vou baixar os fontes que você postou no tópico indicado pelo Elton e acredito que até o final do mês consigo lhe dar um retorno sobre meus testes.

Bom dia Isaque! No caso do IPI não temos como afirmar que ele é o responsável pela definição do tipo de cálculo do imposto, pois na minha visão a CST "50 - Saída tributada" pode ser utilizada tanto em produtos tributados por alíquota Ad Valorem como para produtos tributados à uma alíquota específica. Nestes últimos dias li novamente a documentação da TIPI disponível no site da Receita Federal (Link) e, pelo o que entendi, todos os produtos que possuem o gênero "22" ou o NCM "2105.00" e não possuem um código de exceção "EX" devem ser tributados por alíquota específica. Sabendo disto, se conseguirmos vincular o registro C170 ao registro 0200 do produto, podemos realizar esta validação dentro do método "WriteRegistroC170" para definir se o campo da alíquota deve ser preenchido ou não.

Boa tarde Elton! Vi a alteração que o Isaque realizou no tópico que você mencionou e, depois de pesquisar na documentação do SPED Fiscal, acredito que esta solução não poderia ser aplicada neste caso. Tentei encontrar algum campo no registro C170 ou nos "pais" dele que nos indicasse a forma de tributação do IPI, mas não consegui identificar uma forma clara. Existe um campo no registro C170 chamado de "COD_ENQ", onde se deve informar o código de enquadramento do IPI, mas como a tabela de códigos ainda não foi disponibilizada pela Sefaz, não temos como saber se este campo serviria para diferenciar um produto tributado por percentual de um tributado por unidade comercializada. Não sei se outras pessoas/empresas também estão passando por este problema e como o estão resolvendo. Gostaria de escutar outras opiniões sobre este assunto para tentarmos encontrar uma solução que atenda a todos.

Pessoal, Analisei as duas opções de eventos que poderiam ser incluídas no registro C170 do SPED Fiscal e, apesar das duas resolverem o problema, acredito que não são a melhor solução, pois irão deixar a geração do arquivo de exportação do SPED Fiscal mais lenta. Explicação: Hoje, tanto o evento que já existe para o registro C170 "procedure(var ALinha: AnsiString)" como o registro criado pelo Isaque para o SPED Contribuições "procedure(var ANullVL_BC_PIS, ANullALIQ_PIS, ANullQUANT_BC_PIS, ANullALIQ_PIS_QUANT, ANullVL_PIS: Boolean)" não são "saudáveis" para a geração do arquivo pois não há uma forma de identificar se o campo da alíquota de IPI deve ser enviada na própria linha, tendo o evento de consultar o banco de dados da aplicação para verificar a configuração do produto na nota que está sendo exportada para decidir como enviar o campo. Isto significa que, caso eu possua 10 notas e cada nota possua uma média de 7 produtos, são 70 consultas adicionais ao banco de dados apenas para gerar o registro C170! Isto em uma configuração TCP/IP local ou pela Internet irá deixar a geração do arquivo muito mais lenta, independente da tecnologia utilizada. Gostaria de verificar com vocês então se existe a possibilidade de analisarmos uma alteração na classe para que cada registro possa ter a sua configuração, indicando se os campos devem ser gerados nulos ou com zeros. Exemplo: A cada "RegistroC170New" se definiria as variáveis que são definidas no evento "OnBeforeWriteRegistroC481" criado pelo Isaque e, na hora de geração do registro no arquivo, a classe iria validar as variáveis do próprio registro, e não do evento, tornando assim cada linha independente. Peço desculpas se minha explicação ficou confusa. Se precisar, posso tentar explicar de uma outra forma a minha análise.

Bom dia Elton! Na verdade eu é que devo pedir desculpas agora. Não recebi o e-mail do fórum avisando que o tópico havia sido respondido e acabei não lendo a sua interação antes. Dei uma olhada por cima no evento criado pelo Isaque e acredito que ele irá resolver sim o problema deste registro e dos outros que precisam deste mesmo tipo de validação. Vou fazer alguns testes adaptando este evento para o registro C170 e vou postar aqui o resultado com os fontes depois, para discutirmos a inclusão destes eventos nos outros registros do componente.

Juliomar, Já conseguimos identificar alguns campos que precisam desta mesma modificação, mas como a lógica da alteração seria a mesma, focamos em apenas um deles primeiro. Me disponho a alterar os outros campos também após decidirmos qual é a melhor maneira de realizar a modificação.

Olá pessoal! Despois de ter aberto tópico em agosto do ano passado, acabei sendo recolocado em diversos outros projetos da empresa, e não consegui dar a atenção devida a ele. Voltamos agora então à questão da alíquota de IPI para produtos tributados por quantidade e não por um percentual fixo; No tópico referenciado acima, o Isaque Pinheiro havia dado a sugestão de alterarmos o método "WriteRegistroC170", de forma que o campo ALIQ_IPI chamasse a rotina "LFill()" passando o parâmetro "Nulo" como "True", para que o campo fosse enviado em branco sempre que estivesse preenchido com 0. Acontece que existem situações onde o produto é tributado por um percentual fixo, mas em uma determinada situação deve ser enviado com a alíquota 0, pois a operação é isenta de contribuição ou o produto é tributado à alíquota de 0%. Desta forma, vimos que a solução proposta não atenderia a todas as situações de escrituração do registro. Conversando com meus colegas de trabalho, chegamos a 3 modificações diferentes que poderão solucionar este problema, mas cada uma possui alguns pontos positivos e negativos que devem ser avaliados para decidirmos qual é a melhor implementação para o componente e a comunidade, ou se nenhuma das soluções propostas é a ideal e devemos voltar e analisar isto novamente. 1ª modificação sugerida: Alterar o tipo do field "fALIQ_IPI” de Currency para String Nesta modificação, o tipo do field é alterado para que passe a utilizar o overload do método “LFill” para campos texto, sendo gerado em branco sempre que o field estiver em branco. Para manter o propósito do campo, escrevemos um método “Set” para a property ALIQ_ICM que trata valores brancos e inválidos, permitindo que o field esteja apenas em dois estados (Em branco ou preenchido com uma alíquota válida). Ponto positivo: Esta modificação é a que menos causa impactos no componente, pois apenas duas units são alteradas e as alterações são "cirúrgicas", não influenciando no comportamento do componente; Ponto negativo: O principal ponto negativo desta modificação é que, ao realizarmos esta alteração, o componente irá parar de funcionar para quem já gera o SPED Fiscal hoje, até que a equipe de desenvolvimento da empresa possa atualizar a rotina de geração do registro C170 e alterar o campo de Currency para String; 2ª modificação sugerida: Alterar o tipo do field “fALIQ_IPI” de Currency para Variant Esta modificação é muito parecida com a sugerida acima, alterando o tipo do field para que se possa utilizar o método “LFill” para strings e validar quando o mesmo estiver em branco, mas com a grande vantagem de não alterar o funcionamento externo do componente nos projetos da comunidade. Ponto positivo: Quem já está utilizando a classe não terá de modificar o seu código fonte após atualizar o componente. O registro continuará sendo gerado da maneira correta; Ponto negativo: Um ponto negativo que levantamos para esta modificação é a compatibilidade do tipo "Variant" com usuários do Kilyx. Como nunca utilizamos, não temos como garantir aqui o funcionamento correto desta. 3ª modificação sugerida: Criar um novo field na classe "TRegistroC170" para controlar o campo “ALIQ_IPI” Esta modificação prevê a criação de um novo field na classe para que o usuário possa indicar se um determinado produto tem o IPI tributado por uma alíquota específica ou por quantidade vendida. Desta forma, podemos criar uma validação específica dentro do método "WriteRegistroC170" para gravar 0 ou vazio neste campo do layout conforme a configuração deste novo campo. Ponto positivo: Com esta modificação, podemos garantir que o funcionamento do componente não será modificado para nenhum usuário, independente da plataforma utilizada. Ponto negativo: Não conseguimos encontrar algo que invalidasse esta sugestão, pois a criação de um novo field para controlar esta situação garante o isolamento da modificação. E estas são as sugestões que conseguimos elaborar aqui na empresa para solucionar este problema. Anexo abaixo estão os fontes com as duas primeiras modificações implementadas, para que vocês possam baixa-las e verem como funcionam na prática. Acredito que até o final da semana conseguirei criar um exemplo da 3ª sugestão para avaliarem. Novamente peço desculpas pelo tamanho que este post acabou ficando e agradeço a quem puder auxiliar! Edição: Já consegui montar um exemplo da implementação da 3ª sugestão no componente, anexo abaixo; 1ª modificação sugerida.zip 2ª modificação sugerida.zip 3ª modificação sugerida.zip

Isaque, Vou realizar esta alteração no método do registro C170 e, se tudo estiver funcionando, posto os fontes aqui amanhã para vocês possam analisar como ficou. Obrigado pelo retorno!