Régys Silveira

Por favor anexe o arquivo alterado para que possamos verifica as diferenças, efetuar os testes e enviar ao repositório.

Algumas impressoras necessitam iniciar o dia para começar o movimento fiscal e emissão de cupons, isso geralmente é feito emitindo uma leitura X.

Veja ai, você está adicionando os D3 fora do loop dos D2, assim ele vai adicionar todos os D3 ao ultimo D2.

Poste a sua rotina para darmos uma olhada, provavelmente você está gerando os registros D3 separado do loop de geração dos D2, isso vai gerar a situação que o Juliomar explicou.

Sim isso mesmo, existem registros R06 que não tem R07 um exemplo é o relatório gerencial.

InfoRodapeCupom são propriedades que devem sair no rodapé do cupom fiscal, o identificapaf inclusive quando a impressora não permite informar o MD5 no campo correto utiliza essa propriedade para imprimir o md5 na primeira linha do rodapé. Um conselho, remova tudo que você usa para setar o MD5 do teu aplicativo e use somente o IdentificaPaf(), assim você terá certeza de usar o local correto conforme o tipo de impressora.

Você está colocando o MD5 manualmente? O IdentificaPaf() quando usado verifica o tipo da impressora e programa o md5 no local correto que seria a primeira linha do rodapé para impressoras mais antigas e nas impressoras mais novas o campo de baixo, após o rodapé. Ao que parece você está adicionando o md5 manualmente no rodapé, utilize somente o IdentificaPAF() ao abrir seu aplicativo logo após ter gravado o arquivo auxiliar e obtido o md5 do aplicativo.

Para cada um dos comprovantes citados você deve gerar um R06 e se esse comprovante possuir formas de pagamento (Registro de Venda, Comprovante Não-Fiscal) você deve gerar o R07 para cada forma de pagamento registrada no ECF.

Um outro ponto de vista é o seguinte: Imagine que seu cliente por algum motivo qualquer troque alguma das dlls, é um situação remota, se você valida as dlls então você tem certeza que as dlls que estão ali são as que você usou para a homologação, porque baseado no MD5 você pode validar a alteração delas.

O ACBr utiliza comunicação direta, então ele funciona sem, mas para alguns menus do menu fiscal é necessário baixar a MFD da impressora e gerar arquivos, isso somente as dlls podem fazer porque a MFD e criptografada, então nessas opções o ACBr utiliza Dlls.

Concordo como Kiko, se calcular automático vai abrir uma porta gigante para muitas outras coisas e também suporte.

Obrigado , marque o tópico como resolvido

Se você não vai atuar na UF e não implementar o requisito o homologador vai colocar no laudo uma não conformidade, isso não vai te atrapalhar registrar o software onde não se pede o requisito, mas nos estados que obrigam o registro não poderá ser feito.

Tópico movido para o local correto.

Para a homologação e o fisco não importa a base de dados ou tipo de arquivos, desde que os dados estejam disponíveis quando necessário a fiscalização.

Utilize no ACBrNFeMonitor o seguinte comando: imprimirevento(<caminho do xml do evento>, <caminho do xml da nfe (pode ser vazio)>, <impressora>, <numero de copias>);

Você precisaria dar direitos de leitura e gravação ao usuário que está acessando o diretório, ou gravar em um diretório onde ele possa ler e escrever.

Também funciona em Fast-Report, mas veja, se for o ACBrMonitor somente está disponível o Rave.

Você deve usar um software para emular um par de porta virtuais conectadas o mais usado é o com0com, crie um par de portas, configure o emulador para uma porta e o seu software para conectar na outra.

O ACBr aceita normalmente.

Bastaria ligar o ACBrECF ao ACBrAAC e programar no ACBrAAC os eventos OnVerificarRecomporNumSerie e OnVerificarRecomporValorGT, o componente chama estes eventos quando estão programados ou emite o erro quando não estão, e estes eventos tratam os momentos onde o número de série não foi encontrado ou o Valor do GT não é válido permitindo recompor.

Tentou dar uma olhada no demo do ACBrETQ dentro da pasta exemplos?

Postei o link, inclusive aqui aparece o vídeo normalmente para rodar direto do post.