daniel.simoes

Não necessariamente... o SiTEF que comanda o que deve ser exibido ao Operador e ao Cliente... O ACBrTEFD recebe a informação do SiTEF e repassa para o evento OnExibeMsg... Você pode acompanhar o que o SiTEF realmente enviou, analisando o arquivo de Log gerado pelo ACBrTEFD

Veja... há algo muito errado no seu ambiente (ou no da Seven)... (ou seja, onde ocorre esse erro) Não é nada comum o arquivo da pasta REQ não conseguir ser apagado... Isso não é um problema no componente... é algo externo que está Bloqueando o componente de apagar esse arquivo... PS: Se o erro ocorre na Seven.. tente fazer uma transação TEF com o TEFDDemo, apenas para testar o ambiente... Se não ocorrer o problema, então é algo no seu código, que está prendendo este arquivo...

Não.. no próprio Windows... Verifique se esse arquivo está com o atributo de "Somente Leitura"

Não se esqueça de deixar seu Nome do "Hall of Fame" (Casos de sucesso com o ACBr)

Obrigado Fábio..

Humm... Lembro de ter mudado a declaração de chamada do método, usando o Tipo PAnsiChar ao invés de PChar... Por favor verifique se não é apenas isso..

O Exception só é disparado quando SysUtils.DeleteFile( Arquivo ) falha... Ou seja... algo, ou alguém está prendendo o arquivo... Não há como contornar isso dentro do ACBrTEFD Verifique as propriedades desse arquivo (está como Read Only ?) Quando acusar o erro... mantenha tudo aberto, e tente apagar o arquivo pelo Explorer...

Você mesmo que exibe a mensagem.... dentro do evento: ACBrTEFD.OnExibeMsg... Ou seja, sempre que o ACBrTEFD quer mostrar algo ele chama esse evento...

Mas uma vez não fui capaz de compreender o seu problema... Por favor tente descrever melhor a situação (ou teste)... lembre-se de copiar aqui o texto do teste (nem todos tem o manual nas mãos) Descreva o que vc considera errado... e qual deveria ser o resultado esperado

Essa mensagem aparece de onde ?? Se for o G.P. mostrando a mensagem, o problema está nele... Geralmente isso ocorre quando os arquivos estão dessincronizados ... Feche o G.P. (remova da memória) apague todos os arquivos da pasta c:\tef_dial\req e c:\tef_dial\resp... faça o mesmo com as subpastas do mesmo nome dos programas das operadoras que residem dentro da pasta do c:\tef_dial\

Antes de cada transação o ACBrTEFD envia um ATV... Se o ATV falhar, ele verifica o valor da propriedade "AutoAtivarGP", se ela for True, ele executará o binário definido em "GPExeName"

Provavelmente o cabo está confeccionado de forma incorreta... Mas não posso subir essas modificações para o SVN até termos um manual que diga que os fontes estão incorretos

Por favor seja mais claro em seus questionamentos... O que vc quer fazer ? ou, O que vc não conseguiu fazer ? Data Inválida você mesmo pode verificar não é mesmo ?? qual a dificuldade nisso ?

Não valida, afinal, como ele acessaria o seu banco de dados ?? Ele apenas espera que vc responda se a digitação foi válida ou não, assim como qualquer outro campo...

A classe da NCR há muito tempo não recebe melhorias... está praticamente abandonada... Eu não tenho como dar manutenção pois não possuo este ECF...

Você pode verificar pelo parâmetro: TipoCampo, se ele for 500 você pode abrir a sua própria janela de Senha

André, Não vou mexer nesse layout por enquanto... afinal tive a confirmação de que estava OK... Assim que tiver um tempo entro em contato com a POLIMIG novamente para esclarecer isso...

POLIMIG - SP

Pode ser algum programa de Segurança de Internet, que atue como um Proxy transparente...

Em relação ao relatório de Meios de Pagamento, estou em processo de homologação e o pessoal da POLIMIG já me confirmou que o layout atual, nos fontes do ACBrECF, está correto

Provavelmente seu cliente usa um PROXY... Eu considero os seguintes erros a presença de Proxy: function TDJRegistro.IsProxyError : Boolean ; begin with fsHTTPSend do begin Result := (ResultCode = 0) or (ResultCode = 400) or (ResultCode = 407) or (ResultCode = 411) or (ResultCode = 500) ; end ; end ; Veja a lista de erros HTTP http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

A Quattro tem uma classe específica (ACBrECFQuattro, ecfQuattro)... O protocolo dela era um "clone" do protocolo "ESC .", da Sweda Porém não perca seu tempo, o ECF não existe mais... morreu quando entrou a lei dos ECFs com MFD

Enviei para o SVN algumas modificações baseado no PATCH sugerido... O código da Urano já estava lá.. não havendo a necessidade de boa parte do patch

O fisco entende que se o cliente pode comprar equipamentos e sistemas, então ele DEVE o fazer da maneira correta... que é através do Cupom Fiscal... A isenção de uso do ECF é feita apenas para micro empresas, que teoricamente não poderia arcar com os custos da informatização...

Por favor evite postar várias vezes a mesma coisa... Comece lendo o manual de integração do banco... para compreender o que o Banco quer lhe dizer...