Saturday, September 26, 2026
2 changes · saas-19.4
Resolved issues and error corrections
Fixed an issue where certain Point of Sale promotions could apply less discount than intended when an order included both taxed products and negative-priced lines. Customers are now charged the correct amount because reward lines add up to the full discount.
Original PR description
Steps to reproduce: - Product A with a price-included tax, product B with a negative price and another tax (or none) - Promotion with a fixed amount discount on specific products (or on the order),…
Steps to reproduce: - Product A with a price-included tax, product B with a negative price and another tax (or none) - Promotion with a fixed amount discount on specific products (or on the order), both products eligible - Add both products to a PoS order Issue: The discount is split per tax group with a common factor, so the negative line gets a positive reward line, which is expected. But the reward lines add up to less than the discount and the customer pays too much. Cause: Since 7280f3597ece each tax group is capped with `Math.min(get_total_with_tax(), amount)`. A single tax group is compared with the total of the whole order: here the total includes the negative line, so the positive group is lowered while the negative one is kept as is. Fix: Apply the cap proportionally: every tax group is scaled by the ratio between the order total and the discountable amount when the total is lower. The scenario of 7280f3597ece gives the same result, and the reward lines add up to the discount whatever the number of tax groups. opw-6567973 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288985 Forward-Port-Of: odoo/odoo#288853
Refund lines without a product now suggest the correct type of account based on whether the document is a customer or vendor transaction. This prevents income accounts from being suggested on vendor credit notes, and expense accounts from being suggested on customer credit notes, reducing accounting entry mistakes for contacts used as both customers and vendors.
Original PR description
Before this commit, when adding a line without a product to an invoice or credit note, `_get_most_frequent_account_for_partner` picked the partner's most-used account, filtered to an income or…
Before this commit, when adding a line without a product to an invoice or credit note, `_get_most_frequent_account_for_partner` picked the partner's most-used account, filtered to an income or expense account depending on `get_inbound_types` and `get_outbound_types`. Those helpers classify move types by cash-flow direction which is correct for choosing a receivable and payable account but wrong for choosing an income ro expense account: they group `in_refund` with `out_invoice` as "inbound", and `out_refund` with `in_invoice` as "outbound". As a result, a Vendor Credit Note line with no product would be filtered to income accounts instead of expense accounts, and a Customer Credit Note line to expense accounts instead of income accounts. This only surfaced for contacts who are both customer and vendor, since the query needs matching history to return a result; otherwise it silently falls back to the journal's default account, masking the bug for ordinary contacts. This commit uses `get_sale_types` and `get_purchase_types` instead, which classify by document side, sale vs. purchase rather than cash-flow direction, matching the classification already used for product-based lines `is_sale_document` and `is_purchase_document` opw-6373124 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278794 Forward-Port-Of: odoo/odoo#276846