EMBarbosa

Como o JNP explicou, não é preciso imprimir nada nesse caso... A ideia do requisito é: E se o consumidor quiser que o nome dele apareça no cupom? Afinal, cupom fiscal é documento fiscal. Se devidamente identificado pode ser usado para comprovar a compra assim como uma nota fiscal. Assim, o requisito cobra a possibilidade da impressão dos dados, não obrigatoriedade da impressão.

Pessoal eu editei as mensagens. Não é necessário repetir todas as impressoras na lista para adicionar ou excluir uma. Apenas crie uma mensagem com as impressoras que não estão alistadas. Adicionei as impressoras que o juliomar citou no primeiro post. Assim o primeiro post sempre ficará listando todas as impressoras suportadas. Coloquei um asterisco no fim do nome das impressoras que foram adicionadas por último, apenas pra constar. Também adicionei "Data da última atualização". Valeu!

Não seria 2011?

Então, você acabou de explicar o porquê de não haver o mesmo para o ACBrMonitor: Quem usa no dia a dia não tem condições/não está disposto a ajudar (seja financeiramente ou com o tempo)... Por que outra pessoa, que não o usa, iria parar seu desenvolvimento para fazer isso? É muito fácil cobrar da "comunidade" por atualizações mais rápidas. Mas muitas vezes esquecemos que nós somos a comunidade...

Se você deixar aqui a resposta que lhe ajudou isso pode ajudar outras pessoas...

No demo?

ou VMWarePlayer... Ele agora permite criar máquinas virtuais, e continua sendo grátis.

Não sei se entendi bem sua dúvida iran mas... A pessoa que quer gerar a LMFC por CRZ já deve saber de qual COO até qual COO ela quer gerar... Acho que não é possível a pessoa descobrir qual o COO da ReduçãoZ de uma data sem fazer uma leitura da memória fiscal (exceto, é claro, usando o Dados da Ultima Redução).

Que maravilha!

A função responsável por esses códigos atualmente seria a Bematech_FI_ArquivoMFD... Acho que a gente poderia implementá-la. A diferença dela pra atual é que ela usa chaves passadas como parâmetro para gerar o arquivo e assiná-lo automaticamente com EAD. A gente poderia contornar isso passando uma chave padrão já dentro do código do ACBr e remover o EAD apagando a última linha gerada do arquivo. Eu estou querendo fazer isso já algum tempo, mas não tenho conseguido tempo hábil...

Vamos lá, Assim como o Daniel, muitos outros programadores (incluindo eu), usam o emulador sem problema do jeito que está explicado no tópico. Se não está conseguindo, tem algo errado na sua máquina (pode até ser na configuração do emulador, ou não) ou no seu aplicativo. Teste primeiro com o DEMO, o aplicativo na pasta Exemplos/ACBrECF. Se não funcionar, anexe aí: * impressões das telas de configuração do emulador de portas; * impressão da tela de configuração do emulador da impressora; * impressão da tela de configuração do DEMO quando deu o erro; Se estiver desenvolvendo para o PAF, vai precisar da DLL da Bematech para executar algumas funções como "ArquivoMFD" e "Espelho da MFD por DLL" que não são possíveis atualmente por comunicação direta. Não tem nada a ver uma coisa com a outra, mas sua DLL não é a mais nova... a DLL da Bematech já está na versão 5.10.8. (http://partners.bematech.com.br/bemacas ... afi32-dll/)

André, Será que um bom e simples exemplo no DEMO do ACBrECF seria o NaoFiscalCompleto ou o não pois o cupom Não Fiscal deveria estar aberto antes?

Só lembrando que não há nenhuma objeção a princípio caso haja alguém que se disponha a fazê-lo.

Sobre o emulador de portas seriais, veja: http://www.forumweb.com.br/foruns/topic ... -porta-com

Se esse erro estiver acontecendo dentro do Delphi enquanto está debugando, é normal. O componente já trata isso da maneira correta. Você pode até ignorar esse tipo de erro. Você mencionou que o erro de pouco papel aconteceu ao tentar fazer uma leitura X, mas no log não tem nada sobre leitura X. Esses erros que acontecem, você precisa verificar o log assim como faria com as DLLs e verificar o erro. O Daniel já deu a dica, mas reitero a necessidade de estudar bem o Exemplo do ACBrECF e seus métodos assim como você estudaria as DLL dos ECFs que usaria no seu aplicativo.

Há uma propriedade do componente chamada ArqLOG (ACBrECF.ArqLOG) que identifica o nome do arquivo que vai ser gerado. Se deixá-la em branco ele não gera o log, caso contrário o componente gera. Se você não indicar um caminho além do nome do arquivo, ele cria o arquivo no diretório do seu programa.

Você tem o log do ACBrECF disso Izaias?

Nem leva as crianças pra escola. EDIT: Outra opção é usar as Units dos componentes Indy. Veja aí como: http://delphi.about.com/od/objectpascal ... 5-hash.htm

Apenas um processo pode acessar a porta por vez. Tanto o ACBrECF como a dll acessam a porta. Logo, você precisa desabilitar o ACBrECF antes de acessar com a dll.

Alterações de Alíquota, Forma de pagamento e leituras X até onde sei não é preciso gravar não... Reduções Z você precisa gravar com certeza. Veja Requisito XXV.

Tem razão Marciano, vou verificar. EDIT: Já subi no SVN. Muito obrigado.

Sim. Caso contrário vamos ter que identificar os modelos no momento da inicialização. Atualmente fazemos algo parecido com as impressoras Bematech, verificando se são pós MP25 ou não...

é isso daí? http://www.daruma.com.br/ddcmkt/ddcmkt_001_11.html

Tópico duplicado. Continuar em viewtopic.php?f=6&t=1297

Infelizmente, não tem outro jeito. Esse é uma das coisa mais difíceis de se controlar em um projeto de software. Se tivéssemos um jeito de fazer isso de forma automática seria melhor...