Daniel Simoes

Achei o manual em: http://www.desenvolvedoresdaruma.com.br/dr800/#s4 Por favor use o PosPrinterTeste.exe nesse equipamento e anexe o resultado do Teste de Tags de Formatação... Será algo semelhante ao ultimo relatório postado nesse tópico: O manual é o mesmo da DR700.. e o comando que usamos parece correto... (ela deveria aceita ambas as sintaxes, conforme o manual)

Eu precisaria do manual técnico dessa impressora... você está me dizendo, que esse modelo novo, não é compatível com o EscPos Daruma ? usaram outra linguagem ?

Verifique se você configurou corretamente o número de colunas em "ACBrPosPrinter"

Apliquei a seguinte melhoria, seguindo a sugestão para a Bematech: -- ACBrECFBematech -- [-] Ajuste para correta verificação do Erro "Sem Papel" (por: DSA) if TestBit(fsST1, 7) or (fsST3 = 11) then DoOnErrorSemPapel

"FS-700 M D-PRINTER" é uma impressora Fiscal ? Favor informar o Link do fabricante contendo as especificações da mesma

O ACBrECF somente "conversa" com Impressoras Fiscais

O problema é que a MP4200, no comando "CarregaAliquotas" retorna o Valor do Imposto e não a BASE de Calculo como é o esperado... Veja nos fontes em ACBrECFEscEcf.pas:3035 Porém isso só afetará, se você usar o comando "DadosReducaoZ" (antes da Redução Z) O comando "DadosUltimaReducaoZ" funcionará corretamente, retornando a Base... Veja ainda o ACBrSerial-Change-Log.txt, onde há um tratamento para a Bematech MP4200, no caso de leitura de DadosUltimaReducaoZ com "CRZ > 255"

Apliquei parcialmente as modificações sugeridas, e promovi alguns ajustes e refatoração no código proposto... Não aplicado, pois ACBrECF suporta acentos, desde qua a Página de código esteja corretamente configurada Troca de #13+#10 por #10 já ocorre, em "AjustaLinhas"... Não aplicado, pois ocorre o mesmo efeito da implementação atual Não aplicado. Precisamos de embasamento legal para a modificação e não apenas a opinião do Homologador Não aplicado. Recentemente foi aplicada modificação por Juliomar, com Try/Finally Não compreendi a necessidade. Parece que irá interferir em outros comandos. Favor detalhar qual é o problema e como reproduzir o mesmo... Não aplicado... O código sugerido, parece ter a mesma implementação da classe Pai Não aplicado. Não compreendi a necessidade. Remover as quebras de linha, não parece correto A implementação sugerida pode ocultar outros Exceptions, como por exemplo falha na comunicação. A implementação atual já irá processar pulos na programação de alíquotas, pois ignora os erros quando "ErroCMDAliquotaNaoCarregada" Não aplicado. O teste já existe no final do mesmo método: if (fsST1 = 128) or (fsST3 = 11) then // 127 = Bit 7 ligado DoOnErrorSemPapel else raise EACBrECFSemResposta.create(ACBrStr(ErroMsg)) ;

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Favor leia as regras do fórum.

Por favor use a busca antes de fazer questionamentos... http://www.projetoacbr.com.br/forum/index.php?app=cse&q=ACBRPOSPRINTER USB

Use os eventos QuandoGravarArqINI e QuandoLerArqINI.. com eles você pode gravar a memória do ECF onde desejar, como por exemplo no seu BD...

Não... ele será uma versão do MonitorPLUS, que não dependerá do Servidor X.... Mas hoje não temos um gerador de DANFE compatível com isso... (O FortesReport e o LazReport dependem do servidor X)... A ideia no futuro, é implementar um DANFE usando alguma classe que gere o mesmo em PDF

No momento esse projeto não está operacional...

Acredito de SIM... mas sem o manual deles fica difícil saber com certeza...

Mas o "100-000 = 9900", é algo que o SiTef está devolvendo para você... referente a transação que ele acabou de realizar... Pelo que você descreveu, você deveria iniciar um novo comando (ver manual), enviando a maneira de pagamento...

Tudo indica um erro de configuração no Provedor SMTP O provedor está respondendo ser capaz de fazer uma autenticação "CRAM-MD5", quando na verdade, ela é "PLAIN"... Provavelmente, se fosse tentada a autenticação "PLAIN" primeiro, a autenticação ocorresse com sucesso... O Erro do provedor, é responder que ele é capaz de autenticar usando "CRAM-MD5", quando na verdade, ele não o é... Aplicado um "workaround", que tenta a autenticação PLAIN por primeiro... A correção está no SVN... Commit [r12331]

Notei no seu Log, que houve um erro anterior: -- 08/09 11:32:00:517 -- Ativando a porta: COM3 -- 08/09 11:32:00:533 ----------------- ERRO ----------------- Communication error 5: Acesso negado ---------------------------------------- -- 08/09 11:32:00:533 ----------------- ERRO ----------------- Communication error 6: Identificador inválido ---------------------------------------- Me parece que algo ocorreu com a Porta Serial virtual, e ela ficou inacessível... (Acesso negado)

Não compreendi o que está faltando... Você precisa devolver alguma informação para o SiTef ?

Sim, porém atente para a licença do ACBrMonitorPLUS, que é "GPL", ou seja, toda e qualquer nova versão do mesmo, ou parte do código do mesmo, deve ser distribuída como GPL... Você pode ler a licença na integra, em "licenca.txt"

Isso não tem relação nenhuma... Veja na Especificação Técnica do ECF 09/09... o Ultimo caractere é o CheckSum Para investigarmos o problema é necessário podermos reproduzir o mesmo, no ECFTeste

O ACBrMonitorPLUS é uma aplicação 32 bits... Verifique se você instalou: OpenSSL, LibXml2, libXmlSec em 32 bits... veja ainda, esse post:

Desculpe... não tenho interesse... (TLDR)

Notei que são muitas mudanças sugeridas... mas não há uma atualização no ACBrSerial-Change-Log.txt... e portanto fica difícil compreender a necessidade das modificações, se elas são melhorias, correção de bugs, etc...

Não compreendi muito bem o seu, post... Por favor anexe o log gerado pelo ACBrECF...

A lei apenas especifica que o Lojista, deve guardar o XML por 5 anos... como isso será feito... é de implementação de cada um...