Jump to content

Ofertas Embarcadero
Aproveite até o dia 30

Saiba Mais

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


botao.png

beneficios.png
  • Este tópico foi criado há 1590 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 to post
Share on other sites

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
Ajude o Projeto ACBr crescer - Assine o SAC

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

Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil
Link to post
Share on other 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 to post
Share on other sites

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
Ajude o Projeto ACBr crescer - Assine o SAC

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

Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil
Link to post
Share on other sites

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
Ajude o Projeto ACBr crescer - Assine o SAC

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

Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil
Link to post
Share on other sites

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
Ajude o Projeto ACBr crescer - Assine o SAC

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

Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil
Link to post
Share on other sites
  • 3 weeks later...
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

Edited by Thiago Linhares
Link to post
Share on other sites
  • Este tópico foi criado há 1590 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...