Before the fix, the picking used to create the new stock moves resulting
from changes in the purchased quantity is simply taking the first
available picking of the Purchase. This causes problems when you handle
Purchase Orders with multiple open pickings, as the correct picking to
use when the quantity is updated is not always taken.
After the fix we give priority to evaluate open pickings already related
to the line we are updating. We fallback to the same behaviour as before
is none is available.
closesodoo/odoo#161721
X-original-commit: b3335566a878fd2df29ff02023033acd3cabef70
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before the fix the check function is assigned a boolean, which causes an
error when trying to call the function.
After the fix the result of the check is returned.
closesodoo/odoo#139407
X-original-commit: ea2798c5893373d79f70959e4501d0eef4f964b7
Signed-off-by: William André (wan) <wan@odoo.com>
The current behaviour does not filter the cancelled moves when
evaluating if the product of the purchase order line is a kit.
This causes that, in cases where you have a cancelled wrong receipt
where the product was being received as a kit, if a new receipt is
created without receiving as a kit Odoo will always expect it as a kit.
After the fix, the cancelled moves will not be considered, as this is what
should be expected from cancelled operations.
closesodoo/odoo#107144
X-original-commit: 9659683d1f09c49a3ba3df8770eb7256660d0033
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When executing the product2bom method it is possible that an active_test
context is present in self. However, the method should not consider
archived BoMs.
closesodoo/odoo#104919
X-original-commit: a5f923859fad37e1fc52a3a4bcce5cce4cf69c87
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The parent method _get_computed_account in the account module it already forces
the company to get the correct account, but in the stock_account module the method
is overriden when dealing with anglo-saxon accounting. In the latter, the company
is not being forced, so it leads to multi-company errors.
The fix simply enforces the correct company to prevent the error.
closesodoo/odoo#75747
X-original-commit: beba7c5b377e5aaf5ccb1d52e6b8c3bcf49468d3
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Currently, the default invoice origin for the sale action_view_invoice
is being passed as a list by using the mapped method. This causes that,
when an invoice is created from this view, the origin is set to ['SOXXXXX'].
With the fix, we properly pass the origin as a string so the origin is set
as SOXXXXX, which should be the expected. Notice also that the context is
only passed when dealing with a single SO.
closesodoo/odoo#74579
X-original-commit: 3ad1310eb88581333bb8ccb28b859abcbadabe42
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The current behaviour does not filter the cancelled moves when getting
the related BoM. This implies that, if a new BoM is created for the
same product but with some changes, and the original delivery is cancelled,
the sale order line will still consider the previous BoM.
This causes that the relevant_bom ends up having more than one BoM, which
should not be the expected result.
After the fix, the cancelled moves will not be considered, as this is what
should be expected from cancelled operations.
closesodoo/odoo#74266
X-original-commit: 1e2feaa2851fa07018b912e6536585998487b5ab
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The current behaviour implies that the quantity delivered will never
be updated if there are related moves that have been cancelled.
After the fix, when computing the quantity delivered, it will only
consider the stock moves that are not cancelled.
closesodoo/odoo#73573
X-original-commit: 6f6366888415c5e020ffee893a78cc7a3f6925f5
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When updating the quantities available for a product, an inventory move
is generated without setting the product_tmpl_id, as this field is related
to the product_id of the move. However, when creating the move, Odoo will
consider it a default missing value and will try to fill it in the method
default_get.
When navigating to the product variants of a template from the template form,
a default_product_tmpl_id is set in the context pointing to the template. This
context is propagated to the update quantity action to create/update quants for
the variant.
The problem when dealing with kits is that the products available to update
their quantities are the components of the kit. When navigating to a variant
and updating the quantities of a component of the kit variant, the default product
template in the context will be the kit template.
This is causing that, when generating the inventory move, the move is created with
product_id of the component, and product_tmpl_id of the kit template.
This issue creates a critical data inconsistency as the component's template is set
to the kit's template, which apart from making no sense generates a recursion error.
To fix this, when triggering the action to create/update quants for a kit product, it
must be ensured that no default product template is being set.
closesodoo/odoo#71069
X-original-commit: bdeea73dc1efb6ff7d02cc2f58347a69762bcc3c
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Currently, the quotation amount field added in the CRM Sales Teams Kanban view is overflowing the kanban card once the number is too large.
The fix adds the class text-truncate in the corresponding div to avoid the overflow. Notice that this class is the one already used in the parent view implemented in the CRM module, for the other amount fields.
X-original-commit: 14915f4b6a12bbd4882db5af229fb97be3dd52e9
JordiMForgeFlow