- Create a promotion of discount 10% with coupon (A)
- Create a promotion of fixed discount (50$) with coupon (B)
- Create a sale order of 50$, apply A and then B
Order will have a negative total.
This is due to the check done on the order amount, which needs to be
checked without the current program, to allow correct stacking of
promotions
opw-2410666
closesodoo/odoo#64848
X-original-commit: 22598c88638aaa2570c88f5bdf01d185abadd086
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Create four promotion programs:
if the order > 1500 than 10% discount
if the order > 1750 than 15% discount
if the order > 2000 than 20% discount
if the order > 2500 than 25% discount
Take a product with a price of $300 and add 5 to cart > the 10% discount
is correctly applied.
Add 1 more product (6) > it should now qualify for 15% discount, but it
stays at 10%
Add 1 more product (7) > it (correctly) gets the 20% discount
The 25% discount does not get applied until 11 of the product is in the
cart, even though it should qualify at 9
If you then decrease the quantity, the right discount will
sometimes display.
This occur because when the order amount change and the new total is
used to match the right promo the previously applied discount is not
removed from the amount.
This occur as side effect of
1d59785 in which the amount has to be
kept in order to avoid discount line removal on cart update.
opw-2285656
closesodoo/odoo#54400
X-original-commit: 28c099e6d5b02518b6b5a0be66b2b74a57f0c936
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Create a promotion program with conditions:
- Minimum product quantity (ex 2)
- Minimum purchase in currency (ex 500$ tax excluded)
- Auto apply
- On current order
- with reward:
-- Free product (Free Prod A)
-- 1 Quantity
Create a sale order. Insert 3x ProdA @ 1000$. Click on "promotions".
Nothing will occur because the minimum order amount for applying the reward is
calculated removing from the order the product associated with the
reward. This removed all of the products from the order, so the result is 0.
Fixing by subtracting just the amount specified in the reward program.
opw-2274316
closesodoo/odoo#53407
X-original-commit: 804461fb1353c931986eeae94bd3ad8465b604e7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This refactoring extracts parts of `sale_coupon` module to create a more
generic module called `coupon`. This new module can be extended in
different sales modules to implement functionalities specific to modules
that extend it.
Create a coupon program with:
- Minimum purchase in currency (ex 100$ tax excluded)
- Fixed discount applied on order (ex 100$)
Generate some coupon.
Go to shop. Fill an order with amount slightly above the minimum
required by the coupon (ex. 125$). Apply the coupon.
Nothing occur to the cart: the coupon is applied correctly,
but when the cart is refreshed it will check for any non-applicable
promotion against the current order state (125$ - 100$ = 25$, since
the coupon check is for orders above 100$ the promotion will be removed).
Fixing the condition in '_get_no_effect_on_threshold_lines' to detect
also coupon lines in order to make the fair computation.
opw-2224169
closesodoo/odoo#50694
X-original-commit: 2f733ba85320dd67c6892f6a56e3680a3b2fbb50
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Before this commit, a discount could only target the whole order, the cheapeast
product or a specific product.
With this commit, it becomes possible to select multiple specific products.
This will ease some realistic ecommerce flows.
For instance, one might create a promotion targetting all his bikes by simply
adding all bikes products into the specific products field. This is easily done
with the many2many widget on the form view.
task-33737
closesodoo/odoo#35500
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Pratima Gupta <pgu@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Commit b62ebab58 refactored "all the brol" but left half the occurences
untouched.
It was therefore hard to read and understand the tests as the same items would
be referenced with 2 names.
Purpose
=======
Fields `customer` and `supplier` on `res.partner`
are mostly used in domains of many2x fields.
Those domains can confuse end users because they don't
see the partner they are looking for; and it's not obvious why.
Some identified problems:
1. It can lead to duplicated partners: the user does not find
the partner, so he creates a new one.
2. The user imports supplier contacts in the Contacts app, so they
don't get the `supplier` flag. Then the user wants to make a purchase order,
and cannot find the new suppliers in the list
3. A user removes the customer flag on a prospect, because they don't think
it's a customer yet - except now they can't make a quote for that customer...
Specification
=============
Remove the two mentioned fields.
Since fields `customer` and `supplier` have been removed, all partners
are now shown in many2one dropdowns.
But in some cases, not all partners are relevant or some are more likely
to be relevant than others. e.g. when creating a PO, top suppliers have a
higher priority than other partners.
So, adapt the places where those fields were used with the new mechanism to
display the searched the partners, according to the number purchase/sales
orders they made.
TaskID: 2031147
Co-authored-by: Yannick Tivisse <yti@odoo.com>
- Add repartition lines on taxes
- Link account tags directly to account.move.line; remove the tag_ids field from account.tag
- Add a new report engine dedicated to tax reports, directly generating account tags. It is called as an alternate mode of generic tax report, with a dedicated "Use tax grids" toggle.
>> The biggest change lies in the way the new tax report computes its values.
Everything is now aggregated directly using the tags set on the account move lines. Thanks to that,
modifying the configuration of a tax today will not impact the report for the previous periods anymore.
This is a big improvement, as it means the report will keep on reflecting the values that were submitted
to the state before, whatever the configuration change.
- Add an audit char field to account.move.line telling with tax grids are impacted by the line, with the corresponding amount
- Modify the behavior of cash basis taxes: the cash basis account is now used as the transition account, while the regular account given in tax declaration is used to store the final entry (it was the opposite before)
- Modify every l10n_* module in order to keep them consistent with these changes
closesodoo/odoo#32833
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Andrea Grazioso (agr-odoo)