Jéter Rabelo Ferreira

Olá. Eu estive analisando a unit ACBrNFeWebServices para retirar esse memoryleak. Como existem várias pessoas que utilizam o componente, eu pensei numa forma de fazer isso que gerassse menos transtornos, mas a melhor maneira, a meu ver, é o seguinte, algumas proprietades deverrão ser removidas e outra criada. Analisando: As propridades: property protNFe: TProcNFe read FprotNFe write FprotNFe; property retCancNFe: TRetCancNFe read FretCancNFe write FretCancNFe; não faz muito sentido de existirem se for criada uma propriedade conforme tem a classe TNFeRecibo: property NFeRetorno: TRetConsReciNFe read FNFeRetorno write FNFeRetorno; uma vez que TRetConsReciNFe contém a classe TProcNFe. O que serie necessário acrescentar apenas e TRetCancNFe à classe TRetConsReciNFe. Nesse caso, a property NfeRetorno seria criada no constructor da TNFeConsulta e destruida no destructor, eliminando de vez o memoryleak. A minha dúvida é, como disse no início da mensagem: A Base de usuários que atualmente estão utilizando o componenten ACBrNFe que, após a atualização, vão ter mensagens de erros de compilação. Claro que nada muito dificil de resolver, mas o que pode gerar uma quantidade considerável de perguntas. Caso acharem que pode ser feito, eu efetuo as alterações e envio o arquivo. Uma observação, não analisei se essas propertys são necessárias noutras classes do ACBrNFe, fato esse que, caso sejam, claro que tudo deverá ser corrigido. Aguardo respostas. Atenciosamente. Jéter Rabelo Ferreira

Boa tarde. Está ocorrendo um MemoryLeak ao efetuar consulta de uma NFe. Ao verificar o código fonte, eu verifiquei que um objeto não estava sendo liberado, possuindo com uma mensagem de advertência na frente referente ao motivo da não liberação do mesmo: unit ACBrNFeWebServices Linha 1861 //NFeRetorno.Free; (se descomentar essa linha não será possível ler a propriedade ACBrNFe1.WebServices.Consulta.protNFe.nProt) Ao não liberar esse objeto, gera o MemoryLeak. A não liberação dele, conforme a observação, deve-se ao fato de apenas não conseguir consultar o número de protocolo. Não seria o caso de criar um property para armazenar o nProt? Ter um memoryLeak "apenas" por causa no número do protocolo? Na minha opinião não acho necessário. Atenciosamente. Jéter Rabelo Ferreira

Olá Isaque. Uma parte ja está corrigida e a unit já foi anexada em meu primeiro post. Caso deseje, pode mandar essa unit e, assim que eu terminar umas urgências, eu verifico o restante e te envio para que seja enviado ao svn. Atenciosamente. Jéter Rabelo Ferreira

Olá Daniel. Com certeza, de padrão não existe absolutamente nada. Para você ter idéia, já estou com problemas na unit da CEF. A Unit implementada pelo ACBr deu erro num cliente meu. Ao fazer uma conferência com a unit do RLBoleto, eu verifiquei que a geração do nosso número era complemtamente diferente. Aliás, no RLBoleto existem 3 units da CEF, nomeadas conforme abaixo: > RLCob104 (padrão e funciona com meus clientes) > RLCob104_SIGCB (O ACBr é parcialmente igual a essa) > RLCob_SINCO Com certeza esse é outro banco que precisamos verificar como vai ficar, pois, para mim, devido a urgências com prazo de entrega, tive que setar o Flag em meus programas para que, no caso da CEF, utilizarem o RLBoleto. Conforme dito em post anterior, estou a disposição para ajudar no que for preciso. Atenciosamente. Jéter Rabelo Ferreira

Bom dia. Realmente, "olhando por cima", tem mais alguns métodos na classes ACBrSintegra que precisa da mesma correção, sendo elas: TRegistros75.Add TRegistros75.Insert (Não testei) TRegistros88Ean.Add (Não testei) TRegistros88Ean.Insert (Não testei) Atenciosamente. Jéter Rabelo Ferreira

Olá. O componente ACBrSintegra está gerando um MemoryLeak. Na procedure abaixo, o problema está corrigido. Acontece no comando ADD. O mesmo faz uma verificação se o produto já foi adicionado na classe. Se o mesmo não foi, insere. Caso o produto já foi incluído, deve-se dar um free no objeto. function TRegistros75.Add(Obj: TRegistro75): Integer; begin Result := GetRegistroExiste(Obj.Codigo) ; if Result < 0 then Result := inherited Add(Obj) else Obj.Free; end; Atenciosamente. Jéter Rabelo Ferreira ACBrSintegra.pas

Bom dia. O SCAN é definitivo, uma vez enviado, não há necessidade de fazer mais nada. A série do SCAN começa em 900 e vai até 999. Numeração das NF`s, a cada série, sempre começa em 1. Atencisoamente. Jéter Rabelo Ferreira

Boa tarde. Em consulta a SEF/MG a respeito disso, a resposta enviada por eles foi a seguinte: "A NF-e foi criada para substituir APENAS as notas ficais modelo 1 e 1A. Os demais modelos não sofreram alteração, continuando a emissão da mesma forma que é feita atualmente.". Atenciosamente. Jéter Rabelo Ferreira.

Não. O SCAN é definitivo. Atenciosamente. Jéter Rabelo Ferreira

Boa tarde. Somente um cliente meu emitiu NF's em modo SCAN ontem na parte da manhã. O demais, estão emitindo no modo normal desde ontem de manhã, embora que alguns reclamaram que está meio lento. Hoje de manhã um cliente meu me ligou falando que uma NFe caiu em lote em processamento. Demorou 40 minutos para que a mesma fosse autorizada. Tirando isso, o restante está normal. Atenciosamente. Jéter Rabelo Ferreira

Bom dia. Como informei no meu post acima, o sistema voltou ao normal. Tente enviar a NFe da forma normal, e não via SCAN. O SCAN foi disponizilizado somente poucos minutos na parte da manhã. Atencisoamente. Jéter Rabelo Ferreira

Bom dia O problema foi corrigido agora de manhã. Houve um comunicado no Portal NFe que o SCAN havia sido liberado por tempo indeterminado para MG. O mesmo comunicado não encontra-se mais no portal NFe. Tenho um cliente que chegou a emitir algumas NFe no SCAN devido a urgências. Um detalhe importante é que, as NF-e emitidas ontem foram todas autorizadas. Portanto, caso alguém tenha algum cliente que chegou a utilizar o SCAN, deve-se providenciar o cancelamento das NF-e emitidas ontem, senão serão duas NF-e para a mesma situação. Atenciosamente. Jéter Rabelo Ferreira

Bom dia. O sistema de MG apresentou problemas ontem na parte da tarde. Foi corrigido agora de manhã. As notas emitidas ontem foram todas autorizadas. Atenciosamente. Jéter Rabelo Ferreira

Boa tarde. A mensagem de erro mudou agora! ( Anexo) /nfe2/services/NfeRecepcao2(404) - https://nfe/fazenda/mg.gov.br/nfe2/serv ... eRecepcao2 Atenciosamente. Jéter Rabelo Ferreira

Boa tarde. Essa alteração que a Juliana colocou no Banco do Brasil, foi eu que solicitei. Porque o meu cliente emite boletos de carteira 18 Convenio 6 digitos e essas informações eu peguei de um arquivo do próprio Banco do Brasil. Procurei o arquivo aqui e não consegui achar, acho que infelizmente eu o exclui indevidamente. Essa carteira é de emissão do próprio cliente, não é enviado arquivo de remessa e o retorno é o CNAB400. Juliana, o componente RLBoleto, do qual op ACBrBoleto herdou algumca coisa, tinha uma propriedade para a geração de nosso número. ///////////////////////////////////// {Define o layout do nosso número} TLayoutNN = ({Nosso Número com 11 digitos} lnN11, {Nosso Número com 16 digitos} lnN16, {Nosso Número com 17 digitos} lnN17, {Convênio com 7 digitos e Nosso Número com 10 digitos} lnC7_N10, {Convênio com 4 digitos e Nosso Número com 7 digitos} lnC4_N7, {Convênio com 6 digitos e Nosso Número com 5 digitos} lnC6_N5); ////////////////////////////// Isso somente era utilizado em alguns bancos, dos quais um era o Banco do Brasil. Não seria o caso de pensar a respeito disso? Implementar uma propriedade a mais para que, caso haja necessidade, o usuário modifique a geração do Nosso Número? Diga o que acha a respeito e, caso haja um consenso, posso ajudar a implementar isso. Aguardo respostas. Atenciosamente. Jéter Rabelo Ferreira

Bom dia Juliana. Existem alguns clientes meus que utilizam um nosso número, em algumas vezes, maiores que o tipo Integer, precisando ser um Int64. Eu notei esse mesmo problema numa outra Unit ontem a tarde, Banco do Brasil. Uma dica, pra não termos mais esse tipo de problema, eu acho que essa alteração, do StrToInt para StrToInt64 nas conversões de "nossos números", deveria ser feita em todas as units, pois resolveria os problemas quanto a conversão dos valores. Pra você ter uma ideia, o Banco do Brasil, na sua carteia 18, pode-se informar 17 dígitos no nosso número. Como pode-se notar, isso é uma quantidade de dígitos bem acima que o tipo Integer suporta. (máx 2.147.483.647). Em tempo, respondendo a sua pergunta: Um "Nosso Número" do meu cliente -> 81234567890 (81.234.567.890: bem superior ao tipo Integer). Obrigado pela atenção. Jéter Rabelo Ferreira

Boa tarde. Ocorreram problemas comigo ao gerar boletos da Caixa Federal. O erro ocorre ao tentar efetuar a conversão utilizando a função StrToInt(). Correção: Subsituir a mesma por StrToInt64. Segue a unit corrigida anexa. Atenciosamente. Jéter Rabelo Ferreira ACBrCaixaEconomica.pas

Bom dia Segue anexo a Unit. Atenciosamente. Jéter Rabelo Ferreira ACBrBancoBrasil.pas

Boa tarde. Tenho um cliente que acabei de implantar um sistema, e o mesmo utiliza carteira do Banco do Brasil, de convênio de 6 dígitos carteira número 18. Essa carteira o nosso número é composto de 17 dígitos e tem o número 21 fixo como parte final do nosso número. Essa carteira é sem registro. Atualmente, a classe do Banco do Brasil somente trata nossos números até no máximo com 11 dígitos. Devido a isso, tive que fazer duas alterações em duas funções. Segue abaixo as correções que efetuei, caso acharem necessário implementar essas alterações na classe do Banco, ou se alguém precisar: function TACBrBancoBrasil.FormataNossoNumero(const ACBrTitulo :TACBrTitulo): String; var ANossoNumero, AConvenio : string; aCarteira: LongInt; begin with ACBrTitulo do begin AConvenio := ACBrBoleto.Cedente.Convenio; ANossoNumero := trim(inttostr(strtoint(NossoNumero))); aCarteira := StrToIntDef(Carteira,0); if (aCarteira = 16) or (aCarteira = 17) or (aCarteira = 18) then begin if (ACBrTitulo.Carteira = '18') and (Length(AConvenio) = 6) then ANossoNumero := padR(ANossoNumero, 17, '0') else if Length(AConvenio) <= 4 then ANossoNumero := padR(AConvenio, 4, '0') + padR(ANossoNumero, 7, '0') else if (Length(AConvenio) > 4) and (Length(AConvenio) <= 6) then ANossoNumero := padR(AConvenio, 6, '0') + padR(ANossoNumero, 5, '0') else if Length(AConvenio) = 7 then ANossoNumero := padR(AConvenio, 7, '0') + padR(ANossoNumero, 10, '0'); end else ANossoNumero := padR(AConvenio, 7, '0')+ padR(ANossoNumero, 11, '0'); end; Result := ANossoNumero; end; function TACBrBancoBrasil.MontarCodigoBarras(const ACBrTitulo : TACBrTitulo): String; var CodigoBarras, FatorVencimento, DigitoCodBarras :String; ANossoNumero, AConvenio: string; begin AConvenio := ACBrTitulo.ACBrBoleto.Cedente.Convenio; ANossoNumero := FormataNossoNumero(ACBrTitulo); {Codigo de Barras} with ACBrTitulo.ACBrBoleto do begin FatorVencimento := CalcularFatorVencimento(ACBrTitulo.Vencimento); if (ACBrTitulo.Carteira = '18') and (Length(AConvenio) = 6) then begin CodigoBarras := IntToStrZero(Banco.Numero, 3) + '9' + FatorVencimento + IntToStrZero(Round(ACBrTitulo.ValorDocumento * 100), 10) + AConvenio + ANossoNumero + '21'; end else begin CodigoBarras := IntToStrZero(Banco.Numero, 3) + '9' + FatorVencimento + IntToStrZero(Round(ACBrTitulo.ValorDocumento * 100), 10) + IfThen((Length(AConvenio) = 7), '000000', '') + ANossoNumero + IfThen((Length(AConvenio) < 7), padR(Cedente.Agencia, 4, '0'), '') + IfThen((Length(AConvenio) < 7), padR(Cedente.Conta, 8, '0'), '') + copy(ACBrTitulo.Carteira, 1, 2); end; DigitoCodBarras := CalcularDigitoCodigoBarras(CodigoBarras); end; Result:= copy( CodigoBarras, 1, 4) + DigitoCodBarras + copy( CodigoBarras, 5, 44) ; end; Obs: Esse cliente meu emite mais de 4.500 boletos/mês. E dessa forma, tudo correu normal. Atenciosamente. Jéter Rabelo Ferreira

Olá Retire essa unit do requires do arquivo ACBr_BoletoFC_Fortes.dpk e recompile e instale novamente. Se não der certo, poste novamente. Atenciosamente. Jéter Rabelo Ferreira