Currently on stock moves, product_uom_qty indicates the demand qty
before the move is done and it indicates the acutual done qty when
the move is done.
As a result, when validate a stock move with qty_done !=
product_uom_qty, a new move is always created for the difference.
And the product_uom_qty of the original move will be changed to match
qty_done.
In this commit, we change to that product_uom_qty will always indicate
the demand qty, and qty_done will always indicate actually done
quantity.
To do that, when underconsumption, we won't split the move when no
backorder. and when overconsumption, we will always merge the extra move
back to the original move.
Task-2695732
Part-of: odoo/odoo#130342
entry wrong when resupply subcontractor
In case product is using standard price and automated inventory valuation.
We post account entries in price difference account when the price on
purchase order is different from the cost of product. However, when we
do subcontracting and resupply our subcontractor, the cost is not just
the price on purchase order, but also the cost of the components we sent
to the subcontractor. Currently, we didn't take the components cost in
to account when post price difference entries. Fix it in this commit.
Task-3223451
closesodoo/odoo#132282
X-original-commit: e771535b487e76f4e5a23b767d220d7f640292a6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
Goal:
* Simplified modifiers to only have one way to define modifiers;
* Remove states attributes on python field;
* Use python expression in view `required`, `readonly`, `invisible`;
* More accurate validation of xml views.
This commit change the syntax to python expression. The next commit
will update/convert all xml views.
Before this commit:
* the `required`, `readonly` and `invisible` attributes can only have
values of `True`, `False`, 1, 0 or a python expression to use the
context;
* the `attrs` attribute define a dict. The key of this dict was
`required`, `readonly` and `invisible` and the values are the domain or
a string representing a domain to be evaluate as python expression.
This python expressions was evaluate by the javascript with view fields
and other contextual values as: context, uid, parent, active_id,
active_ids, active_model, allowed_company_ids, current_company_id.
* the `states` attribute in the view was a comma separated list of the
state. This list was combined with the `invisible` attribute;
* the `invisible` attribute on python field is used as default value;
* the `states` attribute on python field was dictionnary with state as
key and list of tuple. This structure was combined with `readonly` view
attribute.
* After combining, the resulting domains of the different attributes
`required`, `readonly` and `invisible` are evaluated with the values of
the fields. The `invisible` attributes is splitted into two use:
`invisible` and `column_invisible`.
After this commit:
* The attributes `required`, `readonly`, `invisible` and
`column_invisible` define python expression. This python expressions
are evaluate by the javascript with view fields and other contextual
values as: context, uid, parent, active_id, active_ids, active_model,
allowed_company_ids, current_company_id.
The domains can contains contextual value and will be evaluate by the
javascript.
```xml
<field name="field_a" readonly="not context.get('show_a')" attrs="{'readonly': [('field_b', '!=', False), ('field_c', '=', parent.c)]}"/>
<field name="field_b" states="draft"/>
```
will be replaced by
```xml
<field name="field_a" readonly="not context.get('show_a') or field_b and field_c == parent.c"/>
<field name="field_b" invisible="state != 'draft'"/>
```
Some inherited views will be modified differently in order to maintain
the previous behavior:
```xml
<field name="field_a" readonly="not context.get('show_a')" attrs="{'invisible': [('field_b', '!=', False)]}">
```
```xml
<field name="field_a" position="attributes">
<attribute name="attrs">{'readonly': [('field_c', '=', False)], 'invisible': [('field_d', '!=', '3')]}<attribute>
</field>
```
will be replaced by
```xml
<field name="field_a" readonly="not context.get('show_a')" invisible="field_b">
```
```xml
<field name="field_a" position="attributes">
<attribute name="readonly" add="(not field_c)" separator=" or "/>
<attribute name="invisible">field_d != 3<attribute>
</field>
```
Validation:
A stricter control is made on the level of the attributes (modifiers)
and the fields necessary for these. The use of the previous attributes
'attr' and 'states' triggers an error (these no longer exist after the
application of the migration script)
task-2495504
Part-of: odoo/odoo#104741
The traceback arises when a user tries to print 'Request for Qutation'
in 'purchase order' after providing 'Incoterm Location' and 'incoterm' value.
To reproduce this issue:
1) Install 'purchase_stock'
2) Open any existing purchase order
3) Click on 'Other Information' and give any value for 'Purchase Location'
4) Select any 'Incoterm'
5) Now print 'Request for Qutation' template
Error:-''purchase.order' object has no attribute 'invoice_incoterm_id''
On 'purchase_report_template' instead of 'incoterm_id', 'invoice_incoterm_id'
is used.
See:-
https://github.com/odoo/odoo/blob/158f8090ef30065b97ebe8b15b0bf73fff6a9ac4/addons/purchase_stock/report/purchase_report_templates.xml#L43-L48
In 'Purchase_order' there is no attribute of name 'invoice_incoterm_id'.
When the user tries to print 'request for Qutaion' and because of
'invoice_incoterm_id' is used, which leads to above traceback.
sentry-4379690422
closesodoo/odoo#132080
X-original-commit: c1daf78d1aa4252bf0f85cd704df0e929062f496
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
Prerequisites -->
1) Login with a user with just Inventory/User access rights
2) Product A with purchase policy set to `on ordered quantities`
3) Product category of A set to `AVCO` costing method
Steps -->
1) Create+confirm a PO with product A and create and confirm vendor bill
2) Switch to Inventory/User user
3) Try to validate picking
4) Access right error
This occurs due to the fact that `Inventory/User` does not have access to s`tock.valuation.layer` or `account.move.line`.
Solution -->
Add sudo to the lines where accesses to SVL and invoice lines are made.
opw-3357028
closesodoo/odoo#130929
X-original-commit: 8d2a77d1bdbe8f865d8f7177801786617e10058f
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
In this commit, _t import from import { _t } from
"@web/legacy/js/services/core" and from
web/static/src/legacy/js/core/translation.js are replaced by
@web/core/l10n/translation.js.
task-3292454
closesodoo/odoo#130865
Related: odoo/enterprise#45270
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Add a new filter to the orderpoints view to allow filtering by vendor.
closesodoo/odoo#101090
Task: 2964309
Signed-off-by: Tiffany Chang <tic@odoo.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Following #127245
It happens because `_should_bypass_reservation` has been removed in 15.0
and only exist on the `stock.move` object and not the `stock.move.line`
anymore
opw-3336131
closesodoo/odoo#129076
X-original-commit: 7e917e8713e246811531f9d7c90395242e544057
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Receiving a kit's component will fail in AVCO + multi-uom
To reproduce:
1. Create a product category PC
- Costing Method: AVCO
2. Create two products P_compo, P_kit
- P_kit:
- In Units
- P_compo:
- In L
- Storable
- Category PC
3. Create a BoM
- Product: P_kit
- Type: Kit
- Components: 1 x P_compo
4. Create and confirm a PO with 1 x P_kit
5. Process the receipt
Error: When validating the receipt, a user error is displayed: "The
unit of measure L defined on the order line doesn't belong to the
same category [...]"
When processing the SM, we create the in-SVL. To do so, at some
point, we need the unit price of the SM, and here is where the error
comes from:
https://github.com/odoo/odoo/blob/708c3d063482e365e49a04f633c83e90e6fa4356/addons/purchase_stock/models/stock_move.py#L39
`self.product_id` is P_component, but `line.product_id` is P_kit,
hence the error with the UoM1
And there will be some similar errors with the `if` block, L40 (we
compare some SM quantities and some POL quantities: we are mixing
components and kit)
For now, in case of a kit, we will always use the `else` block (i.e.,
the unit price of the POL). This will be improved in master
OPW-3357685
closesodoo/odoo#128386
X-original-commit: 3a81eb79cad7f25843315e39da421efa2c34aaf1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
When a RR updates the qty of a POL, the qty to order of that RR will
be incorrect
To reproduce the issue:
1. Create a product
- Storable
- With a vendor
2. Create a RR:
- Min 0
- Max 0
- Factor 1
3. Confirm a delivery with 1 x P
- It should create a PO
4. Confirm a second delivery with 1 x P
- The POL of the PO should be updated
5. Open the Replenishment page
Error: The qty to order of the product is 1 while it should be 0
`qty_to_order` is a computed field and one of the `depends` is the POL
related to the product. This explains why, after step 3, everything
is ok: the compute is triggered (because of the new POL) and the qty
to order becomes 0. However, step 4, the POL qty is updated -> it
does not concern any `depends` -> the compute is not triggered,
hence the error
OPW-3292297
closesodoo/odoo#128279
X-original-commit: 80521431601323c1eb7c85cafbf08e8ae0adbdd6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
On-time-rate is a non-stored computed fields that can take
some time to load because some partners may have lots of
related purchase_orders. The compute function in itself
is relatively difficult to optimize further. This commit
introduces a new system parameter to reduce the timerange of
orders to consider when computing On-Time Delivery Rate.
That way, if for some customers the on_time_rate computation takes too
much time (leading to a slow FormView loading), they can reduce
the accuracy of the estimation to speedup the field's computation.
closesodoo/odoo#128199
X-original-commit: 2e766f11024e9bb905f8e98d7218cf924c43a0c9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Aurélien van Delft (avd) <avd@odoo.com>
Before this PR, the incoterm location was not present in the account module.
This pr does multiple things:
- Add the Incoterm Location field in Accounting on Customer Invoices and Vendor
Bills. The field already exists on Sale Orders and Purchase Orders. When you
create an Invoice from a Sales Order, or a Vendor Bill from a PO, copy the value
of the field on the invoices.
- Update the PDF to display the field value if present, and remove the useless
duplication
- Remove incoterm setting on sale
- Remove useless xpath since now it is displayed directly on invoice when
incoterm field is fill.
Task-id: 3273460
Part-of: odoo/odoo#118954
layer.account_move_id may not be defined on 'manual' valuation.
Use layer.create_date instead which is equal to layer.account_move_id.date.
# HOW TO REPRODUCE:
- Create a product P, storable in AVCO !! MANUAL !!
- Set 'Control Policy' under Purchase to 'Ordered Quantity'
- Create a PO for 10 units of P with for $1 each.
- Create Vendor Bill -> Confirm
- Receive 5 unit of P: Create backorder
- Validate backorder
==>> Traceback
OPW-3383833
closesodoo/odoo#127218
X-original-commit: b1351ee348207283dcdf7118440b31c03f0d0b4b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
If a bill has a price difference with the PO, and if the user
refunds it, it will create some errors in the inventory valuation and
the accounting entries
To reproduce the issue:
(Need account_accountant)
1. Create a product category PC
- Costing method: FIFO
- Inventory valuation: Automated
2. Create a product P
- Type: Storable
- Category: PC
3. Confirm a PO with 1 x P at $10
4. Receive P
5. Bill it at $15
- It should create a price diff SVL, see inventory valuation
6. Refund
Errors: The inventory valuation is not impacted, it is still valued
at $15. Because of the refund, it should be $10 (i.e., the price
difference should be cancelled). Then, suppose the user creates a
new bill at $20, it won't do anything (the stock valuation will not
be impacted).
Long story short: the price difference feature, which is supposed to
impact inventory valuation/account entries, does not work if there
is a (partial/full) refund in the flow.
Now, let's think about a more complicated use case:
- Receive 12 products in several times
- Bill in several times (with different quantities than the receipts)
It could give something like (where `x` are products):
```
SVL01 SVL02 SVL03
/---------------\/---------\/------------------\
x x x x x x x x x x x x
\-----------/\-----/\--/\---------------/\------/
B01 B02 B03 B04 B05
('B' means Bill)
```
We observe that
- a bill could impact several layers
- a layers could be impacted by several bills
And here is the issue: currently in the code, we don't have a relevant
link between layers, account move lines and the quantity that links
both. The only thing we have is a link between the price difference SVL
and the account move line that has generated that SVL (see field
`account_move_line_id` on `stock.valuation.layer`). But this is
clearly not enough and is really problematic: if I refund BILL04, how
should it impact SVL02 ? Then, what if I return a part of the third
delivery before refunding BILL04 ? What if I deliver a part of the
received products before refunding several bills ? What if I refund
B02, B05, then I bill 4 products ?
-> You get the idea: we definitly need a clear link between account
move lines and stock valuation layers and that link has to give a
quantity.
Moreover, it is difficult to create an order between bills. We have
their name, their ID, but the posted time is actually a date. So, if
we mix reset & repost, a draft bill and a draft partial refund, and
so on, and if this mix happens the same day, it is very difficult to
define a clear order. But, considering the above schema, we see that
the order does matter (switch BILL02 and BILL03, the remaining
values of SVL01 and SVL02 will not be the same)
-> So, we also need a way to order the links between account move lines
and stock valuation layers.
Now, about the solution.
First, a **disclaimer**: We are in stable, we are limited by the stable
policy, and we can't let the above use cases unresolved. So, we took
some decisions to fix them and to repesct all the constraints we had.
**This is clearly a (big) patch, it should be considered as such and
will be replaced by a cleaner/better solution on master as soon as
possible**.
About the link between SVL and AML, we had the possibility to create
a new model in a new module. But this would have decreased the
impact of the fix deployment, would have created some
complications for support (different behaviours depending on whether
the module is installed or not) and would have make testing more
complicated (again, different behaviours depending on whether the
module is installed or not).
This is the reason why we decided to "replay the receipts and the
bills". That way, we know which layer is impacted by which invoices,
and vice versa. And, to set the order between all of them:
- For the layers, we use their `create_date`
- For the bills, we use a hack: each time an account move is posted,
because its state is tracked, a tracking value is posted on the
chatter, and this tracking value has a `create_date` (remind the
constraints explained above and the disclaimer...)
OPW-3217215
closesodoo/odoo#126536
X-original-commit: b5e0e1057b81f7333e73ef06e88e8943709119cc
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Improve the returns process by adding the following improvements:
- Removal of the 'return' operations type. Returns of deliveries now
become receipts.
- Update of the `stock_picking_return` wizard by removing the onchange
on picking_id.
- Show returns in the sale portal, with a new 'return label' PDF report
- Enable returns for multi-step receipts on purchases
Community PR: https://github.com/odoo/odoo/pull/118568
Enterprise PR: https://github.com/odoo/enterprise/pull/39761closesodoo/odoo#118568
Task: 3081370
Related: odoo/upgrade#4660
Related: odoo/enterprise#39761
Signed-off-by: Tiffany Chang <tic@odoo.com>
*: account, crm, crm_iap_mine, event, hr_expense, hr_holidays,
hr_recruitment, lunch, mail, mass_mailing, point_of_sale, project,
purchase, purchase_stock, sale, survey, web, website, website_blog,
website_event, website_forum, website_sale, website_slides,
test_main_flows
In odoo/odoo#111103 the tour system was rewritten. The previous tour
system used to depend on the `root.widget` js module, and this module
was an async module that indirectly depended on `session_bind` which
would load the translations, meaning that the js module definition code
of the tours would only run after the translations were loaded. This is
no longer the case with the new tour system, this means that the module
definition code is executed as soon as the dependencies of that module
are fulfilled, which is generally befoe the translations are loaded,
causing most tour tips to not be translated.
This commit adds a hacky workaround for this problem: it creates a new
module that has a default export which is a promise, and has a legacy
alias, this creates an async module that waits for the translations to
be loaded. This module is then imported for its side-effect in all
onboarding tours, causing them to be translated correctly once again.
This commit also needs to convert the steps key in the tours internal
registry to a getter. In previous versions, the steps were directly
added as is to the internal state of the tour service, but since
odoo/odoo#122834 the steps are now mapped, and without a getter, any
edits to the steps occurring after registration will not be taken into
account. This causes issues in some modules that change original
behaviour of other modules (eg accounting makes invoices into a menu in
the accounting app instead of a top-level app in the home menu) as they
need to edit the steps of existing tours to make them work.
In a separate PR, we will implement a more proper fix by changing the
API of the tour manager so that we no longer need this workaround.
closesodoo/odoo#125284
X-original-commit: d130699ba82dc9919c9116f4b64a5e461ebb6319
Related: odoo/enterprise#42655
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
To reproduce:
1. Create a storable product with ordered quantities policy for purchase and with a category set as FIFO automated
2. Create a purchase order in a different currency and set quantities for partial deliveries
3. Create a partial delivery
4. Fully invoice the purchase order
5. Create the delivery of the complementary units
6. Check the stock valuation layer
The valuation of backorder is wrong.
The value on valuation layer is in company's currency, while the value
on invoice line is in the PO's currency. When create valuation line for
backorder, we didn't convert them to same currency.
opw-3300266
closesodoo/odoo#125206
X-original-commit: c2de679fcba7f153201dde5b3aa989eb3f329910
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
before this commit, the field incoterm_id is defined
twice in purchase.order model, i.e., in purchase and
purchase_stock modules
after this commit incoterm_id field is removed
from purchase_stock module
closesodoo/odoo#123602
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
With this commit:
========================
- Added a new field `forecasted_qty` in replenishment to display the
forecasted qty based on a selected warehouse in the wizard
- Changed the `route_ids`(m2m) field to `route_id`(m2o) so that
we can apply a specific route for the
replenishment instead of the product's default routes
- Reduced the width of all the fields
- Remove the time from the scheduled date and make the unit field not editable.
- Can see vendor information with info icon field when buy is selected
- Hide the Dropship route from the Route
TaskId : 2579425
closesodoo/odoo#96948
Related: odoo/upgrade#3796
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Turn the call to filtered after the search on purchase.order.line
into a call to _search. This allows to remove filtered by adding
an additional leaf in the search domain.
Add read calls to fetch fields from db and store them in cache
on recordset batches.
Example speedup: partner with 136555 POL 6.33s -> 3.42s
opw-3277299
closesodoo/odoo#122218
X-original-commit: b3e81b092864c71a9d5d097fbfa965319acf4fba
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Usecase to reproduce:
- Set the currencies as 1€ = 2$ ($ as company currency)
- Create a PO for a product in AVCO auto with a price of 100€
- Do the receipt
- Change the rate as 1€ = 4$
- Bill the PO
Expected behavior:
- One correction account.move.line for the 200$ and the stock
interim receipt account reconciled.
Current behavior:
- An aml from the price difference with the 200$
- Another from the currency exchange also for 200$
- The line from the price diff is not reconcile
`_stock_account_anglo_saxon_reconcile_valuation` should never reconcile
account.move.line from a price difference correction without the context
key no_exchange_difference because the currency correction is already
handle in the correction layer.
closesodoo/odoo#120158
X-original-commit: b8bbd7e2a3f8f9e119b11314bcebfadb2ba75eda
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Description of the issue/feature this PR addresses:
simplification of the credit note wizard
Current behavior before commit:
First users select reverse option (3 radio buttons):
1) refund
2) cancel
3) modify
The reverse action is triggered when the users clicks on the "reverse" button
After commit:
radio button are removed. There is now two buttons that trigger directly the reverse action with the desired option (refund or modify, cancel is not available anymore)
Also, for refund, posting the draft reverse move will also reconcile with reversed move.
task id: 3244377
closesodoo/odoo#117961
Related: odoo/enterprise#40919
Related: odoo/upgrade#4667
Signed-off-by: John Laterre (jol) <jol@odoo.com>
After the modification of the credit note wizard the option 'cancel' is not available anymore.
Since there was no test for 'modify' and the 'refund' option was already tested, the tests are modified so that it now tests 'modify' option
task id: 3244377
Part-of: odoo/odoo#117961
This commit changes the process flow of stock pickings. A new picking will
always be created in immediate transfer mode and 'ready' state. From
their, it can be validated directly or 'reset to draft'. This second action
switch the immediate mode to planned mode and reset the state as draft.
From their the classical workflow is processed
confirm -> (assigned ->) validated
Task: 3256447
Part-of: odoo/odoo#117513
After uninstalling the stock module on a database which also has the purchase
(and purchase_stock) module installed, the qty_received_method is removed for
purchase order lines handling the reception of the products through the stock
module (qty_received_method = 'stock_moves'). Because of this, a recompute
is triggered on the qty_received, setting it to zero.
This leaves the purchase order in an invalid state (the received quantity did
not change through the uninstallation of the stock module), additionally the
problem cannot be corrected, since the receiving method is not set to manual.
Functionally, the uninstallation shouldn't update the purchase orders, instead
they should be decoupled from the associated stock moves. To this end, an
ondelete handler is added for the stock_moves selection option.
Steps to reproduce:
- Install Purchases app
- Install Inventory app
- Create a purchase order with purchase lines and quantity > 0
- Confirm the purchase order
- Click on receive products
- Click on validate
- Uninstall Inventory app
- Check that the purchase order lines have the received field set to zero and
it is not editable
opw-3006951
closesodoo/odoo#121549
X-original-commit: cedd0603a24aa0c0e6716c2e0f49e89c870eae04
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
Co-authored-by: Pedro Manuel Calheiros Lima de Sousa (peso) <peso@odoo.com>
[FIX] *: selectors in tours
[FIX][TMP] account: CogMenu selector in tours
[FIX][TMP] web*: Breadcrumb targetting in tours
Adds a `o_breadcrumb` class to target the whole breadcrumb, no matter
how much elements it contains (collapsed parts, visible path, single
name...).
add classname on last breadcrumb item
[FIX][TMP] project: View buttons selector in tours (moved away from CP)
[FIX][TMP] project: Kanban selectors in tours (quick create)
[FIX][TMP] *: SearchBar selectors in tours (toggle menu)
[FIX][TMP] *: ButtonBox selector in tours
[WIP][IMP] web: add toggleSearchBarMenu in search helpers
adapt and unskip 3 list tests
adapt and unskip calendar tests
unskip web_tour test that actually pass
post rebase fix
allow to lose cell focus after multi edition (given to searchbar) - bug reported, to check later
post rebase fixes
fix
Part-of: odoo/odoo#116641
AttributeError "account.move.line" object has no attribute "purchase_line_id"
occurs in `stock_account` when we confirm vendor BILL or REFUND with product
costing method "first in first out" or "average cost".
With the recent reflacted changes in commit[1], the `purchase_line_id`
field is used and it belongs to `purchase`, but it is not installed and does
not depend, so it causes an error.
The above issue is solved by removing some code in commit[1] from
`stock_account` and adding it to `purchase_stock`.
committ[1] - https://github.com/odoo/odoo/pull/99411/commits/e9ce88a9372843abef7cf8fc94c4dbe5f16c5fa3#diff-e6134a1a5a13058e35f86426a96db0acac44553fa3b0ca26716390f7b19fc96cR318
sentry-3975529425
closesodoo/odoo#121070
X-original-commit: 23ba3c6684e388bcfe317e7ab9f4c9008622e2b4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ansari Mahamadasif (maan) <maan@odoo.com>
Currently, automatically PO is generated in that PO buyer field is empty.
So in this commit, we added buyer field in partner form view, when rfq is
generated automatically and vendor has a specific buyer then at creation
of rfq, the PO buyer field will be set according to that.
TaskID - 3151213
closesodoo/odoo#113709
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- Create a purchase order with 3 unit of “P1”
- Confirm the PO and receive the delivery
- Go to inventory > operation > Inventory Adjustments
- Select the “quant” of “P1”:
- quantity = 3
- inventory_quantity = 0
- Click on “Apply”
- Apply the wizard
Problem:
The quantity is updated to 0
When the `_apply_inventory` function is called, a move is created and
validated to ensure that the quantity matches its corresponding
`inventory_quantity`:
https://github.com/odoo/odoo/blob/15.0/addons/stock/models/stock_quant.py#L606-L611
`inventory_diff_quantity` is equal to -3 in this case, since it's the
result of computing `inventory_quantity` - `quantity`, which is (0 - 3).
Since we add a minus sign to `inventory_diff_quantity`, the final result
becomes `3`.
Afterward, we call the `_update_available_quantity` function with a
minus sign as well, so the value becomes -3:
https://github.com/odoo/odoo/blob/e1cea2640fc064a56b0dba4f79e6b8a91a48b4fc/addons/stock/models/stock_move_line.py#L307
As a result, when we add `quant.quantity`, which is 3, the final result
becomes 0 (3 - 3):
https://github.com/odoo/odoo/blob/9d34c72b2c7bc187c5aac771e9e8cbddd7ead5f2/addons/stock/models/stock_quant.py#L635
Solution:
If no inventory_quantity set, ignore the apply of inventory for this
quant.
opw-3268542
closesodoo/odoo#119867
X-original-commit: 4bedeb514652f5f4a9fd8fa0914d07c8ccba3952
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Create a Storable Product “P1”:
- Route: buy
- Reorder Rules: Min 5, Max 0
- Set up a user with only Inventory / User Access Rights
- Using INV User, create a Delivery Order (Delivery 1) so the amount
of Product On Hand is below the Reorder Rule Minimum
--> this will genreate a PO created by Odoo bot
- Using the same INV User, create a new Delivery Order (Delivery 2)
so that the amount purchased on the PO will need to be changed
Problem:
This is done by the user who created the need and not Odoo bot and
as the INV User does not have Access Rights to edit Purchase Order
Lines, an Access Error is triggered.
opw-3255007
closesodoo/odoo#119866
X-original-commit: 32c48924e5045b2cad4f6fda2f0222be0683c22a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Install purchase, then mrp (in this order)
- Create a storable product “P1”
- route: buy
- Add a supplier
- Add a BoM
- Create a delivery for the product “P1”
- A need is created
- Go to inventory > operation > replenishment
Problem:
An orderpoint is created with the preferred route: Manufacture instead
of buy
As the "Purchase" module was installed first, the override of
the `_set_default_route_id` function will be triggered first, the 'buy'
route will be set in the created order point because the product has a
supplier. Then, the function in the MRP module will be triggered and
since the product has a BoM, the 'buy' route will be replaced by
"Manufacture".
opw-3228971
closesodoo/odoo#119172
X-original-commit: 227d038efbadf25e3a7be7cceedd9159b71162a3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Use case to reproduce:
- Set "receive good in input and then stock" on the warehouse.
- Set two suppliers on a product. one from a partner (higher priority)
and one from a child partner (lower priority).
- Set the child partner as the vendor on the replenishment report.
- Order a replenishment for the product.
It happens due to an hack that use a field on `stock.move` in order
to temporaly store the partner among the moves until the RFQ.
But this field is a many2one on `res.partner` model and not on
`product.supplierinfo`
`_run_buy` receive a partner and still use `_select_seller` with the
partner in order to find the best pricelist. But it won't use the
specific supplier price list set on the orderpoint.
In order to fix, we don't store anymore the price list partner on the
intermediate move. In run_buy we receive the orderpoint if it's the
origin of the procurement. On the orderpoint the supplierinfo is set.
So we take it from there.
opw-3180945
closesodoo/odoo#119063
X-original-commit: 3cd5b9b7688ef7e6c6fa4fce1c0ad319fb577745
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The new backend version of read_group can simplify the
current overrides of read_group. Do it for each of them and
avoid making extra search (done with __domain) when it is possible.
Part-of: odoo/odoo#110737
Steps to reproduce the bug:
- Create a storable product “P1”:
- route: dropship
- Create a purchase order:
- customer: Azure interior
- Deliver to: Dropship
- Dropship Address: any address
- Receipt Date: Tomorrow
- Product: “P1”
- Conform the Picking
- Go to the dropship transfer:
- Validate the picking
- Go to the Scheduled Action > Purchase reminder
- Run Manually
Problem:
The reminder email for the delivery is sent While the picking is in the
'done' status.
When we run the Scheduled action, the `_send_reminder_mail` function is
triggered in which we get the orders with the `_get_orders_to_remind`
function but we filter the purchase orders which have an "effective_date"
already set:
https://github.com/odoo/odoo/blob/181c7d82e30d0848bbac7f7d0188e81aced0af07/addons/purchase_stock/models/purchase.py#L279
but as in drop-shipping, the dest location is customer and the
"effective_date" is not set:
https://github.com/odoo/odoo/blob/16.0/addons/purchase_stock/models/purchase.py#L53
opw-3246218
closesodoo/odoo#118507
X-original-commit: 1495b54aa452498c79f4178c2e38426b1b423e66
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce:
1-create a weight unit 'jm' bigger than reference
ratio 2.47541 rounding 0.001
2-create a stored product uom:'jm' / purchase_uom: 'kg'
3-set valuation method to automated (fifo)
4-create a replenishement for 200 (jm)
5-confirm and recieve the products
6-valuation for that stock move is null
Bug:
computations in the stock module are done with rounding method (half-up)
when computing the unit price the recieved quantity is computed with up
rounding which leads to a mismatch
Fix:
applied the same rounding method on all the Steps
opw-3213997
closesodoo/odoo#118251
X-original-commit: c305942958c73414def47ebd299227999841c6ed
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
_create_or_update_picking() is a time-consuming method.
On some Purchase, all the purchase.order.line may be written with 'product_qty' in 'values', even though it did not change.
OPW-2978569
closesodoo/odoo#117387
X-original-commit: 5575fe2dedfae2e9d558ca29884d2ebead3c8bbe
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
When editing a purchase order line which is not in the company currency
the price_unit on the stock.move is overwritten with the price_unit in
the currency of the purchase order.
Secondary issue this causes is that if any further quantity changes
occur on a purchase.order, any new stock.moves may not be merged. If the
quantity is reduced this results in a negative stock.move quantity which
Odoo helpfully inverses the location and destination locations.
closesodoo/odoo#116620
X-original-commit: e7dfe10c81e69e3eb82b209db25483f29eb557e6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Kit were not reconcile because the `_stock_account_anglo_saxon_reconcile_valuation`
method try to match `account.move.line` and `stock.move` base on the
product field. However in kit case, the moves are exploded in mutliple
moves containing the kit's components. Due to that the matching is not
made.
To fix this issue we use the `purchase.order.line` that is share between
the `stock.move` and `account.move.line` to retrieve them.
closesodoo/odoo#114987
X-original-commit: f594c837c8a347abb48015d4e9bb0d5109228539
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Current behaviour:
If you have a confirmed SO, with a `sale.order.line` that has a
`product_packaging_id`, and you write a new `product_packaging_id`,
the "Delivery Order" has 2 lines, 1 move with the old qty and the old
packaging, and another line with the difference of qty and the new packaging.
Same behaviour is present on purchase side.
Expected behaviour:
If you have multiple `stock.move.line` from the same `sale.order.line`,
they should be able to merge, when you changed the `product_packaging_id`.
Ex: If you edit an SOL from 1 pack of 10 to 1 pack of 20, we should have
1 move line with qty 20 in packs of 20, instead of 2 lines, one with qty 10
in packs of 10, and another line with qty 10 in packs of 20.
Same behaviour is expected on purchase side.
Steps to reproduce:
- Install Sales and Inventory
- Activate "Product Packaging" in Settings
- Create a new product with 2 types of packaging
- PackOf10 with quantity of 10
- PackOf20 with quantity of 20
- Create a SO with a new line that product, quantity 10
- Confirm the SO
- Edit the SOL with 1 pack of 20 (`product_uom_qty`=20)
- The "Delivery Order" has 2 lines, instead of 1 with the new packaging
Reason for the problem:
When saving the SO/PO, a new `procurement` is created which will create
a new `stock.move.line` with the new packaging. This will prevent the
lines to merge correctly, because they have different packaging.
Fix:
When writing the `product_packaging_id` on a `sale.order.line`/`purchase.order.line`,
we directly write the package on the `stock.move.line`,
before any `procurements` are created, so the generate move lines
can correctly be merged.
Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3002612
closesodoo/odoo#114866
X-original-commit: 87ed4b2f6c9c36202a1a4f3de143f638cf38d047
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
yhu-odoo