Migration to version 11.0

[pedrobaeza]

Todo

IMPORTANT EDIT by Raphael Valyi : I don't know where this list of modules comes from but some of these modules like l10n_br_base are in fact a full rewrite of l10n_br_base in a very suboptimal way, forcing a full rewrite of the project. This is based on a fiscal model (the sped_* modules) that has been proposed by the last accepted PSC @mileo. But rejected by the 2 other PSC's (the ones who made around 80% of the codebase of the current OCA repo as in v8 and that wasn't fully migrated yet as nobody did the nearly trivial work to finish the migration) 5 months ago. After we rejected formally the fiscal model in these PR's #529
#548
#547
#544
#542
Not a single correction or answer was given. In fact I myself had to create these PR's to formally give a feedback on the ongoing unilateral rewrite as obviously there was an attempt to go solo and bypass the OCA reviews.
So we cannot accept this new model, we think it is a huge shoot in the feet for the project. Forcing a full rewrite of a code that was good in something that is not, that has been designed by a guy who never made a single PR into to OCA project and worked in an illegal proprietary fork of Odoo 6.1 and tried to push his broken model into the OCA project by all means without working closely in the OCA system. This model has many design mistake which are obviously done by somebody who doesn't know the recent Odoo framework very well and thus made this clumsy in house modelling. We are up for a technical debate about it any time. But better than that, instead of just criticizing, we will soon propose what we would instead consider a good fiscal model to extend the operational side of this localization to make the legal fiscal consolidation easier (notice that some transnational companies invoicing for 10 millions R$/months are using the v8 localization and producing the fiscal consolidation reports with Odoo data with great success since 2014). Instead these guys and everybody using the v8 localization would be very angry to have to spend horrible amount of money to change the data model completely and migrate all their customization to a model that we consider inferior).
END IMPORTANT EDIT

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-11.0

Python dependencies

• pybrasil
• pysped

OCA dependencies

• report_py3o
• repot_xlsx

Modules to migrate

• l10n_br_base
• l10n_br_pos 11.0 mig l10n br pos #570
• l10n_br_resource 11.0 mig l10n br resource #571
• l10n_br_financial 11.0 mig financial #572
• l10n_br_financial_account 11.0 mig financial account #573
• l10n_br_geolocalize 11.0 mig l10n br geolocalize #574
• l10n_br_hr 11.0 mig l10n br hr #575
• l10n_br_hr_contract 11.0 mig l10n br hr contract #569

Analisar se precisam ser migrados

• l10n_br_account
• l10n_br_account_payment
• l10n_br_account_product
• l10n_br_account_product_service
• l10n_br_account_service
• l10n_br_crm
• l10n_br_crm_zip
• l10n_br_data_account
• l10n_br_data_account_product
• l10n_br_data_account_service
• l10n_br_data_base
• l10n_br_delivery
• l10n_br_hr_timesheet_invoice
• l10n_br_purchase
• l10n_br_sale
• l10n_br_sale_product
• l10n_br_sale_service
• l10n_br_sale_stock
• l10n_br_stock
• l10n_br_stock_account
• l10n_br_stock_account_report
• l10n_br_zip
• l10n_br_zip_correios

[mileo]

Olá Pessoal estamos trabalhando na migração neste momento.

Segue um script de instalação da versão 11.0

https://github.com/kmee/produto

Atividades em execução:

• Migração da pybrasil para o python3 https://github.com/kmee/pybrasil/tree/python3
• Migração do módulo l10n_br_base

@divino @sadamo @hugouchoasborges @gabrielcardoso21 @hendrixcosta @aricaldeira @thebmb @wagnerpereirasp @ananiasfilho @leorochael @rvalyi @renatonlima @mbcosta

NEXT STEPS
OCA/reporting-engine#167

[gabrielcardoso21]

Pessoal, estamos migrando os módulos do nosso fork (https://github.com/kmee/l10n-brazil) na branch 11.0-develop:

• l10n_br_base (instalável)
• l10n_br_resource (instalável)
• sped_imposto (instalável)
• sped (instalável) (TODO: campo one2many declaracao_ids chamando view de outro modelo)
• sped_stock (instalável)
• sped_sale (instalável)
• sped_purchase (instalável)
• financial (TODO)
• financial_account (TODO)

[rvalyi]

@gabrielcardoso21 @mileo @renatonlima
desculpa mas a prosposta de modelo fiscal de vcs ja foi rejjeitada ha 5 meses aqui:
#529
#548
#547
#544
#542

Em vez de levar o retorno em consideracao vcs fizeram como se nada fosse e nao corrigiram, nao fizeram nehnum outro PR corrigindo... Nao eh dessa maneira que as coisas funcionam na OCA desculpa. Alem disso isso foi a primeira avaliacao formal, mas o @renatonlima (PSC tb) e o @mbcosta que tem muitos commits e review no projeto participaram de umas reunioes informais com vcs antes e deixaram bem claro que nao ficavam empolgados pelas escolhas que vcs estavam fazendo (que basicamente força nada menos do que um rewrite inteiro do projeto, mata a modularidade e a integracao com os outros modulos do Odoo e da OCA e ainda tem com codigo muito inferior sem teste para ganhos ainda nao comprovados).

Vamos separar a mudanca de modelo de dados da migracao para poder avaliar bem. O @renatonlima esta finalizando a migracao dos modulos existentes da OCA para a v10. A partir dai vcs podem propor as alteracoes de vcs por cima para que a gente possa avaliar bem o que ganha e o que perde e iremos tb fazer uma proposta para poder emitir documentos fiscais indepentemente da parte contabel do Odoo.

Atts.

[rvalyi]

@gabrielcardoso21 @mileo, eu e o Renato, como os 2 fundadores e PSCs originais do projeto pudemos botar nossas clausulas ao aceitar o @mileo no PSC. Fomos bem claro que em caso de divergencia, a ultima palavra seria nossa. No caso dos modulos sped_* estamos exactamente nesse caso. Accredito que nao eh no interesse de vcs de persistir nesse modelo de dados. Ate agora vcs nao viram nossa proposta. Mas quando a gente viu que os PRs de vcs estavam patinando, a gente ate acabou se interessando pelo assunto e em breve iremos propor um modelo que resolve os principais problemas que vcs levantaram sem ter que jogar fora 7 anos de projeto e deixar todas pessoas que usam na merda para migrar (denaturando totalmente a promessa da OCA) para um modelo que nhenuma localizacao da OCA optou por fazer de tao zoado que eh.

[rvalyi]

guys, don't get me wrong: we mostly agree on the shortcoming of the localization for the fiscal document management and consolidation. The thing is we do have a very mature localization on the operational side and we don't want to loose all that fantastic work just for the fiscal new features which is what happens with your sped_* modules and base rewrite proposal.

Instead we think there is another way. Finishing to migrate the existing OCA codebase to v10 and then v11 is actually quite simple (and this is what Trustcode did, they didn't buy your sped_* modules either). And we will show you that will can have a very clean fiscal extension to that can be introduced by phase into the current codebase without breaking any test (we do have 70% of test coverage if we deprecate the txt nfe export out).

You spent months doing your proposals but failed to address the issues we raised. We first told that kindly during the sprint you organized and even tried our best to see if your model was able to fit into the OCA ecosystem. But you persisted into this model and propose it again without fixing the numerous issues we raised.

Now we think it is our turn to make a counter proposal for these new features. So let's finish the migration and we will show you our counter proposal. We think it is a very solid and systematic design to address the fiscal thing of our localization so we have good hope you will release it is in your own interest and the one of everybody in Brazil to follow the proposal we are about to make in a few days.

That being said. The project PSC's are not supposed to work for free migrating modules on demand to fit your own commercial agenda. You know this is the financial crisis in Brazil and we had our slow times too. It doesn't give you the right to just rewrite everything in a suboptimal way. No OCA project would ever accept this. Akretion uses to migrate lots of modules not written by us, really it is part of the daily OCA routine.

New features are new features and hardly new features should sacrifice all the existing features. Fiscal consolidation is a nice feature but that only makes sense when your ERP can manage operations in first place. Over the 8 years of the project, we became battle tested at managing operations. So yes the fiscal side can be improved. But no single test should be destroyed in that process and we are up for a detailed technical debate again if required. Projects PSC's aren't expected to work at your demand to implement the new feature you like selling to your customers. We may do that at our own peace, We are required to give you guidance and feedback and this is what we did (migrate first and drop that inherits design). Alternatively you can manage to make a good proposal/PR that is accepted. It usually works as for many modules in the past, as for the boleto/CNAB modules or the resource module plugin to your HR incubator repo. That would probably work with your POS work too. But we are sorry to state it again firmly that proposal failed in the case of the new fiscal model of these sped_* modules. We also have lot's of ideas refused in many OCA repos. we got our Magento connector rewritten and we accepted it. It happens. Hope we will come to the same page about this.

[rvalyi]

all right, this is not really the process you don't communicate anything on the OCA channel, but I admit things improved a bit since the last time we checked: you removed many inherits and you got more modular. I think there are definitely some good bits to take now. Mostly the tax computation thing provided you manage to test it. As for maintaining the fiscal fields and incorporating the existing localization without just loosing years of experience, I still have a proposal to make which I believe is superior to your code. One thing is sure, we will have lots of work ahead when merging these stuff...

[rvalyi]

follow up: the PSC's of the projects skipped Odoo v11 and focused on v10 and v12 instead. So basically. Right now the focus is migrating the basic NFe emission from v10 to v12 and finish the v8 to v10 port of the remaining modules in the meantime before they are migrated to v12 as well.

So if one really wants v11 modules, it should be possible to backport v12 modules to v11. If the PRs are made properly with all tests passing we may consider merging them.