Daniel Simoes

Dada uma plicação separada em PDV e "Concentrador" PDV - Frente de Caixa Concentrador - ou Retaguarda, que Permite controlar os PDVs, atualizando os preços dos PDVs, concentrando as vendas, etc Ambas aplicações serão homologadas em conjunto. A tela de inclusão do DAV e Pre-Venda pode existir apenas no Retaguarda ou precisa obrigatoriamente existir no PDV ?

(Santa burocracia Batman)

Apenas o Demo tem problema de converter String para Float, caso o Valor não use o separador de decimando nativo do Sistema operacional... no ACBrECF o Valor é do tipo Double No LOG aparentemente está tudo correto.. não há erro...

No teste 104 do roteiro 1.4 temos a seguinte transcrição: Como será feita a entrada de 10 Unidades ? É permitido um "acerto de estoque", ou é necessária uma tela de entrada de Notas ?

Ele deve estar acessível até mesmo na Tela de Login (antes de digitar a senha) ? Ele deve estar acessível se estamos imprimindo um Cupom (na tela de vendas, com cupom aberto) ?

Se meu PAF-ECF não atende ramos específicos como Bar/Restaurantes, Posto de gasolina, Farmac.Manipulação, etc... o Menu fiscal precisa ter as opções específicas destes segmentos ? Exemplo: 12 - “Encerrantes”, 13 - “Transf. Mesas”, 14 - “Mesas Abertas”, 15 - “Manifesto Fiscal de Viagem”, 16 - “Leitura do Movimento Diário"

Se vc for homologar TEF discado, isso não é permitido... Ou seja, Cartão SEMPRE deve ser a última forma de pagamento

Apenas a titulo de informação... Leitores USB se comportam de forma idêntica a leitores ligados no Teclado jacksondb, Experimente desabilitar a seguinte propriedade: ACBrECF.Device.ProcessMessages := False isso fará o ACBrECF se comportar de forma semelhante as DLLs.. ou seja, ele irá "congelar" a sua aplicação enquanto ele estiver ocupado...

Humm... não sou usuário do Delphi2010... Iran, qual foi a correção que vc aplicou ? Elton, poderia verificar isso para mim ?

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...