Jéter Rabelo Ferreira

Bom dia. Sem generalizar, é claro, eu não chamo os profissionais da área de "contador", e sim de "guarda-livros". Em minhas experiências em questionar alguma coisa para esses profissionais, na maioria das vezes, eles não sabem, não querem saber e tem raiva de quem sabe. Voltando ao assunto do POST, eu fiz da seguinte forma: A NF-e já havia sido cancelada no mesmo momento em que o problema foi diagnosticado. No motivo do cancelamento foi informado o erro de numeração incorreta. A empresa continuou a emitir NF-e utilizando a numeração sequencial normal. Em tempo, nem a SEF/MG soube informar o procedimento a ser tomado. Atenciosamente. Jéter Rabelo Ferreira/.

Bom dia. Tive um problema com um cliente meu quanto a Numeração de Notas Fiscais. Ao gravar uma NF-e, o sistema gerou um número de NF bastante diferente, "pulando" vários números de notas. Alguém sabe me dizer o que pode ser feito? - Inutiliza-se a numeração do intervalo entre o último número gerado em seqüência e e continua a numeração. - Ou pode-se continuar a numeração anterior, uma vez que o intervalo de numeração é de mais de 1 milhão de números e o meu cliente, provavelmente, nunca vai atingir o número gerado. Ex: Última NF sequencial : 200 Numero gerado: 1.500.000 Agradeço a atenção. Atenciosamente. Jéter Rabelo Ferreira

Bom dia Juliana. Bom, a resposta é simplesmente não. Nós já trocamos alguns posts há alguns meses atrás (Abril), a respeito do Banco do Brasil, que também tivemos alguns problemas. Na época eu dei uma alternativa para que, em casos como esse, pudéssmos criar alternativas para resolver o problema. A dica que eu dei pode ser lida http://www.djsystem.com.br/acbr/forum/viewtopic.php?p=7174#p7174. Eu ainda acho que essa é uma opção a ser considerada, pois como temos ainda uma quantidade pequena de bancos implementada, eu tenho certeza de que vamos encontrar muitos problemas desse tipo na frente. Caso contrário, no caso da CEF, poderíamos utilizar a property como dito acima para controlar isso, embora que eu acho que um enumerator de configuração fica mais profissional. Qualquer coisa, estou a disposição. Atenciosamente. Jéter Rabelo Ferreira

Juliana, bom dia. O problema que reside é o seguinte: A carteira SICOB trabalha com dois tipo de NN (11 ou 16 Posições). Eu sempre trabahei com meus clientes com 11 posições. Mas, como relatado pelo Grégori, podem ocorrer casos da necessidade de se ter 16 posições. Aí temos um outro problema, a formação do campo livre é diferente nas duas situações. Uma solução seriia deixar a a property TamanhoMaximoNossoNum como read/write, e não como somente read, como é atualmente. Por meio dela, poderíamos fazer as verificações necessárias e gerar o Campo Livre adequadamente. Aguardo retorno. Atenciosamente. Jéter Rabelo Ferreira.

Bom dia. Na realidade, o cliente pode utilizar qualquer uma das duas formas que dá certo. Devido a isso, eu não me lembro de ter testado o NN de 16 posições Hoje e amanhã eu não posso efetuar testes. Caso você não consiga resolver até Sexta, eu posso verificar para você na Sexta. Atenciosamente. Jéter Rabelo Ferreira

Juliana, boa tarde. Favor efetuar uma pequena correção na impressão do Boleto Padrão no fortes. Nas três imagens dos bancos no boleto padrão, colocar Scaled := True; No boleto em formato Carnê está correto. Se alguém for imprimir o boleto com a Logo da empresa e a imagem for maior que o componente RLImage (o que vai ocorrer em 99,9$ dos casos), não sai impresso nada. Atenciosamente. 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