-
-
Notifications
You must be signed in to change notification settings - Fork 344
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] sale_commission_partial_settlement: Migration to 16.0 #561
base: 16.0
Are you sure you want to change the base?
[16.0][MIG] sale_commission_partial_settlement: Migration to 16.0 #561
Conversation
ab8191b
to
3ae3861
Compare
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.
Functional ok
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.
Code review LGTM!
This PR has the |
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.
I have functionally reviewed the addon and identified an unexpected behavior regarding commission recalculation.
When using the "Full Amount" payment amount type, if a commission is already generated and subsequently deleted, re-triggering the settlement generates the commission again as expected.
However, with the "Paid Amount" type, the process differs: you need to first break the reconciliation between the payments and the invoice, then re-reconcile them to allow the commission to be generated once more.
This inconsistency between the "Full Amount" and "Paid Amount" processes may lead to unexpected results and could cause workflow disruptions.
Steps to Reproduce:
Use the "Full Amount" type to generate a commission, delete it, and observe the behavior on re-triggering the settlement.
Use the "Paid Amount" type, generate a commission, delete it, and note that reconciliation must be broken and re-established before the commission can be regenerated.
@Daniel-Melian we've identified the same issue in these days, we're working on a fix that you can then fw-port to 16 |
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.
Please include this fix: #575
Currently translated at 11.5% (3 of 26 strings) Translation: commission-14.0/commission-14.0-sale_commission_partial_settlement Translate-URL: https://translation.odoo-community.org/projects/commission-14-0/commission-14-0-sale_commission_partial_settlement/es/
Currently translated at 100.0% (26 of 26 strings) Translation: commission-14.0/commission-14.0-sale_commission_partial_settlement Translate-URL: https://translation.odoo-community.org/projects/commission-14-0/commission-14-0-sale_commission_partial_settlement/es/
Currently translated at 100.0% (26 of 26 strings) Translation: commission-14.0/commission-14.0-sale_commission_partial_settlement Translate-URL: https://translation.odoo-community.org/projects/commission-14-0/commission-14-0-sale_commission_partial_settlement/it/
If the invoice line agent does not have any settlement
/ocabot migration sale_commission_partial_settlement |
Hi @francesco-ooops @Daniel-Melian ! I have made the changes related to the fix you mentioned, if you can check that everything is correct. Thanks! 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.
@dalonsofl I have reviewed the changes, and indeed it is now regenerating correctly.
Thanks!
@dalonsofl I am seeing some strange conflicts when rebasing this branch locally on |
@dalonsofl can you remove the extra modules from this PR? |
62e5667
to
a3b8eb5
Compare
Hi @francesco-ooops @SirAionTech ! I think it should be resolved by now. Regards |
@dalonsofl I don't think it's correct to include the fix applied in #575 in the migration commit, wdyt @SirAionTech ? |
a3b8eb5
to
3eca214
Compare
I haven't looked at the new code yet, so I can only say that generally the migration commit should only contain what is needed for the old module to work in the new version. |
So, because this reason, it makes sense the fixed applied in #575 is in the migration commit because it is necessary for worlking properly, isn't it? |
You probably should cherry pick it
Il gio 19 dic 2024, 13:28 David Alonso ***@***.***> ha
scritto:
… @dalonsofl <https://github.com/dalonsofl> I don't think it's correct to
include the fix applied in #575
<#575> in the migration commit,
wdyt @SirAionTech <https://github.com/SirAionTech> ?
I haven't looked at the new code yet, so I can only say that generally the
migration commit should only contain what is needed for the old module to
work in the new version.
So, because this reason, it makes sense the fixed applied in #575
<#575> is in the migration commit
because it is necessary for worlking properly, isn't it?
—
Reply to this email directly, view it on GitHub
<#561 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANHLKUOUUDMM7BRL7ZMONTD2GK3WBAVCNFSM6AAAAABOBAUED6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJTGY4DOMZXGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
No because the fix in #575 is not needed for the module to work in A migration from
The full description of what should be done, and how, is in https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-16.0. |
Migration from version 14.0 to 16.0