Daruma - Por onde é melhor?

TerraSoftware · Mensagem por **TerraSoftware** » 21 Ago 2007 17:08

Caros colegas.

Estou com uma Daruma FS345 e preciso estabelecer comunicacao com ela.

Por onde os colegas me aconsenham?

1-Comunicação direta pela SERIAL
2-Via DLL
3-Via OBSERVER2.EXE (software de comunicacao distribuido pelo fabricante)

angeiras · Mensagem por **angeiras** » 21 Ago 2007 21:15

Ola,

No Clipper eu usava o OBSERVER, que e rapido, transparente e facil de programar.
No xHarbour estou usando o ACBR. Com uma interface unica de programacao, fica pronto pra qualquer ECF que o projeto suporta ( e suporta muitos modelos de ECF ).

Acho que no site do projeto ( acbr.sourceforge.net ) tem exemplo em xharbour/clipper.

[]s
Manoel Angeiras

Mensagem por **Stanis Luksys** » 21 Ago 2007 23:41

Rapaz...

Se quer minha opinião. FUJA deste observer... Você já está em 32 bits, e o objetivo dele é somente criar esta interface do DOS com a DLL da daruma, através de uma gambiarra chata de arquivos textos, no estilo TEF. Agora, se quer outra opinião, fuja também das DLLs.

Eu aconselho veementemente o uso da HBCOMM com comunicação direta.

Afinal, você está desenvolvendo em cima de um software livre o no qual você pode até ter o código fonte. Incluir uma DLL no seu sistema só iria contra o princípio básico de se manter o conhecimento de todas as rotinas do seu sistema. Sou contra DLLs e drivers.

A tranquilidade de testar (testar muito) e saber que o SEU código funciona, nenhum projeto pode te trazer. Pifou, é a máquina.

E tenho dito.

angeiras · Mensagem por **angeiras** » 22 Ago 2007 12:41

Olá,

Só lembrando que o SCU ( Set de Comandos Único ) já foi aprovado pelo COTEPE/ICMS e que, provavelmente, a partir de 2008 já estará implementado nas ECF ( é claro que tem gente que não queria isso, mas acho que agora já é tarde ).

Isso implica REALMENTE uma padronização no acesso as ECFs. Eu trabalho com diversos modelos de ECF diferentes ( corisco, sweda, schalter, daruma, bematech, urano, etc ) e ,por mais que tente criar um padrão de acesso, dá um trabalho muito grande.

Por isso hoje uso o ACBR. É um projeto livre, com código fonte disponível, estável ( já homologuei o TEF usando o ACBR ). Tem bug ? provavelmente tem, mas tudo na vida tem bug, até a gente. Se não fosse usar software por causa de bug, ainda estaria programando em assembler...

Mas quando o SCU vingar mesmo, largo de mão o ACBR e pulo para o SCU

[]s
Manoel Angeiras

Mensagem por **Stanis Luksys** » 22 Ago 2007 13:01

angeiras escreveu:o SCU ( Set de Comandos Único ) já foi aprovado pelo COTEPE/ICMS

Sabe o endereço de algum link em que eu possa encontrar isso?

angeiras escreveu:Mas quando o SCU vingar mesmo, largo de mão o ACBR e pulo para o SCU

Sabe me dizer se isto vai padronizar o acesso por comunicação direta? E a Bematech, a rainha-da-cocada-preta, entrou nessa jogada?

Me interesso pelo assunto.

Aproveitando o gancho: sabe me dizer se no Rio de Janeiro é necessário que a soft house tenha cadastro na receita para poder emitir cupom?

Valeu!

angeiras · Mensagem por **angeiras** » 22 Ago 2007 13:16

Ola Stanis,

Vou procurar o link da resolucao do COTEPE/ICMS pra postar.

A bematech foi uma das empresas que criticou, esperneou e boicotou pra o SCU nao virar realidade.

Sim, vai padronizar o acesso direto a ECF e a gente vai ter uma interface limpa pra comunicacao.

[]s
Manoel Angeiras

Cezar · Mensagem por **Cezar** » 24 Ago 2007 14:57

Boa tarde,

Como iniciante, estou com a mesma duvida do Stanis.

Se pra emitir apenas o cupom fiscal o sistema precisa estar homologado como no TEF??

Angeiras, onde poderia baixar o ACBR ??

grato.
cez_a@ubbi.com.br

dopi · Mensagem por **dopi** » 24 Ago 2007 15:10

Olá Pessoal,

O SCU será vantagem apenas para quem usa comunicação direta... já que os fabricantes se manifestaram contrários a uma DLL única...

Acho que a adoção do SCU demora mais para acontecer, pois "junto" com a promulgação do SCU, o fisco exigiu um monte de recursos novos para os ECFs, como por exemplo modem, para que o fisco ligue diretamente para o ECF (coisa de louco)

Já li comentários de fabricantes de ECF que será muito difícil construir um novo ECF com todas as exigências atuais... sem falar no preço final ao consumidor... Aliado ao fato que não haverá vantagem nenhuma para o cliente...
No caso da transição Matricial -> Térmica, há muitas vantagens para o cliente, o que justifica o preço mais caro... porém com esses novo ECFs isso não ocorrerá...

Um pequeno debate sobre o SCU com o autor original do projeto
http://www.forumweb.com.br/foruns/index ... opic=64561

Mensagem por **Stanis Luksys** » 24 Ago 2007 15:30

dopi escreveu:O SCU será vantagem apenas para quem usa comunicação direta... já que os fabricantes se manifestaram contrários a uma DLL única...

Eu uso comunicação direta, mas pelo que pude entender, esta afirmação está errada, o tal do SCU vai sim beneficiar a todos, pois vejamos: o que faz a DLL senão transformar a sua chamada em um comando de baixo nível?

Pois se todas forem iguais, no final da contas você vai poder imprimir numa Daruma usando uma função da DLL da Bematech, ou usar a DLL da Daruma para imprimir na Sweda.

Dá na mesma!

dopi · Mensagem por **dopi** » 24 Ago 2007 15:58

Não, porque já foi afirmado por fabricantes que as DLLs terão "travas" para operar somente com os seus modelos de ECFs... Isso porque hoje em dia, eles consideram DLLs algo "estratégico" para ganhar mercado... e os "GRANDES" não vão querer que outros fabricantes "menores" se beneficiem de avanços inseridos nas DLLs deles (ex: geração de sintegra, rfd, etc)...

Ou seja... o mar de DLLs continua... com ou sem o SCU... No ACBrECF já temos uma classe iniciada com o Protocolo SCU... mas congelamos os trabalhos, pois ainda não existe ECF ou Emulador para testar...

O próprio protocolo publicado tem alguns pontos falhos.. e que se não forem corrigidos podem gerar problemas na implementação dos equipamentos...

Alias.. o SCU já mudou de nome... agora os fabricantes chamam ele de ESC-ECF

jamazevedo · Mensagem por **jamazevedo** » 25 Ago 2007 10:15

Utilizou a FS300 desde 1999 a princípio funcionou bem com acesso indireto através de drives fornecidos pela antiga SIGTRON hoje DARUMA, mas quando começamos a trocar as CPU's e aparecer o WINXP, começei a ter problemas de travamento. Moral da história o acesso direto via COM1 ou COM2 é muito melhor, temos apenas o trabalho de re-escrever as rotinas mas é seguro.
Quanto ao padrão ESC que virou ESC-ECF não conheço mas pela experiência em desenvolvimento e praticidade, acredito que será a melhor solução para nós programadores.

TerraSoftware · Mensagem por **TerraSoftware** » 25 Ago 2007 11:02

Caros colegas.

Obrigado pela atenção.

Mas devido a preça do cliente (alias, cliente vive com preça) optei por usar o observer2.exe (distribuido pelo fabricante). Fiquei surpresso com a velocidade, tanto de desenvolvimento quanto de operação. As respostas da impressora saum muito rápidas. É claro que naum discuto a questaum de comunicaçao direta visa serial ser melhor. Mas o observer2.exe mostrou ser uma obção eficiente para quem tem preça no desenvolvimento.

Mensagem por **Stanis Luksys** » 25 Ago 2007 18:12

dopi escreveu:já foi afirmado por fabricantes que as DLLs terão "travas" para operar somente com os seus modelos de ECFs...

É para fugir deste tipo de encrenca que sempre recomendo a comunicação direta, ser dono do seu código e passar por cima de brigas de concorrência entre as marcas é apenas uma das vantagens. Existem vantagens técnicas também.

De qualquer modo mesmo quem usa hoje comunicação direta terá de refazer o código, mas pelo menos só uma vez, e dada a importância da atualização, vai valer o esforço.

TerraSoftware escreveu:o observer2.exe mostrou ser uma obção eficiente para quem tem preça no desenvolvimento.

Isso é verdade. Mas como dizia o profeta, o barato sai caro. Quando todas essas implementações ocorrerem, e essa lei de comunicação valer, seu trabalho terá de ser refeito.

Falou!

dopi · Mensagem por **dopi** » 27 Ago 2007 09:39

Stanis Luksys escreveu: É para fugir deste tipo de encrenca que sempre recomendo a comunicação direta, ser dono do seu código e passar por cima de brigas de concorrência entre as marcas é apenas uma das vantagens. Existem vantagens técnicas também.

Exato... Esse foi um dos motivos que me levou a inciar o ACBr... O ACBrECF e ACBrMonitor usam comunicação direta com todos os ECFs suportados... nenhuma DLL de fabricante é requerida... Como vantagem, temos um funcionamento idêntico em Windows e Linux..

Stanis Luksys escreveu:De qualquer modo mesmo quem usa hoje comunicação direta terá de refazer o código, mas pelo menos só uma vez, e dada a importância da atualização, vai valer o esforço.

Com certeza... sou entusiasta da idéia do protocolo ESC-ECF, apesar de achar um erro a maneira como ele está sendo implementado (na base do decreto)... Uma padronização dessas deveria vir através de ABNT, ISO, etc.. pois assim, teriamos um amplo debate antes de formatar o padrão...
O ESC-ECF atual foi criado pelo Claudenir da Daruma e é praticamente uma cópia dos protocolos da Daruma... Segundo ele, todos os fabricantes participaram na formação do padrão... mas não vi mudança nenhuma desde a primeira apresentação do mesmo...
Na minha opnião, o melhor protocolo de ECF é o FiscNET, desenvolvido pela ZPM e atualmente é usado em vários ECFs com MFD (Elgin, Urano, Dataregis, etc)... Se ele fosse adotado como padrão as coisas seriam muito mais fáceis... e vários fabricantes já estariam "adapatados" às novas regras

Stanis Luksys escreveu:
TerraSoftware escreveu:o observer2.exe mostrou ser uma obção eficiente para quem tem preça no desenvolvimento.
Isso é verdade. Mas como dizia o profeta, o barato sai caro. Quando todas essas implementações ocorrerem, e essa lei de comunicação valer, seu trabalho terá de ser refeito.

Quem usa DLL ou qualquer outro programa de Fabricante de ECF (aka Observer) não precisa se preocupar com a chegada do ESC-ECF... Pois os fabricantes prometeram compatibilidade total, tratada diretamente pela DLL... Ou seja, a DLL irá identificar que o ECF é do tipo ESC-ECF e usar a linguagem dele... "pelo menos essa é a promessa deles... mas se vai funcionar exatamente igual...".

Mário Isa · Mensagem por **Mário Isa** » 19 Dez 2007 21:39

Hoje tentei com ACBR numa Daruma FS-345 e não consegui ler a leitura da memória fiscal para pegar o grande total e gravar.

Achei estranho pois consegui ler alíquotas, ler formas de pagamento e tudo o mais menos isso, que era importante.

Tenho uma FS-345 de testes aqui e tudo funciona muito bem.

No weekend vou pegar e trazer prá cá prá testar com meu cabo, meu micro, meu XP para ver da necessidade de formatar ou presença de virus e coisa e tal.

Também em outro cliente com uma Bematech FI 20 - na hora de imprimir um item que tinha um (.) em meio à descrição do tipo
TRINCHA ATLAS 1.2 "
Ele recusou dizendo uma mensagem assim:
Float point entre outras..... Infelizmente esqueci de gravar o log.

Depois dou mais detalhes.

Mário