Daniel Simoes

Amarildo, Repare que modifiquei a forma como a VendaBruta é tratada nos cancelamentos... Deixei de forma idêntica ao ECF... mas pode ser que isso afete a sua aplicação... Você pode usar o valor de TotalCanceladoEmAberto, para subtrair da VendaBruta

Por favor veja esse anúncio: http://www.projetoacbr.com.br/forum/announcement/12-novo-fortes-report-ce-e-projeto-acbr/

Estranho... Em ESCPOS, nomes longos ocupariam várias linhas... por favor poste uma imagem do Cupom

Desculpe-me, mas não compreendo seu post, você misturou muitos assuntos

Como autor do TDI, fico contente pela indicação... Hoje em dia interfaces TDI são mais amigáveis aos usuários do que a MDI Mas se você realmente quer um MDI, tenho notado nos commits da Rx da CCR, que eles estão implementando um componente para MDI

Não notei nada nos fontes que pudesse produzir esse espaçamento... provavelmente é uma limitação/característica do EscPos desse equipamento... após a impressão de um QRCode Veja no Log gerado pelo ACBrPosPrinter, se há a o envio de linhas em branco após o QRCode.... isso comprovará se é o equipamento que está causando o espaçamento (ou não)... Ou ainda, tente a impressão em EscPos em outra marca de equipamento...

RoundABNT( 4.855, 3 ); => 4.855 Não há arredondamento... você informou 3 casas, e pediu para arredondar na 3 casa... Tente com: RoundABNT( 4.855, 2 ) Conferiu os fontes da UnitTest ? Confira em: ACBr\Testes\FPCUnit\ACBrComum\acbrutiltest.pas procedure RoundABNTTest.TresParaDuasCasasDecimais; begin CheckEquals( 5.10, RoundABNT(5.101, 2)); CheckEquals( 5.10, RoundABNT(5.102, 2)); CheckEquals( 5.10, RoundABNT(5.103, 2)); CheckEquals( 5.10, RoundABNT(5.104, 2)); CheckEquals( 5.10, RoundABNT(5.105, 2)); CheckEquals( 5.11, RoundABNT(5.1050123, 2)); CheckEquals( 5.11, RoundABNT(5.106, 2)); CheckEquals( 5.11, RoundABNT(5.107, 2)); CheckEquals( 5.11, RoundABNT(5.108, 2)); CheckEquals( 5.11, RoundABNT(5.109, 2)); end;

Acho que quem pode lhe ajudar é o Suporte da Daruma...

Até onde sei.. não há nada de errado com o RoundABNT.... veja os testes que são executados contra ele, nas Unit Testes do projeto... Favor providenciar alguns valores que comprovem a sua tese... Podemos usar o Emulador de ECF Bematech MP4200-TH-FI, para comprovar os resultados esperados

Seus fontes devem estar desatualizados... Por favor leia o Change-Log.txt

Não há problema algum... Também achamos o UniNFe um ótimo projeto...

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Favor leia as regras do fórum.

Como eu já tinha nos meus fontes uma validação de Email usando TRegExpr (FPC), apliquei a mesma nos fontes do ACBrValidador...

Se não deseja migrar para o Trunk2, você pode comparar a Unit ACBrECFEscEcf.pas de Trunk e Trunk2, e verificar a possibilidade de efetuar um merge na sua versão

Apliquei algumas otimizações no código... Testei em Lazarus e D7 e tudo OK

Gere ambos os XMLs, grave em Disco, e compare com WinMerge...

Por favor NUNCA cole um texto gigante como esse... A impressora está em Loop, respondendo como "ocupada" Veja no change-log do Trunk2, que já foi aplicado um "workaround" para essa situação na Daruma

Ajudaria mais se vide descrevesse a exata mensagem do Erro, retornado pelo SAT Seu problema não parece ser o descrito... Não há nada errado com a atribuição...

Notei que o arquivo enviado, está em UTF8... isso poderá causar problemas para usuários de D7

Não se trata disso... Uma reforma estrutural seria necessária, para deixar a aplicação ThreadSafe... Não é criada uma nova instância dos componentes do ACBr a cada Thread... Embora toda a execução de cada conexão ocorra dentro de uma chamada com Synchonize, o que causa o efeito de criar uma nova entrada no CallStack (Pilha)... é possível que as informações de uma thread, contaminem a outra... Imagine o exemplo: duas Threads chamam o mesmo método: NFE.StatusServico... da maneira que está implementado (Synchonize), a última chamada irá congelar a primeira chamada, e ficará acima da pilha, após a ultima chamada ser executada por completo, a pilha retornará para a primeira chamada... mas nesse momento, as Propriedades do Componente ACBrNFe, foram alteradas pela execução da segunda chamada.. e o retorno da Primeira chamada poderá conter dados inválidos...

Isso não é disparado pelo ACBrSAT, mas sim pela DLL do fabricante

SIM, e porque não seria ?? Você não está conseguindo executar 2 Monitores na mesma máquina ? Sim, cada conexão é uma nova thread... mas o Programa não foi escrito para permitir que diferentes Threads façam uso dos mesmos componentes simultaneamente (ThreadSafe)

Sim, mas vc terá que gerar os PDFs manualmente, e criar o email, anexando os PDFs, usando os comandos do Objeto "MAIL"

Geralmente o ACBrMonitor é instalado de forma Local, em cada máquina... Se você tem situações de "concorrência", é melhor continuar mantendo 2 ACBrMonitores

Você deve dirigir essa pergunta para o Suporte Técnico de sua Sw.House