EMBarbosa

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...

Pois então, foi por isso que postei os links de alguma das conversas. Acho que não abordam tudo que foi discutido. Se não me engano, tem mais posts sobre o mesmo assunto.

de uma pesquisada no fórum antigo que vai encontrar as respostas... Como pesquisar no fórum antigo -> viewtopic.php?f=18&t=402

que bom

Não sei se é exatamente isso o seu caso, mas dá uma olhada: http://www.forumweb.com.br/foruns/topic ... aliquotas/ http://www.forumweb.com.br/foruns/topic ... ota-t0000/ http://www.mercantilsist.com.br/ver_not ... ticia=1943

Que estranho... Talvez então seja melhor criarmos um perfil A e um perfil B sem verificações e manter os atuais com verificações. Daí é só escolher o Perfil que vai usar. Ou talvez, criarmos uma propriedade Booleana (ex.: CriticarArquivo) que Controlaria isso. Qualquer uma das duas sugestões permitiria desconsiderarmos as verificações apenas no PAF se as homologadoras pedirem. O que vocês acham? Exemplo de como o Código ficaria na parte mencionado pelo JNPace na segunda sugestão (eu prefiro essa...): if Assigned( RegC001.RegistroC300 ) then begin if RegC001.RegistroC300.Count > 0 then begin if (fCriticarArquivo) AND (FBloco_0.Registro0000.IND_PERFIL in [pfPerfilA]) then raise Exception.Create(ACBrStr('O RegistroC300, não deve ser gerado em movimentações de saída, no PerfilA')); end; for intFor := 0 to RegC001.RegistroC300.Count - 1 do begin[/code] Essa segunda alteração proposta não mudaria em nada para quem já usa o componente.

Já está no SVN. Favor conferir...