Ir para conteúdo
  • Cadastre-se

dev botao

Nosso Número Carteira Rápida CEF


  • Este tópico foi criado há 2836 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

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

Link para o comentário
Compartilhar em outros sites

  • Administradores

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.

Consultora SAC ACBr

Juliana Tamizou

Gerente de Projetos ACBr / Diretora de Marketing AFRAC
Ajude o Projeto ACBr crescer - Seja Pro

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.  Discord

Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil


Participe de nosso canal no Discord e fique ainda mais próximo da Comunidade !!

Link para o comentário
Compartilhar em outros sites

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!

 

open?id=0B4xXFOI2rQ2mUi1zRGl6OVpObkE

Link para o comentário
Compartilhar em outros sites

  • Administradores

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.

Consultora SAC ACBr

Juliana Tamizou

Gerente de Projetos ACBr / Diretora de Marketing AFRAC
Ajude o Projeto ACBr crescer - Seja Pro

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.  Discord

Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil


Participe de nosso canal no Discord e fique ainda mais próximo da Comunidade !!

Link para o comentário
Compartilhar em outros sites

  • Administradores

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.

Consultora SAC ACBr

Juliana Tamizou

Gerente de Projetos ACBr / Diretora de Marketing AFRAC
Ajude o Projeto ACBr crescer - Seja Pro

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.  Discord

Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil


Participe de nosso canal no Discord e fique ainda mais próximo da Comunidade !!

Link para o comentário
Compartilhar em outros sites

  • Administradores

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.

Consultora SAC ACBr

Juliana Tamizou

Gerente de Projetos ACBr / Diretora de Marketing AFRAC
Ajude o Projeto ACBr crescer - Seja Pro

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.  Discord

Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil


Participe de nosso canal no Discord e fique ainda mais próximo da Comunidade !!

Link para o comentário
Compartilhar em outros sites

  • 3 semanas depois ...
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 870SICOB 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 por Thiago Linhares
Link para o comentário
Compartilhar em outros sites

  • Este tópico foi criado há 2836 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!

Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.

Entrar Agora
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.