Fabio Franzini - Compsoft

Boa tarde. Alguem já conseguiu abrir a gaveta, utilizando utilizando a impressora Xprinter (ChingLing... kkk) tem varios marcas e modelos mas todas tem como modelo 58XXX , no caso da minha é 58IIH , é uma impressora que esta aparecendo muito aqui em nossa região, ja adequei toas as minhas impressões para ela, mas ao abrir a gaveta ja tentei varias configuroções de ON Off e Invertido , ja fiz teste utilizando todos os modelos disponiveis no acbr.

Quem puder mudar para contingencia, talvez funcione.

Olá, bom dia. Parece ser geral, tenho muitos clientes relatando o mesmo erro. Alguem tem alguma noticia sobre o SEFAZ SP ?

Olá, boa tarde a todos, me desculpem se não é o local certo. Estou encontrando um problema, vou tentar descrever. Se alguem já passou por esta situação, talvez não esteja usando o fluxo correto. Ocorre o seguinte: 1-Executo a chamada: (Com um CFe já carregado no componente); ACBrSAT1.EnviarDadosVenda; 2-Logo após leio o retorno para gravar em Meu BD os dados do Cupom emitido. Esperando o retorno 6000. if ACBrSAT1.Resposta.codigoDeRetorno = 6000 then .... O que ocorre é que em alguns casos, coisa de 1 dentre algumas centenas de cupom(Isto mesmo, bem esporádico). De não ter o retorno 6000, sendo que o cupom foi emitido, impresso e consta normalmente no comsat. Isto tem atrapalhado, pois não alimenta as tabelas que deveriam ser preenchidas em caso de emissão. Me desculpem se prolonguei demais a explicação....

Daniel, me desculpe, por prolongar o assunto, mas fiquei com uma "pulga atrás da orelha" , isto ocorreu por alguma mudança do lado do servidor ? (Apenas por didática.)

Bom dia Daniel. Seria a mesma coisa que este ? Eu tive sucesso alterando o GET. Da uma conferida.

Juliomar, boa tarde. Aparentemente o servidor esta recusando dados enviados no Header. Ou algo parecido. Na unit ACBrIBGE na linha 1241 : troquei : HTTPGetCompressed( AURL ); por : HTTPGet( AURL ); e obtive sucesso. acredito que o servidor não esta aceitando o parâmetro que indica um retorno compactado. (Não é minha praia, então não sei se o acerto correto seria este , ou até mesmo se soube me expressar de forma clara).

Após atualizar o Firmware da impressora para versão 1.03.42 não ocorreram mais problemas. Acredito que esta possa ser a solução.

Em testes usando o ACBrPosPrinter. Usando este para mais detalhes, o access violation ocorre na linha 797 do arquivo "ACBrEscPosEpson.pas", na função "TACBrEscPosEpson.LerInfo: String;" Gerando o LOG : -------------------------------------------------------------------------------- ATIVAR - 28/10/21 13:21:50:766 - Modelo.: EscPosEpson - TimeOut: 3 - Porta..: USB:Elgin, I9 - Tipo...: USB -------------------------------------------------------------------------------- -- 28/10 13:22:18:653 - LerInfoImpressora -- 28/10 13:22:36:729 - TX -> [GS]IB -------------------------------------------------------------------------------- DESATIVAR - 28/10/21 13:24:19:443 -------------------------------------------------------------------------------- E o log retornado ao solicitar o Status é este : -- 28/10 13:25:24:769 - LerInfoImpressora -- 28/10 13:25:24:888 - TX -> [GS]IB -- 28/10 13:25:28:087 - LerStatusImpressora( 1 ) -- 28/10 13:25:28:190 - TX -> [16][4][SOH] -- 28/10 13:25:28:217 - stErroLeitura, Me perdoem pelo post tão grande, é que não achei forma mais resumida para relatar.

Olá, bom dia a Todos. Estou tendo uma certa dificuldade, com uma impressora Elgin I9 , Primeiro com relação a função "LerStatusImpressora" , onde sempre me retorna Erro de Leitura, e depois executando um teste, achando que o erro poderia ser no meu código, usei o PosPrinterTeste, e nele a impressora é listada como "USB:Elgin, I9" , ao selecionar como modelo "ppEscPosEpson" e porta "USB:Elgin, I9" e clicar em "Ativar" tenho um retorno de Access Violation. Tenho aqui comigo uma impressora Elgin I9 Full que não apresenta estes problemas. Isto pode ser uma característica da impressora ? (De não ter requisitos mínimos para funcionar em USB) -- Detalhe ela imprimi normalmente, Abre Gaveta e aciona guilhotina, mesmo após este access violation.

Aqui, em meus testes, tudo OK.

Daniel, só vi a sua pergunta hoje, na verdade o que deixa certo para ifood é o </reset>

Daniel, fiz um teste rápido aqui, e usando o </fn> resolve o problema da fonte. Mas como no caso do ifood existe alguns saltos de linha que separam áreas distintas do documento, e usando o </fn> elas continuam sendo ignoradas.

Só mais um adendo, para liberar mais rápido eu adicionei a Daniel , para Liberar aqui, eu inseri a tag </reset> na propriedade "Site" do componente, como é a ultima coisa a ser impressa deu certo. Por hora Cliente Fica feliz.... (A mão da Gambiarra até treme ...kkkkkk)

Exato Mestre. Me perdoe, ao procurar levei em conta como chave as palavras "ACBRSAT" e "ACBRPOSPRINTER" por isto não encontrei o Post correto. Obrigado.

Me desculpe, a velha mania de teclar Crtl + Enter ... e acabei terminando o post ao pular linha... Agora editado com os detalhes

Vou tentar explicar o Ambiente. Tenho um Emissor de Cupom (Utilizando ACBRSAT) ligado a um ACBRPOSPRINTER (Configurado para uma Impressora Tanca, configurado para usar EscEpson) . Tudo corre perfeitamente, não existe falhas na impressão. No mesmo PC roda o Gestor de pedidos do ifood. O Problema que ocorre é que após a Impressão do cupom, o gestor do Ifood começa a emitir seus pedidos em fonte reduzida. (Não respeita a configuração existente dentro do gestor), aparentemente ele continua usando o modo condensado que foi ativado pelo ACBRSAT + ACBRPOSPRINTER. Com impressoras Bematechs não consegui simular isto, mas com uma I9 Elgin usando set escpos, também ocorre. Pelo que observei/pensei até acho que quem teria que dar uma solução seria o Ifood. (Resetando e configurando a Impressora de acordo com o que ele precisa, como o ACBR faz). Mas acho que nem preciso dizer, que suporte será acionado nestes casos.... Alguém aqui já passou por caso parecido ?

Ok, entendido. Obrigado, mais uma vez. --- Comentei as partes do código que utilizam a unit.

Ola, boa tarde a todos. Me desculpem se ja foi apontado, mas não encontrei nada referente. Hoje ao abrir ACBRPosPrinterTeste localizado na pasta "C:\ACBR\trunk2\Exemplos\ACBrSerial\ACBrPosPrinter\Delphi" Encontrei problemas com a Unit "ACBrPosPrinterElginE1Service" - declarada no uses. Atualizei todos os fontes e realizei uma nova instalação, mas não obtive sucesso, continua indicando que não é possível encontrar a Unit Indicada. Utilizo Delphi 10.4 Sydney

Acredito que o XML não esta sendo carregado, Utilize o retorno da função Loadfromfile ... para ver se retorna True.. Caso Retorne False o componente não esta sendo carregado, provavelmente erro no XML.

Obrigado pro reportar, vou segurar a implementação aqui também.

Qual erro é retornado ? Anexa o Log do SAT , pode ajudar.

@Rodrigo Bernal Então, citei estas situações pois tive problemas parecidos, e estavam relacionados a isto. Na ocasião não podia fazer uma "Limpeza" no PC pois só tinha o suporte remoto, e resolvi utilizando outro meio de conexão, no caso como era uma impressora que aceitava tal configuração, eu utilizei o posprinter apontando para USB. (Acredito que desta forma o controle sobre a impressora é maior). E não tive mais problemas. Como disse antes em Raw , se não estou enganado, quem gerencia as impressões é o S.O.

Qual forma de configurar a Porta esta usando ? Se este utilizando RAW - pode ser algo de errado nos drivers instalados, ja que nesta opção quem "Faz" a impressão é o S.O. Existe algum outro aplicativo utilizando o Mesmo componente ? Ou até mesmo no mesmo executável, tem mais de um componente acessando a mesma porta ?