Daniel Simoes

Você nunca conseguirá deixar a Data/Hora inferior ao último documento emitido, basta deixar o ECF em intervenção, aguardando chegar a data/hora do último documento emitido, e então ajustar...

Normalmente basta compilar sua aplicação... porém se algo mudou na propriedades Published (que aparecem no ObjectInspector) então você precisa recompilar o Package... Basta acompanhar o Change-log.txt Dica: Estude e leia com atenção o projeto demo ECFTeste.dpr

Nesse Link, da Bematech, há drivers para Linux... Eles não funcionam ? http://www.bematech.com.br/equipamento-produto-impressoras+fiscais-mp-4200+th+fi-downloads.html#conteudo

Nesse caso... somente o suporte do fabricante poderia esclarecer...

A presença da Barra ou Pontos pode depender da formatação do estado... (e da vontade do Lacrador)... já que o campo é uma String livre... A rotina de geração (da DLL) deveria ter um tratamento para remover barras, pontos e traços... Provavelmente você precise relatar o problema ao suporte da Daruma...

Por favor anexe os Logs gerados pelo ACBrTEFD e ACBrECF quando usando o TEFDDemo... precisamos tentar reproduzir o problema no Demo...

Leandro, Trata-se acima de tudo, de preferência de quem administra o projeto... Eu não gosto da maneira de trabalho do GitHub... (opinião pessoal minha) Mas nada impede qualquer usuário clonar nosso repositório SVN no GitHub... Vi algum muito semelhante acontecer com o repositório do Lazarus, onde os desenvolvedores usam SVN, mas um "power" user, criou um repositório de GitHub, com scripts para sincronização do SVN para o GitHub.. Veja esse link: http://wiki.lazarus.freepascal.org/git_mirrors

Resta saber se essa modificação é aceita por outros bancos ... Senão será um eterno problema .... Alguém pode confirmar ?

Obrigado... Isso já nos foi sugerido, mas recusamos... Os Pull Requests podem ser caóticos em um projeto com essa enorme quantidade de componentes... Mesmo as contribuições que recebemos, quase 70% precisam passar por ajustes antes de subir para o SVN

Você mesmo disse que foi obrigado a modificar os fontes do ACBr... Por que será ??? Sendo que centenas ja homologaram sem nenhuma modificação ?? Você nao leu os fontes, nem o Changelog, caso contrario meu tópico anterior seria desnecessário. Se nao estiver satisfeito com o forum ou a assinatura do SAC basta cancelar , nao pagando mais o boleto

A modificação pode atrapalhar outros ECF da Classe FiscNET, como Urano, Itautec, ZPM, TermoPrinter, etc O ideal é levantar se isso é uma restrição apenas deste modelo ou de todas as FiscNET... O problema também poderia ser corrigido capturando a exceção com "Errocmdlinhassuplementaresexcedidas" e tentando o comando com 1 linha a menos...

Fechando o tópico, para evitar uma discussão ainda maior.... Acho que o usuário "rdxdt" está agindo de forma inconveniente...

Você precisará rever sua lógica de programação... Autoefetuarpagamento não é compatível com os testes do Cielo Premia...

Humm... que estranho... será que o pessoal da NTK está ciente do Bug ? Poderíamos contornar o problema, pois o ACBrTEFD deve conseguir ler todas as linhas independente do campo 028... Ou seja, despresariamos a informação do campo 28 e usariamos o numero de linhas lidas pelo ACBrTEFD.... mas em todo caso, é um Bug deles...

Seu PAF-ECF só roda em um Estado ?

Verifique se não é configuração do seu Gerenciador TEF Se o problema persistir, favor informar o passo a passo para reprodução do problema usando o TEFDDemo...

Provavelmente você anexou o arquivo errado... pois o mesmo está idêntico ao do SVN atual

Você tem razão... apenas inverti a chamada dos métodos RightStr e PadR... por favor verifique se está OK

Parece que você fez alterações no Package, e o SVN não foi capaz de fazer o Merge, veja o final... Solução... apague esse arquivo e baixe novamente...

Oi Fabio, Obrigado por sua boa intenção ao doar os fontes... Mas mesmo a tarefa de transformar um fonte em componente do ACBr não é simples, e se depender de algum desenvolvedor ativo, provavelmente ela não ocorra tão cedo... Se tiver disposição de você mesmo terminar os passos necessários, ai sim, fica mais fácil para outros desenvolvedores do ACBr lhe ajudar... Exemplos: (não sei se algo aqui se aplica a seus fontes, pois nem mesmo os analisei) - Remover a dependências de Units específicas de uma versão do Delphi e/ou de API do Windows - "Assinar" todos os fontes do componente com o cabeçalho da licença LGPL - Usar nomenclatura de classes como demais componentes do projeto, Ex: TACBrAlgumaCoisa - Criar um projeto de Demo com o intuito de Testar o componente e Treinar os novos usuários (demonstrar o uso) - Criar um Package, com Imagem...

Muito Obrigado pela sua colaboração... Vou analisar os fontes ainda essa semana... e volto a postar...

O erro 500 não significa apenas proxy... Veja: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

O ACBr usa as DLLs dos fabricantes para gerar arquivos que dependam da leitura da MFD... Se o seu fabricante tiver .SO para Linux equivalente a DLL, deve funcionar... Não existe comando direto para leitura da MFD, pois a mesma é criptografada, e os fabricantes não divulgam como abri-la

Acredito que manter 2 programas com a mesma funcionalidade pode trazer problemas... - Diferença de funcionamento para a mesma funcionalidade. - Aumento da manutenção do código - Confusão dos usuários (qual versão é melhor ? qual está com problema ? qual programa devo usar ?, etc ) Faça um teste, e verifique se manter ambos os programas impacta muito a performance ou consumo de recursos de sua máquina... eu acredito não... Dificulta um pouco a instalação.... mas isso é feito apenas uma única vez...

As DLLs da pasta Trunk\DLL estão na versão correta 0.9.8.14