- Create a tax using the tax template 'GST + QST for sales'
- Create a SO with the following lines:
Product 1 100 Units @ 0.1
Product 2 2000 Units @ 10.334
Product 3 2000 Units @ 10.334
Product 4 5000 Units @ 0.1
Product 5 1500 Units @ 0.1
- The totals are:
Amount without taxes: 41996.00
Taxes: 6288.90
When printed, the quotation gives:
Amount without taxes: 41996.00
Taxes: 6286.52
This is due to the method `_get_tax_amount_by_group`, which is using
`line.price_reduce` for tax computation. Since it is a Monetary field,
it is automatically rounded to the currency precision, while it should
be rounded with the same precision as `price_unit`.
To avoid breaking overrides, changing the field type is done in master
branch.
Introduced in 99743cc4aa
opw-752487
This fix previous commit a29f7f671b.
(1) Some objects have no color field.
(2) There was an issue when two many2many tags were instantiated:
If the first one had the 'color_field' attribute the second one
had it too even if this attribute weren't specified.
Now, it's fixed in data_manager
The field 'payment_acquirer_id' is added on the sale.order model
in the website_sale module, which may not be installed when this
code runs since it is higher up in the dependency tree.
Either way, it's quite convoluted to go fetch the acquirer on the
quote since it's already available on the transaction itself anyway.
opw-755998
Before this fix, the base64 image are remove and never send. The images
were in the body increasing the size of the database unnecessarily
(cfr some odoo users with the chatter)
NB: According to the prophecy Khoi will come and dominate the world,
ask him anything
The old behavior was to call wkhtmltopdf for each report and to put all of them together
using the merge_pdf method. It was a very slow approach because all report needs
5 temporary files, one subprocess and then, a merge.
The new behavior is to perform a single call to wkhtmltopdf by putting all the footers/headers
html together and so, avoid call to merge_pdf to greatly improve the performances of the reporting.
The state of the search bar (expanded or not) is supposed to be saved
into a local storage variable which is retrieved whenever loading a view
that has the search bar in it and it is expanded automatically if it was
done previously in any other view, this didn't happen previous to this
commit because the variable wasn't being set properly (missing key).
Some reports require additional information to render. When
accessed in Odoo, the user has to fill a wizard to provide those
information. However, when these reports were opened in Studio,
it crashed as those information were missing (we don't pass
through the configuration wizard in this case).
This fix checks if all the required information are given before
trying to render those reports, and it displays a warning in
the logs in they are missing, which is better than a traceback.
backported in v10 for opw-753036
Steps to reproduce:
-Create a PO with two lines L1 and L2
-L1 has product P with qty=10 for a scheduled date=23/07/2017
-L2 has product P with qty=10 for a scheduled date=30/07/2017
-Confirm the PO
When delivering 5P of L1, the scheduled date of the picking is the
right date which is 23/07/2017
But when delivering the other 5P of L1, the scheduled date of the
second picking was 30/07/2017 instead of 23/07/2017.
opw:752192
Before this revision, multiline links in form views had a different
colour depending on whether we were editing a record, or merely
viewing it.
As an example, the 'customer' field (containing both the name and the
address) in the form view of 'invoice' is affected. When editing the
invoice, all lines have @link-color as colour. However, when viewing it,
only the first line does, while the address is in @odoo-main-text-color.
Since f963500a9f, users of the ecommerce
were able to select carriers even if they actually were not shipping to
their address.
Also, using an integrated carrier (eg: Fedex) caused a crash at the
payment page.
With this commit, delivery price is now computed only on the payment
page and when selected.
Editing the cart after selecting a delivery method will now be much
faster, since delivery prices are not recomputed anywhere else than on
the payment page
(we also fix minor CSS and JS issues)
The module is described in either static/description/index.html, either in
README.md file.
It is ok to have both README.md and index.html as index.html is for a formated
description and README.md is displayed in github
e.g. https://github.com/odoo/odoo/tree/10.0/addons/stockCloses#18036
This commit aims to replicate saas-15 behaviour when adding columns in
a Kanban view by not folding the column quick create widget when
creating a new column, thereby allowing users to add multiple columns in
one go.
Following the previous commit, it appears than the scrap mechanism needs
some rigorousness when looking for quants characteristics (i.e. if we
look for a quant without `lot_id`, it should not return one with one)
but some flexibility with the location (i.e. we can look in sublocations
to find one with the given characteristics).
Before this commit, we centralized everything related to quant's search
in stock_quant.py and the `_gather` method, which has a `strict` kw. As
we exposed the `_get_quantity` method but is only used in stock_scrap,
and that the `strict` flag does not fulfill the needs of stock_scrap, we
inline the appropriate search, as it was done previously.
When updating the quantity on hand in a location without quant but
where one of its sublocations has onee, it will increase the available
quantity in the sub location instead of the defined location.
This happens because _gather method in quant search on child_of location
in any case.
This commit change the domain by using '=' on the locations if `strict` is
passed as True in _gather, or 'child_of' if it is set as False. It also
removes the strict argument on _update_avaible_quantity since it does
not make sense to change the quantity on an undefined quant. And it was
never used in our code for good reasons.
A previous revision[0] forbid to scrap consumables. The rationale at the
time was that, since consumables do not have quant, scrapping them does
not make sense. It appears that people use this feature on consumable
for traceability reason, so we bring back the old behavior.
A slight change was done in stock_scrap.py: if the product is a
consumable, do not raise the error if the quantity to scrap is not
available in stock for obvious reasons.
Also, a leftover todo in the code indicate that we should unreserve the
any move having reserved the scrapped product. This is actually already
done, since this mechanism is in the move line `action_done` and a scrap
uses a classical stock move and stock move lines.
We introduce some test to prove that it is possible to scrap a stockable
product and the quant are impacted, to scrap a consumable product and
the stock is not impacted and to scrap something that was reseved by a
move and that the move changes its state.
[0] 86f08c091e
PURPOSE
=======
Currently 'Sales Analysis' report have by default group by creation date. here matters if confirmed SO is the confirmation date(for sales commission, etc), not the creation date.
SPECIFICATION
=============
'Sales Analysis' have default group by 'Confirmation Date' instead of 'Creation Date'
PS: Validate 2 SO to have a confirmation date.
When creating a new line in a picking, the initial demand should be 0.
When editing a move line and changning the product, the initial demand
should not be reset to 1.
The rationale is that when creating a picking by hand, most users do
want to skip the reservationm and, by forcing the initial demand at 1,
we force the user to enter to encode two times what he's doing.
The owner was not correctly passed to the move lines, and indeed it was
written as a "to do". So we do it. We correctly indent all the
move_line_ids block and add a testcase.
Before, it was possible to have a move without move line / pack
operations and the `restrict_lot_id` was used in this case. Now, every
move has move lines / pack operations and this field was unused. Let's
remove it.
Consignment worked in backend but there was no
tools in front end in order to use it.
This commit update the views and add consignment in picking
and stock move lines
Purpose
=======
Hidden mode on product attributes (variants) is deprecated
Beforehand it was used to not show the attribute name in the order (in case of single attributes). Now it's automatic: if only one value for a product attribute, this value doesn't show up in the product name.
see support ticket 744129
Specification
=============
remove it
For uploaded modules (e.g. saas), uploaded assets are stored in
attachments.
When the asset content is retrieved, static "filesystem" files are
assumed to be UTF8 and properly decoded, but attachment data is not
and is thus interpreted as ASCII further down the line, leading to a
UnicodeDecodeError (and a broken page/template/...) if the asset data
is not actually ASCII (e.g. if it's UTF-8).
Fix by treating attachment assets as UTF8 encoded, same as filesystem
assets.
OPW-752858
When an order is shipped, a notification email is sent to the customer.
If there is a tracking URL, it is included in the email.
(and also a bit of refactoring)
It was possible to set a payable account for an expense.
So it raised a UserError when reconciling the lines in
function expense_post_payment because two different accounts
were used as payable account.
A expense account is expected as account for an expense.
opw:752695
In an editable list view, the translation icon would display incorrectly
(out of place) for translatable char fields. This can be traced back to
two reasons, compared to saas-15:
- We now use tables instead of divs for list views
- The translate icon would have inline css that would override its
positioning with top and left attributes
This is fixed by adding top and left attributes to translate buttons
inside a field inside a table cell using CSS classes
In the chat, there is an indication of when a message was sent, This indication gets updated as time passes. When the last one in the conversation is updated to an indication that takes more space (e.g. from 'now' to 'a minute ago'), the text below is pushed lower (as expected) but the chatter does not scroll down. As a result, we do not see new messages, unless manually scrolling down.
(PR #17469)
Nicolas Martinelli