Daniel Simoes

Acredito que essa modificação não seja necessária... Observe que em procedure TGerador.wCampo, será aplicado esse replace para todo tipo String tcStr: begin // remover as quebras de linha e trocar por ;, porque a quebra de linha causa erros de assinatura ConteudoProcessado := ChangeLineBreak( Trim( VarToStr(valor) ), ';'); EstaVazio := ConteudoProcessado = ''; end;

Forneça um passo a passo de como reproduzir o problema usando o Demo do ACBrNFe

Verifique no ACBrNFeServicos.ini se o endereço está correto

Não compreendi o seu post... é uma afirmação ou pergunta ? ainda há algum problema com esse WebService ?

Acho que o Antivírus poderia causar esse tipo de problema...

Oi Henrique, Já enviei para o SVN...muito obrigado...

Por favor teste com uma versão mais recente... eu promovi várias correções nos métodos de leitura de Retorno e Envio Submeti o seu XML ao MonitorPLUS, depois de editar as informações do emitente para a do meu certificado, mas aparentemente há um erro nas informações do produto...

Adicione esse diretório no Library Path do Delphi

Henrique, Você acha que devemos deixar esses parâmetros como default ? Se SIM, poderia por favor enviar as Units modificadas ?

Vou baixar o doPDF e testar...

Se você não anexar o XML, não há como testarmos... A rotina de Validação está ok... caso contrário seria impossível enviar NFe pelo Trunk2 Pode ser alguma peculiaridade do seu XML...

Aparentemente esse problema só ocorre em algumas impressoras... Usando uma Impressora PDF (FoxIt) o problema não ocorre... (ainda não testei em uma impressora real... haja papel... ) Em todo caso, vou revisar a rotina e ver se acho algo que possa ocasionar o problema

Basicamente, se o comando "ConsultarNumeroSessao" funcionasse corretamente para todas as Sessões do dia (ou de um periodo), já seria ótimo, e conseguiriamos recuperar o XML... Porém atualmente, o ConsultarNumeroSessao só funciona uma vez, e se for imediatamente após a venda (praticamente inútil)

Alguns fabricantes não fazem distinção de cor para definir se é Produção ou Homologação (é o caso da Sweda) Se o número de série do SAT inicia com "9", então ele é de homologação...

Você chegou a analisar o componente TACBrNCMs do Package ACBrTCP ?

Implementação interessante... acho que podemos usá-la no ACBrPosPrinter... Mesmo ela tendo um escopo de funcionamento bem específico, pode ser útil... Ando ocupado com o Trunk2 e NFe... mas assim que possível, volta a analisar esse assunto...

Testei aqui, e tudo está funcionando a contento... Provavelmente você está carregando com o AsXMLString, a versão de envio (sem o ID)... Verifique se o XML de Cancelamento que você está armazenando, é o XML de Resposta do SAT.. (ele deve conter a Tag ID)

Não há nenhum erro nesse Log Esse problema não tem relação com o discutido aqui no tópico... (loop infinito)

Prezados, Evitem usar a porta USB.... Usem a porta Serial do ECF, que muito provavelmente o problema será resolvido...

Não compreendi muito bem a sua lógica... Como isso irá trazer a resposta esperada, ao comando enviado ao ECF ?

Parece ser um problema no S.O. dessa máquina... Experimente em outra máquina...

Obrigado pelo interesse em ajudar... Basta anexar aqui mesmo no fórum as Units modificadas, ou criadas, que vamos analisando...

O Recibo não irá retornar pois o documento já foi aprovado... O Recibo só tem sentido se você precisa consultar o documento que está aguardando uma aprovação (NFe, assíncrona)

Paulo, Não compreendi exatamente o que você quer... Você quer que ele grave NOVOS XMLs na pasta, mas que NUNCA modifique os XMLs já existentes... é isso ?

A comunicação serial do ACBr é feita pela classe SynaSer... que está estável a anos... E todos os demais modelos do ACBr, usam o mesma classe...(que funcionam corretamente) Outro fato a favor do ACBr, é que esta mesma classe (mesmo código fonte), funciona nos equipamentos Epson TM-T800F e Daruma FS800, (pois todos esses equipamentos usam o protocolo EscECF)... e o problema não ocorre neles... Em todos os Logs que me foram enviados para analise... fica comprovado que o equipamento (ECF) continua respondendo... O Loop ocorre, em algumas situações específicas.. mas em único ponto do código do ACBr, que é quando o ACBrECF, envia um pedido de Status... o ECF responde com (ocupado).. após isso o ACBrECF aguarda 50 (200) milissegundos, e solicita novamente o Status... e isso fica de forma infinita... Eu sempre mantive um bom relacionamento com a Bematech, e estou disposto a trabalhar em conjunto na solução do problema, se eles me procurarem... Mas tenho notado um certo distanciamento da Bematech com as Sw.Houses ...A título de exemplo: solicitei para eles um SAT e MP4200 para testes... ficaram de enviar... estou esperando até hoje...