EMBarbosa

Algumas sugestões. Verifique: se as contas e dados de login realmente existem; se os e-mails estão configurados corretamente (por exemplo, no google é exigido uma configuração para permitir o acesso por aplicativos menos seguros); se as dlls estão atualizadas (exemplo, dlls da openssl); se existe algum problema externo. (Exemplo: modem?)

Eu sugiro você usar um profiler ou medir o tempo de execução de cada linha para conseguir verificar onde exatamente dentro dessa rotina acontece a lentidão nessas máquinas.

Acontece nas melhores famílias. O código que você está interessado está no arquivo ACBrEFDBloco_H_Class.pas, na procedure TBloco_H.WriteRegistroH005(RegH001: TRegistroH001), especialmente essa parte abaixo: if (FBloco_0.Registro0000.COD_VER >= vlVersao104) then begin if DT_FIN >= EncodeDate(2012,07,01) then begin case MOT_INV of miFinalPeriodo: strMotInv := '01'; miMudancaTributacao: strMotInv := '02'; miBaixaCadastral: strMotInv := '03'; miRegimePagamento: strMotInv := '04'; miDeterminacaoFiscos: strMotInv := '05'; else strMotInv := '01'; end;

Moderação: Tópico dividido.

Sim. Porque é uma função para o tipo Motivo de inventário. Sim. Foi isso mesmo que você mesmo escreveu no seu primeiro post que queria, veja: Aqui você está confundindo índice com valor. O valor do tipo enumerado não é necessariamente o seu índice. É justamente por isso que temos essas funções. Claro! MOT_INV é do tipo TACBrMotInv. Não é string. Mas também não é inteiro. Se você quer converter o valor para atribuir ao campo MOT_INV você deve usar a outra função StrToMotInv. Isso, na verdade é mais uma prova que você está equivocado, porque conforme você mesmo disse no primeiro post, e conforme consta no Guia prático da EFD, página 191:

Olá Mateus, A alteração não é necessária. Você não deve converter o tipo enumerado diretamente para inteiro ou vice-versa. Se fizer isso, vai ter problemas com outros tipos. Use as funções declaradas nessa mesma unit como: function StrToMotInv(const AValue: string): TACBrMotInv; function MotInvToStr(AValue: TACBrMotInv): string;

E quando terceiros prestam serviço de manutenção? Quem é o responsável técnico? Dúvidas assim podem surgir quando fixamos na mente mais a ideia de um "representante da classe de programação" perante a lei do que na ideia de um responsável pelo sistema. Talvez isso aconteça porque o termo usado é "responsável técnico". Logo nos vem a mente um engenheiro responsável pela obra e tal... Mas veja bem, a ideia do responsável técnico, é ter uma "pessoa" para quem a Sefaz vai mandar um e-mail quando quiser falar sobre o software emissor do DF-e. Como dito antes, suponha que o software emissor tentou retransmitir a mesma NF-e com erros no XML, por 70.000 vezes... ou seja, mesmo recebendo o erro de rejeição por XML inválido, a aplicação ficou em algum Loop, tentando retransmitir o mesmo XML que já sabia era rejeitado, isso por 70 mil vezes. Nesse caso, quem a SEFAZ deveria contatar? Pensar nesses termos, nos ajuda a entender o motivo das tags Responsável Técnico e assim saber como preencher. Vamos a dois exemplos, com base nas perguntas desse link: Imagine uma microempresa, distribuidora de produtos de limpeza, que para emitir a notas fiscais, paga a um programador fazer as alterações nos fontes de um sistema emissor. Esse programador é pessoa física. Como fica esta situação? Não se engane. A resposta depende mais do tipo do vínculo entre eles e menos de o programador 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 talvez de cada UF. Responder algumas perguntas podem ajudar a resolver a questão: Atualmente, o sistema é 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. Não é um sistema que ela aluga. Caso alguma resposta para as perguntas for não, então, provavelmente, o responsável técnico é o programador. Será necessário verificar com a UF como ele deve ser informado já que ele não tem CNPJ. No caso da empresa ter uma pessoa que saiba programação e faça estas alterações mas não é programador registrado e sim diretor ou gerente ADM, como fica? 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 é um programador ou o contínuo da empresa. 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.

Você está respondendo a um tópico de aproximadamente um ano atrás. É provável que agora o problema seja outro. Por exemplo, talvez eles tenham implementado um limite de pesquisas por período.

A propósito, o XML não foi feito para isso (incluir arquivos binários). Ele não é eficiente para isso. Você vai gastar mais tempo e recursos. Seria melhor verificar com o servidor uma alternativa.

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?

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.