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á 1729 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui

Recommended Posts

O módulo do banco do nordeste (.pas) na parte em que gera o arquivo de remessa (cnab400), na coluna 108 (carteira), está usando a mesma carteira utilizada no boleto (ex: carteira 21) que usa duas posições e na verdade não é. No manual do bnb diz que é para usar a carteira (tipo de operação) conforme nota Nª 1 que usa uma única posição, trata-se de uma tabela que vai de 1 a K que faz um relacionamento entre as carteiras e esse código.

Inclusive, usando a carteira normal de suas posições (ex: 21) a linha de transação fica com 401 posições.

Link to post
Share on other sites

Boa noite.

Caso tenha feito a alteração e desejar contribuir com o projeto, anexe aqui a unit alterada e o manual do banco.

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
  • 2 weeks later...

Oi Juliana, eu refiz o módulo do banco do nordeste (.pas) por completo. Pelo que eu entendi, o módulo do projeto estava completamente baseado em outro banco e o banco do nordeste é muito diferente. então refiz muito coisa, haviam muitas posições erradas e muitos tratamentos errados, como o tratamento de erro do retorno. Segue um pequeno resumo do que alterei e os arquivos em anexo para sua avaliação.

- Alterado CalcularDigitoVerificador - removido a parte onde manda transformar digitofinal 1 p/ 0
- corrigidos os códigos de tipos de inscrição. Onde tinha 11 pessoa física e 14 jurídica, acrescentado 01 física e 02 jurídica
- criadas funções carteiratotipooperacao e tipooperacaotocarteira
- alterada a posição 394 (código da moeda) do registro de transação da remessa que estava '1' p/ '0', que é o código correto p/ R$
- alterado o leretorno posições de agencia (linha/posição 1,26 p/ 0,27), conta (1,31 p/ 0,33) e digito da conta (1,37 p/ 0,40), que são as posições corretas
- alterado o leretorno posições do nosso número, posição 71 p/ posição 63
- alterado leretorno (carteira) p/ TipoOperacaoToCarteira(copy(linha,108,1))
- removido ValorOutrosCreditos  := StrToFloatDef(Copy(Linha,280,13),0)/100 - As colunas de 280 a 356 são reservadas p/ os erros
- corrigido o bloco de erros (motivos de rejeição) - criada a função motivorejeicaocoluna
 
Tudo conforme manual do banco, testado e aprovado com uma carteira com registro.

ACBrBancoNordeste.pas

PADRAO BNB - CNAB400.pdf

A02501301120154000069206288000.RET.SAI

cb271101.rem

Link to post
Share on other sites
  • 2 weeks later...

Boa noite.

Alterações disponíveis no svn com alguns ajustes.

Att.

Boa noite.

Alterações disponíveis no svn.

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

Fiz algumas modificação em cima das modificações que você fez:

- DIGITO VERIFICADOR:
Alterado CalcularDigitoVerificador - Removido a parte onde manda transformar digitofinal 1 p/ 0
  Seu módulo continua transformando digitofinal 1 p/ 0. Isso não existe no manual e eu já mandei homologar um boleto que o ACBr transformou digito final 1 p/ 0 e não passou, só passou quando o digito correto era realmente 1.   O manual diz que quando o resto da divisão (por 11) for 1 ou 0 aí o digito será 0, mas o resto da divisão, lembrando que ainda vamos subtrair de 11 o resto da divisão, portanto é para transformar o resto da divisão em 0 quando este for 1 ou 0 e não o próprio digito final encontrado.

Por isso esta parte dever ser retirada ou comentada como à seguir.
{
   if Modulo.DigitoFinal = 1 then
      Result:= '0'
   else
}

- MOTIVOS DE REJEIÇÃO:
Em GerarRegistroTransacao400, alterada a posição 394 (código da moeda) estava '1' p/ '0', que é o código correto p/ R$
  Onde está '991' o correto é '990'. Essa moeda com '1' também deu problema na homologação e o manual é claro quanto à ser 0 para R$

As rejeições estão nas colunas entre 280 a 356 mas no caso de toRetornoLiquidado as colunas 296 a 301 são reservadas para a data do crédito.
Do jeito que você deixou, se a linha se tratar de um retorno de liquidação com data de crédito por exemplo 120115 o ACBr irá tratar as colunas da data com 1 como erros e não são, já fiz os testes, por isso o correto é:

for i := 0 to 76 do
begin
  if (copy(Linha,280+i,1)='1') then
    if ((i+280 < 296) or (i+280 > 301) or (OcorrenciaOriginal.Tipo <> toRetornoLiquidado)) then
      DescricaoMotivoRejeicaoComando.Add(MotivoRejeicaoColuna(280+i));
end;

Não entendi a função CodMotivoRejeicaoToDescricao no Bnb, uma vez que no Bnb não tem código de erro, o erro é de acordo com a coluna.
Você pode ver que esta sua função não é usada em parte nenhuma do módulo.
Mas mantive assim mesmo.

- CARTEIRA:
Em GerarRegistroTransacao400 você colocou na posição da carteira a linha: IntToStr(StrToInt(Carteira)), mas como existe carteira alfanumerica como o 'I' não vamos usar strtoint ou inttostr, por isso alterei simplesmente para 'Carteira'

Só lembrando que da forma que você deixou (fpTamanhoCarteira:= 1) eu devo usar na carteira (ex: 4), ao invés de 21.
Dúvida: No boleto deve ser impresso o Tipo de Operação no lugar da carteira (ex: 21) ao invés de 4, como imprimir o CarteiraToTipoOperacao?
Eu resolvi via código no próprio Fast Report, não sei se existe outra forma.
 

ACBrBancoNordeste.pas

Link to post
Share on other sites
  • 1 month later...

Oi, estou me preparando para homologar o boleto para o BNB e em meus testes me deparei com o número '1' na posição 394. Como não faz muito tempo que eu atualizei os meus fontes do ACBR gostaria de saber qual o repositório que em que estão as alterações mencionadas a cima, trunk ou trunk2 ?. E porque que no meu fonte aparecem de forma fixa a opção para não protestar '99' (posições 392 a 393) e o códio da moeda '1' posição 934?

 

Edited by emisael
Link to post
Share on other sites

Bom dia.

Somente o Trunk2 vem sendo atualizado  a algum tempo, como você pode observar não foi adicionado comentário quanto ao comit destas alterações no svn, ou seja, as mesmas ainda estão na fila para análise.

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

Olá Juliana e Luciano

Atualizei o componente, mas ficamos com um problema numa homologação. Ao validar os arquivos o Banco nos repassou que o nosso numero estava invalido pois conforme a Nota 0, no item "e" do Layout passado pelo Luciano o digito do nosso número será 0 quando o resto da divisão for 0 ou 1.

Diante disso fizemos a seguinte alteração no arquivo.

Na linha 101, do arquivo onde tinhamos: 

if Modulo.DigitoFinal = 1 then
      Result:= '0'
   else
      Result:= IntToStr(Modulo.DigitoFinal);

Trocamos por:

   if Modulo.ModuloFinal <= 1 then
    Result:= '0'
   else
    Result:= IntToStr(Modulo.DigitoFinal);

 

Outro detalhe é a impressão do código de carteira no boleto, pois com a criação da função CarteiraToTipoOperacao, onde passamos o código a ser utilizado no remessa, o mesmo converte o código passado e faz o calculo correto para o calculo do digito do nosso numero. Entretanto, na impressão do boleto temos o campo Carteira. Como meu código de carteira para remessa é "4", na impressão do boleto deveria aparecer "21" e devido a isso o banco não esta liberando nossa homologação.

Antes dessa versão eu tratava isso em minha própria aplicação, onde no cadastro de contas eu tinha 2 informações "Carteira Boleto" e "Carteira Remessa". Outros banco tambem tem situação semelhante, como CCB(antigo BicBanco).

Até tentei implementar alguma solução, mas o valor que vai para a impressão do boleto sempre é o valor informado na propriedade carteira, e é lido nas Unit's de impressão do FortesReport ou FastReport.

Alguma ideia?

Valeu!!!

Junior

 

Link to post
Share on other sites
21 minutos atrás, Juliana Tamizou disse:

Boa tarde.

Em relação a carteira, como vc está informando a propriedade?

Att.

Juliana, não sei se foram implementadas minhas alterações enviadas dia 20/12/2015. Elas resolvem todas essas reclamações acima. 

ex: Digito verificador do nosso número = 1 que o ACBr está transformando em 0, Moeda 1 quando o correto é 0 e as coluna de rejeição.

Quanto à carteira, ela está sendo informada com 1 dígito pela alteração que vocês fizeram (ex: 4). Eu transforma o 4 para 21 no código no Fast Report. Mas acho que o ideal é deixar a carteira com 2 dígitos mesmo, como era antes (ex: 21), porque é esse código que deve ser impresso no boleto e transformar em 1 digito (ex: 4) apenas na geração da remessa. Assim não precisa de código algum no Fast Report. Se você quiser eu faço essa implementação e envio aqui.

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