daniel.simoes

Usamos a versão do Synapse do SVN... verifico diariamente...

Se o Demo não rodar, provavelmente o componente não rodará... Qual é o seu Delphi ? Remova e reinstale o Package do ACBrTEFD... pode ser que o Delphi esteja "se perdendo" por não conhecer as novas propriedades e eventos do componente... ele só tomará conhecimento delas após a completa recompilação do Package

Conforme detectamos junto ao suporte da Daruma, o problema é causado pelo fato do .SO da Daruma não usar a notação de porta Serial nativa do sistema operacional... Ou seja, ele não aceita "/dev/ttyS0 ou /dev/ttyUSB0", ao invez disso a porta deveria ser chamada de COM1 e COM10 respectivamente... Sabendo disso, apliquei modificações nos fontes para que o ACBrMonitor faça uma conversão nos nomes das portas para o utilizado pelo .SO da Daruma Gerei um novo ACBrMonitor para Linux (0.9.14) na pasta de download do SAC http://www.djsystem.com.br/acbr/sac/ind ... cbrmonitor

Alexsander, Atualizei o SVN com correções para compilar corretamente no FPC 2.7.1

Se você não nos informar qual ECF, modelo e versão... podemos dizer que esse é o primeiro erro

sim... todos os testes que fiz foi no TEFDemo... experimente apagar sua pasta e baixar os fontes novamente...

Sim, Veja no Demo do ACBrTEFD a programação efetuada para o evento: ACBrTEFD1DepoisConfirmarTransacoes e use as propriedades: Resposta.Debito e Resposta.Credito

Acho que o que vc chama de "travar" é o bloqueio de mouse e teclado durante a impressão...

Somente testando para descobrir... Mas acredio que o SiTEF tb leve em consideração o número do terminal que é definido na Inicialização da chamada a DLL (chamada a função ConfiguraSiTef...)

Provavelmente é um problema no seu virtualizador de portas... Experimente o com0com

Devo trabalhar na compatibilização do Linux amanhã e nesse fim de semana

Você diz que a impressão do comprovante sai diferente ? Se for isso, não sei se a alteração no modo faria diferença... o ideal é confirmar com o pessoal da NTK

Uso Mandriva e Mageia.... mas isso nunca foi testado no Linux... ou seja, usar o .SO da Daruma em conjunto com o ACBrMonitor... Estou com dificuldade de tempo (estou em homologação externa) e também para montar um laboratório para testes com esse ambiente... mas vou tentar acertar isso no final de semana...

Isso mesmo..... Dinheiro deve ser pago primeiro... e o saldo devedor em operações de TEF... se você não permitir multiplos cartoes, o saldo restante deve ser igual a operação TEF que será iniciada

Vc pode até mesmo usar os 2 simultaneamente... TEF_DIAL -> Visa (Cielo), Amex, RedeCard TEF_DISC -> TecBan, Hipercard e outros mais exóticos

Não precisa escrever código para isso.. basta criar o "debug.txt", vazio, na pasta c:\tef_dial

Demorei, pq meu Linux em VirtualBox não funcionou de maneira nenhuma com o meu adaptador USB -> Serial .... para testar, tive que instalar uma partição Linux em minha máquina... Onde você encontrou instruções para a instalação dos .SO ? (já procurei em todos os TXTs e no Help on-line sem nada achar) O Demo em QT da Daruma está acusando o erro: "A biblioteca DarumaFramework.so não foi encontrada"

Usando a sua IDE, procure por todas as ocorrências de "DEBUG" no diretório do ACBrTEFD... Em relação as vias a serem impressas, ACBrTEFD está usando a lógica descrita no documento: "TEF IP e Discado - Alterações Automação Cielo Premia 20120608.docx"

Não há nenhuma referencia sobre isso na documentação de Certificação do TEF... Provavelmente cada operadora faça de um jeito diferente...

Veja a propriedade: ACBrECF.MemoParams no Object Inspactor... é tudo HTML, você pode configurar como desejar

A obrigação é sempre do Cliente... cabe a ele a guarda e Backup das informações.... Deixe isso bem claro no seu contrato

Achei os .SO.. Mas não achei o exemplo de uso deles em Linux... qual vc está usando ?

Oi Alexsander... bem lembrado... vou inserir aqui...

Não há como... porém alguns componentes tem um numero de versão do próprio componente... SVN é muito dinâmico... e não adotamos o hábito de manter uma versão estável ou releases... A regra atual para os desenvolvedores é: "Mantenha o código do SVN sempre funcional"... ou seja, não é permitido enviar código em experiencia para o "trunk" do SVN... Com isso espera-se que o SVN tenha sempre o melhor código, ou o com maior numero de correções possíveis... Novos recursos quando muito complexos são gravados na pasta "branches", até ficarem estáveis e serem transferidos para a "trunk"

Para assinar arquivos ele usa apenas a chave Privada...