Régys Silveira

O duro é que quem precisa homologar fica em um empasse, complicado para nós que temos que lidar com essas leis, tem horas que penso que eles não pensam antes de publicar estas coisas. O mais interessante é a parte da lei que dizia que a ER não poderia sofrer alteração pelo prazo de 1 ano a não ser correções, isso não é uma correção é uma mudança, ou seja, esquece o que está escrito.

Marquei como resolvido. realmente seria bom pegar de lá, mas como ainda tem gente usando o jeito antigo, acho que não seria uma boa ideia por enquanto.

Cleber eu chequei aqui, nos fontes do ACBr e meus fontes, precisa preencher o P1 e o E1, assim ele coloca corretamente, mesmo não sendo mais abordado na ER, ele foi mantido para retrocompatibilidade, visto que vários usuários ainda estão homologados na ER antiga.

Cleber, você estava atualizado? Porque eu já homologuei 3 vezes na ER nova e não aconteceu isso.

Esse erro geralmente ocorre porque você tem a dll em vários lugares, o recomendando e ter ela somente no path do aplicativo, juntamente com as dlls e arquivos que vem junto da bemafi dll. Verifique também o arquivo .ini de configuração da dll se o diretório está ok, geralmente o ACBr seta ele corretamente, mas dependendo de como instalou tudo pode ser que o ACBr não consiga configurar corretamente o ini.

Anexando um log do ACBrECF fica mais simples de te ajudar.

Você está misturando as coisas, o manual não fala nada de quando deve ser baixado o estoque, o que ele fala é quando se deve ou não atualizar o estoque em um software a parte. Se você desenvolve stand-alone, tudo está dentro do software, portanto, não existe integração com outro, então o estoque é baixado normalmente. Não misture este estoque também com o estoque gerado ao imprimir o primeiro documento no dia, esse estoque do primeiro documento é para geração de arquivo, ele é um flash, não pode ser o estoque atual. Então na verdade você tem "dois" estoques, um para geração do arquivo que é um flash e outro para venda, que é você quem controla como bem entender.

Sendo stand-alone, ele próprio ira controlar o estoque somente dele mesmo.

O problema é esse então, você vai precisar editar os dois pacotes para que usem o fortes para fr3. Você pode fazer o seguinte, desmarque os dois no ACBrInstall, proceda a instalação, entre no delphi e instale os dois pacotes que faltam manualmente. Antes de instalá-los manualmente, você edita eles e remove as condicionais dos pacotes por versão do fortes, forçando ele a utilizar a que você tem, ou simplesmente deixe somente a versão XE3. {$IFDEF VER150} RLibWinD7vcl, vcljpg;{$ENDIF} // D7 {$IFDEF VER200} RLibWinD2009, vclimg;{$ENDIF} // D2009 {$IFDEF VER210} RLibWinD2010, vclimg;{$ENDIF} // D2010 {$IFDEF VER220} RLibWinDXE, vclimg;{$ENDIF} // XE {$IFDEF VER230} RLibWinDXE2, vclimg;{$ENDIF} //XE2 {$IFDEF VER240} RLibWinDXE3, vclimg;{$ENDIF} //XE3 <----------- deixe somente essa {$IFDEF VER250} RLibWinDXE4, vclimg;{$ENDIF} //XE4 Lembrando que o ideal e ter a versão correta, mas esse é um quebra galho que vai funcionar enquanto o fortes não libera a nova versão.

Como eu lhe disse, vai ser lançada uma exceção, basta tratar ela com um bloco try..except.

Verificou se tem alguma quebra de linha no XML?

Pelo seu log você está tentando instalar as versões "fortes report" do boleto e danfe da NFS-e, e o pacote RLibWinDXE5 do Fortes não foi encontrado, tem certeza que o fortes tem versão para o XE5? Se sim, o seu fortes está atualizado?

Mas isso o ACBrInstall faz sozinho, basta não marcar para usar o OpenSLL na primeira tela, você deve ter marcado por isso ele tentou compilar usando ele.

Deve ser um problema pontual então, somente para essa classe. Não tenho uma impressora com fiscnet aqui, vou tentar achar alguém para fazermos mais testes.

Verificou se não tem a ver com o Encoding?

Poderia confirmar se o mesmo ocorre com outros modelos de impressora? Daruma ou Bematech por exemplo.

Posso estar enganado, mas geralmente você não envia XML assim, precisa primeiro encodar em base64, ei você envia e o outro lado recebe e decoda.

O que você fez não está certo, a propriedade imposto deve existir no componente, se não existe, tem algo errado na sua instalação do ACBr. Você instalou o ACBr manualmente ou utilizando o ACBrInstall? Se foi manual, provavelmente não setou as library paths do delphi corretamente ou não compilou o pacote ACBrNFe corretamente.

Mas esse tipo de erro o cStat você não trata o cStat, trata o erro, por isso que não entra no "for". Esse erro é uma exceção lançada pelo componente.

Você deve ler sempre os dados de retorno das notas fiscais, seguindo seu exemplo ficaria mais ou menos assim: for i := 0 to ACBrNFe1.NotasFiscais.Count -1 do begin cStat := IntToStr(ACBrNFe1.NotasFiscais[I].NFe.ProcNFe.cStat); xMotivo := ACBrNFe1.NotasFiscais[I].NFe.ProcNFe.xMotivo; nProt := ACBrNFe1.NotasFiscais[I].NFe.ProcNFe.nProt; ChNFe := ACBrNFe1.NotasFiscais[I].NFe.ProcNFe.chNFe; end;

Tente ao invés de ".\teste.txt" utilizar o caminho completo.

Se não estou enganado a Bematech é uma das que não aceita, talvez os modelos mais novos sim, não tenho agora para testar.

Como eu disse depende de cada software e situação, existem softwares que lançam tudo no caixa no momento que acontece, isso depende muito de como você projetou o aplicativo.

Utilize o método identificaConsumidor(..), mas veja, nem toda impressora fiscal aceita informar o cliente após aberto o cupom.

O arquivo não é binário, é um arquivo TXT, que na verdade juntou todos os arquivos gerados anteriormente em um só arquivo. O registro E2 conforme descrito na ER deve ser gerado ao imprimir o primeiro documento fiscal do dia. O layout está correto, talvez você não esteja informando o campo verifique o demo do ACBrPAF para maiores informações, eu mesmo homologuei 3 aplicativos já na ER 02.01 até o momento sendo um deles para todos os perfis e não foi encontrada irregularidade. Essas e outras dúvidas já foram amplamente discutidas no fórum, faça uma busca e encontrará tudo que precisa.