EMBarbosa

Acho que você não pode simplesmente atribuir ao NodeValue (que é um OleVariant) uma string que é na verdade um arquivo binário. É provável que vão existir caracteres de controle não compatíveis e resultará em um xml malformado. Talvez por isso seja necessário converter para base64. Visto que está usando Delphi 7 espero que esse link te ajude: https://stackoverflow.com/q/32306960/460775

Como você está convertendo o tipo binário? Está usando base64 por exemplo?

Se seus schemas estão realmente atualizados, então é provável que essa SEFAZ ainda não está preparada para essas tags em produção.

Essa planilha pode estar desatualizada.

Vou responder suas dúvidas, mas vou fazer isso no final, porque quero esclarecer algo importante. Suas dúvidas me parecem esbarrar mais na ideia de um "representante da classe de programação" perante a lei do que de um responsável pelo sistema. Talvez isso tenha acontecido porque o termo usado é "responsável técnico". Mas veja bem, o responsável técnico é a pessoa para quem a Sefaz vai mandar um e-mail quando quiser falar sobre o software emissor da NF-e. Talvez queira recordar esse tópico onde explico o motivo porque não se pode colocar o projeto ACBr como responsável técnico: As ideias são as mesmas. Dito isso, vamos a suas perguntas: Depende mais do tipo do vínculo entre eles e menos de ser uma pessoa física. A questão que deve ser respondida é: Quem é o responsável pelo software? Quem a SEFAZ deve contatar caso queira falar sobre o sistema? Isso vai depender de cada caso e de cada UF. Então algumas perguntas podem ajudar a responder. O sistema é atualmente da ME distribuidora de produtos de limpeza? O programador é chamado como um terceirizado ou mesmo como funcionário temporário da empresa, não tendo de fato vínculo com o sistema? Por exemplo, ele pode ser substituído por outro programador? (Note, não importa aqui o conhecimento interno do sistema...) Se a resposta a essas perguntas for sim então, a menos que algo diferente esteja em contrato, o responsável técnico é a empresa distribuidora de produtos de limpeza. Ela contrata outra pessoa para dar manutenção mas, ainda assim, ela é responsável, porque o sistema é dela. No PAF-ECF, chamávamos isso de "sistema próprio". Quer dizer próprio da empresa. Caso a resposta para as perguntas forem não, então, provavelmente, o responsável técnico é o programador e será necessário verificar com a UF como ele deve ser informado já que ele não tem CNPJ. Nesse caso, sem dúvida o responsável técnico é a própria empresa. Ela tem um sistema próprio, desenvolvido internamente para emitir os DF-e. Não importa se quem faz as alterações é programador ou o contínuo. O importante é quem é responsável perante a SEFAZ e, nesse caso, é claro que a SEFAZ não vai querer saber quem deu manutenção no sistema. Quando ela precisar falar com um responsável, ela vai querer contatar diretamente a empresa. Afinal de contas, se a empresa não quisesse isso ela teria contratado um sistema de alguém ao invés de permitir um funcionário (ou sobrinho do dono) criar o sistema. Espero ter sido de ajuda.

Isso torna as coisas ainda mais estranhas.

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".

Não acreditamos que tenha relação com várias instâncias do Delphi. O problema é que mesmo conseguindo reproduzir, há essa inconsistência que torna difícil descobrir exatamente o motivo para isso acontecer. Estamos tentando resolver mas enquanto isso, já que você usa o ACBrIntegrador no seu sistema, quando essa mensagem aparecer: Clique no YES! A mensagem vai ficar repetindo. Mas não vai mais ser necessário reinstalar.

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.

Olá Felipe, adicionalmente, o erro apresentado no log: "Unable to Open File" geralmente significa que alguma aplicação está utilizando esse arquivo e o ACBr Monitor não consegue salvar/modificar/apagar. Verifique antivírus e ferramentas similares. Coloque as pastas do Monitor na lista de exclusão.

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?

Eu repeti os passos aqui utilizando o Lazarus 2.0.2 e não consegui reproduzir o problema. Então, dei uma olhada no CallStack reportado na sua imagem e não consegui visualizar nada no código listado que poderia gerar esse vazamento de memória. Talvez seja algo específico de uma versão ou do Lazarus ou do LazReport...

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.