EMBarbosa

Duplicado.

Olá, quais as especificações deste SAC?

Mas se você fez as modificações, agora você não faz mais o FreeAndNil. Então onde está dando erro?

Depende... mas se você vai precisar usar o objeto sempre, seria melhor deixar ele criado já de uma vez. Afinal, criar e destruir consome processamento.

Moderação: Movido.

É por esses e outros motivos que se aconselha a fazer um "merge" dos dados recebidos antes (DadosReducaoZ) e depois (DadosUltimaReducaoZ) da emissão da Redução Z.

Sem um passo a passo para reproduzir no ECFTeste, você precisa descobrir exatamente qual linha gera o esse AV (Access Violation) e o motivo. Caso contrário, fica muito difícil pra gente ajudar.

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.