Daniel Simoes

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

Acho que podemos adotar uma terceira solução... Fazer todas as funções retornarem em ambos formatos NUmGNFC e NumNFC... assim todos os sistemas continuam funcionando... O que acham da ideia ?

Uma coisa de cada vez... O que vc está tentando ? Daruma ou Bematech ? Windows ou Linux ? Para Bematech em Windows...certifique-se: - Você tem as últimas DLLs fornecidas pelo fabricante, - Elas estão na mesma pasta do ACBrMonitor.exe - Não há nenhuma outra copia das DLLs em outra pasta, como por exemplo: Windows\System32

Tópico movido para a área correta

Fernando, O ideal é que as modificações sejam efetuadas apenas na classe da Sweda e SwedaSTX... Não sei se compreendi muito bem as mudanças sugeridas... mas pelo que notei elas poderiam estar internas... Estou enviando para o SVN modificações nesse fonte: -- ACBrECFSwedaSTX -- [*] Método CorrigeEstadoErro modificado para suportar problemas de ECF a muito tempo sem uso, onde é necessário informar a Data e Hora atual (por: DSA) [+] Implementado o método: PafMF_GerarCAT52 (por: DSA)

O código de Bematech e Daruma é completamente diferente... portanto o funcionamento ou não em um modelo não é garantia de que o mesmo que ocorrerá no outro... Se não me engano a Bematech não tem .SO equivalentes a DLL de Windows

Vi que você é usuário do SAC... Use sempre a versão do SAC, que é atualizada Semanalmente http://www.djsystem.com.br/acbr/sac/ind ... cbrmonitor

Tenta o COM0COM http://sourceforge.net/projects/com0com ... m/3.0.0.0/

Acabei de ligar na Sw.Express... e conversei bastante com o suporte deles, sobre esse teste 50... O Atendente (Roberto) me informou que provavelmente é um erro no Roteiro, e a transação deve ser NÃO CONFIRMADA, ou seja, Cancelada... o que não pode é deixar a transação Pendente