Daniel Simoes

Uma dica desses leitores seriais, é identificar muito bem o sufixo enviado após o código lido... Geralmente é apenas #10... mas se podem ser 2 caracteres, como por exemplo #13,#10 (CR+LF) Quando o ACBrLCB sabe o sufixo correto, ele consegue "quebrar" corretamente um buffer serial grande, com vários códigos lidos rapidamente... Se o sufixo estiver errado, o componente ficará esperando ele chagar, e com consequencia, nunca retornará os códigos lidos... Se o sufixo estiver incompleto, (ou vazio) o ACBrLCB pode juntar dois códigos lidos... A aplicação demo do ACBrLCB é ótima para descobrir o sufixo..

Até onde eu sei, apenas a Daruma retorna isso no momento da venda... Não se prenda muito ao que a lei diz... os caras que escrevem isso parecem nunca ter visto um ECF na frente... Leia o roteirto de testes, lá vc verá tudo que será verificado...

Oficialmente, não mais... nenhum dos desenvolvedores do ACBr usa D5 para testes de compatibilidade... Mas é possível ajustar os Packages com pouco esforço...

Não há nada de errado com os eventos do ACBrTEFD.. por favor estude atentamente a aplicação demo, TEFDDemo, disponível na pasta Exemplos

Humm.. agora que percebi que se tratava de uma Nao Fiscal... Nesse caso o ACBrECF tenta emular um ECF em todos os aspectos... O modelo ecfNaoFiscal existe apenas para ajudar no desenvolvimento de aplicações (sem a necessidade de um ECF)... mas jamais deve ser usado em produção, sob o risco de crime de sonegação fiscal...

Olá Sobrinho Estamos procurando concentrar todo o suporte do ACBr nesse forum... Haviam várias listas e foruns usados para manter contato com os desenvolvedores do ACBr, mas estava cada vez mais difícil "visitar" todas elas... Mas é claro, o desenvolvedor (do ACBr) é livre para responder onde quiser Por favor anexe a rotina nesse post... eu mesmo a analiso... Um T.F.A.

Não há... mas acredito que o problema esteja no Gerador de Relatório e não no ACBrBoleto... Tente primeiro com o Demo, se nele tb não funcionar, vc poderia informar os passos para reprodução do problema...

Acho que não vale a pena usar replicação... Use um BD simples no PDV... SQLite é ótimo para isso... e uma rotina que a cada fim de venda, "descarrega" as vendas do SQLite para o BD (se a conexão estiver presente)

Não sou o autor da ACBr32.DLL... e o erro descrito com certeza não ocorre no ACBrECF... Tente a área: viewforum.php?f=19 Os campos impressos no cabeçalhos são feitos pelo próprio ECF, não há como mudar isso... ECFs não são impressoras comuns, toda sua impressão é padronizada por rigidas regras de leis

Todo documento fiscal de ICMS pode gerar crédito de Nota Fiscal Paulista No caso da NFe... o crédito já é feito pelo próprio sistema do fisco

O Lazarus é "apaixonante"... é muito bom poder opinar e ajudar no desenvolvimento da própria ferramenta de trabalho... Se vc ainda não faz parte... recomendo essas listas: Lazarus-BR E a lista oficial... de alto-nível... mas capaz de encher uma caixa postal rapidamente http://lists.lazarus.freepascal.org/mai ... fo/lazarus

Muito bacana... com campos Memo ele cria um StringList... parabéns pelo seu trabalho, Já conhece esses Projetos semelhantes ? http://tiopf.sourceforge.net/ http://www.pressobjects.org/

Pode ser que a empresa de lacração não tenha feito um "bom serviço" e não tenha inserido a quebra de linha no Cliche.... Acho que podemos fazer essa atribuição num Try/Except... mas nesse caso a variável cEndereco sempre ficaria vazia

O ACBrECF tenta, na maioria das situações, abstrair as diferenças... Ou seja.... ACBrECF.LeituraX funciona em todos os modelos suportados por ele... Mas algumas coisas sempre mudam, como por exemplo os Indices das Formas de pagamento... a maioria usa 01, 02, 03... mas na Epson vc terá 1, 2... nas FiscNet (Elgin, Urano, ZPM, DataRegis) elas são mais exóticas ainda... Exemplo: -2 = Dinheiro,

A Daruma não possui emulador, e já declarou que nunca irá produzir um... Bematech, Sweda, Epson, e todas as "FiscNet" possuem ótimos emuladores...

Quando o cliente for utiliza-la ela deverá ser re-lacrada... Não é uma boa ideia usar ECFs lacrados, emprestados de cliente, para testes... Lembre-se que o Cliente paga imposto sobre todos os cupons emitidos... O ideal é ter um ECF para desenvolvimento... pois uma vez ou outra vc precisará dele... Quase todos os fabricantes tem condições especiais para ECFs para desenvolvedores...

SIM... mas vc deve compreender o que os fontes do componente fazem (em qual rotina isso é feito)... acompanhe o processo de inicialização do componente com o Debug... Na homologação é fundamental conhecer bem os fontes....

Vc deve enviar o comando de SubTotalização aplicando os 10%... antes de abrir para as formas de pagamento...

Oi Elton, Vc tem razão... Antes, no inicio do ACBr, tínhamos apenas um número de versão para tudo... que era o número da versão do ZIP com os fontes disponíveis para Download. Com a distribuição dos fontes apenas por SVN, isso perdeu completamente o sentido... e tb projeto cresceu muito, abraçando NFe, PAF, TEF e vários outros componentes, o que criou a necessidade de números de versões individuais para cada componente... Acho que cada componente deve ter seu próprio numero de versão... o que faz desnecessária a propriedade AboutACBr... Agradeço muito a sua ajuda para corrigirmos isso...

Sendo Java... Vc usa o ACBrMonitor ou a ACBr32.DLL ?

Para Desenvolvimento geralmente é utilizada um ECF "aberto", sem o lacre, pois em algumas situações é necessário fazer uma Intervenção Técnica... a titulo de exemplo durante a homologação PAF-ECF são realizadas várias Intervenções técnicas... Mas o que vc imprime não pode ser considerado um Cupom Fiscal, já que este equipamento não foi registrado no Posto Fiscal, ou está registrado como equipamento para desenvolvimento (o que é exigido em alguns estados)... Ou seja, o ECF de desenvolvimento se comportará de forma idêntica a um ECF lacrado, mas os documentos impressos não tem valor legal...

SIM... realmente estava... por favor veja: viewtopic.php?p=4459#p4459

AFF... Isso é que dá fazer as coisas de madrugada e com sono Já corrigi no SVN... Obrigado pelo aviso...

- o TCP é muito, muito mais rápido do que troca de arquivos TXT... - Vc pode operar uma máquina com ECF remotamente... (eu uso muito isso com Linux+SSH) Basta modifica na aba principal do ACBrMonitor... Sua aplicação tb deve estar apta a trabalhar com Socktes

A informação do Rodrigo está correta... Mas isso já deveria ter sido ajustado pelo lacrador, no momento da Intervenção Técnica