giulianon

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

Você tem que colocar o emulador na COM3 e o ECFTeste utilizando a COM4. Colocando ambos na mesma porta vai apresentar esse erro mesmo. O que o VSPE faz é o papel de um "CABO" que conecta em suas "pontas" 2 dispositivos. Emulador (COM3) <----- VSPE ----> (COM4) ECFTeste Att.

Tem que verificar(site, suporte, etc) junto ao fabricante do equipamento se existe o driver para criar a COM virtual. Att.

Eu controlo pelo número do item. Caso ocorra uma falta de energia, ao recuperar a venda eu consulto o número do último item na impressora e comparo com ultimo item gravado no meu banco de dados. Se por acaso o item acabou sendo impresso e eu por ventura não gravei no meu banco de dados eu cancelo o item na impressora. O sincronismo é mantido. Em último caso se faz forma tradicional, tirando a fita-detalhe ou gerando o arquivo das vendas da ecf e vendo o que falta. Att.

Bom dia! Pode utilizar o ACBrInstall que se encontra em downloads. Lembrando que o ACBrSMS fazer parte do pacote ACBRSerial. Att.

Venda concomitante é a venda que no momento que você vende o item ele já é impresso na impressora fiscal, ou seja, você está vendendo e já imprimindo o cupom fiscal. A pré-venda como o nome já diz é uma venda que você registra todos os itens PRÉviamente (em "memória") e depois comanda no pdv a impressão de todos esses itens na impressora fiscal. A idéia da pré-venda é ter várias máquinas de atendimento e outras máquinas para "caixa". Inclusive se não estou enganado não pode ter no mesmo computador a pré-venda e a emissão do cupom fiscal. Att.

Se você realiza qualquer impressão de forma não concomitante no seu pdv já caracteriza DAV ou pré-venda e isso já obriga os testes. "Importar" venda no pdv como você citou já caracteriza isso. Att.

Basta cadastrar esse meio de pagamento na impressora fiscal. Lembrando que isso pode ser feito de duas formas: 1-A qualquer momento com intervenção técnica. 2-Imediatamente após a redução Z sem a intervenção técnica. Observação: Caso a impressora já tenha atingido o limite(normalmente 20) de meios de pagamento ai só é possível via intervenção técnica. Você pode utilizar o software do fabricante ou através do próprio ACBr. Dê uma olhada no exemplo que acompanha o mesmo chamado ECFTeste. Att.

Só completando, o órgão homologador mais perto é a Unisul. Nesse link contém orientações de como proceder. http://aplicacoes.unisul.br/PAF/ Att.

Hehehe. Segue o arquivo. Att. ACBrSMS.zip

Bom dia! Implementei o método ApagarSMS no componente ACBrSMS. Segue para análise. Att.

O ACBr se utiliza de comunicação direta com a impressora sem o uso da DLL. Nesse caso a dúvida tem que ser sanada junto a Bematech mesmo. Att.

Essa regra é imposta pelas operadoras. Peça para o cliente enviar uma mensagem do celular dele com palavras acentuadas e verificar a mensagem no celular de quem recebeu. Vai ver que a mensagem chega sem acentuação.

Então André! A Sweda me ligou informando que já estava corrigido na última versão do firmware deles. O cliente pagou para atualizar uma impressora com esse firmware mas ao testar o problema ainda existia. Ai passei exatamente esses valores de exemplo para a sweda e até hoje nenhum retorno. Ainda estou usando truncamento nos casos da Sweda e Bematech. O cliente por fim vai abrir uma loja nova com mais de 15 pdvs e vai usar Epson. Só lamento para Sweda. Acredito que aos poucos vai ocorrer toda a troca das ecfs por uma marca que funcione. Att.

Tratei desse assunto nesse post. Dá uma olhada.

Essa função ainda não existe, pelo menos na versão (Não é a última) que estou utilizando. Nos exemplos de comunicação direta que a Daruma fornece existe essa função. Att.

O método de leitura está implementado mas as mensagens são geradas em um arquivo "txt". Ai é necessário ler as mesmas a partir desse arquivo, o que é bem tranquilo já que tem um formato padrão. Se olhar no ACBrSMSDemo vai conseguir implementar certinho. Att.

Bom dia colegas! Já tenho funcionando a coisa de um mês um programa de envio de SMS com o modem da daruma. Tudo vinha funcionando perfeitamente até ontem quando os créditos do chip acabaram. O chip é da CLARO. Coloquei créditos e mesmo assim começou a dar erro de envio. Na dúvida tirei o chip, coloquei no celular e enviei alguns SMSs e todos foram. Coloquei novamente no modem e nada. Erro de envio sem índice da mensagem e com a mensagem de erro ERROR. A partir dai foi uma verdadeira maratona de testes. Testei com o ACBrSMSDemo e com todos os programas de teste da Daruma. Todos apresentando erro. Mudei bandeja, limpei as mensagens recebidas, mudei configurções de timeout, etc. Nada resolveu. Coloquei novamente o chip no celular o os SMSs vão normalmente. Pra descartar a possibilidade de problema no modem coloquei um chip da VIVO e todos os SMSs vão perfeitamente. Ou seja, o problema está na CLARO. Hoje pela manhã coloquei novamente esse CHIP da CLARO no modem e envie 3 mensagens. A primeira foi e as duas seguintes não foram. Alguém já passou por algo semelhante?

Só pra deixar registrado, após a troca de alguns emails com a toledo a dúvida foi sanada. Realmente essa balança quando equipada com o display 9091 permite a leitura de 2 maneiras: 1 - Sob demanda apenas com o pressionamento da tecla de pesagem NO DISPLAY. As configurações da serial para esse modo são: Velocidade: 4800 Databits: 7 Stopbits: 2 Paridade: Par (Even) Controle de Fluxo: Nenhum OBS: Esse modo foi o que eu testei e funciona perfeitamente. 2 - Contínuo. A balança envia o peso o tempo todo e deve ser monitorada para fazer a leitura. OBS: Esse modo eu não testei mas quando a alteração que o Dipold for pro svn posso testar. Att.

Entendi. Bom vou esperar o Daniel subir a sua alteração e depois posso fazer esse teste pra gente ter uma posição exata. Valeu! Att.

Boa tarde Dipold. Chegou a fazer o teste com o display 9091? Estou em contato com o suporte da Toledo e segundo eles a captura do peso nesse display funciona de duas maneiras. Contínuo onde você recebe o peso constantemente sem envio de comando para solicitar o mesmo. Ou por demanda onde você normalmente enviaria a solicitação (#5) e receberia peso. Só que segundo o suporte da toledo nesse display não tem com fazer isso. Para que o peso seja retornado é necessário pressionar um tecla no próprio display. Por isso a dúvida se você fez o teste nesse modelo de display. Att.

Boa tarde! Também não consegui fazer essa leitura com o ACBrBal pois no retorno da balança rodoviária vem muito mais informações do que vem em balanças normais. Como o tempo tá curto fiz a leitura através de outro componente serial mas pretendo assim que folgar aqui alterar o ACBrBal pra tratar isso. Outra coisa é que para comandar a leitura do peso nessas balanças é necessário desabilitar o display da mesma, caso contrário ela fica enviando o peso o tempo todo "buferizado" e complica bastante para filtrar as informações. Desabilitando o display ela só envia o peso se comandar essa leitura. Att.

Lembrando que normalmente ecf permite fazer isso após a emissão da redução z. Att.

Opa! Beleza então Juliomar. Era só pra confirmar mesmo. Achei meio estranho ninguém ter comentado nada diante do fim de uma "coisa" tão chata e custosa. Agora falta só o fim do PAF \o/ Pena que em SC ao que me parece ainda está longe. Obrigado! Att.