Bnb - Remessa Cnab 400

[Luciano Rodrigues Pereira]

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.

[Juliana Tamizou]

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.

[Luciano Rodrigues Pereira]

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

[Juliana Tamizou]

Boa noite.

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

Att.

Boa noite.

Alterações disponíveis no svn.

Att.

[Luciano Rodrigues Pereira]

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

[emisael]

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?

 

Editado 21 Janeiro, 2016 por emisael

[Juliana Tamizou]

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.

[Juliana Tamizou]

Boa noite.

Alterações no svn.

Att.

[araujojunior]

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

 

[Juliana Tamizou]

Boa tarde.

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

Att.

[Luciano Rodrigues Pereira]

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.

[Juliana Tamizou]

Boa noite.

Ajuste disponível no svn.

Att.