Jéter Rabelo Ferreira

Bom dia; Fiz uma pequena alteração nma unit do BANCOOB, pois na geração do boleto, não estava setada a propriedade fpTamanhoCarteira := 1 no create da classe. Com isso, ele deixava o campo carteira como '' e não gerava o boleto; Atenciosamente. Jéter Rabelo Ferreira ACBrBancoob.pas

Boa tarde Giuliano. De uma verificada antes de enviar as alterações do boleto que você homologou. Pois no formato carnê estava com problemas na impressão, pois foram acrescentados componentes e o arquivo dfm não havia sido enviado ao SVN, como a Juliana mencionou. Senão podem ocorrer novos problemas. Isso se você efetuou as alterações utilizando o Fortes como gerador de relatórios. Atenciosamente. Jéter Rabelo Ferreira

Bom dia Juliana. Fica bom assim. O que você acha de colocar o nome (resumido) do banco antes para melhor visualização? Tipo: oCobCaixaSICOB oCobCaixaSIGCB Num futuro próximom quando necessário: oCobBrasilXXX e etc. Atenciosamente. Jéter Rabelo Ferreira

Juliana, boa tarde. Realmente eu acho essa a única opção. Há não ser que alguém sinta-se "iluminado" de nos dar uma outra saída. Quanto as propriedade, eu acho que deveria ser pensada para ser utilizado em várias situações. CEF -> Tipo de cobrança, e etc Banco do Brasil -> Tamanho do Convênio e etc Etc. Com esse recurso em nossas mãoes, não teríamos limite para configurarmos nossos sistemas. O bom seria que se o componente pudesse tratar tudo de forma transparente, como é o caso de alguns bancos, mas isso não é possível, infelizmente. Qualquer coisa, estou a disposição. Atenciosamente. Jéter Rabelo Ferreira

Boa tarde. Em contato com o pessoal da CEF, eles me informaram o seguinte: No SIGCB não existe um padrão a numeração do código do Cedente, ele é sequencial. Atualmente está Maior que 270000. No caso do SICOB, sempre começa com 870. Salvo em caso de clientes muito antigos que o código do cedente era utilizado o número da conta, nesses casos, começa com 003. Segundo minha fonte, a cada 100 clientes, 1 vai ser dessa forma. Hoje não utiliza mais dessa forma. Bom, e aí, como ficamos? . Atenciosamente. Jéter Rabelo Ferreira

Boa tarde. Eu efetuei uma atualização do componente e, um cliente meu reclamou que não estava conseguindo imprimir o boleto na forma de carnê. O padrão estava normal. Fui verificar e, verifiquei que foram feitas várias modificações, excluindo várias propriedades que, na hora da montagem do boleto, era gerada uma violação de acesso. Ao abrir a unit e salvar, vários erros aparecem de componentes não utilizados ou inexistentes. Confirmei a remoção de todos eles e comentei as linhas cujo os quais eram relacionados. Recompilei meu projeto e funcionou corretamente. Deixo a dica para o pessoal que efetua o commit verificar esses erros para que, no próximo commit, possa isso estar corrigido. Minha versão do Fortes é a última disponivel do SVN. Atenciosamente. Jéter Rabelo Ferreira

Boa tarde. Eu efetuei uma atualização do componente e, um cliente meu reclamou que não estava conseguindo imprimir o boleto na forma de carnê. O padrão estava normal. Fui verificar e, verifiquei que foram feitas várias modificações, excluindo várias propriedades que, na hora da montagem do boleto, gerada uma violação de acesso. Ao abrir a unit e salvar, vários erros aparecem de componentes não utilizados ou inexistentes. Confirmei a remoção de todos eles e comentei as linhas cujo os quais eram relacionados. Recompilei meu projeto e funcionou corretamente. Deixo a dica para o pessoal que efetua o commit verificar esses erros para que, no próximo commit, possa isso estar corrigido. Minha versão do Fortes é a última disponivel do SVN. Atenciosamente. Jéter Rabelo Ferreira

Bom dia Juliana. Pelo tamanho do Código do cedente dá para fazer duas coisas: - Impressão do Boleto - Gerar arquivo remessa Pois, nesses dois casos, o sistema possui a referida informação. Quanto a Ler o Retorno não tem como, pois o sistema não possui essa informação. E a estrutura do retorno é diferente das duas modalidades de cobrança. Se compartilhassem as estruturas, sem problema. Por isso, eu fiz uma unit separada. Se alguém tiver alguma idéia de como fazer para implementar isso, de um post. Na minha opinião, teríamos que ter uma property para controlar isso, podendo ser um campo enumerado, meio genérico, que poderia ser utilizado pelos demais bancos que possuirem alguma configuração específica. Aguardo posição para "unir" as duas unit`s. Atenciosamente. Jéter Rabelo Ferreira

Boa tarde. Bom pessoal, terminei de (re)escrever a unit da CEF. Temos um "pequeno/grande" problema. Não tem como, a princípio, a mesma Unit possuir condições de identificar qual sistema de cobrança o usuário está utilizando - (SIGCB/SICOB). Se fosse para utilizar apenas impressão de boleto, ok. Mas para ler o retorno e gerar remessa não tem como, a não ser que seja criada uma property para identificar o tipo de cobrança. Mas, para isso, eu não tenho poder de decisão. Segue anexa a unit da CAIXA totalmente reescrita. OBS: - Essa unit serve somente para o sistema de cobrança da CEF - SICOB. - Está gerando o arquivo remessa conforme manual, porém não efetuei homologação junto a CEF - A leitura do arquivo de retorno está OK. Por enquanto é só. Atenciosamente. Jéter Rabelo Ferreira ACBrCaixaEconomica - SICOB.pas

Aviso. Já comecei a reescrever a unit. Atenciosamente. Jéter Rabelo Ferreira

Boa tarde. Bom, como disse em meu Post anterior, entrei em contato com o pessoal da CEF a respeito do SIGCB/SICOB, e eis as perguntas que eu fiz e as devidas respostas: A CEF disponibiliza as duas formas de cobrança para o cliente. Diferenças: SIGCB: - Carteira disponibilizada pela CEF para emissão de boletos por meio do programa do cliente - Somente nessa carteira os boletos são homogados pela CEF SICOB: - Boletos podem ser descontados (Desconto de duplicatas) - Envio de arquivo remessa Como é feita a escolha de qual tipo carteira a utilizar? - Bom, aí vai depender do gerente e do cliente. Qual das duas é melhor? - A SICOB, por ter mais versatilidade. Tais como: - Arquivo Remessa - Desconto de Duplicatas - Possibilidade de envio de boletos para cartório (com registro) - Pode ser utilizadas a emissão de Nosso Números de duas formas: - 11 Dígitos - Começando com 9 - 16 Dígitos - Começando com 8 (isso não é uma regra, porém não faz diferença na prática ) - Obs: Eu utilizo com 11 dígitos começando com 8 faz tempo e nunca tive problemas; Como eu consigo diferenciar uma da outra? - Pelo número do cedente: - SIGCB: 6 Dígitos (sem o DV) - SICOB: 11 Dígitos (sem o DV) O cliente pode mudar a qualquer momento o tipo de cobrança? - Sim O cliente pode ter os dois tipos de cobrança? - Sim Bom pessoal é isso. Acho que já dá para "matar" o problema CEF. Se apenas utilizar-mos o tamanho código cedente para verificar o tipo de cobrança o cliente utiliza, podemos adaptar a unit da CEF para tratar os dois problemas: NumCed <= 6 (ou 7 com DV) SIGCB senão -> SICOB, Posso tratar dessas alterações a partir da semana que vem. Caso alguém estiver disponível antes, fiquem a vontade. Mas eu gostaria que, se alguém for fazer as alterações, deixe um post aqui antes, para que ninguém faça trabalho duplicado . Atenciosamente. Jéter Rabelo Ferreira.

Olá Você voltando a versão, como eu fiz, vai ficar correto e vai conseguir efetuar a homologação. Atenciosamente. Jéter Rabelo Ferreira

Bom dia Juliana. Realmente o problema está aí. SIGCB X SICOB. Em todos os clientes em que eu trabalhei com cobrança CEF utiliza-se SICOB. Seguem anexos os manuais SICOB. No componente RLBoleto, a CEF possuia duas unit`s para tratar desse problema. O SIBCB era uma unit separada (RLCob104_SIGCB.pas). Como eu nunca precisei trabalhar com esssa modalidade de cobrança, nunca me preocupei em saber se no referido componente tinha uma forma de trabalhar com as duas unit's simultaneamentes. Como eu possuo conta na CEF, vou tentar entrar em contato com o suporte deles para tentar esclarecer melhor esse assunto para que possamos criar uma única unit, contendo as duas formas de emissão. Tem tempo, como disse acima, estou anexando os manuais SICOB. Baixei do próprio site da CAIXA. Atenciosamente. Jéter Rabelo Ferreira CNAB_240_SICOB.pdf CNAB__400__SICOB.PDF ESPCODBARBLOQCOBRANREGIST_16POSICOES.pdf ESPCODBARR_SICOB.pdf

Boa tarde. Pegando o "gancho" a respeito do boleto da CEF. Vou falar apenas da impressão dos boletos SICOB, utilizando cobrança Rápida ou Sem Registro (SICOB). Conforme a Juliana disse, houveram alterações na unit há alguns dias. Há tempos atrás, eu postei uma dúvida aqui no fórum relatando um problema na impressão de boletos CEF, quanto a geração do nosso número, visto que o sistema incluia números no inicio do Nosso Número (24). Isso foi corrigido semanas atrás. Porém, com a última atualização, isso voltou a ocorrer. De posse do programa CobCaixa, da própria CEF, efetuei uns testes e, o que pude perceber foi o seguinte: - Cobrança Rápida: Nosso Número = 11 Posições, começando com 9000000000 - Cobrança sem registro: Nosso Número = 16 Posícões, começando com 800000000000000 Ao tentar alterar esses valores, o CobCaixa não permite que altere os números iniciais, sendo 90 e 8. Pois bem, da forma em que está atualmente a Unit da CEF, ela está colocando 24 antes do nosso número, portanto isso foge do parâmetro que o CobCaixa exige, portanto, de nossos programas. Perguntas: - Em qual manual de cobrança da CEF consta que o nosso número deverá começar com 24? - Isso é regra do SICOB ou SIBCB? Atenciosamente. Jéter Rabelo Ferreira

Olá. Faltou mencionar o último ítem do manual: 11. Não sou o fabricante do produto, preciso preencher os campos cEAN e cEANTrib? Sim. Se o produto comercializado na NF- possuir código de barras com GTIN ele deve ser destacado no documento, seja o documento gerado pelo fabricante, distribuidor, revenda, varejo, etc. Atenciosamente Jéter Rabelo Ferreira

Boa tarde. Na alteração que eu fiz na unit ACBrBancoItau e enviei no primeiro post tem um problema. Como eu fiz os testes gerando apenas um boleto na remessa, se houver mais de um boleto a sequencia do arquivo vai ficar errada. Segue anexo a unit corrigida. A remessa está homologada e meu cliente já começou a emissão dos boletos na carteira 173. Eu recebi o email do Banco Itaú o boleto scaneado referente ao arquivo remessa enviado para testes e, que, no caso do meu cliente, vai personalizado com a logo da empresa dele no boleto. Atenciosamente. Jéter Rabelo Ferreira ACBrBancoItau.pas

Juliana, bom dia. Segue anexo. O manual é um só, tanto o da cobran;ca com registro como a sem registro. A parte da remessa sem registro começa na página 41. Atenciosamente. Jéter Rabelo Ferreira COBRANCA 400 BYTES CNAB-VERSAO7 0-JULHO-2010-NEW.pdf

Olá. A resposta é sim. Solicite o arquivo junto ao banco. Atenciosamente. Jéter Rabelo Ferreira

Bom dia. Estou tendo uns problemas com o Banco Itaú há algum tempo, resolvido ontem, a respeito de arquivo remessa de cobrança sem registro. Um breve histórico: Um cliente meu, fechou um contrato com o Banco Itaú para emitir boletos, cobrança simples e sem registro, para que o banco efetuasse a entrega dos mesmos. Porém, após quase dois meses de problemas, que o banco dizia que o arquivo remessa estava correto, e o problema era outro e etc e etc, Quinta-feira passada, dia 26/05, recebi um e-mail do setor de cobrança do Itaú que o arquivo remessa estava inválido, pois para cobrança simples sem registro é um outro LayOut. De posse desse LayOut, efetuei as alterações necessárias, para isso, também tive que efetuar uma alteração na Unit ACBrBoleto (anexo). Informo que já está homologado pelo Banco itaú, conforme e-mail recebido ontem, 31/05. Por isso, estou disponibilizando as duas unit`s (ACBrBancoItau, e ACBrBoleto) para que possam sem enviadas ao repositório. As modificações efetuadas por mim estão comentadas nos fontes. Atenciosamente. Jéter Rabelo Ferreira ACBrBoleto.pas ACBrBancoItau.pas

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