elton.barbosa

Acho que esse tópico está na área incorreta. Qual componente ACBr você está utilizando para fazer isso? Já que você pesquisou nos tópicos, seria bom você também mencionar o que você já tentou fazer e o porquê de não resolver.

Possibilidades: 1) Ainda há arquivos ACBr*.DCU ou ACBr*.bpl, PCN*.dcu ou PCN*.bpl no seu computador 2) Algum dos seus arquivos está com alguma alteração

Os componentes do ACBr não foram totalmente preparados ainda para trabalhar em 64 bits. Pode ser que dê problemas nos Mas esse erro está claro. Uma constante está sendo enviada para um método (procedure ou function) que está pedindo um parâmetro tipo var.

Parece que está ok. Obrigado Juliomar.

Me pareceu que no arquivo anexado não dá pra ver o ACBrECF listando as alíquotas e suas descrições...

Talvez possa ser a diferença da versão do Software Básico. Já verificou essa possibilidade?

Normalmente aconselhamos colocar na mesma pasta do Executável.

Conforme o post no site do SPED datado de hoje 16/06/2014: Fiquem atentos.

Este problema é devido a uma alteração feita pelo Juliomar na revisão 6977. Vou precisar verificar com ele o que foi que levou à alteração.

Como? Bem isso a legislação não diz. Mas ele deve ser guardado de maneira que você garanta a recuperação. Ou você pode sofrer a penalidade de receber multas e tributações pelo que você não tem como provar que vendeu ou não vendeu. No entanto, se depois de recuperar o arquivo (seja do campo BLOB ou outro lugar) você não conseguir reproduzir a assinatura digital, isso significa que o arquivo é inválido.

O caso do Pedro_Paulo foi resolvido conforme o

Veja: Aproveitando, crie um tópico novo para uma dúvida nova conforme as regras. Veja neste em especial a "2.2 - Permaneça no assunto".

O registro C114 é filho do C110. Você está criando os registros C110 antes? Não consegui reproduzir seu problema com o Demo do ACBrSPEDFiscal. Você fez alguma alteração no código do Demo para testar? Queira disponibilizar para que eu possa averiguar.

Vai ser necessário fazer uma limpeza no seu computador e reinstalar o ACBr. Siga os passos delineados

Você vai precisar usar o debug, usando o F7, e descobrir qual exatamente a linha do método RegistroC114New onde acontece esse problema.

Infelizmente, sem as exatas alterações que eu pedi e sem os logs eu não tenho como aprofundar mais nesse problema até que consiga um ECF físico e tempo para testar...

Bem, eu não tenho um ECF destes aqui para testar... Por favor, faça as alterações que eu sugeri, faça o build e anexe o log depois de cada alteração. Tenha certeza de que só as alterações que eu sugeri estão no código.

Olá EddieBr, Vou pedir para que você faça dois testes. Vou apontar onde você vai alterar no código e vamos ver o comportamento se melhora ok? Você deve fazer o seguinte. Faça uma alteração primeiro. Faça Build dos componentes. Faça o Build do ECFTeste. Faça o teste. Anexe o log. Faça a outra alteração. Faça Build dos componentes. Faça o Build do ECFTeste. Faça o teste. Anexe o log. Aqui vão: Arquivo ACBrECFClass.pas, método TACBrECFClass.DoLeResposta (por volta da linha 1851), aumente o timeout do fpDevice.LeString de 100 para 2000, conforme abaixo: Fim := True ; if not FimLeitura then begin Fim := False ; try fpRespostaComando := fpRespostaComando + { Le conteudo da porta } fpDevice.LeString(2000) ; // ALTERADO AQUI !!!!! // fpDevice.LeString(100) ; // ESTAVA ASSIM!!!!! Segunda e Terceira Alteração são no arquivo ACBrECFBematech.pas. Método TACBrECFBematech.VerificaFimImpressao, por volta da linha 1044. Veja abaixo: try GravaLog(' '+FormatDateTime('hh:nn:ss:zzz',now)+' VerificaFimImpressao: Pedindo o Status (19)' ) ; fpDevice.Serial.Purge ; // Limpa buffer de Entrada e Saida // fpDevice.EnviaString( Cmd ); // Envia comando // // espera ACK chegar na Porta por 1,5s // wACK := fpDevice.LeByte( 3000 ) ; //ALTERADO AQUI !!!! // wACK := fpDevice.LeByte( 1500 ) ; //ESTAVA ASSIM !!!! if wACK = 6 then // ECF Respondeu corretamente, portanto está trabalhando // begin GravaLog(' '+FormatDateTime('hh:nn:ss:zzz',now)+' VerificaFimImpressao: ACK = 6, OK... Aguardando ST1 e ST2' ) ; TempoLimite := IncSecond(now, TimeOut); fsFalhasFimImpressao := 0 ; // Aguarda ST1 e ST2 por mais 2 segundos // RetCmd := fpDevice.LeString( 4000, 2 ) ; // ALTERADO AQUI!!!!! // RetCmd := fpDevice.LeString( 2000, 2 ) ; // ESTAVA ASSIM !!!! Result := (Length( RetCmd ) >= 2) ; end else raise EACBrECFErro.Create( 'ACK <> 6' );

O que a está escrito na wikipédia é justamente o que eu escrevi ali acima. O documento que eu citei tem uma explicação mais profunda. A propósito, esse é um problema de qualquer linguagem. O que acontece é que algumas tem uma precisão maior, então pode ter passado despercebido. Claro, a forma como o compilador trata as variáveis e as constantes também pode influir. Mas sempre haverá o problema da imprecisão por se tentar representar um conjunto infinito de números num espaço limitado de memória ou seja um conjunto finito.

Apenas para explicar, as dlls devem ser de acordo com o aplicativo que fará as chamadas e não com o sistema operacional. Assim, se o aplicativo é 32 bits, mesmo estando instalado em um sistema operacional de 64 bits, as dlls devem ser 32 bits.

Talvez alguma incompatibilidade do Delphi 2010 com o Windows 8.1 64 bits.

Que problemas? Poderia ser mais específico? Qual o comportamento que você esperava? Qual o comportamento que encontrou?

Daria pra reproduzir o cabeçalho do arquivo de log deste teste no ECFTeste? Informe outros parâmetros também (Intervalo entre comando, por exemplo). Parece que o timeout é pequeno.

Veja

Na verdade, a princípio, você não deveria fazer esse tipo de comparação. É para isso que existem as funções como SameValue, CompareValue, IsZero na unit Math do Delphi (e Lazarus). Daniel, provavelmente o que você quer é algo mais parecido com o What Every Computer Scientist Should Know About Floating- Point Arithmetic. De forma resumida, o que acontece é que, como existem números infinitos e memória limitada, alguns números não são possíveis ser representados. Então para esses números os valores são armazenados internamente com uma aproximação. Então, dependendo do valor, temos que lidar com uma aproximação. Tem outro tópico no fórum onde teremos que lidar com um problema semelhante devido as peculiaridades dos pontos flutuantes. Inclusive com código para teste. Finalmente, essas diferenças são o motivo de muitas pessoas aconselharem a trabalhar com o tipo Currency para valores monetários ou onde não se pode perder a precisão. O tipo Currency não é armazenado como um float, mas como de ponto fixo (mais precisamente como um int64). O problema é que nesse caso, ele possui um número de dígitos significativos limitado, não sendo possível expressar nenhuma diferença entre valores fora de sua precisão (que é 4). Assim, para os valores Currency, não há diferença entre 1,12345678 ou 1,12348765.