Daniel Simoes

Por essas e outras, que recomendo apenas A1 e OpenSSL... onde esses problemas de certificado, não existem...

Mais um ponto de preocupação (além do Switch e cabos de rede)... se a máquina do Servidor SAT para... TODOS os caixas morrem... Sei que não é simples desenvolver um servidor desse nível...e deve ser muito bacana ver ele funcionando... mas sinceramente... acho que isso é "economia a base da porcaria"... eu não entro nessa conversa do Cliente... Seu cliente pode achar que está economizando... mas no dia que der um problema em um dos componentes cruciais...e ele ter prejuízos e reclamações, ele vai querer achar um culpado... mesmo que o motivo seja a queima dos equipamentos por descarga elétrica... Bom... acho que já deixei claro meu ponto de vista... vou parar de monitorar esse tópico...

Um valor bom para TimeOut é 10... No caso do protocolo 'EscEcf', como o ECF tem a capacidade de responder que está ocupado... o TimeOut não tem muita função...

Consegue em ambos os casos.. via programação seria melhor... pois seria mais fácil de fazer um "merge" com as futuras modificações do ACBr

o erro indica que o seu provedor recusou a conexão... com certeza há algo errado na sua configuração... mas fica impossível ajudar, sem saber mais detalhes do seu provedor...

Tente também com: "libCapicomDelphiSoap".. Leia mais em:

Você observou no Log, que o o componente detecta a situação de loop e sai dela corretamente ? Estude o Log com atenção... Acredito que o seu problema, seja o TimeOut muito alto... (30)... o componente ficará aguardando uma resposta válida do ECF por até 30 segundos

O que você quer dizer com "agora não passa pelo monitor" ?? Conforme descrito na correção... o XML será enviado para o SAT, exatamente igual, como você o enviou para o MonitorPLUS... e isso pode ser comprovado com o ACBrSAT.log (O XML foi enviado com sucesso)

Vc usa o ACBrTEFD ? Devida a essa limitação de alguns ECFs, o ACBrTEFD, agrupa vários Comprovantes, que usam a mesma forma de pagamento, em um único CCD

Sim... no caso do TEF, as maquininhas autônomas (chamadas de "POS"), podem ser usadas com contingência... e NFCe, pode ser usada em modo off-line... A conta que deve ser feita é: - Qual a economia gerada na compra de SATs ? - Qual o prejuízo/hora, se o todos os caixas pararem ?

Por favor poste um exemplo do XML sem a assinatura, e um Exemplo de como ele deverá ficar após assinado

Mas se o Switch morre, todos os caixas param de operar.... Já se perguntaram se Burger King, Americanas, Carrefour usariam esse modelo ? Para quem o cliente vai ligar desesperado, quando o Switch cair, e todos os caixas pararem ? Dependendo do volume do cliente, talvez só o prejuízo causado por uma situação dessas (lucro cessante), por alguns minutos, já represente um valor maior do que o do SAT... Na minha opinião o PDV deve ser capaz de funcionar mesmo totalmente off-line... e a transição on-line / off-line, deve ocorrer de forma transparente para o operador... Para quem nunca fez certificação de PAF-ECF, pode ser muito difícil de implementar um PDV totalmente off-line ... mas com certeza isso é um recurso muito valioso no momento da venda do sistema...

Isso não depende do ACBrECF... Enquanto o ECF responder que está ocupado... para o ACBrECF, só resta aguardar e pedir novamente o status...

Em que momento ela fica ocupada por tanto tempo ? consegue identificar isso no Log, pelo numero de pedidos de Status ?

Leia o protocolo do EscEcf... O ACBr perguntou: "Qual o seu Status ?" e o ECF respondeu WAK (ocupado)... Faça o seguinte, crie um novo Log, e reproduza no ECFTeste, a situação onde ocorre o loop infinito...

Mergulhe no código (ligue o seu debug)... só com botão e tentativa e erro, você não vai descobrir nunca... o problema é local (na sua máquina)... Centenas de desenvolvedores usam o ACBrMail com sucesso...

Não há nada de errado nesse Log... e o ultimo comando está incompleto...

Vá com o Debug e apure o ponto de "travamento" provavelmente está ocorrendo uma demora no Login...

Adicione emtradas de LOG para arquivo, em diversos pontos do seu programa... Nao há como debugar isso sem Logs... Provavelmente o programa está ficando preso, em algum Loop infinito

Reveja a sua rotina... Provavelmente ainda há algo errado... A mensagem de erro é muito clara, o ACBrMonitorPLUS tentou abrir o arquivo, e o acesso foi negadado... Não há nada que possa ser feito do lado do MonitorPLUS

O componente ACBrMail não faz uso de nenhum componente visual (WidGetSet)... Provavelmente a mensagem vem da aplicação que está chamando o ACBrMail

Se deseja sugerir correções nos fontes do ACBr, favor anexar os fontes modificados...

A compilação do ACBrMonitorPLUS é semanal... E é reponsabilidade do @Isaque Pinheiro

Comprar e manter esse gerenciador, não irá ser mais caro do que comprar 6 SATs ? Lembre-se de que dessa maneira, compartilhando por Rede, você mata a grande vantagem do SAT, que é poder trabalhar totalmente Off-Line Instale um SAT por caixa e durma sossegado...

Qual comando você está enviando para o ACBrMonitorPLUS (ENT.TXT) ? Qual a versão que você está testando ?