EMBarbosa

essa DLL faz parte do projeto OpenSSL. Você a pode baixar pela internet. Mas existe ela na pasta do ACBr. Veja trunk\DLLs\OpenSSL.

Boa Fernando!

Olá Marcelo, O componente não está completo. É por isso que está na pasta Branches. [moderação] estou movendo esse post para área de dúvidas gerais, visto que não tem relação com legislação...

Você precisa definir o que vai mesmo precisar... e o que não. Precisa saber quais as legislações estão vigentes no seu estado. E por aí vai... Vou tentar reunir algumas informações de forma resumida: (observe que os links são de alguns estados específicos, o que pode não ser o caso do seu estado, mas provavelmente lhe dará alguma ideia.) ECF é o Emissor de Cupom Fiscal (em geral, a Impressora Fiscal) Manuais... (alguns estão abaixo) Manual Fiscal do Usuário de ECF - Para o usuário final do ECF. Indica como ele deve agir com o ECF. Perguntas e respostas PAF- Programa Aplicativo Fiscal (ou seja, o seu programa PDV quando precisa agir de acordo com as normas estabelecidas pela receita.) Requisitos técnicos para PAF - uma seleção das leis em vigor relacionadas com o PAF. RAFPAF (Roteiro de Análise de Programa Aplicativo Fiscal - PAF-ECF) - Serve para dizer exatamente o que seu programa deve fazer para ser homologado no PAF. Pode ser encontrado aqui RAFPAF-ECF - Requisitos Técnicos Comentados. Também pode ser encontrado aqui Manual do Desenvolvedor de Programa Aplicativo Fiscal (PAF-ECF) Serve para dar uma idéia do que você vai ter que implementar no seu sistema. TEF O TEF é a comunicação com programas das operadoras de cartões... http://www.fazenda.mg.gov.br/empresas/ecf/informacoes/solucaotef.htm http://www.forumweb.com.br/foruns/topic/46063-tef-homologacao Vou ter que sair, depois vou tentar voltar com mais informações... talvez outros usuários podem ajudar também... EDIT: PS: A tag de url não está funcionando no fórum EDIT2: Adicionado outros documentos.

Esse tipo de informação seria melhor você verificar com o fabricante. Se não está sendo retornado e deveria, é bug ou então funcionalidade não implementada... Você mesmo pode verificar o código fonte e analisar... é por esse motivo que o ACBr é OpenSource. ArqMFD eu não tenho certeza, mas dos DadosReducaoZ e DadosUltimaReducaoZ nós fizemos algumas implementações faz pouco tempo (alguns meses).

O ACBrECF só faz comunicação com porta serial. Sua impressora USB deve criar uma porta Serial Virtual e aceitar comunicação por meio dela. Se isso for possível, o ACBrECF vai conseguir se comunicar com ela sem problemas.

Olá ESsantos, entendo seu desespero. Mas fazer um "UP" com 4 horas de diferença não vai ajudar. Talvez aconteça justamente o contrário. Lembre-se que os usuários aqui são voluntários e estão todos com os mesmos prazos que você, talvez até menos. Você não paga pela assistência que recebe. Estou falando isso pois no fórum anterior já tivemos esse tipo de problema. Por favor não faça isso novamente. Voltando ao seu problema, tente analisar o log do ACBrECF e do ACBrTEF. Talvez aumente o timeout do ACBrECF para ele dar mais tempo pra executar o comando. Se não conseguir resolver anexe aí os logs.

Pelo que me parece, há alguma requisição que o GP encontrou pendente e não está conseguindo cancelar. Se você está em testes faz uma limpeza nas pastas req e resp. Feche o aplicativo, o GP, e apague quaisquer arquivos lá dentro. (.sts, .tmp, .001, etc...) Olhe também na pasta do seu aplicativo visto que o ACBrTEFD faz uma cópia temporária desses arquivos pra justamente cancelá-los em caso de erro. Apague-os também.

viewtopic.php?f=5&t=899

Olá pessoal, Só gostaria de compartilhar algo que vi saindo hoje no site da fazenda. Embora não temos ainda nada definitivo sobre o CF-e, ele já está fazendo parte do SPED. Foram acrescentados registros C116, C800, C850, C860 e C890 no Bloco C para tratar desse novo modelo de documento. Fiquem atentos. http://www.fazenda.gov.br/confaz/confaz ... 046_10.htm http://www.fazenda.gov.br/confaz/confaz ... 009_08.htm A propósito, acho que vamos ter que atualizar isso no SPED.

Isso daí acima é a correção né?

e você testou assim no prompt e funciona? É que eu não tenho uma dessas aqui pra testar... Em caso afirmativo, anexe o log do ACBrECF...

Favor não fazer tópicos repetidos: viewtopic.php?f=5&t=970

é o mesmo problema do registro 0300 veja viewtopic.php?f=12&t=915

Acho que no comando. O comando a ser enviado deveria ser uma sequência de Chars. De onde você tirou o LeInteiro e NomeInteiro="ECF"?

O problema acontece pelo visto no próprio souceforge. Parece que já estão corrigindo. Veja: http://sourceforge.net/apps/trac/source ... cket/17134

Olá, Acabei de observar esse mesmo erro no Demo. Está acontecendo no Delphi 2010. O motivo é que no método TBloco_0.WriteRegistro0300, onde é chamado LFill( IDENT_MERC ), o compilador do Delphi por algum motivo está usando a função LFill incorreta. Está sendo chamada a função LFill para parâmetros TDateTime ao invés da LFill para Integer. Abaixo uma correção provisória até que alguém tenha mais tempo pra verificar. ACBrEFDBloco_0_Class.pas linha 685 Add( LFill('0300') + LFill( COD_IND_BEM ) + LFill( IDENT_MERC, 1) + LFill( DESCR_ITEM ) + LFill( COD_PRNC ) + LFill( COD_CTA ) + DFill( NR_PARC, 0 ) ) ; [/code] EDIT: Se isso ocorreu aqui pode ser que ocorra em outros lugares também.

Não posso te afirmar com 100% de certeza sem analisar o seu próprio código, mas podemos fazer algumas suposições e ter alguma ideia baseado no que temos de informações desse vírus e do ACBrBoleto. Não sei qual o seu grau de conhecimento de funcionamento interno de anti-vírus mas acredito que saiba que existe o método de detecção chamado heurística. Esse método na verdade não identifica se um arquivo está realmente infectado. O que ele faz é analisar o arquivo binário e procurar algo semelhante entre ele e os vírus conhecidos. Encontrando um certo grau de semelhança, ele acusa o arquivo como infectado. Veja que o vírus citado é visa buscar os dados de bancos. Muito provavelmente foi desenvolvido em Delphi e deve ter referencias em strings aos sites. Pelo visto ele envia e-mails também. O que o ACBrBoleto faz justamente é usar dados sobre os bancos. Talvez isso em conjunção com os códigos do seu programa foi o suficiente para que o anti-vírus tenha detectado alguma semelhança no seu programa executável (ou seja no arquivo binário dele) com o vírus. Eu sou meio neurótico com questões de segurança, então mesmo acreditando que nada passa de um falso positivo, ainda assim, eu sugiro que você faça a verificação cautelosa. Talvez queira fazer o seguinte: Ponha o código na versão 1973. Depois faça Revert de uma das pastas alteradas na versão 1973 para a versão 1972. Faça o Build do seu projeto após o Revert. Passe o antivírus. Repita os passos 2, 3 e 4 para cada pasta alterada. Num dado momento vai perceber qual pasta contém a alteração que supostamente cria o vírus. Repita então os passos, mas ao invés de usar as pastas faça para cada arquivo na pasta até perceber exatamente qual alteração que faz isso.

Acabei de fazer uma verificação nas alterações enviadas nessa revisão (1973) e não achei nada de anormal. O único arquivo que não consegui verificar foi o ACBrBoletoFCLazReport.lrs; Parece que o seu Executável caiu no que chamamos falso positivo. Envie-o para o site http://www.virustotal.com/pt e coloque aí o resultado. Mas pra garantir verifique alguns desses sintomas: Presença do arquivo explori.exe na pasta do sistema Presença do registro de valor "explorer" e conteudo "\explori.exe" Na subchave: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run fonte: http://www.microsoft.com/security/porta ... ncos.gen!A"

Isso daí parece mensagem de heurística. Ou o seu projeto foi infectado ou é um falso positivo. Eu tenho Avira rodando na minha máquina, AVG-free em outra e não aconteceu nada. Talvez queira enviá-lo para http://www.virustotal.com/pt O que o André mencionou é válido. Use o WinMerge para diferenciar as alterações do seu código para o código do SVN e veja você mesmo o que foi acrescentado e que poderia gerar esse erro.

1) Eles vão se atentar aos testes. Só os testes e nada mais. No entanto os testes devem ser executados 100% de acordo com as instruções. 2) SIM. Você precisa de um ECF e do Pinpad físico. Caso não possua, ligue para lá antes e veja se eles podem emprestar. Não obstante você precisa enviar cupons fiscais pra uma pré-certificação. Como vai fazer isso sem o ECF? 3) Você precisa fazer o cadastro em ambas pra conseguir o material usado para certificar e conseguir também atendimento gratuito via telefone. Se ainda não fez o cadastro, faça. 4)

Acho que me confundi ou não soube explicar direito. O que o Daniel mencionou é correto. O D-TEF é com certeza BEM diferente do TEF Discado. EDIT: Puxa eu comi mosca nessa mensagem... Não sei pq... Estou editando pra dar uma resposta mais adequada... Mas então, o que eu queria dizer é que talvez o pessoal do D-TEF estivesse usando uma forma de comunicação semelhante (ainda não tinha ouvido falar do D-TEF naquela época). Infelizmente meu prazo pra trabalhar com TEF já se esgotou, agora só estou mexendo com outras áreas e correções de bugs. Não compensaria pegar mais um GP pra desenvolver...

Não. Esse registro ainda não foi implementado. Você pode usar algum dos registros já prontos como base.

Acho que você não entendeu a pergunta do Daniel. Se você disse que a transação é cancelada é porque você testou em alguma impressora. Em qual impressora (marca e modelo) você testou? Ainda assim, você não postou o log do ACBrECF

artur, O ACBrTEFD não faz CNF logo após o CRT quando está configurado pra multiplos cartões. A não ser que haja um erro. Primeiro você precisa saber o que o pessoal do D-TEF requer na comunicação, pra depois você estudar o ACBrTEFD e só então acertar o código. O motivo é que talvez já seja compatível. Por exemplo: O pessoal do Fast-TEF me disse uma vez que o programa deles funcionava em comunicação idêntica ao Sitef. Mas o Sitef já está implementado no ACBrTEFD, então não seria necessário fazer nenhuma alteração. Bastaria configurar o ACBrTEFD para trabalhar com o Sitef. Obs.: não sei se essa compatibilidade continua valendo ainda.