EMBarbosa

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.

Olá, Sobre a questão dos nomes de arquivos, boa parte dos moderadores e devs não acham apropriado alterar esses nomes. Para não criarmos uma polêmica vamos tratar nesse tópico apenas das outras alterações propostas. Se você realmente achar esse recurso muito importante, por favor, crie um novo tópico só sobre isso. Assim, poderemos pedir que tanto outros devs como usuários do ACBr de modo geral possam opinar. Sobre as mensagens, eu enviei ao SVN na revisão 17056. A única linha que não alterei foi a que altera "FNFe.Ide.verProc". Porque a string é ACBrNFe. Não existe ACBrNFCe. Ainda assim, deixei um comentário, caso tenhamos outros motivos para ajustar isso. Queira por favor, atualizar e testar.

Sim. No momento só ela tem dado problema nas UFs.

A validação pela Sefaz RS também passou normal. Mais uma vez acho que o problema é local. Veja também esse tópico: Se em todo o caso você continuar achando que o problema não é local, acho melhor você entrar em contato com a sefaz da BA.

Provavelmente o seu método CriaConexao está sendo chamado mais de uma vez, antes de ser chamado o método DestroiConexao.

Olá maicon, Eu acredito que é um erro no seu arquivo schema local. Note que o campo vICMSSTRet é obrigatório em todas as menções dele na NT 2018.005. Sim. A princípio ele foi o único campo que gerou problema nessa rejeição específica (938).

Há uns 6 anos atrás achei isso: tão verdade...

Se tiver sugestões de onde o evento pode ser realizado em campinas você pode criar um tópico dando as sugestões. Certeza que vão ser levadas em conta.

Pode ser que o estado não esteja preparado para a versão 2.0 do GNRe. Você pode verificar isso no seguinte site: Pode-se consultar alguma (in)compatibilidade no seguinte site: http://www.gnre.pe.gov.br/gnre/portal/consultarTabelas.jsp Queiram por favor verificar também o seguinte tópico sobre o assunto que indica que alguns campos adicionais podem não estar disponíveis em algumas UFs: