Daniel Simoes

Sim, realmente... a modificação é possível, penalizaria um pouco o tempo de carga, já que ele tentará verificar todas as 20 posições...

Não há nada desenvolvido para essa integração... R$ 3,55 por consulta simples de CPF ?? É isso mesmo ? Vale a pena ?

Provavelmente o cliente passou alguma informação errada...

Qual o modelo do equipamento ? Ou ainda, qual arquivo devo olhar no link indicado ??

O código atual para de procurar assim que encontra uma posição não programada... Na verdade acho que seria um erro do "lacrador", programar uma posição superior e manter uma posição inferior vazia... A correção pode ser aplicada com o próprio ECFTeste, assim como o Lucas acabou descobrindo, ou seja, programando a posição vazia...

Na aba ECF há configuração para essa propriedade...

Anexe o LOG gerado pelo ACBrECF

Você precisaria encontra o manual do equipamento que descreva o funcionamento do protocolo serial do mesmo...

Por favor tente com a versão atual do SVN... (se necessário renomeie a Unit que você alterou antes de atualizar )

Concordo Isaque... apliquei a seguinte modificação:

Humm.. parece que você está informando a I.E. errada para o CNPJ, veja o resultado da consulta em: http://www.sintegra.gov.br/ pelo "CNPJ" do contribuinte

Não há nada para ser corrigido no ACBrValidador... tente validar a I.E. com "0" na frente usando o site: http://www.sintegra.gov.br/

Seus fontes estão atualizados ?? Se não me engano isso foi corrigido recentemente...

Use o modelo ecfSwedaSTX

Não há nada de errado com o ECF ou com o ACBr, você que que está fazendo algo errado... A mensagem retornada pelo ECF e bem clara... Ele não permite programar uma forma de pagamento que já existe.... Afinal porque iria querer programar "Dinheiro" se ele já existe ???

Você pode ter várias formas de pagamento, até mesmo com o mesmo indice... como por exemplo: 02 CARTAO 20,00 02 CARTAO 20,00 01 DINHEIRO 10,00 Mas nem todos ECFs suportam a abertura de 2 Vinculados (CCD) com o mesmo índice de forma de pagamento (a Bematech não permite) Por isso é muito melhor "bufferizar" tudo em uma única forma de pagamento 02 CARTAO 40,00 01 DINHEIRO 10,00

Os homologadores não permitem nomear as formas de pagamento com os nomes das Bandeiras... Precisa ser algo genêrico, como "TEF", "CARTAO", etc Veja a msg de erro no Log gerado pelo ACBrECF...

Exatamente isso que quis dizer... E o problema é de difícil diagnóstico pois aparentemente não ocorre em todos os ECFs... e Red.Z é apenas 1 por dia

@Isaque, A página do IBGE não prevê filtro por UF http://www.ibge.gov.br/home/geociencias/areaterritorial/area.shtm @Jeter, Obrigado pela sua contribuição... já disponível no SVN, (apenas acrescentei um "break" após a atribuição do cód. do IBGE)

Você não instalou todas as DLLs... use a busca do fórum e rapidamente você achará vários tópicos sobre o assunto Veja esse por exemplo:

Ainda não compreendi o problema... Será que seus fontes estão idênticos ao do SVN ? Experimente pagar os fontes e Demos com o icone vermelho do SVN... baixar novamente do SVN e testar...

Na Unit atual, o RoundTo não está mais na linha indicada... qual é o conteúdo da linha com o erro ? Em todo caso, a Qtd = 1 e o Preço Unit = 9,9... Nenhum desses casos seriam passíveis de erro de divisão por zero, no RoundTo Não está faltando algum patch para ser aplicado no seu Delphi ?

Provavelmente o que ocorre é que a impressora responde ao ACBr, após imprimir a Z e antes de iniciar os códigos 3D... O ACBrECF fica perguntando o status do ECF, e sabe que se o ECF não foi capaz de responder, é porque ele está trabalhando... porém nesse intervalo provavelmente o ECF está respondendo ao pedido de status.. Problema de difícil resolução... Acho que precisaríamos de uma segunda leitura de status no caso da Redução Z

Algum passo a passo de como reproduzir o problema usando o Demo ?

Sim, é proibido... Pelas leis atuais, o ECF deve ter a relação de 1 para 1 com o Computador do Caixa