Por que uma versão 2.0? #1
Comments
|
@apbertoletti O projeto foi totalmente reescrito e não terá compatibilidade com a versão atual, por isto criamos um novo repositório. |
|
@carloscds Olá Carlos, tem previsão de postar o projeto? |
|
@joaoluizsouza Acredito que em alguns dias! |
|
Estou dentro para ajudar, tenho utilizado a outra versão mas já virou bagunça. Sugiro dois projetos, 1 para boletos outro para CNAB remessa e retorno. Pode contar comigo. |
|
Entendi Carlos, Já sabe nos dizer quais as principais novidades e mudanças arquiteturais Abraços 2016-10-10 22:44 GMT-03:00 Carlos dos Santos notifications@github.com:
|
|
@apbertoletti O código está bem mais simples. |
|
@carloscds já tens algo desenvolvido para essa versão 2.0? |
|
@marcieltorres Já temos sim. |
|
Legal! E vocês já criaram a estrutura de dados principal? Pergunto pelo seguinte, no projeto atual temos algumas classes do tipo: Instrucao_Bradesco, EspecieDocumento_Bradesco, etc (elas se repetem para todos os bancos). Acredito que esse seria um ponto para melhoria, a estrutura básica de dados. |
|
@marcieltorres Sim, estamos dando uma ultima olhada no código e depois iremos subir. |
|
Olá, alguma previsão de upload dos fontes??? |
|
@diegomborges Estou aguardando o desenvolvedor que fez as mudanças finalizar algumas homologações. |
|
Pessoal, boa noite... Só agora vi que já tem mensagens por aqui... vou agilizar a revisão proposta pelo Carlos e encaminhar esse código para ele. Basicamente são 3 detalhes: 1 - Excluir alguns testes unitários que eu fiz. Importante adiantar que, o objetivo principal deste projeto foi padronizar o código entre os diferentes bancos / carteiras, tornando mais fácil de entender (independente do banco) e mais fácil de colocar em produção com segurança (código mais limpo). Com relação a geração e leitura do CNAB, foi unificado em apenas 2 formatos: CNAB240 ou CNAB400 (que inclui o CBR641 do BB). Além disso, foi criado propriedades para totalizar os títulos que estão presentes no arquivo, facilitando a criação do regristro trailler de alguns bancos. Outra alteração foi a possibilidade de gerar mais de um registro para o arquivo CNAB400 (por ex: Bradesco gera o registro 1 e 5). Na parte da leitura, o arquivo é analisado e para cada título, um objeto "Boleto" é criado na coleção. Na versão anterior, para cada retorno, havia um objeto diferente, o que na prática acabava sendo necessário converter (novamente) para um objeto boleto. Por conta disso, nem todas as características de todos os registros de retorno irão para uma propriedade definida, mas existe uma propriedade específica que irá trazer a linha inteira do arquivo, e se houver necessidade buscar alguma informação, é só acessar a posição de acordo com o manual do banco. Sobre as instruções de cobrança: Essas classes foram excluídas. Agora, o que existe, são duas propriedades Instrucao1, Instrucao2 do tipo string. Basta informar e pronto. Algo parecido foi feito também para os textos do cedente (são duas propriedades, uma para o arquivo remessa com tamanho reduzido, e outra livre para impressão do boleto). Para que tudo isso fosse possível, todos os bancos e carteiras do projeto anterior foram excluídos. Atualmente só temos Bradesco, Banco do Brasil e Caixa Economica Federal neste novo projeto. Todos eles com testes unitários. Para manter o padrão, o ideal é não criar novos bancos fugindo do padrão já implementado nos existentes. O primeiro passo seria criar um checklist para implementação de novos bancos, e só aceitar PR desses novos bancos se seguirem essa diretriz. Esse projeto já está em produção desde janeiro/2016, nos 3 bancos citados. A culpa do código não estar disponível ainda, é minha. Venho falando com o Carlos já faz algum tempo, mas infelizmente não me sobra muito tempo para isso. Assim que o código chegar aqui, acredito que as coisas vão mais rápidas, pois outras pessoas poderão ajudar. Só pedi um pouco de paciência para o Carlos, pois preciso dar uma última olhada no nome das propriedades, pois seria muito complicado fazer qualquer ajuste nisso depois de publicado. Por fim, uma classe "Proxy" também foi adicionada para facilitar o uso da DLL em outras ferramentas (fora do V.Studio)... Abs! |
|
Show Rodolfo,
Muito obrigado pelo retorno.
Abraços
Em quinta-feira, 8 de dezembro de 2016, Rodolfo Duarte <
notifications@github.com> escreveu:
… Pessoal, boa noite...
Só agora vi que já tem mensagens por aqui... vou agilizar a revisão
proposta pelo Carlos e encaminhar esse código para ele.
Basicamente são 3 detalhes:
1 - Excluir alguns testes unitários que eu fiz.
2 - Revisar (mais uma vez) o nome das propriedades dos objetos.
3 - Montar um roteiro de implantação de novos bancos/carteiras.
Importante adiantar que, o objetivo principal deste projeto foi padronizar
o código entre os diferentes bancos / carteiras, tornando mais fácil de
entender (independente do banco) e mais fácil de colocar em produção com
segurança (código mais limpo).
Com relação a geração e leitura do CNAB, foi unificado em apenas 2
formatos: CNAB240 ou CNAB400 (que inclui o CBR641 do BB). Além disso, foi
criado propriedades para totalizar os títulos que estão presentes no
arquivo, facilitando a criação do arquivo retorno. Outra alteração foi a
possibilidade de gerar mais de um registro para o arquivo CNAB400 (por ex:
Bradesco gera o registro 1 e 5). Na parte da leitura, o arquivo é analisado
e para cada título, um objeto "Boleto" é criado na coleção. Na versão
anterior, para cada retorno, havia um objeto diferente, o que na prática
acabava sendo necessário converter (novamente) para um objeto boleto. Por
conta disso, nem todas as características de todos os registros de retorno
irão para uma propriedade definida, mas existe uma propriedade específica
que irá trazer a linha inteira do arquivo, e se houver necessidade buscar
alguma informação, é só acessar a posição de acordo com o manual do banco.
Sobre as instruções de cobrança: Essas classes foram excluídas. Agora, o
que existe, são duas propriedades Instrucao1, Instrucao2 do tipo string.
Basta informar e pronto. Algo parecido foi feito também para os textos do
cedente (são duas propriedades, uma para o arquivo remessa com tamanho
reduzido, e outra livre para impressão do boleto).
Para que tudo isso fosse possível, todos os bancos e carteiras do projeto
anterior foram excluídos. Atualmente só temos Bradesco, Banco do Brasil e
Caixa Economica Federal neste novo projeto. Todos eles com testes
unitários. Para manter o padrão, o ideal é não criar novos bancos fugindo
do padrão já implementado nos existentes. O primeiro passo seria criar um
checklist para implementação de novos bancos, e só aceitar PR desses novos
bancos se seguirem essa diretriz.
Esse projeto já está em produção desde janeiro/2016, nos 3 bancos citados.
A culpa do código não estar disponível ainda, é minha. Venho falando com o
Carlos já faz algum tempo, mas infelizmente não me sobra muito tempo para
isso. Assim que o código chegar aqui, acredito que as coisas vão mais
rápidas, pois outras pessoas poderão ajudar. Só pedi um pouco de paciência
para o Carlos, pois preciso dar uma última olhada no nome das propriedades,
pois seria muito complicado fazer qualquer ajuste nisso depois de publicado.
Por fim, uma classe "Proxy" também foi adicionada para facilitar o uso da
DLL em outras ferramentas (fora do V.Studio)...
Abs!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGhsZUkVTmYXtmNpZNY9OUk6Ejl75ezpks5rGJpwgaJpZM4KS1-6>
.
|
|
Status dos trabalhos aqui, para subir o código: Concluído:
Em andamento (precisa ser concluído para liberar para uso):
Pendente (pode ser feito após liberar a versão inicial):
|
|
@excelente @rafd75, precisamos subir logo este projeto! |
|
Alguma novidade? |
|
@carloscds --- Onde paramos? |
|
@rafd75 Nos testes acredito. |
|
@carloscds --- nos próximos dias (estou aguardando a documentação) vou acrescentar o Santander (e talvez o Itau) no projeto... Quando puder, da uma olhada no código do meu Fork... Preciso pegar o histórico de nossa conversa, mas acho que já está no jeito.... |
|
@rafd75 Blz. |
|
O @jonasscalar comentou que seria interessante dividir entre boleto e CNAB. Também acredito ser interessante. Será que é viável? |
|
@rogernascimento --- no projeto atual, continua junto (no mesmo projeto). Mas a classe de geração de remessa e retorno foi (muito) simplificada. A principal mudança foi que a classe retorno já preenche uma coleção de boletos (na versão 1, cada banco tinha a sua classe). Não sei como ficaria dividir isso. Precisaria pegar o código novo, e ver como está, e como ficaria em dois projetos. Particularmente, não consegui enxergar um motivo para isso ... no final, com a cobrança registrada, não vai existir boleto sem remessa, e vice-versa. |
|
@rafd75 entendi. |
|
@rogernascimento - não sei se você consegue acessar esse repositório: http://github.com/rafd75/boleto2net IMPORTANTE: Pode olhar o código a vontade... mas não passou ainda pela aprovação do @carloscds --- Não me recordo onde exatamente paramos... Ele havia me passado alguns comentários a respeito... Então, pode estudar o código a vontade, inclusive para dar sugestões... Apenas não utilize como base, pois poderá ser alterado para a primeira versão do repositório oficial. Aliás, se olhar o código e tiver sugestões, fique a vontade... a ideia é exatamente essa, criar um formato único que será utilizado em todas as carteiras implementadas. Isso vai fazer (certamente) o projeto andar mais devagar que o oficial, mas acredito que será compensado pela qualidade do produto final. Da uma olhada e mande suas sugestões. |
|
@rafd75 Rodolfo, estávamos analisando os testes! |
|
@carloscds --- da uma olhada no código atual... Eu alterei algumas coisas, de lá para cá, se não me engano, já implementei o SICOOB, e devo fazer o Santander nas próximas semanas.... Talvez Itaú em breve também.
Meu código está atualizado com meu repositório.... Veja novamente os testes do jeito que está ai... Acho que já resolvemos aquelas pendências (testar arquivo REM, etc, foram retirados... Ficou apenas os testes de código de barras, com dígito verificador de 1 a 9, etc). |
|
@rafd75 Parece ok, só tem um teste marcado como Inconclusivo, você vai finalizar ? |
|
@carloscds - Sim , precisa ser feito... Mas estou com um problema aqui. O cliente que me pediu essa carteira (11 - Emissão do boleto por conta do BB), acabou não implementando. E eu não consigo dados para fazer o teste... Minha sugestão é deixar assim (ou criar uma ISSUE no projeto) para não esquecer de que é necessário fazer isso antes de usar essa carteira. Obs: A carteira 17 do BB está em produção e com testes OK! O que vc acha ? |
|
@rafd75 Dei uma olhada superficial no código, vou olhar com mais calma depois, mas a primeira coisa que achei que podia melhorar, é a nomenclatura dos testes, não consegui entender rapidamente o que cada coisa testava, se aquele teste é uma certificação de uma rotina executada com sucesso ou se é de falha. |
|
@AlbertoMonteiro --- boa tarde.... (obs: Conversei com você em um VSSummit - 2015 eu acho - sobre o EF... Um dia ainda iremos voltar neste tópico... enfim).... Como sempre desenvolvi sozinho, eu não tenho muita experiência com esse tipo de nomenclatura... O que você sugere? .... Poderia pegar apenas um exemplo de teste que eu fiz, e fazer a adequação e retornar aqui? Vou implementar o Santander nos próximos dias... e se for o caso, já ajusto essa nomenclatura. |
|
@rafd75 Vou tirar um tempo mais tarde para fazer um PR para o seu fork, ai acho que fica mais fácil demonstrar algumas ideias, o que acha? |
|
@AlbertoMonteiro - pode ser... (aliás, deve ser... ) - como disse, não sou acostumado com essa dinâmica de desenvolvimento aberto... sempre fiz as coisas "só para aqui"... valeu! |
|
@rafd75 Eu bem que achei seu rosto familiar, mas como já faz um tempo, desde 2015, não consegui me lembrar de onde era, conversei com você pelo Facebook, não foi? Quando quiser marcar um talk por Skype ou similar, só avisar!! |
|
@AlbertoMonteiro Isso mesmo... eu fiz umas coisas malucas aqui ...e iam de encontro com o conteúdo da sua palestra lá... Mas eu estou me perdendo aqui faz tempo, não consigo sair fora do "legado" e começar a migrar as coisas... Pelo menos, com o BoletoNet (e outras DLLs que tenho usado em C#), já vai me ajudando a ir para este lado (abandonar o VFP e migrar para uma nova ferramenta)... enfim... triste.. kkk |
|
Pessoal, alguma previsão para disponibilização dos códigos ? |
|
@EltonRst boa tarde... Eu estou terminando de homologar o Santander e Itaú. Além disso, já temos homologado o BB, Caixa, Bradesco e Sicoob. Mais uma ou duas semanas, estarei com isso pronto... Qual sua urgência? |
|
@rafd75 Obrigado, por enquanto nenhuma urgência, era mais curiosidade mesmo, mas assim que for disponibilizado vou migrar tudo da outra versão para essa. |
|
Bom dia, parabéns pelo trabalho, estou disposto a colaborar. Além disso há alterações no layout de cada banco tanto no CNAB como na impressão. |
|
@jonasscalar - bom dia! O Avalista já existe... (obs: não sei que versão do código está contigo, pois na primeira versão que subi aqui, realmente não existia)... Se for na versão mais atual, basta acessar diretamente da classe "Boleto" (e não do "Cedente") como você estava tentando... |
|
Pessoal, acabei de fazer um PR... @carloscds Veja se tem alguma consideração... se não tiver, está liberado... Neste caso, acho melhor fechar essa issue e a partir de agora, começar novas issues para tratar assuntos específicos. Note na observação do PR as condições para aceitarmos novos PRs do projeto... Manter o padrão já implementado, facilitando a manutenção depois... E se não estiver homologado e com todos os testes - igual as carteiras já existentes - eu acredito que não deveria ser aceito. Vamos ver... fico no aguardo. |
|
Alguém pode disponibilizar o código de implementação no MVC? |
Olá pessoal, td bem?
Desculpe a curiosidade, mas gostaria de saber o que seria este projeto BoletoNet 2.0?
Alguma razão especifica motivou sua criação?
Será um projeto diferente e desacoplado do BoletoNet original?
Muito obrigado
André
The text was updated successfully, but these errors were encountered: