Which approach account_fiscal_year v14
Closed this issue · 13 comments
The account.fiscal.year model has been moved to EE in odoo/odoo#46110
In v8 and before, we had fiscal years and periods, we relied on that. In v9 and v10, account_fiscal_year had its own data model because fiscal years were not supported in Odoo. In v11, v12, v13, we relied on the upstream Odoo model. In v14 this model still exists but has moved to EE... sigh.
This is particularly annoying because it cripples the ability for community reports depending on fiscal year data to produce correct results. We could recreate our own data model, but then people installing OCA reports on EE would get wrong results unless they populate the community data model.
Perhaps we should first do an inventory of OCA modules that depend on it ?
mis-builder needs res.company.compute_fiscalyear_dates.
I think we have to restore OCA's account_fiscal_year module, but extracting the code from core v13, so we only need to add the dependency, but not changing the code in dependent modules.
Hello I agree with @pedrobaeza about making a basic v13 port. Also when porting previously open source Odoo SA modules to the OCA, I suggest to stick with the newest official Odoo Enterprise data model whenever possible. I believe having the same tables and columns when this is trivial is no licensed code infringement and instead it minimizes the diff with the Odoo official doc, it also makes migration with Odoo EE easier and improves our eco-system compatibility.
With this in mind I just check the v14 fiscal year data model and it seems there is no change in v14:
Hello I agree with @pedrobaeza about making a basic v13 port. Also when porting previously open source Odoo SA modules to the OCA, I suggest to stick with the newest official Odoo Enterprise data model whenever possible. I believe having the same tables and columns when this is trivial is no licensed code infringement and instead it minimizes the diff with the Odoo official doc, it also makes migration with Odoo EE easier and improves our eco-system compatibility.
+1 - I also think it would be best to stick to the newest odoo data model.
I think we have to restore OCA's account_fiscal_year module, but extracting the code from core v13, so we only need to add the dependency, but not changing the code in dependent modules.
👍 (in fact I don't see other options).
@fpodoo : It seems you are full closing accounting features gradually. Could you explain the next steps of your roadmap ?
Thanks !
+1 to keep the same model as long as we can, of course.
What do we do with the methods, such as compute_fiscalyear_dates ?
@fpodoo in case you read this, I for one usually don't complain loudly when features move around and indeed it is no surprise that some accounting stuff moves to EE. Yet there was a kind of untold agreement that basic data models that are required for basic interop of accounting modules would stay in CE. account.fiscal.year is one of them, since if it diverges between EE and CE, unsuspecting users well get different results when running, e.g. EE and OCA reports. This will create bad user experiences.
@fpodoo i think your answer is well understandable, but if you consider "Odoo Community" as always only the official community version of yours w/o any OCA code, the OCA can't rely on any base architecture any longer, because that would naturally read as "If some model or feature is not used by Odoo CE official code, it may be eventually moved to Odoo EE even if it was CE code in the first place". This relatively small change for you, increases friction, frustration and double work not only among integrators but also among users. I doubt that this would be beneficial to anybody in the end. So honestly is there any chance you overrule that decision and take it back, than i think this would be the time to do it. Thanks for considering!
There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.