EMBarbosa

Não seria exatamente obrigatório. Acho que poderíamos dizer que seria recomendado, mas não obrigatório. E se você já tem algo funcionando, penso que seria até contraproducente exigir isso sem analisar seu código. Por outro lado, se você puder verificar os outros componentes que fazem esse tipo de leitura, pode ser que você veja algumas vantagens: talvez note algum código que você não precisaria refazer e poderia eliminar do seu componente; talvez perceba alguma maneira melhor de fazer certa rotina; talvez entenda melhor o código do ACBr e isso o ajude em outras ocasiões ... talvez encontre algum erro no código dos componentes atuais que você corrigiu no seu e possa nos ajudar

Embora eu tenho certeza que outros usuários aqui do fórum podem te responder, sugiro você procurar outro caminho. Quando os próprios fiscais não se entendem, eu sugiro você fazer uma pergunta formal a SEF e a qualquer outro órgão competente. Você pode até mencionar que fiscais diferentes exigiram procedimentos diferentes o que deixou então uma dúvida sobre qual o procedimento correto. Junte essas informações e compartilhe com os responsáveis. Isso inclui os funcionários e os contadores da empresa de transporte. Daí, se continuar acontecendo dos fiscais implicarem, você pode orientar os motoristas e responsáveis pela carga a apresentar a resposta da SEF (e qualquer outro documento recebido). Isso evita dor de cabeça.

Por favor, continue no seguinte tópico:

Olá muito obrigado pelas várias contribuições. Está na nossa fila de análise.

Muito obrigado pela sugestão. Fiz uma implementação baseada nela. Subi as alterações para o SVN na Revisão 17110. Pelo que vi está tudo certo. Favor testar e reportar qualquer problema.

Olá, Em primeiro lugar, muito obrigado pela iniciativa e pela intenção de contribuir com o projeto. Ficamos felizes com as contribuições. Obrigado por ter apontado também ao outro tópico, de modo que podemos relacionar os dois. Hmmm... acho que precisamos fazer um artigo na base de conhecimento sobre contribuições em forma de código ou componentes... Mas vamos lá! Nós pedimos que os novos componentes: funcionem em Lazarus e Delphi preferencialmente usem apenas bibliotecas de terceiros que já estão no nosso SVN se esforcem em seguir a formatação dos componentes já implementados possuam um aplicativo simples de demonstração Sobre o componente específico, depende mais do que for necessário. Se for comunicação com WebServices, é provável que se você basear num componente da paleta ACBrDFe poupará trabalho. Mas se for apenas comunicação TCP, então veja os componentes da paleta ACBrTCP. Acho que eu não entendi exatamente como você quer que ajudemos. Se você tiver uma dúvida mais específica, talvez fique mais fácil opinar. Caso contrário, você pode enviar o código, explicar suas dúvidas e pedir sugestões.

Enviei as alterações ao SVN na revisão 17103. Creio que está tudo ok. Queira por favor atualizar, testar e reportar qualquer problema. Muito obrigado pela contribuição.

Muito obrigado pela contribuição. Enviei as sugestões na revisão 1702 com a seguinte diferença: Não é necessário adicionar True no Create, porque o método Create já atribui True para FFreeObjects. Queira por favor atualizar, testar e reportar qualquer problema.

Hmm então parece que você quer uma recomendação pra apresentar o grid na tela. Se for isso, vai depender do que você realmente quer e da sua disposição de pagar algum componente já pronto. Eu sugiro você dar uma olhada nos componentes de grid da TMS e da DevExpress. Existem outros na internet e, se tiver condições, vale a pena investir. Por exemplo, eles costumam já ter embutido no código a conversão do grid para Excel e, em alguns casos, até a impressão. Pense em quanto tempo você economiza de desenvolvimento. Caso não possa adquirir, tente usar os grids da biblioteca Jedi (JCL/JVCL). Por exemplo o UltimateGrid tem alguns recursos que o grid padrão do Delphi não tem.

E qual o problema?

Olá, Eu acabei de enviar ao SVN (revisão 17083) uma correção para os ECF de modelos que utilizam o protocolo ESCECF, FiscNet e Epson. Você pode atualizar o seu código e testar novamente. Queira, por favor, reportar qualquer problema.

Se for uma ECF MP4200 TH-FI é possível que seja sim. Só que a alteração será no outro arquivo (ACBrECFEscECF.pas).

Pode ser um problema do ACBrECF. Para confirmar poderia por favor alterar o arquivo ACBrECFEpson.pas na seguinte procedure, TACBrECFEpson.SubtotalizaCupom: procedure TACBrECFEpson.SubtotalizaCupom(DescontoAcrescimo: Double; MensagemRodape : AnsiString); begin fsTotalPago := 0 ; if DescontoAcrescimo = 0 then exit ; EpsonComando.Comando := '0A04' ; if DescontoAcrescimo < 0 then EpsonComando.Extensao := '0006' else EpsonComando.Extensao := '0007' ; EpsonComando.AddParamDouble( abs(DescontoAcrescimo), 2 ); EnviaComando ; ZeraCache; RespostasComando.AddField( 'SubTotal', EpsonResposta.Params[0] ); fsEmPagamento := True ; end; E depois refazer os testes?

hmmm então o teste que eu passei não foi suficiente. Poderia manter a alteração que eu pedi e comentar essa verificação? A intenção é que não seja levantado nenhuma exception para que possamos avaliar se há ou não o vazamento.

Acho que o parâmetro nLote é obrigatório. Você verificou o manual? https://acbr.sourceforge.io/ACBrMonitor/NFEEnviarNFe.html

Puxa isso é frustrante. Um vazamento de 0,1 a 1 mega é muita coisa pra vazamento de memória numa função usada tantas vezes. Mas dá pra gente resolver. Vamos lá... Que ótimo! Isso ajuda muito para que juntos, analisemos o problema! Já li aqui e identifiquei um possível problema. Por favor veja essa parte que você escreveu: Poderia alterar a linha para a seguinte? DadosPFX := 'Texto apenas para ter algum valor.'; Daí repita o teste para ver se acontece o mesmo vazamento de memória. A propósito, qual versão do seu Delphi?

Eu que agradeço você ter se disposto a alterar as mensagens de erro e postar aqui para benefício de todos. Obrigado também por tentar compreender com respeito ao que não foi prontamente aplicado. Acreditamos que, quando possível, é melhor envolver a comunidade nas decisões que podem impactar diretamente sobre ela.

A comunicação pelo ACBrBal é direta pela serial, então não depende de drivers externos. Mas se você instalou uma placa serial, deve verificar os drivers dessa placa (não da balança). Você deve conferir qual é a configuração de comunicação que está no equipamento (velocidade/baud rate, Data bits, etc...) está de acordo com a porta serial e com a configuração do componente. No manual do equipamento muitas vezes menciona como você pode acessar o menu de configurações e verificar esses dados na própria balança.

Você pode resolver isso por verificar se o retorno do ECF é consistente com o retorno do ACBr. Você pode para isso usar um aplicativo do fabricante para verificar o retorno do estado do ECF. Se ao acontecer o problema o ECF estiver retornando estado como em estPagamento, então o ACBr está correto. Nesse caso você precisará verificar o seu software ou com o suporte do fabricante. Caso ao acontecer o problema o ECF esteja retornando que o seu estado é estVenda mas o ACBrECF está informando que o estado é estPagamento, então o problema é no componente do ACBrECF.

Como você detectou que o vazamento está aí? Está utilizando o FastMM? Poderia apresentar um log? Precisamos de uma aplicação que demonstre o problema. Pode montá-la? Inspecionando o código por cima não vi nada que possa ocasionar um vazamento de memória como você afirma haver. Veja bem: Se você ler o código ao redor do método ReadStrFromStream, notará que esse método não cria nenhum objeto, os objetos passados a ele por parâmetros não tem incrementação de RefCount, DadosPFX é AnsiString, o método TDFeSSL.SetDadosPFX não parece causar nenhum vazamento.

Olá não foi possível entender plenamente seu problema. Por que você não consegue fazer a alteração do ID?

Esse tipo de problema geralmente tem essas causas comuns: Erro no XML - O arquivo xml não está válido, mas não existe uma rejeição específica. Por exemplo faltando a versão do documento ou evento no arquivo xml. Nesse caso, você precisa verificar o xml, talvez usando o validador da SEFAZ. Erro na SEFAZ - Nesse caso, você só consegue uma posição entrando em contato com o suporte da própria SEFAZ. O que sabemos é que por algum motivo a SEFAZ está retornando esse erro e é preciso aguardar até que eles tenham corrigido a situação. Isso já aconteceu mais de uma vez, como podem ver nesse tópico: Schemas inválidos ou misturados - Isso pode acontecer quando os schemas estão desatualizados, são de outros documentos fiscais eletrônicos ou são misturados/colocados na mesma pasta. Exemplo:

Nada que você fizer via RTTi ou no código vai bloquear um outro programador. É melhor você atacar o problema em vez do sintoma. Proponha uma documentação pequena com informações pertinentes ao projeto. Daí você poderá adicionar isso na documentação.

Pelo que eu entendi esses arquivos são gerados pelo MF-e/integrador, então não dependem se você usa ou não o ACBr.

Que bom que resolveu. Obrigado pelo retorno.