Daniel Simoes

Finalmente consegui um tempo para analisar as pendências... Me desculpe pela demora... já enviei no SVN, rev.2402

Entre em contato com um integrador do SiTEF.... eu recomendo a DataRegis... o atendimento ao desenvolvedor é muito bom http://www.dataregis.com.br/fasttef.shtml

O ACBrAAC está sendo completamente re-estruturado... infelizmente haverá quebra de compatibilidade, mas os benefícios compensam... Devo detalhar tudo no Change-Log.txt

sim.. Fiz um teste com o 56 e notei que ele truncou o desconto calculado, imprimindo 300,00 Resolvei implementar uma ampla reforma (sempre adiada) em relação ao método "DescontoAcrescimoItemAnterior", com ele poderiamos tratar essa questão de forma mais segura...

O problema não é o TruncFix... é em ACBrECFBematech.pas, linha 1535 if TipoDescontoAcrescimo='%' then DescontoStr := IntToStrZero( Round( RoundTo(ValorUnitario*Qtd,-2) * ValorDescontoAcrescimo), 8 ) + #0 else DescontoStr := IntToStrZero(Round(ValorDescontoAcrescimo*100), 8) + #0; [/code] O problema reportado só ocorrerá se, for ECF Bematech e Desconto for informado em %

Mas na classe da Bematech, não há como enviar o desconto em Porcentagem para o ECF... apenas por Valor... então o Valor é calculado pelo ACBrECF, mas usando o round... por isso o 33,63...

Nao... A alíquota é do Produto e não da UF... O que ocorre é uma redução da Alíquota em alguns CFOPs

Notei que a Classe da Bematech sempre usa o desconto por Valor... Ela calcula o Valor do Desconto de acordo com a Porcentagem informada... Esse pode ser o problema... Acho que na verdade, informando o Parâmetro Desconto em Valor será sempre melhor... pois o ECF não precisará fazer conta, simplesmente aplicará o desconto...

O calculo do Memo está correto... Veja: 333,62 * 10,08 % = 33,628896 Truncando... temos: 33,62 333,62 - 33,62 = 300,00 Provavelmente você está informando o desconto em Valor no ACBrECF1.VendeItem... por isso o ECF não faz a mesma conta...

é lá mesmo... Veja esse manual do ACBrMonitor http://acbr.sourceforge.net/ACBrMonitor ... eItem.html (a sintaxe do componente é a mesma) Antes de partir pro código, faça vários testes usado o Demo ECFTeste.dpr, e estude bem os fontes dele...

Vc quer ver o estado a mesmo tempo que o outro programa roda ? Se SIM, isso não seria possível... pois a DLL prende a porta serial... Experimente Baixar o programa "DJIdentificaECF" deste site: http://www.djpdv.com.br/ (na seção de Downloads) Seria + ou - isso que você precisaria ?

Pessoal, A proposta já foi efetuada... e não vamos modificar os valores pelo menos por enquanto... Manter uma equipe para dar suporte eficiente (de forma proposta) custa muito caro... Não estamos falando de técnicos recém formados, mas de programadores experientes... e conhecedores do ACBr... com certeza um profissional com essas características exigirá uma boa remuneração... Agradeço as opiniões... mas nós é que vamos ter que bancar os custos do negócio, e calculamos os valores propostos baseados nas despesas estimadas... Entendo que muitos não podem (ou não querem) pagar R$ 120,00 p/ mês... mas não estamos obrigando nada a ninguém... como as respostas do primeiro tópico deixam bem claro, o ACBr e este fórum sempre continuarão abertos, e muitas pessoas conseguiram obter sucesso no uso do ACBr sem precisar de mais nada do que a boa vontade de outros usuários do ACBr... Se a "onda" seguir em frente, sempre teremos muitos voluntários ajudando quem chega... Exemplificando o que eu quis dizer: Você provavelmente recebeu ajuda de alguém aqui mesmo no fórum... portanto, quando seu programa estiver funcionando e você tiver uma boa experiência, é a hora de ajudar alguém que está chegando, respondendo as perguntas de outros usuários... Quantos usuários do fórum fazem isso ?? Para algumas empresas, apenas a boa vontade dos usuários não basta... Já perdi a conta de quantas vezes vi empresas que gostaram do ACBr, mas que decidiram não utiliza-lo, por não ter uma suporte "formal" por trás dele... Empresas que temem se "aventurar" no mundo Open Source... sem uma garantia formal... para essas empresas, o SAC foi criado... Se você acha que o ACBr merece uma remuneração mensal pelo que ele lhe proporciona, mas não quer pagar R$ 120,00... tudo bem, temos a doação para isso... Temos usuários que fielmente nós fazem uma doação mensal... como por exemplo o Toninho, que todo mês nos doa R$ 50,00... Basta acompanha no site: http://acbr.sourceforge.net/drupal/?q=node/35 Se alguém quiser criar um suporte comercial, concorrente, a R$ 80,00 / mês, fique a vontade... acho que há espaço para todos... eu não posso (e não desejo) impedir isso.. Eu sempre vou estar presente no fórum aberto, pelo menos sempre que meu tempo permitir... Sempre tive consciência, de que não adianta simplesmente criar os fontes... é necessário termos exemplos, documentação e suporte... sem isso nenhum projeto Open Source vai para a frente... O fórum aberto sempre será a "porta de entrada" para os novos usuários do ACBr... e olhando pelo lado comercial, abandonar os usuários recém chegados, não é uma boa tática... Qual seria a motivação uma nova empresa para pagar o SAC no futuro, se ele tiver uma péssima impressão do seu primeiro contato com o projeto aqui no fórum ? A previsão de inicio de funcionamento do SAC é em Agosto... A equipe da DJSystem está muito ocupada no momento, com desenvolvimento interno... e esse tempo também nós dará a oportunidade de fazer um levantamento real de nossa receita x despesas. Se eu falar que não pretendo ganhar dinheiro com o SAC, estaria mentindo... Mas este não é o meu principal objetivo... Atualmente a minha empresa, DJSystem, vai muito bem (obrigado) e eu realmente poderia viver sem a renda do SAC... Entendo até se no primeiro ano, o SAC gerar mais despesas do que receita... O meu principal motivo para a criação do SAC é profissionalizar o ACBr... Ganhar peso, ficar atraente, e atrair grandes empresas e fabricantes... Com a renda obtida poderíamos melhorar significativamente a qualidade dos fontes, tempo de analise das sugestões, documentação, etc e tudo isso seria prontamente revertido para o projeto.

Cada Impressora tem uma maneira... geralmente é ligar o equipamento mantendo um dos botões pressionado por alguns segundos... Por favor verifique no manual do seu equipamento

Humm.. eu tb não sabia que já havia uma versão 64 bits do com0com... estava usando um chamado "vspMgr"

Veja o Demo em: \ACBr\Exemplos\ACBrCEP

Vc instalou algum programa virtualizador de Portas Seriais ? Veja esse tópico: viewtopic.php?p=813#p813 http://acbr.sourceforge.net/ACBrMonitor ... nitor.html

Sobre USB, veja esse tópico: viewtopic.php?p=9626#p9626 O ACBrETQ já usa o GAP (sempre). Se a Etiqueta não está respeitando isso ela deve estar com alguma configuração de página na memória... Nesse caso é necessário efetuar um reset no equipamento O Avanço é usado para ajudar o usuário a destacar a etiqueta no termino da impressão... e quando usado, a própria impressora retorna o papel na próxima impressão...

Provavelmente sua Impressora está com a configuração de pagina na memória... e com isso ela não usa o GAP da etiqueta Experimente efetuar um reset na impressora

Ok... vou debugar aqui... mas por favor teste o seguinte... - Feche/Finalize o ACBrMonitor 0.9.4, - Feche a sua aplicação - Abra o ACBrMonitor 0.9.4 -Teste a comunicação com a sua aplicação Preciso saber se o Bug é a cada inicialização do ACBrMonitor (o que seria mais grave) ou se é apenas quando da primeira configuração

Oi Jonas... Acho que realmente temos um bug aqui... mas ainda não consegui identificar como reproduzi-lo... Usando uma ACBrMonitor recém instalado, quais são os passos para reprodução do problema ?

Jonas, O finalizador mudou... http://acbr.sourceforge.net/ACBrMonitor.htm

Acho que esse protocolo (ZPL2) ainda não está corretamente implementado no ACBrETQ...

Somente em modo de Intervenção Técnica...

Apenas complementando... Somente na Bematech MP20-FI II que ocorre o fato de apagar as formas de pagamento após a Red.Z

Vc está usando qual modelo no ABCrETQ ?