EMBarbosa

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:

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.

Algumas sugestões. Verifique: se as contas e dados de login realmente existem; se os e-mails estão configurados corretamente (por exemplo, no google é exigido uma configuração para permitir o acesso por aplicativos menos seguros); se as dlls estão atualizadas (exemplo, dlls da openssl); se existe algum problema externo. (Exemplo: modem?)

Eu sugiro você usar um profiler ou medir o tempo de execução de cada linha para conseguir verificar onde exatamente dentro dessa rotina acontece a lentidão nessas máquinas.

Acontece nas melhores famílias. O código que você está interessado está no arquivo ACBrEFDBloco_H_Class.pas, na procedure TBloco_H.WriteRegistroH005(RegH001: TRegistroH001), especialmente essa parte abaixo: if (FBloco_0.Registro0000.COD_VER >= vlVersao104) then begin if DT_FIN >= EncodeDate(2012,07,01) then begin case MOT_INV of miFinalPeriodo: strMotInv := '01'; miMudancaTributacao: strMotInv := '02'; miBaixaCadastral: strMotInv := '03'; miRegimePagamento: strMotInv := '04'; miDeterminacaoFiscos: strMotInv := '05'; else strMotInv := '01'; end;

Moderação: Tópico dividido.

Sim. Porque é uma função para o tipo Motivo de inventário. Sim. Foi isso mesmo que você mesmo escreveu no seu primeiro post que queria, veja: Aqui você está confundindo índice com valor. O valor do tipo enumerado não é necessariamente o seu índice. É justamente por isso que temos essas funções. Claro! MOT_INV é do tipo TACBrMotInv. Não é string. Mas também não é inteiro. Se você quer converter o valor para atribuir ao campo MOT_INV você deve usar a outra função StrToMotInv. Isso, na verdade é mais uma prova que você está equivocado, porque conforme você mesmo disse no primeiro post, e conforme consta no Guia prático da EFD, página 191: