Migration to version 14.0
OCA-git-bot opened this issue · 33 comments
Todo
https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-14.0
Modules to migrate
- account_asset_management - By @joao-p-marques - #1112
- account_balance_line - By @hildickethan - #1105
- account_chart_update - By @Reyes4711 - #1136
- account_check_deposit
- account_fiscal_year: discussion in #1069
- account_loan - By @AntoniRomera - #1316
- account_lock_date_update
- account_lock_to_date - By @AntoniRomera - #1314
- account_menu
- account_move_budget - By @AntoniRomera - #1315
- account_move_fiscal_year - By @xavier-bouquiaux - #1263
- account_move_line_purchase_info
- account_move_line_tax_editable
- account_move_line_used_currency - By @DhavalTforgeFlow - #1486
- account_move_reversal_choose_method - By @AlvaroTForgeFlow - #1278
- account_move_template
- account_netting
- account_spread_cost_revenue - By @kittiu - #1244
- account_tax_repartition_line_tax_group_account
- base_vat_optional_vies
- account_move_force_removal: By @tafaRU - #1167
Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list
@pedrobaeza Since the reconciliation is not available in the v14.0, do you think we can have more detailed account_netting module, we have a PR in here OCA/l10n-romania#76, which basically does the same, allow you to select the amounts (partial, full) and add notes for detailing the compensation.
Well, the idea is to restore the reconciliation in an OCA module. We can include the compensation/netting there or continue with current module. What are the differences between account_netting and yours?
@pedrobaeza first it adds separate models to keep track of compensations, compensation lines, amount that you want to distribute.
Uhm, not sure about the convenience of having such overhead for a simple operation like this one.
@pedrobaeza It's coming from the issues with Fiscal Authorities, since you need to document the compensation operation.
Well, the reconciliation record itself is such document IMO.
So, for account_fiscal_year we follow this approach #1069 (comment) right?
I would say yes.
I'm starting to work on the account_fiscal_year migration, I'll try to follow the guidelines given in #1069 (comment) and will create a PR as soon as I've got something working
Thanks, Simone. Ping me with any doubt.
On the road to restore reconciliation widget. I would like to know if it fits in this OCA repo as 'account_reconcile_widget'. Comments and indications also woud be appreciated.
@ozono I have that on my development backlog, talked on OCA Online Days. Check https://twitter.com/alexisdlattre/status/1317149095597887491?s=20
Do you want us to meet for debating about this?
@ozono I have that on my development backlog, talked on OCA Online Days. Check https://twitter.com/alexisdlattre/status/1317149095597887491?s=20
Do you want us to meet for debating about this?
Ok Pedro. I'll send you a mail to make an appointment.
account_reconciliation_widget development was moved to from this repo to OCA/account-reconcile#359 after request
I will migrate account_asset_management
please add: account_invoice_currency to the list
Please add: account_reversal (https://github.com/OCA/account-financial-tools/tree/11.0/account_reversal)
account_reversal features are included in core.
account_move_force_removal
Please, add account_move_force_removal in the modules to migrate list
Thanks
I'm starting to work on account_move_force_removal migration.
Please, add account_move_force_removal in the modules to migrate list
@fgarcia-humanoide done
I'm starting to work on
account_move_force_removalmigration.
Thank you very much Alex - @tafaRU
FYI, I'm working on porting account_permanent_lock_date and account_permanent_lock_move_update to v14. I think this feature is important. Any serious auditor would be very surprised to see that you can update lock dates backwards without any problem!
In v13/v14, there are 3 native lock date fields: https://github.com/odoo/odoo/blob/14.0/addons/account/models/company.py#L43
period_lock_date, fiscalyear_lock_date and tax_lock_date.
The module account_permanent_lock_date adds a new field permanent_lock_date. So, that would be a total of 4 lock dates... it's starting to be very difficult for users to understand the difference between these 4 lock dates!
So I propose the following: the module account_permanent_lock_date would use the native "fiscalyear_lock_date" and make sure it cannot be set backwards or set to null.
Advantages:
- no need to inherit create() and write() of account.move in account_permanent_lock_date => perf improvement and code simplification
- no need to maintain the "glue" module account_permanent_lock_move_update
- only 3 lock dates fields instead of 4 => easier to understand for accountants.
So I plan to implement this change in the migration PR of the module account_permanent_lock_date. What do you think ?
Although I don't use such module (at least not for now, there's a new law incoming that I think will force us to use it), I see it correct and a better implementation.
Thanks for sharing your thoughts Pedro!
BTW, as I will not re-use any existing line of code of account_permanent_lock_move, it will not be a "migration" but a new module. As it's a new module, it could have a new name (for example: account_fiscalyear_lock_date_no_backwards)
My opinion: I prefer to keep the current name because the feature is similar. But, if some people prefer to keep the module account_permanent_lock_date with the field "permanent_lock_date", then I'll propose my module under a new name.
+1 for keeping the name.
Here it is: #1271
I kept the same name for the module.
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.