Each qty of a line in the BOM Structure report must be computed in
the uom of its BOM line.
Example:
With 2 products: A, B
BOM A: 100 kg of A is produced by 5t of B
So 1kg of A needs how many t of B ?:
In the code:
qty_per_bom = 100 kg expressed in the uom of B => qty_per_bom = 0.1t
qty = 1 kg expressed in the uom of B => qty = 0.001t
l.product_qty = 5t
qty of B = (l.product_qty *qty)/ qty_per_bom = 0.05t
opw:697502
Before this commit, the pager counters and buttons were at the same
level, and could not be styled independently (with some rules such as
nowrap).
Close PR #14865
Karma is now displayed on preference view. Also,
add a empty group to allow other module to set their
preference parameters on this form view.
Little big details are important !
Due to an error introduced when migrating the module at new API
at commit a4e57ea16c limited attendances
having date_from and / or date_to were not correctly taken into
account.
Tests have been added to avoid regression.
Give some details about the badge: its description, its image, who granted
it, ... Otherwise it is quite complicated to understand the email content.
Thanks to @mart-e who reviewed and tested.
Posting on a document not inheriting from mail_thread was impossible
due to several crashes or wrongly set variables. Some cleaning is planned
in those methods as there are a lot of unnecessary computation. This will
be done in another commit. Probably.
You may want to send emails related to a document not inheriting from
mail.thread. In that case we have to use the default computation of
reply_to and not call a method defined only if the model inherits
from mail.thread.
Group-based channels automatically add people belonging to user groups to the
channel. If a member leaves the channel he will be automatically added back
by the channel automatic subscription. This generates unnecessary changes and
messages in the channel.
We now prevent people from leaving group-based channels. All group members
have to be channel members. Unsubscribe buttons are therefore removed for
those channels.
Commit d861cdc1c4 introduced the tax group feature. The tax line
details were removed from the printed invoice in favor of the tax group.
However, it requires that all tax groups are correctly defined in the
localization, otherwise the printed invoice doesn't show the required
tax details.
The correct fix, which is the complete definition of the tax groups,
will be done for the upcoming v11 version. In the meantime, this simply
introduces back the tax details table.
[IMP] revert a serious usability issue: people creating an address can
not select a state: it's weird to have to set the country first.
This reverts commit 24aba6014c.
In multi-company:
- Create 2 companies A and B
- Set the superuser on company B
- Set the website on company A
When a SO is generated from the eCommerce, it is defined on company B,
while it should be on company A.
opw-695253
from odoo#14848
Those subscribed to the department of the employee didn't get notified when
the employee encoded a leave.
It was due to the department_id not being given as value in create when the
employee made the leave.
This is because there's a group group_hr_holidays_user on that field in the
view, so only when they created a leave the followers would be added correctly
(as department_id was given as value in create).
This commit also remove the useless subscribe_followers method.
With Company A (Warehouse Wa) and Company B (Warehouse Wb)
When making inventory adjustments for Warehouse Wb in company A,
the inventory lines displayed must only be the lines of the company A in
the Wb.
In this way, the user avoids confusion with the adjustments he is creating.
opw:697182
When making an inventory adjustments in multi company, the company field
must be set according to the location_id set. In this case, it avoids creating
by default different inventories for the same warehouse.
opw:697182
This is related to revision dfcc0c40b1
If the invoice line provided the amount currency, but
set to False, the amount_currency must be computed anyway
opw-702045
When selling in a foreign currency,
A double currency rate change, one in each way, was applied when creating the good cost
move line of the invoice, which leaded to some precision loss when the decimal accuracy was
set with a number of digits greater than the currencies digits rounding
e.g.
Product cost price: 52.56422
CAD to USD rate: 0.7383
The product cost price is always in the company currency
while `_anglo_saxon_sale_move_lines` always returned the price
in the currency of the invoice. A first conversion rate was applied
from the company currency to the invoice currency.
52.56422 * 0.7383 = 38.808163625999995, rounded to 38.81
Then, when validating the invoice, and creating the move line,
the price was then converted again, to the company currency,
as the debit/credit of a move line is always in the company currency:
38.81 / 0.7383 = 52.566707300555336, rounded to 52.57
The cost price of the product in the good cost move line was therefore
set to 52.57, insteaf of 52.56, because of this precision loss.
With this revision, we avoid to do the currency rate conversion
two times, in both ways, to avoid the precision loss.
opw-702045
Christophe Simonis