OpenCnabPHP
OpenCnabPHP copied to clipboard
Remessa SICREDI
Alguma previsão p/ implementação da remessa p/ SICREDI ?
Por enquanto não tem previsão, isso depende de um dos clientes dos meus sistemas precisar, ou de alguém aqui no projeto se interessar em implementar, dei uma olhada por cima na documentação e acho que um ponto de partida é a do bradesco, caso tenha interesse posso te ajudar, mas infelizmente não tem como me dedicar a isso agora.
Opa, boas noticias, vai rolar sim, começarei o desenvolvimento agora mesmo. e provavelmente farei uma PR no freddo/openboleto para o boleto
Excelente notícia, estou com um projeto em desenvolvimento p/ esse banco e precisando bastante da remessa e boleto deles.
@Rctnet qual o padrão vai desenvolver CNAB 240 ou 400 ?
400
Só para ter certeza, vai ser impressão pelo cliente?
Sim, pelo cliente
Tentei usar o projeto do freddo/openboleto, mas não tinha SICREDI implementado. Achei esse projeto que parece está funcional https://github.com/paseto/boleto-sicredi Mas não testei com o validador do banco.
@guilherme00 , atualizei a biblioteca para receber SICREDI ainda está em beta é não fiz o retorno, tambem postei em https://github.com/fredroo/openboleto implementação para o boleto
@Rctnet vou verificar e fazer alguns testes, te dou um retorno
@Rctnet a resposta da remessa.
- Nomenclatura do arquivo incoerente com o Manual CNAB 400, página 26
- Registros inconsistentes na linha “Header”, faltando entre outros, código do beneficiário, data de gravação do arquivo, conforme Manual CNAB 400, página 28
- Nosso Número inválido em todos os registros. Para Nosso Número, deve-se seguir a orientação constante no Manual CNAB 400, página 07.
A nomenclatura não sei se é alguma informação dentro do arquivo ou o nome do arquivo em si. Meu sistema nome o arquivo dessa forma "remessa-2018-05-21_16_34_37.rem"
Imagino que o código do beneficiário foi falha minha, o BD estava com limitação de caracteres
O Nosso número acredito que eu tenha preenchido de forma incorreta estou verificando, mas a dúvida por hora é se devo colocar o nosso número exatamente igual ao boleto AA/BNNNNN-DV ?
Ok vou dar uma conferida, mas quanto ao nosso numero só informar o sequencial, AA uso o ano da data de emissão do boleto B constante 2, assim esta no openboleto NNNNN , informar o sequencial sem os zeros a esquerda DV é calculado dentro do layout o nome do arquivo tem que ser especial, me esqueci, mas tinha planejado um método para nomear os arquivos
Ok, vou aguardar o update.
@Rctnet me enviaram o validador, o nome do arquivo de remessa tem que certo códigocedenteMD.crm Essa é a nomenclatura que eles reclamaram, executei o validador no arquivo de remessa e acusou essa mensagem.
Adicionei um método para isso, no exemploRemessa.php mostra como usar
e outros updates
Vou baixar os updates e dou um retorno
@Rctnet gerei novamente a remessa, mas acabei não utilizando o novo método p/ geração do nome deixei como eu estava gerando mesmo, o validador leu o arquivo e acusou isso agora
o primeiro erro é o teu sequencial de remessa o segundo acrescentei um adaptador que transforma o 2 em B e o 1 em A Já esta disponível.
@Rctnet parece tem alguma inconsistência na geração do DV do Nosso Número na remessa. No boleto está 18/200010-3, na remessa está indo 18/200010-0. No nosso número da remessa estou informando 00010, o mesmo sequencial p/ gerar o boleto. O boleto está sendo validado corretamente.
voce tem uma planilha com o testador do DV?
Tenho o validador de boletos e remessa que eles me mandaram. Na classe Registro1, a função set_nosso_numero estava mandando a base 7 para o módulo 11 fiz a alteração p/ 9 e começou a calcular o DV corretamente, porém tem um IF que está sempre dando TRUE fazendo com que o DV seja setado com 0
se for na linha 332 é para mudar para 0 só se $result['digito'] == 10
Sim, alterei somente a base de 7 p/ 9 e o validador não acusou nada aparentemente, subentendo que validou a remessa. Mandei os boletos e a remessa p/ o teste no ambiente deles, agora vou aguardar.
otimo, em caso de sucesso , pode criar uma PR coma solução.
@Rctnet a remessa não passou por causa da codificação tem que está no formato DOS mas o servidor da aplicação codifica o arquivo p/ UNIX. Acha que dá p/ resolver isso via biblioteca ou somente convertendo de UNIX p/ DOS ?
Estive olhando a documentação, e vi que uso um delimitador de fim de linha /r/n e na documentação pede que no final da ultima linha pede um hexadecimal (HEXA 0D0A) , se for só na ultima linha deveria da para fazer uma gambizinha e remover os dois ultimos caracteres e inserir o hexa, mas se for todo finalizador de linha posso criar uma variável no projeto e mudar o finalizador de linha conforme o banco/layout, gostaria que descobrisse se é para ter esse hexa somente no fim do arquivo ou em todos as linhas
@Rctnet não consegue a informação de codificação do arquivo. O que fiz foi converter o texto do arquivo no Notepad++. Após a conversão a remessa passou, agora falta o retorno.
blz, faz a conversão para que codificação?
O Notepad++ te essa opção abaixo p/ converter o texto
