-
-
Notifications
You must be signed in to change notification settings - Fork 775
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[16.0][MIG] account_move_name_sequence: Migration to 16.0 #1510
[16.0][MIG] account_move_name_sequence: Migration to 16.0 #1510
Conversation
This module restores the good old behavior where journal entry numbers were generated from a sequence configured on the journal.
Add post-install script to create a sequence for all existing journals Update README accordingly
…ge lines data based on current moves
…ange_day More info about: - odoo/odoo#91019 TODO: Revert this commit after it is merged
After remove required=True for journal.sequence_id field it is possible to post an invoice with misconfigured journal with empty sequence So, this constraint will raise an error for this kind of cases since that using '/' could raise the unique constraint for all other moves
The required flag was wrong for sequence_id and refund_sequence_id So, it was not possible to store any change in journal for journal different to sale and purchase
…efix In case you want name your invoice YYYY-MM-SEQ (ie: 2022-07-00001) where: * YYYY: is the account move year * MM: is the account move month * SEQ: is a numerical sequence that is continue along the fiscal year assuming fiscal year is over two years (ie: from july to june next year) Before this commit the sequence prefix use now() to be compute but the range is selected with the account move date. This commit make consistency computing prefix with the account move date as well. So account move manage the first janunary for the last day of the previous year will properly use the account move date. Co-authored-by: Alexis de Lattre <[email protected]>
/ocabot migration account_move_name_sequence |
For v16.0 the new PR is fixing almost concurrency issues: The README of I mean, It was asked (without answer) in the original PR: e.g. we have v11.0 instances with custom modules migrated to v14.0 failing with the following case of use: Subscriptions
Shop
(This case was considered in It could be fixed if you allow gaps for the journal of these kinds of payments Even if the bottleneck was already fixed in v16.0 you don't have the allow-gaps option anymore, so, the module So, the README of |
Thanks for this migration to v16. I'm testing your PR and it fails in the following scenario:
The bug doesn't happen when the supplier refund is created manually from scratch. |
105326e
to
dc30382
Compare
Hi @alexis-via Yea, its error its same this issue #1501 for v14 and v15. I put de fix #1514 but this not working in v16. I have added another fix that does solve this case and I have added a test. |
4971302
to
ad51021
Compare
The problem is fixed, thank you!
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
functional test ok
…space between name and returns.
…ence true if value not get in vals
ad51021
to
ab8e59d
Compare
Hi @alexis-via, I have checked the warning, the problem is that account.journal in V16 uses @api.model_create_multi for the create method. I have added the changes to work with this @api.model_create_multi for the create method. Regards |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
runboat is ok
I think we could make the changes in the readme post-migration PR /ocabot merge nobump |
Hey, thanks for contributing! Proceeding to merge this for you. |
Congratulations, your PR was merged at 146c448. Thanks a lot for contributing to OCA. ❤️ |
#1472
Add fix return sequence names do not add a space between name and returns
And add fix comment in issue #1465
And add fix comment in issue #1501 and comment #1510 (comment)