Daniel Simoes

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

Acredito que seja necessário salvar a sua Chave Privada nas configurações do ACBrMonitorPLUS

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

Você abriu o link indicado ? Tentou atualizar ? Acione o suporte do fabricante e verifique

Porque o seu Delphi é antigo e não é compatível com o evento da maneira que está escrito... Você precisará remover o evento... e deixar a IDE criá-lo novamente..

Obrigado pelas informações, analise e correção... Modificações já estão no SVN..

Isso fica a seu critério... que tal "Modelo, Porta, SerialParams"... veja no ECFTeste.ini... Você pode salvar toda a configuração do "Device" em apenas 1 linha... Veja: ACBrBAL.Device.ParamsString

Proceda como nos posts indicados... Tente registrar a DLL da CAPICOM manualmente... Pode ser que o Instalador não tenha conseguido realizar essa tarefa, nesse sistema Operacional

NÃO