EMBarbosa

Provavelmente colocando o horário no servidor do RS como fora do horário de verão, conseguiria resolver para ambos os locais. Mas é uma solução PORTA (Programação Orientada a Recursos Técnicos Alternativos - é eu acabei de inventar esse termo. ). O melhor é você consultar a Receita.

Na verdade DT_INI pertence à classe TACBrSPEDFiscal. Ele é definido quando você faz no seu código algo como: ACBrSPEDFiscal1.DT_INI := now;[/code] O quê fez você acreditar que o erro está num "With RegistroG110New do" se ele nem aparece no arquivo fonte?

Tópico repetido? http://www.djsystem.com.br/acbr/forum/viewtopic.php?f=10&t=7763

No arquivo Readme do Firebird, se não me engano, tem explicação sobre os problemas que podem ocorrer na migração.

Eu verifiquei aqui SwedaSTX e Bematech, e nenhuma das duas retornam esses dados nessa função. Isso porque o ECF não retorna esse dado na função.

O uso do with deve ser evitado por dois motivos básicos: pode tornar o código menos legível e pode confundir o compilador no caso de uso de classes com métodos ou propriedades que tenham mesmo nome. Ainda assim, o with usado no seu código atual vai reduzir as chamadas conforme mencionado, e provavelmente vai agilizar o código. Mas seria melhor você fazer algo assim: procedure xxxxxxx Var cdsClienteRunTime:TClientDataSet begin //.... cdsClienteRunTime := TClientDataSet(FindGlobalComponente('frmCliente').FindComponente('cdsCliente')); cdsClienteRunTime.Append; cdsClienteRunTime.FieldByName('valor01').asString := '1'; cdsClienteRunTime.FieldByName('valor02').asString := '2'; cdsClienteRunTime.FieldByName('valor03').asString := '3'; //... cdsClienteRunTime.FieldByName('valor99').asString := '99'; cdsClienteRunTime.FieldByName('valor100').asString := '100'; cdsClienteRunTime.Post;[/code] Mas a raiz do problema do seu código no primeiro cenário não é a criação dos objetos em RunTime. O problema é a falta de controle sobre essa criação. Por exemplo: Se você criou um objeto frmCliente, você já deveria saber onde ele está e qual é a instância do objeto que o controla. Não deveria ser necessário você usar um método do tipo FindGlobalComponente('frmCliente') para isso. Ou mesmo que fosse necessário, você deveria poder fazer a mesma coisa da ideia do with anterior. [code] frmCliente := TfrmCliente(FindGlobalComponente('frmCliente')); //a partir daqui só usar-se-á frmCliente. Finalmente, sobre o uso do FieldByName no seu segundo cenário. Exatamente como o Isaque mencionou, com o With ou sem o With será ruim a performance. Isso pois o método FieldByName é lento por natureza. Por isso, sempre que possível é melhor usar o objeto direto. Ou então usar a propriedade Fields do dataset. Mas há alguns casos que usar FieldByName é realmente necessário e você tem algumas saídas para agilizar as chamadas. Veja esse link: http://delphi.about.com/od/database/ss/faster-fieldbyname-delphi-database.htm Esse artigo explica alguns métodos para "acelerar o FieldByName" e você pode escolher o que lhe aplica melhor. Espero que ajude.

E lá se vai embora o objetivo anterior das linhas de rodapé, que era adicionar algo personalizado do LOJISTA para o cliente.

Sim. Mas há ainda ECFs talvez estejam no cliente e que, como não foram para intervenção, continuam com Redução Z automática... Como ele perguntou como faz pra desabilitar, eu achei por bem responder, já que ele vai precisar. Visto que você já tinha respondido de forma correta sobre como faz pra pegar os dados, eu cortei essa parte do comentário.

Só acontece quando o ECF vai para intervenção e volta no mesmo dia para o cliente. É um caso muito específico pois se o ECF for pra intervenção e não voltar no mesmo dia, ou se mesmo quando voltar no mesmo dia, o cliente não o utilizar, não há problema algum. Tivemos um caso desse no mês de setembro passado. O registro 60M e a redução continua a se basear na Data de Movimento. Mas quando há mais de uma Redução no mesmo dia, o componente estava ordenando os registros de forma aleatória. As vezes punha um na frente, as vezes outro, dependendo da ordem de entrada e do número de registros... Não é necessário liberar nada manualmente. O funcionamento dessa parte para o usuário do componente continua do mesmo modo, tanto na destruição do TACBrSintegra como no método LimparRegistros. A única diferença é que agora, ele controla os registros filhos internos do 60M ao invés dos externos. O comentário que coloquei no código que deve ter gerado essa confusão. É só um lembrete que o componente deve fazer a limpeza daqueles registros enquanto o OwnObjects for False. Esclarecendo: Quem não quer se preocupar com o caso de duas reduções Z no mesmo dia não precisa alterar nada no código. Pode continuar usando da mesma maneira. O código continua o mesmo como no exemplo para registros 60A abaixo: //Exemplo código Redução Z.. wregistro60M:=TRegistro60M.Create; wregistro60M.Emissao:=ACBrSintegra.Registro10.DataInicial; wregistro60M.NumSerie:='000000987456'; wregistro60M.NumOrdem:=1; wregistro60M.ModeloDoc:='2D'; wregistro60M.CooInicial:=1000; wregistro60M.CooFinal:=1050; wregistro60M.CRZ:=1; wregistro60M.CRO:=1; wregistro60M.VendaBruta:=1050; wregistro60M.ValorGT:=10000; ACBrSintegra.Registros60M.Add(wregistro60M); wregistro60A:=TRegistro60A.Create; wregistro60A.Emissao:=ACBrSintegra.Registro10.DataInicial; wregistro60A.NumSerie:='000000987456'; wregistro60A.StAliquota:='F'; wregistro60A.Valor:=500; ACBrSintegra.Registros60A.Add(wregistro60A); wregistro60A:=TRegistro60A.Create; wregistro60A.Emissao:=ACBrSintegra.Registro10.DataInicial; wregistro60A.NumSerie:='000000987456'; wregistro60A.StAliquota:='I'; wregistro60A.Valor:=550; ACBrSintegra.Registros60A.Add(wregistro60A); i := 0; wregistro60M:=TRegistro60M.Create; wregistro60M.Emissao:=ACBrSintegra.Registro10.DataInicial; wregistro60M.NumSerie:='000000987456'; wregistro60M.NumOrdem:=1; wregistro60M.ModeloDoc:='2D'; wregistro60M.CooInicial:=1000; wregistro60M.CooFinal:=1050; wregistro60M.CRZ:=1; wregistro60M.CRO:=1; wregistro60M.VendaBruta:=1050; wregistro60M.ValorGT:=10000; ACBrSintegra.Registros60M.Add(wregistro60M); //Registros filhos do 60M que acabamos de inserir... wregistro60A:=TRegistro60A.Create; wregistro60A.Emissao:=ACBrSintegra.Registro10.DataInicial; wregistro60A.NumSerie:='000000987456'; wregistro60A.StAliquota:='F'; wregistro60A.Valor:=500; ACBrSintegra.Registros60M[i].Regs60A.Add(wregistro60A); // wregistro60A:=TRegistro60A.Create; wregistro60A.Emissao:=ACBrSintegra.Registro10.DataInicial; wregistro60A.NumSerie:='000000987456'; wregistro60A.StAliquota:='I'; wregistro60A.Valor:=550; ACBrSintegra.Registros60M[i].Regs60A.Add(wregistro60A); // inc(i); //Próximo registro 60M Esse é o tipo de coisa que a lei não nos prepara para fazer de antemão.

Só com intervenção técnica.

Tivemos um problema com a internet aqui na cidade... Só conseguiram resolver hoje. O problema da ordenação do registro 60M foi resolvido verificando, além da data, também o CRZ. Já para organizar os filhos de reduções no mesmo dia, foi necessário utilizar de forma manual as propriedades internas do Registro60M a saber Regs60A, Regs60D e Regs60I. Assim, ao invés de, por exemplo, criar um registro 60A e adicioná-lo no Registros60A do ACBrSintegra, a pessoa cria os registros para aquele 60M específico, e o adiciona no Registros60M.Regs60A. O mesmo vale para Registros60D e Registros60I.

Como assim?

Pessoal, Detectei um erro na geração do arquivo Sintegra pelo ACBrSintegra quando há mais de uma Redução Z no mesmo dia. O componente não consegue ordenar corretamente caso criemos os registros e deixemos que ele próprio relacione os registros 60A e 60M devidos. Assim é necessário fazer esse relacionamento manualmente. Mas caso usemos as propriedades existentes para isso, o componente não cria os registros 60A. O mesmo ocorre com os registros 60D, 60I e 60R. Fiz uma alteração no componente para corrigir esse erro, mas estou ainda testando para ter certeza que não vai alterar o comportamento para quem já faz uso do componente. Foi necessária alteração no modo de criação e destruição interna dos registros para que não houvesse leak de memória, mas isso não deve alterar em nada o código dos usuários atuais do ACBrSintegra. Apenas quem precisar atender o caso de mais de um registro 60M no mesmo dia é que deverá alterar o código. Achei por bem avisar a todos que, assim como eu, talvez não tenham percebido essa limitação no componente. Devo terminar os testes amanhã e fazer o commit.

Você configurou a versão do validador no componente? Qual está configurado?

Não sei agora, mas até a pouco tempo atrás, ainda era melhor homologar no XP por causa do TEF. Mas sobre o ECF, use o que o seu programa funciona e não dê problema com a comunicação com o ECF. Principalmente ao tentar gerar os arquivos do Menu Fiscal que vão fazer acesso à DLL do fabricante.

Não precisa abrir uma nova aplicação se usar a opção Menu -> Component > Import WSDL

Acabei de fazer um teste aqui com o Validador 2012 e deve ser assim:

Tem certeza que vem desabilitado? Numa máquina que temos aqui, pareceu normal. No Delphi XE tem até duas maneiras de entrar nele: Menu -> Component > Import WSDL ou Menu -> File > New > Other > Delphi Projects or C++Builder Projects > WebServices > WSDL Importer Sendo que a segunda opção exige que exista uma aplicação já criada antes que habilite o comando.

O maior problema não é ter um Windows 64 bits, mas compilar para 64 bits. Você ou qualquer outrapessoa que possua o Lazarus ou Delphi que permita compilar para 64 bits pode ajudar da seguinte maneira: 1) Compilar os programas de exemplo para 64 Bits. 1.1) Reportar quaisquer erros de compilação, se possível com sua correção. 2) Executar os programas de exemplo no Sistema operacional de 64 bits e verificar seu funcionamento se está de acordo com a versão 32 bits. 2.1) Reportar quaisquer erros ou divergências no funcionamento, levando em conta o funcionamento da versão de 32 bits. Assim, a pessoa pode testar todos os componentes ou projetos mesmo que não utilize o componente em questão.

Vou verificar e dou um retorno.

Algumas possibilidades: Se os valores não são iguais, eles precisam ser. Se estiver trabalhando com múltiplos cartões, precisa configurar o ACBrTEFD para isso.

Daniel, obrigado pelo retorno. Mas não sei se entendi como o código poderia quebrar a compatibilidade com outros usuários. Também acho que essa parte da geração do Requisito X usando os componentes não está bem clara. Se puder me dar uma resposta um pouco mais elaborada. Se for o caso, eu mudo aqui a minha implementação para não ter que usar uma versão do ACBrPAF diferente da do projeto.

Anexe o log do ACBrECF.

Realmente. Por um momento achei que estava falando do SPED Fiscal. No EFD Contribuições (SPED Pis/COFINS), esse erro está relacionado às opções que você muda dos registros 0110 e seus anteriores. Por exemplo: Seu registro 0110 atual é o seguinte: Mude a linha para o seguinte e tente validar: A mensagem de erro é totalmente diferente.

Não tem uma regra no Discado dizendo que o cartão sempre deve ser a última forma de pagamento?