EMBarbosa

Saiu alguma notícia sobre essas alterações no Discado?

Com certeza isso resolve o problema da Bematech. Mas aí será que não teria faer o mesmo em outras impressoras também?

Tem o driver que vem com o WinITFI que pode ser feito download no site da Bematech. Mas eu não testei se é o mesmo, se funciona ou como funciona.

Então, é justamente isso que estou dizendo. Que já está quebrada no caso de ECFs Bematech. A função MontaDadosReducaoZ é quem é responsável por montar em DadosReducaoZ e ela monta como NumGNFC. Mas a função da GetDadosUltimaReducaoZ de ECFs Bematech está retornando NumNFC

O validador não reclama de faltarem os outros campos? Se possível, anexe as alterações e mencione a base legal.

O título do seu post está incorreto, você não quer mais de uma impressora fiscal. Você quer mais de uma impressora, sendo que uma delas é fiscal. Posso estar até enganado, mas acho que não tem nenhum problema desde que o que for emitido na impressora não fiscal não seja parecido com um cupom, nem seja emitido com base na tela de vendas do seu programa. Uma impressora não fiscal é como uma outra impressora qualquer.

A ideia não é decriptografar o Arquivo Auxiliar Criptografado (AAC), mas alterar o GT, o CRO e o Número de Série que ficam armazenados no AAC. E fazer isso um por vez. Se você usar o ACBrAAC você pode usar o DEMO do ACBrAAC alterando a senha usada nele para a mesma que usou no seu programa. Ou levar o programa que você usa para cadastrar o ECF no ACBrAAC.

Talvez o arquivo BPL esteja sendo jogado na pasta errada. Ou talvez buscado numa pasta errada, como a de uma outra versão do Delphi ou Lazarus Faça uma busca por ACBr*.bpl em todo o computador e verifique. Se for o caso, apague todos (mande pra lixeira), inclusive de outras versões do Delphi. Faça um build e reinstale o ACBr completamente. EDIT: A propósito, tenha certeza de que está com a versão mais recente do SVN

rmauro, veja: viewtopic.php?f=23&t=6401

Eu estou resolvendo pendências para o processo de homologação do software da empresa em que trabalho. Infelizmente, só vou poder dar atenção a isso na semana que vem. Talvez outro desenvolvedor possa verificar antes disso...

Então a área correta é de classificados. Estou movendo o tópico para lá.

Só pra constar: A alteração no ACBrTEFD foi feita na revisão 3741 deixando assim o componente com um comportamento idêntico tanto no LINUX como no Windows e com um pequeno ganho de performance no Windows.

Você quer adquirir/fazer parceria sobre esse software?

Olá gabrielhw, Você deve usar a Especificação de Requisitos PAF-ECF 1.12 ou pelo menos o 1.11 para se preparar para uma possível homologação. Então, verifique o ATO COTEPE no site da receita, por esse link http://www.fazenda.gov.br/confaz/confaz/atos/atos_cotepe/2008/ac006_08.htm. A atualização para o PAF-ECF 1.12 foi mencionada nesse link do fórum

Mas você não precisa tentar cancelar o cupom, afinal o ECF está desligado. É impossível cancelar o cupom com o ECF desligado. Você precisa enviar um NCN para cancelar a transação e só. E até onde me lembro, o componente já faz isso automaticamente, como pode-se ver no código. Você tentou reproduzir o erro no DEMO do ACBrTEFD?

Verifique a propriedade ACBrECF.Retentar. Ela deve estar false. Edit: Relendo seu post, na verdade, não tenho certeza que entendi o problema... Se não estiver relacionado com a sugestão acima, poderia reescrever destacando o problema?

Ele foi desenvolvido para possibilitar a implementação de todos os perfis gerando o arquivo final. O perfil é o que define os registros que serão gerados.

Obrigado johnbh3.

Não ouvi falar de nada disso. Apenas esse tópico, mas é sobre SPED Fiscal, e apenas para o RS.

Se os arquivos são diferentes é normal que um não gere o erro. Você pode comparar os dois arquivos gerados com um programa de diff (Winmerge, por exemplo). Veja o que é diferente. Isso pode dar uma sugestão do que é importante para o Validador.

O ECF Contribuições é o novo nome do Pis/Cofins sim. É que eles adicionaram mais coisas além do Pis/Cofins e resolveram mudar o nome. Sobre o erro em si, acho melhor fazer uma consulta perguntando sobre o erro. Me parece um erro do validador e não do arquivo.

Se houver alguma sugestão para correção, queiram anexar por favor.

O change-log do SVN costuma ser até mais completo que os arquivos. Inclusive é aconselhado você verificar o log do SVN ANTES de fazer o update. Por exemplo, quando há uma quebra de compatibilidade mesmo que pequena, essa atitude pode ajudar você a evitar uma atualização do ACBr sem estar preparado para implementar o que for exigido.

Obrigado Wilson. Corrigido na revisão 3709

dá uma olhada neste tópico: