Siepi

Moçada, peguei um lance aqui, estou lendo a resposta em cada vendeitem, isso tem atraso tudo. Mandando os comandos em um envio somente, e lendo o retorno, posso analisar e saber se deu certo ou algum item deu pau. O retorno de cada item vendido vem. Muito obrigado pela ajuda.

Daniel, foi esse exemplo que vem que eu fiz a correção do fatal error do PHP, pois como disse, ele não aceita mais array por referência. Esse ClientSocket que anexei na mensagem original, é justamente o da pasta exemplo. Anexo aqui agora o php_socket, tb da pasta exemplo com as correções, pois tb não estava funcionando. Abraço php_socket.php php_socket.php

Nao sabia que se poderia enviar mais de um comando! A rotina base foi o proprio socket de teste que veio com o abcrmonitor. Somente incluí novos vendeitem, coloquei o arquivo anexo. Vou testar enviando mais de um comando ao mesmo tempo. Essa possível implementação poderia ter como retorno um ok, ou um int com o item que deu erro, se fosse o caso, cobrindo assim a falta de controle quando mandamos mais de um comando com vendeitem. obrigado e volto depois dando noticia. php_socket.php

Prezados, estou realizando testes maciços com o ACBrMonitor e PHP via socket, no que tenho tido muito sucesso até o momento. Praticamente já passei por todos os comandos do objeto ECF sem erro. Uma coisa que me preocupou foi a venda de muitos itens via socket. Vamos aos testes. Temos o método ECF.VendeItem onde vamos vendendo itens, um a um. Quando há concomitância nem há tanto problema, mas quando vendemos uma pré-venda aí complica. Pois mandamos o primeiro item, aguardamos a resposta, mandamos o segundo e assim sucessivamente. Com um teste de 15 itens, levou 1 minuto e 5 segundos da abertura do cupom ao fechamento. Vi que no utilitário ECFTeste que vem junto ao instalador para auxílio nos testes, existe uma função bem interessante no menu Cupom Fiscal, o Teste de Velocidade, vc indica a quantidade de itens, a quantidade de cupons e ele dispara para a impressora. A mesma quantidade de itens (15) nesse teste demorou 12 segundos da abertura ao fechamento. Muito mais rápido. A lógica, creio, é que o ECFTeste usa a comunicação direta e não o socket como estou usando. Seria viável se modificar o método no ACBrMonitor, onde passaríamos arrays? Exemplo: Hoje temos ECF.VendeItem(789012456780,PRODUTO TESTE, II, 3, 2.5) O comando acima continuaria como está e a modificação poderíamos passar ECF.VendeItem([789012456780,PRODUTO TESTE, II, 3, 2.5], [789012456780,PRODUTO TESTE, II, 3, 2.5],[789012456780,PRODUTO TESTE, II, 3, 2.5],[789012456780,PRODUTO TESTE, II, 3, 2.5],[789012456780,PRODUTO TESTE, II, 3, 2.5],[789012456780,PRODUTO TESTE, II, 3, 2.5],[789012456780,PRODUTO TESTE, II, 3, 2.5]) o método, reconhecendo que está recebendo arrays, faria exatamente o que o teste de velocidade faz, mandando estes itens ao cupom, não necessitando assim eu realizar um comando via socket para cada itens, mas apenas um comando para todos os itens. No mais um abraço e até logo.

Prezados, hoje a tarde fiz uns ajustes no exemplo em php que vai no instalador do ACBrMonitor, pois o mesmo não está funcionando. Uma das causas é o php não aceitar mais que se passe arrays por referência. segue o ClientSocket.php, funcionando e um script de teste que fiz. Vale lembrar que após a conexão, é retornado junto com o primeiro comando a mensagem inicial do monitor ACBrMonitor Ver. 0.10.2.3 Conectado em: 18/06/14 17:05:52 Máquina: 127.0.0.1 Esperando por comandos. Então cuidado com o tratamento do primeiro retorno. Espero que ajuda alguém que como eu está implementando o PAF em PHP. ClientSocket.php teste_socket.php

Obrigado camarada!

Prezados, a legislação mais atual do sintegra seria qual?

Pessoal, foi o seguinte,dll fora da pasta, eita nóis! Mas imaginem agora a seguinte situações. No dia 12/06 houve movimentações do COO 2540 a 2780. Quando mando ler dia 12/06 a 12/06, tudo ok, como falado acima. Mandei ler de 2600 a 2605, deu pau. Aí por curiosidade, mandei ler justamente de 2540 a 2780 e deu certo. Reduzi um pouco, de 2560 a 2590, deu certo! N!ao sei se por algum motivo, existe cupom vinculado que ficou de fora do range 2600 a 2605, que possa estar gerando o erro, vou até conferir cada documento e posto as minhas impressoes aqui. Mas de inicio foi isso, um valor tal de COO que gera o erro descrito. Muito estranho. Dou mais notícia a noite.

Prezados, boa noite. Estou testando o acbrMonitor com o próprio ECFTeste. Achei fantástico, imprimi documentos fiscais, não fiscais, muitas outras opções e tudo ok. Minha impressora é uma Bematech 2100 serial com um adaptador USB COM. Estou tendo uma dificuldade no seguinte: Quando tento Relatórios->Leitura MDF serial-> por periodo, tudo ok. mas por COO ele dá erro. Olhem o log No comando enviado: [sTX][19][0][28]>EC0026000026021e[ETX] Na resposta: Ativar - + - + - + - + - + - + - + - + - + - + - + - Erro retornado pela Impressora: Bematech Número de parâmetro inválido A[1][ETX][0] - + - + - + - + - + - + - + - + - + - + - + - Tentando também espelho mfd dll tanto por data quanto por COO tenho erros ACK que variam (120, 124, 116) resposta: Erro. Resposta da Impressora Bematech inválida (ACK = 120) - + - + - + - + - + - + - + - + - + - + - + - E mesmo erro com Arquivo mfd dll por periodo ou COO resposta Erro. Resposta da Impressora Bematech inválida (ACK = 116) - + - + - + - + - + - + - + - + - + - + - + - O resto inteiro tudo ok, somente os espelhos mfd citados dando problema. estou na versao do ECFTeste 3.00 ACBR 0.9.0a compilado com Lazarus 0.9.29 beta O AcbrMonitor é a versão 0.10.2.3 O pacote de dll é o mais atual do site da bematech Cheguei a aumentar o timeout para 60 segundos, mas não é tempo de resposta, pois o erro vem praticamente com 2 segundos. Alguem dá alguma luz? Obrigado Aproveito e lanço um acbrlog.txt criado justamente antes de dar o ok para um espelho MFD DLL por periodo Desativando ACBrECF xBematech_FI_AbrePortaSerial xBematech_FI_FechaPortaSerial Ativar ACBr: SIM -------------------------------------------------------------------------------- ATIVAR - 12/06/14 22:50:15:590 - Modelo: Bematech - Porta: COM1 - TimeOut: 60 Device: BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE=RTS/CTS HARDFLOW MAXBANDWIDTH=0 -------------------------------------------------------------------------------- -- 22:50:15:598 EspelhoMFD_DLL( 01/06/2014 , 12/06/2014 , teste.txt ) TX -> [sTX][4][NUL][FS][19]/[NUL] 22:50:16:700 RX <- [233][208]||t{{zx|td{zx|td{zx|td{zx|td{z -- 22:50:16:705 TX -> [sTX][ENQ][NUL][FS]#)h[NUL] Bematech EnviaComando_ECF: ACK = 123 Falha: 1 TX -> [sTX][ENQ][NUL][FS]#)h[NUL] Bematech EnviaComando_ECF: ACK = 124 Falha: 2 TX -> [sTX][ENQ][NUL][FS]#)h[NUL] Bematech EnviaComando_ECF: ACK = 116 Falha: 3 22:50:16:963 RX <- ----------------- ERRO ----------------- Erro. Resposta da Impressora Bematech inválida (ACK = 116) ---------------------------------------- -- 22:50:16:966 TX -> [sTX][ENQ][NUL][FS]#[sOH]@[NUL] Bematech EnviaComando_ECF: ACK = 122 Falha: 1 TX -> [sTX][ENQ][NUL][FS]#[sOH]@[NUL] Bematech EnviaComando_ECF: ACK = 124 Falha: 2 TX -> [sTX][ENQ][NUL][FS]#[sOH]@[NUL] Bematech EnviaComando_ECF: ACK = 123 Falha: 3 22:50:17:234 RX <- ----------------- ERRO ----------------- Erro. Resposta da Impressora Bematech inválida (ACK = 123) ----------------------------------------

Pelo que vi, dessa versão não consta esse método.

Temos que entender que o conversor é como se fosse a com que sai de trás do gabinete do computador e o cabo possui transamento específico. Se ligar direto conversor na impressora é como se você espetasse a impressora na traseira do micro diretamente e aí a pinagem não bate, pois como eu disse, o cabo é transado, não é direto pino1 com pino1, pino 2 com pino2 e assim por diante. Seria pino1 com pino 5, pino2, com pino7 e por aí vai.