daniel.simoes

O nome da propriedade MsgPoucoPapel ficou pouco Intuitivo... Na verdade ele contem o intervalo em Segundos que o ACBrECF deve esperar antes de avisar novamente sobre o PoucoPapel... você pode programar o evento OnMsgPoucoPapel para customizar a sua msg... A propriedade AguardandoResposta é ReadOnly em ACBrECF... ela é Read/Write apenas na classe interna, ACBrECFClass

O Próprio Lazarus cria um backup... o Lazarus.old.exe

Obrigado pela dica mbcarniato, Elton ou Isaque... (ou algum outro desenvolvedor do ACBr que utilize D2010) poderiam verificar isso para mim ?

Se o banco de dados não for "fechado" ou criptografado, você poderia contratar um programador para fazer a rotina de geração do Sintegra

Estou atolado com o DJPDV e seu credenciamento nos estados... isso está consumindo muito mais tempo do que eu imaginava... Estou adiando o inicio do SAC para Agosto

Por favor forneça mais detalhes... copie trecho da lei, explique-a melhor... Coloca-lo em qual componente ??

Você variou apenas o último dígito do EAN13, que é justamente o digito verificador... Se os 12 caracteres iniciais são os mesmos, então é esperado o mesmo dígito verificador... Provavelmente a ARGOX está re-calculando corretamente o dígito verificador

F é o tipo de código de Barras.. Baixe no nosso SVN o manual PPLA e PPLB da Argox https://acbr.svn.sourceforge.net/svnroot/acbr/tools/

Como diria o Arnaldo Cesar Coelho... "A regra é clara" O próprio Sw.Básico do ECF está lhe retornando o erro de que o cupom não foi totalmente "pago" ... provavelmente você tem alguma diferença de Centavos no Pagamento que vc enviou... Estudando o LOG do ACBrECF isso pode ser esclarecido

William, Copie trecho do LOG gerado pelo ECF onde o problema ocorre..

De mais informações... poste um trecho de código onde isso ocorre... Trabalho a anos com a ARGOX e nunca ouvi falar de algo parecido... provavelmente é algum problema na sua rotina

Justamente para isso que já existe o evento... OnPAFCalcEAD...

Vc não pode ligar o Emulador e o ACBrMonitor na mesma porta COM, por isso vc obtem esse erro... Vc precisará instalar um virtualizador de portas seriais, que irá criar um PAR de portas seriais (já conectadas por null-model)... após isso ligue o emulador em uma porta e o ACBrMonitor na outra porta do par

Já atualizastes teus fontes ? Se SIM, e o problema continua, por favor proceda com as orientações do Post anterior: "Pode ser que o ECF esteja em um estado que não apto para enviar as informações... Quando isso ocorrer, experimente desligar e ligar o ECF... Tente tb acesso ao mesmo com a DLL do fabricante, quando o problema ocorrer."

Provavelmente não é no Emulador, e sim no programa Virtualizador de Portas Seriais... ainda mais se o Windows for 64 Tente o com0com http://sourceforge.net/projects/com0com ... m/2.2.2.0/

Aonde está o Sleep ?? Depois de Imprimir insira: Sleep(1000)

Adicione a Unit toda para analise...

Pelo que sei o BCB é capaz de compilar ObjectPascal... Vc precisaria ajustar os Packages e instalá-los

Varia de acordo com a versão do Windows... mas seria em Configurações de Impressora / Spool -> Imprimir diretamente para a impressora... (algo assim)

Acho que a rotina da SwedaSTX estava correta... precisamos desprezar os blocos que não são do Tipo '+' ou '-', pois eles não trazem a resposta final do comando solicitado Quando ativamos o ECF a primeira coisa que ele solicita é a informação do registrador 'I1', para verificar o modelo do ECF... se o ECF não devolve as informações para esse comando, não é possível continuar... Modifiquei a Unit para que o LOG fique mais claro, informando qual comando ele está tentando ler na ativação... Pode ser que o ECF esteja em um estado que não apto para enviar as informações... Quando isso ocorrer, experimente desligar e ligar o ECF... Tente tb acesso ao mesmo com a DLL do fabricante, quando o problema ocorrer...

Veja o Demo do AAC... ele é uma espécie de Gerenciador de arquivos criptografados... No ECFTeste da versão Lazarus eu introduzi uma aba AAC, que pode lhe ajudar a compreender melhor... Antes de disparar a Exceção acusando a diferença o ACBrAAC irá chamar o seu evento, e você deve, retornar nos parâmetros passados por "Var" o valor do GT se a recuperação ocorreu com sucesso...

Cuidado geralmente o Fisco entende que o uso do ECF SEMPRE é obrigatório, quando o cliente tem recursos para se informatizar... Veja esse post: viewtopic.php?f=8&t=2128 Não há como fazer o que vc quer... Impressoras paralelas não enviam Status... e o Spool do Windows sempre fica no meio..

Se vc ler a Lei e Roteiro do PAF-ECF as coisas ficam mais claras... A aplicação deve ser capaz de recuperar o GT (em alguns casos) quando o Valor do GT no arquivo não é o mesmo do ECF

Eu uso esse emulador sem problemas... Vc precisa de um emulador de portas seriais... existem alguns tópicos sobre isso aqui no forum

O ACBrAAC não limita o tamanho do Num.Série... verifique se vc informou o mesmo corretamente no momento da gravação O ACBrECF e ACBrAAC fazem todas as comparações, e apenas quando elas forem necessárias, como por exemplo na abertura do Cupom.... Muitas das dúvidas podem ser sanadas lendo os fontes do ACBrAAC... Veja os fontes do método: TACBrAAC.VerificarGTECF