EMBarbosa

Por favor, verifique o demo. Acho que ele tem ambos os exemplos.

Fiz um commit nos registros já implementados para resolver de vez (assim espero) os problemas de casas decimais. Agora preciso analisar os casos em que os campos irão ficar em branco, ou seja, ||

Pelo que entendi alguns documentos podem ser tributados ou não pelo PIS/Pasep ou pela Cofins. Mesmo assim eles podem ou não se referirem a operações geradoras de receitas ou de créditos de PIS/Pasep e de Cofins. Exemplo: A) documento tributado - gera receita ou crédito documento não tributado - gera receita ou crédito C) documento tributado - Não gera receita ou crédito D) documento não tributado - Não gera receita ou crédito A e B devem ser informados. C e D não devem ser informados.

Vou alterar no componente. É que talvez ele precisasse de algo pra fazer com urgência, por isso eu dei a sugestão de alterar o CurMask.

Faça a alteração do CurMask para '#0.00##' e veja se resolve por favor.

Obrigado Alan. Corrigido na Revisão 3278

Não seria True nesses campos?

Qual o motivo de você não ter feito o mesmo com o TrimString e CurMascara?

Olá? Você já fez essa alteração nos fontes? Pode anexá-los? Isso facilitaria na hora de fazer o merge.

Você tem razão. As rotinas exigidas estão fazendo o PAF ficar mais lento. Mas a princípio, o método que você propôs e o que eu disse não tem tanta diferença na performance.

O que as pessoas normalmente fazem é armazenar o valor da última redução Z chamada pelo aplicativo. Daí, ao iniciar o seu PAF você verifica se o CRZ é o mesmo que está no seu banco de dados. Se não for, você chama a DadosUltimaReducaoZ. EDIT: Vi que isso é possível por meio da dll (função Bematech_FI_VerificaReducaoZAutomatica). Mas me pergunto: será que outros ECF's também tem esse tipo de informação?

Acho que poderíamos dividir sim. Por questões de organização e até de facilitar na hora de instruir novos usuários. Mas pensar numa divisão funcional é o que acho que é o mais complicado. Acho que podemos discutir sobre isso e decidir com mais tempo... não é algo urgente, mas algo que deveria ser feito, no meu ponto de vista.

Feito. Revisão 3271

Olá Antonio, O problema foi você ter desconsiderado minha mensagem e não ter percebido que a discussão sobre esses campos já aconteceu aqui e no Mantis, mas ninguém foi capaz de citar um exemplo. De qualquer forma, obrigado por reportar. Eu vou analisar a fundo essa questão na segunda feira e postar as correções assim que possível.

Já consegui usar o ACBrECF com impressoras USB sem problemas. É só instalar o drive que cria Porta Serial Virtual.

Olá Daniel, Resolve sim. Mudar de SimpleRoundTo para RoundTo resolveu o problema. EDIT:Quer que eu suba a alteração?

Também achei isso muito estranho pois no Delphi dá erro mas no Lazarus não deu nos meus testes aqui... Daí criei um aplicativo tentando reproduzir a mesma coisa por fora da unit ACBrTEFDClass.pas, mas também não consegui. Vou testar a sua sugestão agora...

Sugestão: Verificar o arquivo LEIAME.TXT. Muito das informações que estão lá, já estão prontas pra serem lançadas no wiki.

Talvez a melhor solução seja usar a rotina CompareValue especificando o delta. if (not MultiplosCartoes) and (CompareValue(Valor, SaldoAPagar, 0.01) = LessThanValue) then raise Exception.Create( ACBrStr( 'Multiplos Cartões não habilitado.' + sLineBreak + 'Valor da Operação TEF deve ser igual ao Saldo a Pagar' ) );[/code]

Subi uma correção para isso. Favor testar.

Me parece que o Isaque adicionou um(alguns) evento(s) no componente. Isso deve ter introduzido o bug. EDIT: ver também http://www.djsystem.com.br/acbr/mantis/view.php?id=1146

Pelo que me parece isso só acontece na versão do Delphi, e não se você compilar ele em Lazarus. Passos para reproduzir: Iniciar o DEMO do ACBrTEFD Configurar o ECF (no meu caso Emulador 2100 da Bematech) Inicializar ECF Deixar Múltiplos cartões desabilitado Inicializar Gerenciador Padrão (se ainda não foi feito) Abrir cupom e vender um item de 0,35 Chamar CRT de 0,35 Retorno: O erro acontece na função TACBrTEFDClass.VerificarTransacaoPagamento. Na seguinte verificação (linha 2363 do arquivoTACBrTEFDClass.pas): if (not MultiplosCartoes) and (Valor raise Exception.Create( ACBrStr( 'Multiplos Cartões não habilitado.' + sLineBreak + 'Valor da Operação TEF deve ser igual ao Saldo a Pagar' ) ); [/code] O motivo é que o valor de SaldoAPagar vem de SubTotalECF que é do tipo [i]Extended[/i], mas SaldoAPagar é [i]Double[/i]. Por isso o valor que fica armazenado em SaldoAPagar é realmente diferente de Valor. A solução pra esse tipo de comparação é usar a função CompareValue da unit Math. Mas ela não parece retornar o valor correto no Lazarus. Então a solução mais rápida foi adicionar um [b]RoundTo(SaldoAPagar,-2)[/b] antes de comparar as duas variáveis. Gostaria que alguém pudesse confirmar o erro e se isso não afeta o funcionamento no lazarus. Em anexo a unit alterada. ACBrTEFDClass.pas

Qual ECF você está usando? Qual versão da sua IDE de desenvolvimento (Lazarus, Delphi 7, 2010, XE)?

O quê você quer dizer com "Nesse quando ele pega o SubTotalECF ele esta vindo com os valores acumulados do ECF e assim ficando diferente do que a impressora realmente está no seu subtotal"? Pode dar um exemplo?

Pessoal, Criem tópicos novos para dúvidas diferentes. Por favor, não utilizem esse tópico que tem o tema Andamento do ACBrNFSe se a sua dúvida não estiver relacionada com o Andamento do ACBrNFSe. Obrigado.