EMBarbosa

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:

Essa alteração foi adicionada há bastante tempo por causa desse tópico aqui: Parece que a opção True ocasionava problemas quando se cria os componentes em runtime. Essa opção do Fast Report está relacionada a Multi-threading. Não tenho certeza se ainda é pertinente...

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.

Esse erro é de schemas, ou na sua máquina ou no servidor da SEFAZ. Pelo visto você está enviando informações no elemento 'infRespTec', mas os schemas não estão preparados para isso. Por favor, verifique se os schemas estão atualizados e também se você deve enviar essa informação a SEFAZ de MG. Se depois de verificar isso continuar a ter os erros, nos envie as informações que o Amarildo pediu acima.

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).

Para acrescentar ao que o Júnior escreveu, Esse erro se refere a uma nota que foi emitida e transmitida e ao considerar o horário da recepção pelo servidor da SEFAZ, isso aconteceu num tempo superior a 5 minutos. Por exemplo: Você emite uma nota e a data de emissão dela consta 16/05/2019 10:30:19. Mas quando ela é transmitida, o horário do servidor da receita consta 16/05/2019 10:36:19. Nesse caso a nota vai ser rejeitada com o erro mencionado. No caso de vocês parece que está havendo um mal entendido da diferença de funcionamento Síncrono/Assíncrono. Quando vocês emitem e transmitem pela primeira vez dá tudo certo, como o Júnior mencionou. Só que não há consulta do status então talvez o programa de vocês encare como se a nota ainda não foi processada. Daí o sistema está tentando transmitir a mesma nota várias vezes. E como isso está acontecendo até com um mês de diferença, vocês passam a receber o erro acima. Veja abaixo que é a mesma nota sendo enviada nessa parte do log:

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:

Tenho algumas sugestões para você: Opção 1 - Verificar com o contador se o seu cliente pode fazer os lançamentos com enfoque no declarante. Quer dizer, ele lançaria não exatamente o que vem escrito na nota, mas como ele considera o produto. Nesse caso em vez de lançar 120 m3 de madeira ele vai lançar 120 caibros 5X2, 60 caibros 5,5X2, etc... Opção 2 - Verificar como o seu cliente fazia anteriormente pra controlar o estoque. A partir daí, você pode tentar seguir o mesmo esquema automatizando de acordo com seu programa. Opção 3 - Criar um sistema de conversão de produtos de entrada. Nesse caso, seu sistema teria um cadastro de produtos que são gerados a cada m3 de madeira. O cadastro seria alimentado pelo cliente e, a partir da entrada, seu programa faria a conversão. Mas só funcionaria mesmo se os fornecedores dele mandam sempre a mesma quantidade de material para a mesma quantidade de m3 de madeira. Opção 4 - Criar um sistema de produção. Esse seria uma área separada do seu programa e funcionaria como o Italo descreveu acima.

A parte de comentar era responder as perguntas acima mesmo. Não precisa comentar o código.

Na verdade pode existir fórmula, mas vai depender das medidas e do método de transformação. Poderia explicar com mais detalhes como é a peça de madeira que ele compra e como ele a transforma pra venda?

Moderação: Fechando esse tópico que é de 2014. @Dempsey e @Agnaldo Prates Há tópicos mais recentes falando sobre esse assunto. Queiram por favor acompanhar o seguinte:

Use o mesmo tópico apenas se estiver falando sobre a mesma coisa que o primeiro tópico menciona. Quando o assunto não for o mesmo, por favor, sempre crie um novo tópico. Por exemplo, se no primeiro tópico estiver falando sobre o nome do arquivo gerado pelo ACBrNFe e o que você quer criar for sobre a geração de imposto no ACBrNFe, crie um novo tópico. Ambos são sobre NFe, mas são assuntos diferentes. Mas nesse caso, me parece que todas as alterações estão seguindo a mesma ideia e você só está encontrando lugares diferentes a alterar. E mais, nenhuma delas foi enviada ao SVN. Então é melhor continuar usando o mesmo tópico.

Apenas para acrescentar: Isso acontece porque a grande demanda obrigatória do TEF foi próximo desses anos. Havia a exigência do TEF no PAF-ECF, muitos "players" novos no mercado e grande atividade no projeto ACBr nessa área. A maior parte das informações continuam atuais. Mas algumas coisas ou exigências foram simplificadas. Geralmente, dá pra perceber isso no roteiro de certificação que eles te passam. Geralmente é remoto. Não conheço nenhuma que hoje em dia exija a certificação presencial. Não existe emulador de tef do ACBr. Mas ao entrar em contado com as certificadoras elas vão te disponibilizar tanto as dlls como um sistema que emula o TEF para que você possa implementar.