Nosso Número Carteira Rápida CEF

[Jorge Luis Menezes Carrijo]

Estou desenvolvendo para um cliente o boleto da CEF Carteira Rápida e não estou conseguindo passar o valor da propriedade TamMaximoNossoNumero; O ACBR está atribuindo sempre o valor 15 para essa propriedade

Já atribuí em diversas partes do meu código 

Boleto.Banco.TamanhoMaximoNossoNum := Boleto.Banco.CalcularTamMaximoNossoNumero('CR');

Como não funcionou cheguei ao ponto de cravar o valor

Boleto.Banco.TamanhoMaximoNossoNum := 10;

 

Mesmo asssim não funcionou o nosso número

[Juliana Tamizou]

Bom dia.

O tamanho da propriedade NossoNumero é calculado pelo próprio componente com base em algumas informações especificas, qual tipo de cobrança você está utiiizando SICOB ou SUGCB?

Att.

[Jorge Luis Menezes Carrijo]

Olá Juliana, bom dia!

SICOB a carteira do cliente é o CR

[Jorge Luis Menezes Carrijo]

Juliana,

Acredito que o problema pode estar na função. 

function TACBrCaixaEconomicaSICOB.CalcularTamMaximoNossoNumero(
  const Carteira: String; NossoNumero: String): Integer;
var
  wTamNossoNumero: Integer;
begin
   Result:= 15;

   wTamNossoNumero:= length(NossoNumero);

   if ((wTamNossoNumero >= 8)  and (wTamNossoNumero <= 10)) or
      ((wTamNossoNumero >= 14) and (wTamNossoNumero <= 15)) then
      Result := wTamNossoNumero;
end;
 

 

Sempre está retornando 15!

 

[Juliana Tamizou]

Boa tarde.

A função espera que você envie o nosso número do tamanho desejado, desde que dentro dos parâmetros destas condições.

Att.

[Jorge Luis Menezes Carrijo]

Juliana,

Dessa forma, preciso tratar fora do ACBR o tamanho e o formato do nosso número? Não existe nenhuma função interna que faz isso, RetornaTamMaximoNossoNumero(Banco, Carteira) : Integer

if banco = 104 and carteira = 'CR' Then
   wNossoNumero = 11

 

 

[Juliana Tamizou]

Boa tarde.

Infelizmente alguns bancos não possuem uma regra clara de qual tamanho de nosso número deve ser utilizado, a caixa infelizmente tem essa situação.]

Para que seja possível tentar te ajudar forneça mais detalhes de qual é a situação do seu cliente (carteira, convênio, tamanho Nosso Número esperado pelo banco..etc)

Att.

[Jorge Luis Menezes Carrijo]

Boa tarde!

Carteira : CR

Convênio: Cliente ainda não passou, já pedi para ele solicitar ao banco, se for o SICOB ou  SIGCB é SICOB

Tamanho Esperado pelo Banco : 10 Digitos + Verificar / iniciado por 9. Exemplo: 9000005411-4

[Jorge Luis Menezes Carrijo]

Juliana,

Convênio: 870000003125

[Juliana Tamizou]

Boa tarde.

Alteração para considerar também o código de operação (parte do número do convênio) foi adicionada para definição do tamanho do nosso número.

Att.

[Thiago Linhares]

Em 31/05/2016 at 15:59, Juliana Tamizou disse:

Boa tarde.

Alteração para considerar também o código de operação (parte do número do convênio) foi adicionada para definição do tamanho do nosso número.

Att.

Boa tarde Juliana,

a função TACBrCaixaEconomicaSICOB.CalcularTamMaximoNossoNumero ainda está incorreta, pelo menos de acordo com a lógica que parece que foi pensada no código fonte dela. Na lógica, ao invés de setar o Result, está sendo setado uma variável local wTamNossoNumero, que não é usada para nada. Creio que não precisa enviar a unit, pois está bem evidente ali na função.
O impacto disto seria talvez sobre as lógicas de leitura do retorno de remessa... que é onde o CalcularTamMaximoNossoNumero é usado, além do SetNossoNumero. Mas como não estou usando retorno de remessa agora, não testei o retorno para ver o que daria errado... acredito que daria, já que está inconsistente... mas vai saber se o retorno tem formatações diferentes. Mas de qq forma, o código da função atual CalcularTamMaximoNossoNumero não faz sentido.

 

Agora, Outro ponto, que ai realmente me afeta, é sobre forçar que sempre seja usado o padrão de 16 posições no nosso número quando a carteira for SR (sem registro) e operação do convênio for 870 (é SICOB tb). Eu tenho um caso desse que estou implementando agora para homologação, e o banco enviou documentação para uso de 11 dígitos do nosso número, não 16! Sei que tem um outro manual (que o banco não enviou, mas este enviado é mais novo acredito) que se refere a operação 870 para carteira SR usando nosso nr de 16 posições... mas o fato do banco ter solicitado no meu caso o de 11 posições, cria a dúvida de que esta regra não é uma regra, e sim uma opção talvez. Alguém sabe se clientes do banco que tenham SR e 870 talvez possam escolher usar um ou outro layout? Será que mesmo se o banco pedindo 11 posições, enviar o de 16, eles aceitam? Alguém teve um caso similar ou tem alguma info sobre isto?

 

Por fim, sobre a abordagem de obrigar a setar o nosso número fora do componente, sou contra, pois vai contra as boas práticas de encapsulamento e coesão. Hoje para não desencapsular uma pá de regras de bancos, eu seto o NossoNumero com o mesmo valor do NumeroDocumento, cuidando para que ele não estoure o tamanho máximo... e o ACBr faz o resto.. não preciso colocar regras de formatação de nosso número pela aplicação. Mas devido a forma como o ACBr está implementado... essa abordagem ainda fica estranha, pois não foi feito com esta estratégia em mente. Entendo que a melhor abordagem é a de encapsulamento... onde propriedades como NumeroDocumento, que hoje fazendo um search são usadas somente para geração de remessas, seriam usadas internamente para montar o Nosso Número "final". Preocupações para construção do NossoNumero deveriam ficar todas encapsuladas dentro das classes. E surgindo casos como o do 870 com SR acima, são tratáveis de uma forma ou de outra, sem precisar desencapsular. Por exemplo.. o antigo GBBoleto usava uma diferenciação na carteira para decidir se gerava com 11 dígitos ou 16 dígitos, bastando passar a carteira pra ele como "SR" ou "SR16" respectivamente (não que esse devesse ser uma solução para o ACBr, mas é uma ideia interessante se for preciso). Inclusive esta abordagem do GBBoleto me chamou a atenção para o meu caso onde usar a especificação de 11 ou 16 dígitos talvez seja uma escolha do cliente ou do próprio banco, sendo impossível "calcular" (é só uma suposição... infos please! )... o GBBoleto suportava esta escolha.

 

Enviando o manual atualizado que o banco mandou, para referência se necessário.

Abraços!

Leiaute_Boleto_Caixa.dot

Editado 22 Junho, 2016 por Thiago Linhares

[Thiago Linhares]

Em tempo, a chama de CalcularTamMaximoNossoNumero no TACBrCaixaEconomicaSICOB.FormataNossoNumero não faz nada... ficou estranho, teria que ser retirada.