elton.barbosa

talvez porque na hora de imprimir no ECF só poderia ter 40 posições... Tente passar só o nome ou o caminho relativo ao invés do caminho por inteiro.

Você conseguiu algum jeito de sempre reproduzir o problema? Por exemplo, consegue reproduzir utilizando o ECFTeste?

Como a dúvida inicial era sobre se o ACBr possuía algo relacionado, movi o tópico para o subfórum "dúvidas gerais". Se tiver novas dúvidas, seguindo as regras, crie um novo tópico no subfórum apropriado. Por exemplo: se for sobre como implementar uma parte específica, use o subfórum "Programação"; se for dúvida sobre ou legislação pertinente, use o subfórum legislação; etc...

Do jeito que o ACBrECF implementa.

Sendo assim, sim...

Até onde eu sei, não existe mais Roteiro de análise. Mesmo assim, veja: Passo 8: Abra um Cupom Fiscal registrando um item comercializado na tela de venda. Diz pra abrir um cupom. Não diz pra alterar o GT antes de vender um item.

Verifique o manual. Muitas podem ser configuradas para se comunicar como se fossem Toledo, Filizola, etc...

Qual item do requisito XXIV trata isso na venda do item?

Isso não é do Delphi especificamente. Toda linguagem de programação é assim armazenando apenas uma aproximação do número decimal (conhecido como ponto flutuante ou float). Pense no seguinte: Quantos números reais existem entre 0 e 1? Infinitos. E entre 0,1 e 0,2? Infinitos. E entre 0,0000001 e 0,0000002? Infinitos. Mas a memória do seu computador é finita. Pior, a memória alocada para uma variável numérica é finita. Então é impossível expressar todos os números entre 0,1 e 0,2 com a memória alocada para um tipo. Quanto menos expressar todos os números reais... Um artigo com explicação mais detalhada é o "What Every Computer Scientist Should Know About Floating-Point Arithmetic" por David Goldberg. Já citei este artigo em outro tópico, juntamente com um link para uma pergunta relacionada no StackOverflow:

-2,84147705365001E-15 é mais ou menos igual a -0,000000000000002841477053650. Essa é a diferença entre os dois números que você calculou. Isso acontece devido a forma de armazenamento. O artigo que o Daniel citou explica um pouco sobre isso.

Mas porque ele alterou o valor do GT no arquivo AAC? Esse teste não me parece fazer sentido. O que ele estava testando?

Se funciona como o tefdial, tente usar o ACBrTEFD e a classe do tefdial como base. Pode ser que lhe ajude.

Na realidade, não é uma verificação. O que acontece no FinalizaVendeItem é uma Atualização do GT que está no AAC. Até onde me lembro o ACBrAAC em conjunto com o ACBrECF nunca precisaram fazer a verificação após cada venda de item. Você tem essa necessidade? Qual o problema que realmente está tendo? Como reproduzir no ECFTeste?

No ACBr não há nada específico para isso.

Se o tributo é ISSQN, a função AchaICMSAliquota não vai encontrar mesmo. Não entendi o motivo de isso ser um problema.

Se não me engano é o NCN. Você pode verificar o método TACBrECFBematech.GetDadosUltimaReducaoZ na unit ACBrECFBematech.pas e comparar com o manual do ECF.

Acho que outros ECFs não tem essa funcionalidade e por isso o ACBrECF não tem isso implementado. Afinal, como o @giulianon mencionou, esses dados já estão na aplicação. Quanto menos você buscar dados no ECF melhor. É sempre mais lento...

Você precisa verificar quais partes do seu código está precisando ser otimizada.

Por favor pesquise antes de postar, talvez sua dúvida já está respondida em outro post. Experimente nosso mecanismo de Busca com algumas palavras chaves e surpreenda-se com os resultados. No topo da página, você encontrará a caixa de busca. Altere onde está escrito "Tudo" para "Google" se desejar pesquisar usando o motor do Google.

Ahhh essa assinatura. Bem, não há nada no ACBr para isto. Essa assinatura é feita para se transmitir um arquivo já validado. Não sei nem se o governo disponibilizou alguma documentação sobre como ela é feita. Penso que não exista nenhuma informação realmente útil para nós nessa assinatura.

Obrigado pelo retorno.

Talvez a implementação da OpenSSL é otimizada.