The fields containing the quantity of product doesn't display numbers
over 999 correctly: only 3 digits display in the field.
We add a specific class `quantity` for input fields, with a padding of
zero. The class `js_quantity` is not used since it is linked to jQuery
events.
opw-727640
opw-725671
The type of account Vorsteuer 2500 is Non-current Assets(like in l10n_be).
In this way, the amount due will include the taxes Vorsteuer 10%
and Vorsteuer 20% when computing the amount due with _compute_residual
because the account is not receivable or payable.
opw:725619
- Set discount policy: Show public price & discount to the customer
- Set a product with 100% discount
When added to a SO, the product discount is 0 %.
opw-727519
This is needed in order to clear the 'unreconciled payments' in the bank statement reconciliation report when you wrongly encoded a bank statement and reversed it.
This patch goes along with the modification of the bank reconciliation report in enterprise to exclude such 'reconciled' lines.
- Update Cart Quantity when 'add to cart'
- Change usability for b2b/b2c add/move to cart
- Disable 'add to wishlist' if already in wish list
- Wait the commit of 'Move to cart' of the last item
before the redirect to avoid to get a fake empty cart.
- Reset red notification after a small delay
- Fix 'list of variants' optional feature (broken by commit 045a859)
- Adjust animation to match cart/wishlist
- Fix button cart / wishlist / comparison order
- ...
Courtesy of @adr-odoo for testing
In case of error, paypal return some lines where error message and not a
string with 'key=value'.
This commit fix traceback:
ValueError: dictionary update sequence element #0 has length 1; 2 is required
In monetary field refactoring (3407fb70e4) there was a small issue that
made context lost so the language use to render the field could be
different from the one to render the view.
For example: if the user has english, and print a report using the lang
of a partner in language spanish, the report would use spanish to format
number for all fields but monetary (which would use english).
opw-708197
In case a product is a single variant we should not leave it with a BoM
of zero as soon there is a BoM for its template. This would for example
hide the `compute_price` object button which relies on the `bom_count`to
be visible.
BoM is not found for a single variant product and compute price not
possible from the `product.product` view although it is implemented
actually there.
Closes#16237
- Create an invoice of 10000 at date 2016-11-30, due 2017-02-28
- Make a partial payment of 1500 at date 2016-11-09
- Make a partial payment of 1000 at date 2016-11-30
- Make a partial payment of 2000 at date 2017-01-30
At current date (e.g. 2017-04-04), run the Aged Partner Balance. 5500 is
still due, but set to the +120 days period instead of 30-60.
opw-725890
The call of the name_get on records with falsy ids was unnecessary
as it wasn't used afterwards and could lead to errors if a name_get
doesn't handle falsy records.
solves https://github.com/odoo/odoo/pull/16244
The constraint should only check for move lots with a lot number already
filled in. Indeed, in case we use work orders, we can potentially create
move lots without S/N, and fill in the S/N later.
opw-727679
Create a product P with a price = 1799
Make a pricelist P1 in USD with an item I1 for a product P with a
fixed price to 100.
Set P1 with discount_policy = "with_discount"(include in price)
Make another pricelist P2 in USD with an item I2 based on P1.
I2 is a formula = 50% of the price
Set P2 with discount_policy = "without_discount"
Create a SO with P2 for the product P
Bug: The subtotal of P is 899.5 instead of 50
The problem came from _get_display_price wich in this case recomputed
the price according to the discount(in this case equal to 50% and this is
the good discount to display because P1 include the discount) and the lst_price
of the product(=1799) So the displayed price was equal to 899.5 instead of
50.
All the other cases worked because
1. P1 without_discount and P2 without_discount:
Price returned by _get_display_price was equal to 1799 with a discount of 97,2%
So the subtotal was equal to 50
2. P1 without_discount and P2 with_discount:
Price returned by _get_display_price was equal to 100 with a discount of 50%
So the subtotal was equal to 50
3. P1 with_discount and P2 with_discount:
Price returned by _get_display_price was equal to 50 with a discount of 0%
So the subtotal was equal to 50
And the last case(P1 with_discount and P2 without_discount) didn't work because:
Price returned by _get_display_price was equal to 1799 with a discount of 50%
So the subtotal was equal to 899.5
NB: The subtotal is computed with function "_compute_amount" with the following line:
price = line.price_unit * (1 - (line.discount or 0.0) / 100.0)
opw:724924
- Create a kit (phantom BOM), composed of 2 different products A and B
- Create a SO, sell a random stockable product, confirm and validate the
picking.
- Edit the SO, add the kit and save.
Two pickings are created, one for product A and one for product B.
Commit 8fe8ca9948 forces the recomputation of the stock moves, in order
to be able to find a newly created picking. This should actually be done
after each picking creation.
opw-725929
When getting the default sales team, we could get erroneously the
team of another company (either because the use is in a team of another
company or the default sales team was in non-bethren company).
This fix when searching a sales team:
- search only teams the user should see (with access rules)
- make default teams "Website Sales" and "Direct Sales" not restricted
to one company (and it's ancestors).
opw-726461
When the quantities on a purchase or sale line decrease,
the amount of the receipt or delivery order is not adapted.
Also, when the quantities increase, it is good to follow it up.
That is why, when we change some quantity, a message is
posted in the chatter of the purchase/sale to indicate about
the change. There is also a message when you add a new line.
In 9.0 in some particular instances with embedded views, if:
- an x2many list view is editable,
- we go from a form view of an existing record to creating a record,
- the timings of deferred resolving are in a certain order
the x2many list view could be tought as loaded whilst in reality it is
the 'editable list view' row editing 'form view' that has been loaded.
This could cause sometimes issues after bc031379 because the onchange
computation would happen before the list view is really loaded.
This is probably an issue with the deferred system in one of the views,
but it would be rather hard and dangerous to change it.
So this fix introduce an additional test which ignore relational views
if there is an embedded view.
opw-726701
opw-726768
note: only needed for 9.0, the relational views have been changed as of
saas-11 and this issue is not present.
When grouping by a field datetime in kanban view, the name of the
column is an abreviated datetime. Afterwards, when making a quick
create, the abreviated datime was set in the context and
used as default value. So it raised a tracebacks because the value
of the datetime was not in the correct format.
Now it's only possible to make a quick create if the type of the field grouped
is a char, a boolean or a many2one.
opw:727266
Wrong event category field was used leading to an incoherent feature.
This commit also improves event form view to add an '#' before the
hashtag field so that users understand they don't have to put it.
Currently line was incorrect as the purpose is to ensure all lines of
the scheduler are sent. Currently not send lines are filetered and therefore
not taken into account. This commits fixes it.
lap-odoo