giulianon

Vou te responder baseado no que o homologador me falou. Vou homologar na semana que vem. Sou de SC e vou homologar na UNISUL. 1-Tem que fazer parte obrigatória do Menu Fiscal? Não precisa estar no menu fiscal 2-Posso simplesmente gerar o arquivo xml após a redução z e ter um módulo à parte, como se fosse um concentrador de xml´s pendentes e enviar os xml´s por esse módulo no final do dia? Ou tem que estar no próprio executável do frente de caixa e enviar automaticamente esse xml logo após a Z? A maneira como vão ser enviados os arquivos ainda não está disponível. 3-A partir de quando tenho que gerar esses arquivos? Foi prorrogado? Homologando na ER 02.03 já é obrigatório e não foi prorrogado. 4-Para usuários de ECF de MG (aqui não tem mais a homologação) esse bloco é obrigatório? Acho que tem que olhar na tabela de requisitos por estado para saber se é obrigatório ou não. 5-Como é a rotina do envio do xml? Idem pergunta 2.

Eu faço assim: Gerar ACBrEcf.ArquivoMF_DLL("arquivoMF.bin"); Assinar ACBrPaf.ead.AssinarArquivoComEAD("arquivoMF.bin"); Att.

Esse log anexado nem possui o comando de Venda de Item. Att.

O homologador me enviou os arquivos xsd. Segue anexo para que tiver dúvida na estrutura. Att. ReducaoZ.xsd Estoque.xsd

Hehehehe. Exatamente. Eu até solicitei para ele um validador mas ele me informou que ainda não está pronto. Sem roteiro de testes e sem validador fica complicado. Att.

Enviei o arquivo ao homologador (Vou homologar dia 3/3 - Unisul - SC), e ele me informou que está correto, ou seja, sem as alterações que você informou que o seu homologador solicitou. E segundo https://www.confaz.fazenda.gov.br/legislacao/despacho/2015/despacho-209-15 e a imagem, acho que de fato o seu homologador está equivocado. Att.

Tinha feito uma coisa errada. Alterei para try ff := TStringList.Create; ff.Add('EAD'+ACBrEAD1.CalcularEADArquivo('arquivo_mf.bin')); ff.SaveToFile('assinatura_arquivo_mf.txt'); finally ff.free; end; Mesmo assim não funcionou. Att. Resolvido. Pura burrice minha. Em vez de validar a assinatura do arquivo .bin estava validando o arquivo .txt Att.

Estou com o mesmo problema mas meu caso é no arquivo MF. Fiz o procedimento de gerar tudo(chaves e xml) novamente. Assino o arquivo de registros do paf por exemplo, e funciona perfeitamente. Gero o arquivo TXT com a assinatura do arquivo MF e ao validar no eECFc dá inválida. Já calculei a EAD e inseri manualmente no arquivo TXT mas também não valida. Por último utilizei o próprio demo do ACBrEAD, incluindo um botão gerar e assinar o arquivo. try ff := TStringList.Create; ff.Add('EAD'+ACBrEAD1.AssinarArquivoComEAD('arquivo_mf.bin')); ff.SaveToFile('assinatura_arquivo_mf.txt'); finally ff.free; end; Não funcionou também. Att.

Funcinou Daniel. Obrigado! Att.

Boa tarde! Já faz uns 4 dias que um cliente me relata que não consegue emitir a redução z pelo sistema. Olhando os logs notei que o retorno da impressora ao tentar emitir o z é o seguinte: Categoria: 13-Relógio Motivo: 3-Relógio com data/hora anterior ao último documento gravado na MFD. Enquanto não pude analisar o problema com calma, emiti o z pelo programa da própria epson. Hoje com tempo, atualizei os fontes (trunk2) para última versão e fiz o teste com o ECFTeste obtendo o mesmo retorno. Como esse problema só foi relatado por esse cliente, desconfiei que fosse algo da impressora e entrei em contato com a epson. Informei do acontecido e expliquei pro suporte que utilizava comunicação direta, driver para porta COM e o ACBr. Pra minha surpresa, o suporte da epson me pediu para análise o log do ACBr mesmo, e percebeu que ao enviar o comando de redução z, tanto com a data/hora, como sem data/hora o retorno era o mesmo. A diferença era que, ao emitir o z sem data/hora, automaticamente era enviada a data e hora 30/12/1899, o que segundo ele ocasiona o erro. Ele me pediu para enviar o comando de redução z sem parâmetro algum. Para fazer o teste, comentei as linhas no fonte (destacado abaixo) para enviar o comando sem parâmetro. Dessa forma funcionou. Questionei ele se era pra enviar sempre sem data/hora, e ele me informou que sim. Vi que ali tem a chamada recursiva, para caso falhe o envio com data/hora, a tentativa seja feita sem data e hora, mas essa solução nesse caso não funcionou. Como o cliente está usando a impressora agora, não tenho como depurar para ver o motivo da não chamada do método recursivo. Vou aguardar até amanhã para fazer isso e tentar identificar onde ocorre o problema. Em anexo segue o log gerado pelo ECFTeste. procedure TACBrECFEscECF.ReducaoZ(DataHora : TDateTime) ; begin if DataHora = 0 then { Aparentemente a DataHora é obrigatória na EscECF } DataHora := now ; EscECFComando.CMD := 21; //if DataHora = -1 then { Sem Data e Hora } //begin EscECFComando.AddParamString(''); // Sem Data EscECFComando.AddParamString(''); // Sem Hora //end //else //begin //EscECFComando.AddParamDateTime(DataHora, 'D' ); //EscECFComando.AddParamDateTime(DataHora, 'H' ); //end; EscECFComando.AddParamInteger(0); // Imprime no ECF try EnviaComando ; Sleep(800); // intervalo para ECF ficar operacional... RespostasComando.Clear; SalvaRespostasMemoria(True); except on E : Exception do begin // Woraround para Epson, para Erro de data na Redução Z if IsEpson and (EscECFResposta.CAT = 16) and (EscECFResposta.RET.ECF = 3) then begin ReducaoZ(-1); end else if (pos('5-1',E.Message) <> 0) then // Comando inválido para o documento atual. begin // Ficou algum Cupom aberto ? // Cancelando o Cupom em aberto EscECFComando.CMD := 31; EnviaComando; ReducaoZ(DataHora); end else raise ; end ; end ; end; acbrlog2.txt

Funcionou Daniel. Testado nos modelos ST1000, ST2000 e ST2500. Também testei a impressão de cheques e funcionou perfeitamente. Mencionei a impressão pois vi que tem um comentário no fonte da classe, no método de impressão, que diz que não foi testado por falta do equipamento. Agora foi Obrigado mais uma vez!

Bom dia pessoal! Fiz atualização para o trunk2, e efetuando testes percebi que a leitura da CMC7, a qual este tópico trata, e que juntamente como Daniel conseguimos ajustar para funcionar, deixou de funcionar. Analisando o código do método, notei que o mesmo foi refatorado. Analisando também o log gerado no ECFTeste, percebi que o comando de leitura é enviado, e que a impressora retorna corretamente o CMC7, só o método aparentemente fica aguardando por alguma resposta, e gera uma exeção um timeout. Ajustei os timetous pra mais e para menos e nada mudou. Segue anexo o log para análise. acbrlog.txt

Sim Daniel! Foi foi exatamente com esse driver que você tinha informado que o pessoal da Bematech te passou. Att.

Boa tarde! Não seria ACBrTEFD.TEFCliDTEF.Resp.NomeAdministradora ?

Mesma coisa comigo. Coloquei hoje pela manhã o sistema a funcionar conforme o recomendado (USB 2.0, Sleep(200) e driver novo), e acabei de receber uma ligação do cliente informando que travou do nada, no meio de um relatório gerencial. Complicado! Att.

Boa tarde colegas! Estou tentando imprimir cheque na impressora citada no título do tópico, mas conforme esse post http://www.projetoacbr.com.br/forum/topic/17939-código-para-impressão-cheque-em-epson-fbiii-h6000/#comment-110599, no primeiro parâmetro do comando deve ser passado número do registro(pré-configuração do cheque) e não o código do banco. Isso está no manual da epson página 115. Fiz o teste passando o número do registro e funcionou perfeitamente. Até pensei em passar o código do banco como sendo o número do registro, mas não vai ser possível, pois esse número do registro que o comando exige, permite apenas 2 dígitos, e os códigos dos bancos são formados por 3 dígitos. A assinatura do método para impressão do cheque é: ImprimeCheque(Banco: String; Valor: Double; Favorecido, Cidade: String; Data: TDateTime; Observacao: String); Agora gostaria de saber a melhor forma (sobrecarga no método, criar um outro método, etc) de alterar a classe pra dar suporte a esse comando, sem claro, quebrar qualquer tipo de compatibildade. Estou com a impressora aqui por tempo indetermidado, então estou a disposição para fazer qualquer teste que seja necessário. Ah e estou com o trunk1. Att.

Bom dia pessoal! Recebi hoje uma Bematech MP-4200 TH FIII de um cliente. De ínicio já aconteceram os travamentos conforme os relatos dos posts desse tópico. Seguindo as dicas (USB 2.0 e Sleep(200)) dos colegas, os travamentos realmente não aconteceram mais, pelo menos ao utilizar somente a impressora. Quando parti para os testes de venda "frenética" notei que travava de primeira. Percebi que isso acontecia sempre que o scanner (está ligado em outra porta usb com um adaptador serial->usb) era utilizado a primeira vez. Exemplo: - Utilizei o scanner pra consultar um produto e em seguida fui abrir o cupom. Trava. - Abri o cupom, consultei o produto com o scanner, e fui enviar a venda do item para a impressora. Trava. - Abri o cupom, vendi um item, e depois utilizei o scanner para consultar um produto. Vou subototalizar o cupom. Trava. Sendo assim, acredito que além dos problemas relatados nos outros posts, ainda exista mais esse problema que aparentemente é com o driver. Vou precisar me deslocar até o cliente para fazer o teste com o scanner ligado diretamente na porta serial (sem adaptador). Assim que efetuar esse teste lá, posto no resultado aqui. Em anexo o log que não apresenta erro. Simplesmente a comunicação para. Att. ecf_25092015113419.txt

Sim meu Windows é x64 e utilizo o com0com e funciona normalmente com o emulador. Junto com o emulador do Fiscnet tem um doc explicando como se faz a programação inicial dele. Basta seguir que você consegue facilmente fazer funcionar. Att.

Use o modelo ecfFiscnet. Att.

A função que você citou é utilizando a DLL. No ACBr existe esse tipo de parâmetro que indica o tipo de desconto apenas na venda do item. No subtotal não existe. Mas porque existe na DLL e não no ACBr? Os administradores do projeto me corrijam se eu estiver errado, mas acredito que seja pelo fato de que nem todas as impressoras sejam compatíveis com essa função. Dessa forma para manter o projeto compatível com todas as marcas e modelos esse comandos específicos de algumas marcas ficam de fora. Como o ACBrEcf permite o envio de comandos diretamente para as impressoras, você pode ver qual o comando e enviar. ACBrECF1.EnviaComando() Só que a partir desse ponto vão começar os IFs por marca e modelo e ai já viu o inferno que vai ser hehehehehe. Eu prefiro calcular o desconto e passar o valor. Att.

No Subtotaliza não existe. Você tem que fazer o calculo e passar o valor. Att.

Eu utilizo o modem da Daruma e funciona muito bem. A questão da acentução é uma limitação das operadoras e não dos modens. Att.

Na mosca Daniel! Continuei com o trunk e desmarquei a opção Range Check no projeto. A partir dai fiz todos os testes sem problema algum. Em anexo segue o print da opção para caso alguém se depare com o mesmo problema. Lembro que o meu Delphi é o XE. Acredito que nas versões seguintes seja no mesmo lugar. Obrigado mais uma vez! Att.

Psé Daniel eu vi que é um boolean e também achei estranho, mas depurei várias vezes e é exatamente quando passa nesse if que gera a exceção. Vou testar com o trunk 2 e já dou um retorno. Att.

Boa tarde colegas! Adquirimos uma EPSON TM-T800F a qual estou testando com o nosso sistema. Já nos primeiros testes me deparei com o retorno RANGE CHECK ERROR. Percebi que esse erro acontece sempre nos relatórios gerenciais mas acontece depois de um tempo. Não consigo reproduzir uma sequência que gere o erro, Imprimo relatórios gerenciais normalmente e posso repetir o mesmo relatório com o mesmo conteúdo várias vezes sem que o erro aconteça. Depois de imprimir alguns relatórios o erro acontece e ai qualquer coisa que se tente fazer após esse erro não funciona. Posso tentar imprimir uma leitura x, um não fiscal, uma venda, etc que todo e qualquer comando retorna esse erro. Depurando percebi que a exceção é gerada sempre na linha em destaque no fonte abaixo. function TACBrECFClass.EnviaComando(cmd: AnsiString = ''): AnsiString; begin try try AtivarPorta; GravaLog('-- '+FormatDateTime('hh:nn:ss:zzz',now)+' '+fpComandoLOG,True ); if Assigned(fpDevice) then if (not fpDevice.Ativo) then raise EACBrECFNaoInicializado.create( ACBrStr(cACBrECFNaoInicializadoException) ); if AguardandoResposta then raise EACBrECFOcupado.create( ACBrStr(cACBrECFOcupadoException) ) ; VerificaEmLinha ; fsBytesRec := 0 ; AguardandoResposta := True ; try Result := EnviaComando_ECF( Cmd ) ; finally AguardandoResposta := False ; IgnorarErroSemPapel := False; GravaLog(' '+FormatDateTime('hh:nn:ss:zzz',now)+' RX <- '+fpRespostaComando, True); if ControlePorta then ////////////////////////// AQUI GERA A EXCEÇÃO DesativarPorta; end ; except On E: Exception do begin GravaLog('----------------- ERRO -----------------' + sLineBreak + ACBrStrToAnsi( E.Message ) + sLineBreak + '----------------------------------------' + sLineBreak ); raise ; end ; end ; finally fpComandoLOG := '' ; end ; end; Estou com a última versão do fontes do trunk atualizado hoje. Utilizando o ECFTeste não consegui gerar o erro. Segue anexo o log gerado pelo componente. Versão do software da impressora é 01.01.00. Não sei se o problema tem a ver com esse post mas acredito que não http://www.projetoacbr.com.br/forum/topic/23373-protocolo-escecf/ Se alguém tiver alguma dica ou sugestão agradeço. Att. ecf_07082015143403.txt