daniel.simoes

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

Oi Evandro... Achei aqui... eu que estava lendo o roteiro errado... Você sabe me dizer se isso é uma regra para qualquer Relatório Gerencial Impresso pelo Menu Administrativo ? Ou seja, sempre que um Relatório Gerencial disparado pelo Administrativo falhar, devemos mesmo assim confirmar a transação ?

Qual a versão do roteiro ? na versão 11, que segundo me informaram é a última o teste 50 tem um texto totalmente diferente... Você está falando do Roteiro com CliSiTEF DLL ?

Ajuda mais se você postar exatamente qual é a mensagem de erro

O ACBrECF não suporta Impressoras fiscais de Restaurante ou Bilhete de Passagem

Em qual momento exato ocorre o problema ? Você consegue fornecer um passo a passo para reproduzi-lo no Demo do ACBrECF ?