Novas funcionalidades

[fernandomr]

Cnab240 Itau, CEF e Bradesco. Cnab500 Pagamento de Fornecedores Bradesco.

[rvalyi]

Eu entendo que densenvolvem isso para resolver a situacao em alguns clientes. Mas porem acho que estao re-inventendo a roda. Temos esse projeto que tem 29 contrbuidores que ta bastante ativo com um modelo de negocio real por cima https://github.com/kivanio/brcobranca e que tem uma cobertura de teste muito alta: https://github.com/kivanio/brcobranca/tree/master/spec

e que eu acho que eu levaria so uns 4 dias para comecar a fazer funcionar com o Odoo... E talvez so 10 dias para ter algo muito solido.

Com certeza pode ser util. Mas porem aqui nao tem muitos testes, nehnuma comunidade ativa que vai manter isso. Enfim novamente entendo que as vezes os imperativos dos projetos obrigam a tomar certas decisoes, so queria expressar aqui meu ponto de vista a respeito do "big picture".

[danimaribeiro]

Então porque você não começa a fazer algo e publica? Com certeza iriamos ajudar.

[rvalyi]

@danimaribeiro ja expliquei 2015 foi foda para a gente. E hoje vc pode ver que estamos bem apegado na estabilizacao da v8 de depois na migracao da v9...

Depois disso acho que a gente vai fazer. A grana tb e um ponto importante. Hoje selecionamos clientes para quais esse ponto nao e critico. A reciproca e que nao vao bancar isso.

Agora se alguma empresa paga uma semana de dev para Akretion a gente poderia encarrar isso antes.

Mas enfim, esse tipo de desencontros de cronogramas acontecem nos projetos open source. Eu so prefiro avisar que ao nivel da OCA, se temos como ter todos boletos e CNAB com 500 linhas de codigo em vez de 10000 e com 95% de coverage em vez de 10% obviamente iremos favorescer essa outra opcao. Agora eu nao estou criticando o trabalho feito aqui. Fazer coisas para resolver uma situacao de forma temporaria a gente ja teve que fazer inumerosas vezes na Akretion tambem entao eu entendo perfeitamente.

[danimaribeiro]

Acho que vcs tem que começar a trabalhar mais em conjunto conosco, senão vocês vão ficar numa ilha isolada.

O trabalho que o Luis ta fazendo com os boletos aqui eh excelente, se vcs ajudassem o trabalho iria mais rápido.

Agora usar uma lib de outra linguagem aqui no odoo com certeza não é a melhor solução.

[rvalyi]

@danimaribeiro olha durante 6 anos nos liderenos isso de uma forma bem colaborativa, nos co-criamos a propria OCA ate bem antes de vc comecar a olhar no Odoo sabe... Entao nao vou discutir esse ponto sendo que tivemos um problema durante apenas 6 meses de 6 anos.

Na Akretion eu treinei gente que treinou gente de forma que hoje tem 10 caras fazendo contribs na OCA cada semana somos o quarto editor de modulo mundial, entao nao sei bem que esta na ilha isolada.

O ponto e que nos nao estamos trabalhando nesse ponto agora. Assim como vc nao esta trabalhando nas coisas de de MRP que a gente faz por exemplo. E normal as pessoas focar em coisas diferentes em momentos diferentes. O importante e ter coordenacao no core.

A linguagem para fazer uma tarefa que se usa e de menos. o Engine de report do Odoo nao e feito em Python, o nodejs que o CMS usa para tratar os js e css e feito em Python, nao vejo problema que a lib que imprime o pdf de um boleto ou o parsing dele nao seja em um python. Me interessa muito mais fazer o esforco minimo e ter a confiabilidade maxima.

Vejo que iremos precisar de uma estrutura de boleto persistente no Odoo e nisso teremos sinergias. Porem a gente preferiria que esse objeto seja apenas um transcode (mesmo que manual) do objeto do BRCobranca para evitar mapping.

Mas enfim talvez usaremos uma parte do que vcs fazem, iremos avaliar isso, de qualquer jeta essa parte vai mudar bastante ma v9. Depois de qualquer jeito as pessoas sao livres de usar a lib que querem.

[rvalyi]

@danimaribeiro tambem eu falei do brcobranca ja uns 2 anos na lista pelo menos.

Bom vamos tentar da um gaz nisso quanto antes. Sei la talvez ate o fim de dezembro consigo ter um POC. Mas para algo de producao, acho que so iremos fazer na v9 e nao antes de Feveirero ou coisa assim. Entao entendo perfeitamente voces ter que fazer algo em Python para atender o seus clientes hoje. Ve por exemplo o retrabalho que tivemos que fazer no modulo account_product_fiscal_classification porque o Sylvain nao tinha visto o modulo OCA incialmente, isso acontece ate com o a gente. Acho que o importante e o copo meio cheio e nao o meio vazio.

Abraco.

[rvalyi]

@danimaribeiro de tambem uma olhada quem fez o modulo account_direct_debit que estao usando para os boletos (o que ta certo na v8 pelo menos)... Entao essa questao de ilha isolada sabe...

[mileo]

@rvalyi

Não vejo beneficio a longo prazo em manter uma dependência em Ruby. Com o modulo em Python ganhamos dois novos contribuidores.

Realmente vai ter muita coisa que vai precisar ser refeita na V9, mas o grosso esta no framework. Extrair as informações do Odoo é simples, agora suportar múltiplos bancos e diversas formas de recebimento e pagamento é o que da trabalho. A forma como isso vai ser exportada/importada é indiferente.

Se vc acha melhor fazer em Ruby duvido que nesses "2 anos" vc não teve uma tarde para fazer um POC.

Comunidade > Código

[]s

[rvalyi]

@mileo sim o importante e fazer o mesmo tipo de diferencia entre as coisas persitentes e as libs de import/export como nos fizemos com o l10n_br_account_product e o adapter do pysped.

Sendo assim teremos sinergias boas e as formas de fazer o import/export sera plugavel com a melhor coisa para fazer o trabalho. Essa parte persistente disso depois a gente consegue dar a bencao da OCA tb.

O lance e que mesmo que 2 anos atras eu ja enxergava esse jeito com o brcobranca realmente era longe de ser uma prioridade. A propria construcao da OCA por examplo era muito mais prioritaria. Se 2015 fosse um ano normal para gente, certeza que eu teria feito, mas com a perca da minha esposa realmente foi um ano perdido para mim.

Enfim o importante e que vamos ficar ligados nesses dev para ver onde a gente consegue encaixar sinergias.

Agora sobre a lib de import/export, minha visao e que mesmo que arruma algumas pessoas para contribuir, nao vai conseguir alcancar a confiabilidade e a atividade da comunidade que o brcobranca conseguiu: https://github.com/kivanio/brcobranca/pulls?utf8=%E2%9C%93&q= Sendo que os caras ja tem um coverage perto de 100% em todos bancos que trabalham.

Nesse tipo de situcao o primeiro que faz a coisa muito bem aggrega todas contribuicoes e depois ninguem quer se dar o trabalho de re-inventar a roda. Pelo menos eu nao.

[rvalyi]

@mileo @danimaribeiro @fernandomr so mais algumas consideracoes:

o TED e DOC, isso o brcobranca nao faz entao sera 100% aproveitado

Eu tinha olhado esse repo um mes atras e o que tem atualmente na branch 8.0, que e a parte persistente dos boletos e 100% util por isso nem tinha comentado nada. So quando vc me falou @mileo que iria trabalhar nos CNAB num sprint que eu levantei a questao do brcobranca de novo suspeitando que poderia ser nessas coisas de impressao de boleto e parsing de CNAB que considero um pouco inutil a medio e longo prazo.

Ou seja, infelizmente nosso cronograma nao nos permitiu de contribuir isso antes, porem nao acho justo dizer que a gente estaria desligado do projeto numa "ilha isolada". Tambem nao podemos ser cobrado de fazer algo que consideramos inutil pelo menos para gente. Sabiamos que as questoes dos pagamentos iriam mudar muito na 9 (porque partcipamos do workshop de contabilidade na Odoo SA um ano atras alias) por isso a gente selecionou projetos onde isso nao era critico na v8. A gente ja fez uns 90%-95% dos modulos que estao hoje na OCA e ainda tem muito trabalho na 8.0 e depois para migrar para a 9.0. Infelizmente nao podemos fazer tudo, mas nem por isso apoiamos a ideia de re-escrever em Python coisas que ja sao super maduras em outros linguagens e super faceis de se aproveitar.

[mileo]

@fernandomr Pq vc fechou?

[fernandomr]

Pra juntar as correções com a sequencia de arquivo e fazer um novo PR. Tinha alguns arquivos que eu deveria ter tirado nesse PR tbm.