homologação Boleto - Caixa

[sidnei_alves1]

Boa parte pessoal,

Fui tentar homologar meu sistema com o AcbrBoleto na Caixa federal ,mandei os 20 boletos conforme eles pediram.

pediram pra fazer algumas correções conforme segue abaixo:

1 - Inserir os campos (-) Outras Deduções e (+) Outros Acréscimos.

2 - falaram o campo nosso numero esta errado ex: 90000000240-2

Gostaria de saber se o componente já tem essas opções, ou se eu precisa efetuar as alterações aqui no meu fonte.

[Juliana Tamizou]

Bom dia.

1-Você testou a remessa ou a impressão dos boletos? Onde foram solicitados estes ajustes?

2-Qual o convênio você está testando? SICOB ou SIBCB?

Esta semana foram feitas atualizações na unit da caixa, com algumas correções.

Att.

[giulianon]

Também estou homologando e me pediram o mesmo (Outras deduções / Outros acréscimos).

Esses campos tem que aparecer na impressão do boleto (Convênio SICOB).

Notei que os campos existem na classe mas não saem na impressão, pois realmente não estão no form.

Vou tentar corrigir aqui a impressão e ai posto pro pessoal analisar.

Abraço!

[Jéter Rabelo Ferreira]

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

[Juliana Tamizou]

Bom dia.

O manual que pede '24' se for cobrança registrada e '14' se for sem registro é o SIGCB.

No link abaixo você pode baixar os manuais dos bancos para os quais o ACBrBoleto já está trabalhando.

https://acbr.svn.sourceforge.net/svnroo ... ols/Bancos

Att.

[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

[Juliana Tamizou]

Bom dia Jeter.

Já adicionei, os manuais que faltam ao svn, o endereço está no post anterior ao seu.

Att.

[giulianon]

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

Psé eu também tinha gerado os boletos e o tanto o nosso número quanto o dígito verificador estavam conforme o solicitado pela caixa.

O que faltava eram só os campos (+) Outros Acréscimos e (-) Outras Deduções na impressão do boleto. Eu inclui esses campos e em seguida atualizei o componente e ai o nosso número voltou a começar com 24 e o dígito verificador do cendente está incorreto.

Mandei pra homologar e não passou de novo.

Segue o que o pessoal da caixa me retornou

LOCAL DE PAGAMENTO

- No campo “Local do Pagamento” deve constar: “Pagamento em qualquer agência bancária

ou lotéricas até o vencimento, após somente na CAIXA”.

AGÊNCIA/CÓDIGO DO CEDENTE

- O código do cedente está incorreto. O código correto é: 1662.870.00000288-1.

NOSSO NÚMERO

* SICOB

- Para carteira SR, o nosso número deve possuir 11 posições (incluindo o DV) e começar

com os algarismos 80, 81 ou 82, ou ainda possuir 16 posições (incluindo o DV) e começar com o algarismo 8.

CÁLCULOS DO DOCUMENTO

- Os campos que ficam abaixo do campo "valor do documento" devem ficar assim:

( - ) Desconto/abatimento

( - ) Outras deduções

( + ) Mora/multa

( + ) Outros acréscimos

( = ) Valor cobrado

Vou voltar a versão da Unit da caixa que fazia o cálculo correto e incluir o form com os campos solicitados e ver se passa.

Att.

[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

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

[Jéter Rabelo Ferreira]

Aviso.

Já comecei a reescrever a unit.

Atenciosamente.

Jéter Rabelo Ferreira

[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

[Juliana Tamizou]

Bom dia Jeter.

Pelo tamanho do número do cedente não era possivel definir qual layout está sendo utilizado?

Att.

[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

[Juliana Tamizou]

Bom dia.

Ainda sobre o tamanho do Código do Cedente, vc sabe me dizer se existe a possibilidade de comecar com 0?...pq senão podemos entender que os 0(zeros) a esquerda que retornarem no arquivo podem ser ignorados, dessa forma saberíamos o tamanho do Código do Cedente, mesmo no arquivo retorno.

Acho que se não for possivel dessa maneira, só resta criar a propriedade mesmo.

Att.

[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

[Juliana Tamizou]

Boa tarde.

Então o tamanho do código do cedente também não pode ser usado para definir o tipo de cobrança, já que você disse que é sequencial.

Se não houvesse nenhum cliente com as excessões que você mencionou, poderiamos utilizar os 3 primeiros digitos como padrão.

Outro detalhe que percebi é que mesmo para impressão e geração da remessa, o tamanho do código do cedente não é algo que possa ser utilizado para definir como essas operações devem ser feitas.

Estou começando a pensar que nossa unica opção passa a ser, criar uma propriedade para o tipo do convenio a ser seguido.

Att.

[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

[Juliana Tamizou]

Bom dia Jeter.

Estive pensando em criar uma propriedade TIPOCONVENIO, como tipo enumerado, então poderiam existir inicialmente 3 tipos oCobGeral(para não atrapalhar os demais bancos que não necessitam dela), oCobSICOBCaixa e o oCobSIGCBCaixa.

Acho que isso já resolveria nosso problema.

Att.

[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 Tamizou]

Acho que assim fica melhor mesmo.

Att.

[giulianon]

Bom dia Juliana e Jéter!

Meus boletos foram homologados, mas pra isso tive que usar uma versão mais antiga da classe que atendia ao siscob, e também alterar o form do boleto pra incluir os campos Outros Acréscimos e Outras Deduções.

A parte da classe já vi que resolveram, então gostaria de saber se no form já foram incluidos os campos que citei.

Se não foram ainda, posso enviar o que eu e fiz para que seja atualizado no svn.

Att.

[Juliana Tamizou]

Boa tarde Giuliano.

Ainda não recebi nenhuma contribuição referente a estas alteração do Outros Acrescimos e Outras Deduções... se quiser pode postar aqui.

Att.

[Jéter Rabelo Ferreira]

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

[giulianon]

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

Estou utilizando o Fortes sim.

Mas quando me solicitaram esses campos a mais eu atualizei conforme a Juliana recomendou e esses campos não existiam e a parte do calculo do digito que tava certa ficou errada.

Ai voltei a versão pro calculo do digito ficar certo, alterei o form e enviei pra homologar.

Ai passou.

De qualquer forma vou dar update agora e comparar com o meu.

Se os campos não existirem eu dou um post do form aqui.

Abraço!