Daniel Simoes

Por favor seja mais objetivo no relato de bugs... Use o Demo do ACBr, ou forneça um mini-projeto que reproduza o erro... Sem um passo a passo, não tenho como reproduzir o problema, e chegar no mesmo problema que você

A rotina de geração de MDFe do Demo estava errada, faltava chamar: ACBrMDFe1.Manifestos.GerarMDFe; Apliquei a correção no SVN

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)