-
Notifications
You must be signed in to change notification settings - Fork 17
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] pos_customer_wallet #300
base: 16.0
Are you sure you want to change the base?
Conversation
06ace62
to
1109db1
Compare
1109db1
to
afb08db
Compare
Codecov Report
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. @@ Coverage Diff @@
## 16.0 #300 +/- ##
==========================================
- Coverage 97.73% 94.52% -3.22%
==========================================
Files 12 26 +14
Lines 221 347 +126
Branches 30 39 +9
==========================================
+ Hits 216 328 +112
- Misses 1 15 +14
Partials 4 4
... and 5 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
….config Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
…t payment method Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
…stead of settings Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
…ines This does not yet live-update in the POS. The window needs to be reloaded to see the updated balance. Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
… balance Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
…ner._invoice_total algorithm Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
…r account is set instead Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
…ly tree Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca BAKKER <[email protected]>
…thout perms Previously there was a permission error on trying to read the `account.bank.statement.line` model. Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca Bakker <[email protected]> Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Is it ready to review ? |
@legalsylvain yes, i think! |
Problem found during functional testing: The balance is not reduced when making POS payments with the child of a partner. Needs further investigation. |
Ignore previous comment. I was testing the wrong payment method ('Customer Account' instead of 'Customer Wallet') I did find another bug, though. After closing the session, all changes to the customer wallet balance disappear, as if the POS session never happened. |
Interesting. The account.move.lines generated by closing the POS do not contain partner_ids. This is going to be painful to research. |
Hi @carmenbianca. Thanks for porting this module. Just did some tests. Globally it works ! Regarding your problem.
It is partially wrong. for the payment account move, if you check the checkbox split_transactions AND set the outstanding account : it will :
Ex : payment of 5€ with wallet : BUT : if you sale "wallet product", AFAIK, the account move does'nt contain the partner, if it is not possible to credit the wallet, saling wallet in the PoS. Ex : credit 999€, saling wallet product : Do you know how we could fix it ? |
|
||
const WalletPaymentScreen = (PaymentScreen_) => | ||
class extends PaymentScreen_ { | ||
/* eslint-disable no-unused-vars */ |
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.
/* eslint-disable no-unused-vars */ |
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.
This is needed to satisfy eslint regarding the isForceValidate parameter. It's not smart enough to recognise that await super.validateOrder(...arguments)
implies the use of isForceValidate.
* @param {Boolean} isForceValidate - Passed to super. | ||
* @returns {Boolean} Whether the order is valid. | ||
*/ | ||
async validateOrder(isForceValidate) { |
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.
async validateOrder(isForceValidate) { | |
async validateOrder() { |
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.
It doesn't seem right to me to adjust the function signature.
* @returns {Boolean} Whether the order is valid. | ||
*/ | ||
async validateOrder(isForceValidate) { | ||
/* eslint-enable no-unused-vars */ |
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.
/* eslint-enable no-unused-vars */ |
if (payment_lines_qty > 0) { | ||
this.showPopup("ErrorPopup", { | ||
title: this.env._t("No customer selected"), | ||
body: this.env._t( | ||
"Cannot use customer wallet payment method without selecting a customer.\n\n Please select a customer or use a different payment method." | ||
), | ||
}); | ||
return; | ||
} |
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.
useless in V16.
check payment_method.split_transactions
will do the job.
Thanks for the tip on
I've been looking at this for a while. I'm not sure what a good solution is. When closing the session, it correctly gets the income account from the wallet product for each pos.order.line that sells a wallet product. However, the amount for every such pos.order.line is eventually accumulated/aggregated into a single partner-less account.move.line on the session's account move. There exists no Furthermore, the session's account move is on the POS journal, not on the customer wallet journal. If we were to succeed in splitting the lines on the session's account move, we might still run afoul of some expectations made in account_customer_wallet. Trivially fixed, I think, but important to keep in mind. Some solutions that I can think of, but haven't thought through:
I will expand later. |
Now is later. All three options proposed above have some flaws. A full example. Find below the account.move of the POS session, where Alice bought 800€ of wallet product, and Bob bought 200€:
Option 1: Split on the pos session's account moveI've explained the flaws of option 1 fairly well. The account move is on the wrong journal, retroactively editing a closed account move seems like a bad idea, and there are no good hooks to make this happen. But if we did make it happen, we would turn the example account move into this:
Option 2: Do creative accounting after the pos session closesOption 2 is fine-ish, if a little verbose and difficult to retroactively comprehend. You have to undo the account.move.line against the customer wallet account and create new per-partner lines. Given the example, we would create one or two new moves that look a little like this: Two moves against a temporary account
and
One move against the wallet account itselfNot sure if this is possible.
Option 3: Compute the balance from pos orders; don't touch the account moves any furtherOption 3 seems fairly easy, but I'm not certain it's a good idea. One ramification is that you cannot uninstall But overall, I just feel like it would be (mis)using pos orders for the wrong purpose. |
Thanks a lot @carmenbianca for all the investigations !
I'm not sure. for me saling wallet product should go in sale journal. Don't you think ? I'm pretty sure it is the current behaviour in v12. Regarding option 2, I think writing a single extra account move is OK in a accounting point of view. For the time being, I think option 1 has my preference, but I read the code that prepare the account move lines, and it is just horrible. ;-) So maybe option 2 will be mandatory. What is your deadline for this developpement ? we could make a little code sprint during the oca days? regards. |
@legalsylvain We can definitely sprint on this at OCA Days! I agree with you on option 3. |
@legalsylvain I wrote an implementation for this finally! It was tricky to get right, but it implements option 1. It needs heaps more tests before this can be merged, but I thought I'd notify you. |
228bd28
to
7f85b83
Compare
base_suspend_security's functionality is wrapped into Odoo's sudo by default
This change was also done in account_customer_wallet. It simplifies things. This change is necessary for the 16.0 migration, but is not included in its commit for clarity's sake. Signed-off-by: Carmen Bianca BAKKER <[email protected]>
…t computation The pos session does not create these anymore. It creates pos.payment records instead. Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca BAKKER <[email protected]>
…ssion Signed-off-by: Carmen Bianca BAKKER <[email protected]>
…wallet products Signed-off-by: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca BAKKER <[email protected]>
7f85b83
to
dcf77e8
Compare
I have to review this one ! thanks for the ping ! |
@carmenbianca à combien d'heures estimes-tu la finalisation du portage ? |
Description
Odoo task (if applicable)
https://gestion.coopiteasy.be/web#id=10799&action=475&active_id=492&model=project.task&view_type=form&menu_id=536
Checklist before approval