EMBarbosa

Não vou ter tempo pra ver, mas achei muito interessante seu componente. Pelo erro, ou o arquivo dfm já possui o campo, ou o seu componente está criando os campos novamente. Então bastaria você tratar isso. Estritamente falando, os campos não existem "nela". Eles estão relacionados com ela. Então a ideia seria validar se eles já existem no form ou DM. Bom, se não tiver jeito de fazer isso automaticamente, isso explica o motivo de não ser feito nos componentes do Delphi. Mas caso contrário, se você tem o Delphi, você tem o código da VCL e assim pode verificar como é que um TDataSet implementa essa facilidade quando selecionamos "Add all Fields".

Olá Willian, Ao analisar o código eu notei as seguintes características. Precisava que você comentasse antes de a gente incluir no projeto ACBr: A unit GerarBlocos.pas está vazia e não é utilizada por nenhum arquivo. Poderia avaliar se não está faltando nada? O componente não está utilizando nenhuma das classes do ACBrTXT. Isso foi proposital? Os registros estão definidos usando Generics. Como nosso projeto atualmente suporta o Delphi 7, talvez tenhamos que alterar os tipos. Vê algum problema nisso? Por último, mas mais importante: Notei que nenhum arquivo tem a licença anotada, mas na procedure de registro está o nome de uma empresa. Você confirma que esses fontes são de sua autoria e podem ser licenciados como LGPL ou MPL, alterados e adicionados ao projeto seguindo as licenças do ACBr?

Se você abrir o arquivo no Delphi, ele costuma remover os IFDEF na cláusula uses dos arquivos DPK e DPR. Pode ser isso que aconteceu.

Daniel, Achei manuais que implementam qrCode em PPLA e PPLB. Teria que verificar se é válido e quais modelos aceitam. Abaixo um manual da PPLB que encontrei: https://downloads.genesysinf.com.br/downloads/uteis/argox/fscommand/manual/PPLB.pdf Talvez possamos colocar isso na nossa lista de afazeres. O que acha?

Então como pretende comunicar com o modem?

Nesse log não parece haver nada estranho. Você consegue reproduzir o problema no DEMO? Qual a marca e modelo da balança? Talvez seja o protocolo.

Olá, Acabei de verificar aqui e as verificações de versões estão no código do SVN. Veja nesse link: http://svn.code.sf.net/p/acbr/code/trunk2/Pacotes/Delphi/ACBrBoleto/FC/Fast/ACBr_BoletoFR.dpk E nesse também: http://svn.code.sf.net/p/acbr/code/trunk2/Pacotes/Delphi/ACBrDFe/ACBrNFe/DANFE/NFe/Fast/ACBr_NFeDanfeFR.dpk

Sim. Esses campos entram em produção nessa data mesmo.

Enviao ao SVN. Favor atualizar, testar e reportar qualquer problema. Muito obrigado.

Oi Rodrigo, Enviei a alteração ao SVN. Revisão 16978. Favor atualizar, testar e reportar qualquer problema. obrigado.

Muito obrigado. Foi pro SVN na revisão 16971. Favor atualizar, testar e reportar qualquer problema.

No momento, o componente de importação é mantido mais pela comunidade do que pelos desenvolvedores do ACBr. Se você conseguir corrigir o erro e quiser enviar uma sugestão de correção, ficamos gratos e vamos analisar. Do contrário, teremos que aguardar alguém que possa fazer isso.

Muito obrigado pela contribuição. No SVN na revisão 16970. Favor atualizar, testar e reportar qualquer problema.

Eu entendi o que você perguntou, só não entendi o que você precisa e nem o porquê você precisa. Acho difícil ser um bug. Provavelmente a lógica está mal formulada em algum ponto. O código que eu passei vai voltar o valor sempre para o anterior, mesmo que ele seja nil. Talvez não seja isso que você quer... Sugiro você partir desse código e debugar para entender o que está acontecendo.. Sim. Esse código vai dar access violation. Não compila porque defaultfilter não é string. Isso me parece código vindo de VB... Não compila porque null é Variant e defaultfilter não é variant. Se você está querendo atribuir uma referência com valor nulo, você quer o valor NIL. Então, só coloquei aquele aviso porque acho que estamos tratando do problema XY.

Mas não seria mais fácil você remover o "ponto e vírgula" na sua aplicação?

Olá Já está assim no SVN . Talvez seu arquivo estivesse desatualizado. Obrigado pelo aviso. Me parece correta a alteração em vista dos erros que você está recebendo. Mas parece que não tem mais usuários do MS com o mesmo problema. Estamos avaliando o motivo... Assim que resolvido te damos um retorno ou enviamos pro SVN.

Olá Carlos, Esse é um tópico de notícias. Peço o favor de, caso necessário, criarem tópicos de dúvidas.

Olá, A princípio, seria melhor você explicar o que deseja conseguir, o que já tentou, e o que está acontecendo para que a gente conseguisse te ajudar melhor. Vou responder sua pergunta diretamente, embora talvez isso não seja o mais indicado. Por isso esse aviso... Você precisa armazenar o valor e retornar o valor posteriormente. var oldFilter: TRLCustomPrintFilter; begin //Armazena valor atual... oldFilter := RLRcobapea.DefaultFilter; try RLRcobapea.DefaultFilter := DMSistema.Matricial; ... ...imprimir... ... finally //Retorna valor anterior... RLRcobapea.DefaultFilter := oldFilter; end;

Exatamente isso que conversamos e estamos planejando fazer. Parece que não vamos ter outra opção pois pode ser que, de agora em diante, comecem a surgir mais eventos e eles acabem tendo o mesmo código. Infelizmente, isso deve quebrar algum código...

Enviei essa alteração ao SVN. Queira por favor atualizar, testar e reportar qualquer problema. Note que ainda precisamos resolver a questão levantada no princípio das conversões.

A versão do SVN deles tem tido algum movimento. Mesmo assim, não sei se confiaria. https://sourceforge.net/p/synalist/code/HEAD/tree/trunk/

Esse problema não é no ACBr. Você pode tentar com o programa de exemplo para conferir.

Por favor, crie um tópico na área do SAC com os dados de como reproduzir e verificar o problema, como configuração utilizada, arquivo ENT para emissão e xml gerado.

A princípio, pode usar o CNPJ da empresa onde foi desenvolvido. Isso é chamado de "sistema próprio". Quer dizer, sistema desenvolvido pela própria empresa. Isso está de acordo com o que o Felipe disse acima.

Na verdade, tem muitos outros... Esse abaixo tem cerca de duas semanas: Isso depende de legislação estadual. Cada UF tem seu próprio direito de estabelecer as leis e, por isso, pode mudar de uma região para outra. Mas tem dois princípios que as UFs atendem nesse respeito: Não permitir sonegação; Não causar prejuízo ao contribuinte; Esse ponto "1. Não permitir sonegação" é o mais fácil de entender. É lógico que o estado deseja receber os impostos para poder administrar. Por isso existem tantas leis relacionadas a isso. E esse é o princípio, (ok, um dos), que os levam a serem rígidos na legislação sobre emissão de documento fiscal. O ponto "2. Não causar prejuízo ao contribuinte" é o que leva algumas UFs a estender permissão para emissão diferenciada de documentos. Imagine que uma criança vá numa padaria e compre uma bala. O custo da emissão do documento fiscal talvez seja mais caro que a bala. Por isso, alguns estados permitem que esse tipo de estabelecimento gere uma nota fiscal no final do dia com o acumulado de todas as compras pequenas. Contudo, geralmente isso tem diversas limitações e exceções para garantir que empresas não se aproveitem dessa brecha para sonegar. Como isso funciona? Depende da UF... No tópico acima eu menciono que em MG a pessoa poderia ter um sistema de gestão que não emitia nota, mas a empresa não poderia ter nenhum computador na área de atendimento ao cliente e fosse uma empresa pequena. Porque se entende que se a empresa, mesmo pequena, tem condição de ter um computador na área do cliente, então ela tem condições de ter um sistema de emissão de notas eletrônico. Por isso o melhor é sempre você verificar com a Sefaz do seu estado, com o seu contador e com um advogado tributário. Mas tenha cuidado: Qualquer permissão ou proibição da SEFAZ, peça a legislação pertinente ou documento por escrito; Se você consultar um contador do seu cliente, ele pode estar mais interessado em facilitar a vida do cliente do que na responsabilidade que sua empresa vai ter em caso de uma fiscalização; Se você consultar um advogado que não entende da legislação tributária, ele pode te dar uma orientação não perita Isso não é 100% correto. A software house responde sim pelo que o sistema permite o usuário fazer. É claro que a responsabilidade vai depender de cada caso e de cada UF. Mas se isso não fosse verdade, não teria existido o PAF-ECF e ele não teria atingido tantas UFs. Procure saber sobre responsabilidade solidária da software house ou de sistemas de emissão de documentos fiscais na tributação. Sabe-se de concreto que vira e mexe uma software house vira notícia por permitir esse tipo de sonegação, seja lá qual for o documento fiscal usado na época. Sabe-se também que as UFs estão sempre criando operações para fiscalizar qualquer tipo de sonegação.