Daniel Simoes

Humm.. ainda não temos um plug-in para isso... acho que o pessoal edita o título do tópico

Se vc deixar vazio, o componente utilizará o mesmo diretório do seu .exe e criará a subpasta "\TEF"

Senhores, Se desejarem sugerir alguma correção para ser aplicada nos fontes originais (SVN), por favor especifiquem: - O que está sendo modificado - Porque precisou ser modificado (o que estava errado) - Todos os fontes corrigidos

Provavelmente você tem algo errado na sua instalação de Delphi, já que vários usuários usam o Boleto com QuickReport com sucesso... Em todo caso, você pode tentar usar o Boleto em Fortes Report que é OpenSource..

O FreeReport é mantido pelo pessoal do FastReport... Verifique em: http://www.fast-report.com/pt/download/ ... nload.html

Tente novamente... movi o post indicado da área do SAC para a área do ACBrBoleto

Atualmente usamos o ACBrNFeMonitor, com nossos projetos em Lazarus... achamos que ele traz vantagens estratégicas pois atua como um Servidor de certificados A3... Mas temos planos de compatibilizar o ACBrNFE2 para Lazarus em um futuro próximo...

Se você usa o ACBrTEFD ele já faz isso a cada transação enviada... Veja a sua propriedade: ACBrTEFD.PathBackup

Atualmente não temos como testar o ACBr no Delphi 6 pois a Embarcadero não nos disponibiliza acesso a esta IDE... ( a menor é o D7) E sinceramente seria difícil consumir o pouco tempo dos desenvolvedores com esta compatibilização e testes... Se desejar, nos forneça "patchs" com as correções necessárias para rodar no D6 corretamente. Podemos avaliar se elas causariam algum problema nos Delphis atuais ou Lazarus...

Realmente está errado... enviei uma correção.... Mesmo assim esse método precisa de uma revisão... pois ele precisa mostrar Todas as alíquotas, e na ordem correta que elas foram cadastradas no ECF

Qual a versão do ACBr e ECF ? Um característica conhecida da Daruma é efetuar uma compactação da MFD a cada N itens, e pode ser esse o motivo do erro... Entretanto a um bom tempo já existe um ajuste para isso nos fontes do ACBrECFDaruma.

Analisando melhor, o desconto é concedido pelo próprio lojista, pois o premio pode ser brindes, etc... Na verdade o programa "Cielo Premia" apenas faz o controle, da premiação... o prémio realmente é concedido pelo Lojista... Vou analisar o ACBrTEFD para ver as modificações necessárias

Isso irá variar muito de modelo e versão de ECF... Qual é o que você está usando ? A sugestão não pode ser aceita, pois na grande maioria dos ECF, o método LinhaRelatorioGerencial exige que exista um Gerencial aberto

Nenhuma operação TEF pode retornar Troco... com exceção do Visa SAQUE, onde o saque é lançado como valor a mais e registrado como troco... Lembre-se que nem todo Cheque pode gerar transação TEF...e portanto não há problema em gerar troco... mas geralmente isso é uma regra de negócio do estabelecimento comercial... alguns só voltam Troco até um limite, ou em Vale crédito (por exemplo)

Isso não seria possível na Bematech... a não ser que você use indices de formas de pagamento diferente para cada um dos cartões... Exemplo: 02 CARTAO 10,00 04 CARTAO 2 10,00 05 TEF 20,00[/code] Isso permitiria abrir 3 vinculados associados a cada uma dessas formas de pagamento e imprimir em cada um deles um comprovante... Porém se você fizesse: [code] 02 CARTAO 10,00 02 CARTAO 10,00 02 CARTAO 20,00 Você não conseguirá abrir 3 vinculados na Bematech.... Por isso optamos fazer de forma diferente, ou seja, bufferizar todos os pagamentos de TEF e soma-los em uma única forma de pagamento: 02 CARTAO 40,00[/code] E após isso, imprimir todos os comprovantes dos 3 cartões dentro do mesmo vinculado... Isso é ACEITO normalmente nas homologadoras... a grande maioria usa dessa maneira

Já que isso virou regra de homologação, vou introduzir essa lógica dentro do ACBrTEFD... Talvez com uma propriedade, para sabermos se deve ou não usar o Gerencial ao invez do CDC quando for consulta de Cheques...

Qual o modelo e versão do ECF ? Vamos usar o mesmo teste.... Use o programa Demo da Bematech e tente fazer o Download: Um bom teste é o próprio exemplo em Delphi que faz uso do DLL http://partners.bematech.com.br/suporte ... ds/?did=90

Os Projetos de exemplos estão nos fontes do ACBr... pasta: \ACBr\Fontes\ACBrNFe2 e \ACBr\Fontes\ACBrSPED estude em detalhes os fontes dos mesmos, internamente há muita comentário e exemplos de uso

Primeiro certifique-se que o .SO está instalado corretamente... A Daruma deve ter um exemplo em Linux que usa o .SO dela própria, certo ? Se este exemplo rodar corretamente, provavelmente o .SO está instalado de forma correta... Pelo que notei o pacote do .SO não vem com nenhuma informação de instalação... então não há outro jeito a não ser recorrer ao suporte deles...

Você pode fazer as honras de subir para o SVN ?

Pelo que notei, você apenas removeu: "(Resp.QtdLinhasComprovante acho que não compreendi direito... mas não vejo como isso faria o ACBrTEFD imprimir um Gerencial ao invés de CCD A argumentação do homologador tem fundamento... hoje o PAF-ECF determina que o CCD só pode ser usado para comprovante de Crédito ou Débito... o que não é o caso de consulta de cheques

Estive analisando o caso, aqui com o pessoal da DJSystem.... Da maneira que estão propondo tem alguns problemas... até mesmo de ordem legal... - Se a aplicação efetua desconto no cupom, isso implicará em diminuição do montante a ser pago de imposto, quando na verdade o lojista não concedeu nenhum desconto ao cliente, pois receberá integramente o valor da Operadora... O fisco pode encarar isso como sonegação fiscal. - Não dá para rastrear o quanto foi pago de premio, pois os descontos concedidos pelo "premia" se misturam como os descontos do próprio lojista, nos relatórios de Leitura X e Redução Z Acredito que o correto seria lançar no cupom o valor do premio como uma forma de pagamento, distinta da do TEF... Ex: "PREMIO", isso resolveria os dois problemas levantados acima...

Sim, acho que uma revisão em todas as classes seria necessário... e pensando melhor, não é muito elegante manter dois Registradores com nomes diferentes com o mesmo conteúdo, em todas as classes... acho que pode mais confundir do que ajudar... Vamos deixar o NumGNFC como está... em DadosReducaoZ e DadosUltimaReducaoZ... e apenas na Bematech deixamos com os dois nomes... O que acha ?

A mensagem indica que os fontes do ACBr estão tentando carregar essa função e a mesma não existe no .SÓ Provavelmente você não está com a última versão do SO... Más ainda pode ser, que essé metodo ( aCarregarBitmapPromocional ), não exista na versão Linux... Isso pode ser confirmado com o Fabricante...

Há algo errado com a DLL o na maneira que ela está instalada... é difícil para nós do ACBr... talvez o pessoal da Bematech tenha mais alguma dica... Em todo caso, por favor copie aqui um LOG gerado pelo ACBrECF, apenas para verificarmos a chamada do comando e seus parâmetros