These changes are made as a result of simplifying attrs and 'states' in
views.
Before applying the migration script, it is necessary to fix some views.
These views are erroneous and either work by chance or are simply
untested. We have for example wrong domains, elements used by modifiers
but not present in the view, obsolete domain operators, inherit views
not targeting the right views, xpaths using attributes as target, the
use of %(...)s in views, false attribute value types in python.
Part-of: odoo/odoo#104741
When user uninstall the module 'stock_dropshipping'. The value 'dropship' for
selection field 'Type of Operation' does not get deleted and cause error.
From version 14.0 when user uninstall the module 'stock_dropshipping', record
does not get deleted.
To reproduce the issue in sass-16.2:
- Install 'stock_dropshipping' module
- Go to 'inventory' module
- Go to 'Dropship' and click on 'NEW'
- Make sure 'Type of Operation' is 'Dropship' and save
- Uninstall 'stock_dropshipping' module.
- Go to 'Inventory' and click on 'Receipts' and remove all the filters
- Another way--> Create a new 'stock.picking' with 'Operation Type' as 'Dropship'
Error: A traceback appears: 'Wrong value for stock.picking.picking_type_code:
'dropship'
Fixed this issue by updating the code of the picking type and archiving it after
uninstallation of module using 'ondelete' function.
sentry-4167898386
X-original-commit: ee281cf59d25e7e33f08022784f390e8eb798324
Part-of: odoo/odoo#131725
If `stock_dropshipping` is installed, the "Transfer To" field of a lot
does not work with standard flows
To reproduce the issue:
1. Create a tracked-by-sn product
2. Update its quantity with 1 x SN
3. Deliver SN to a partner
4. Open the list view of lots/serial numbers and enable the column
"Transfer To"
Error: The field "Transfer To" for SN is empty, it should be the partner
The field `last_delivery_partner_id` is a computed one and the compute
method calls `_find_delivery_ids_by_lot` to get all relevant
information. In this method, we search the SMLs based on a domain
provided by `_get_delivery_ids_by_lot_domain`. If `stock_dropshipping`
is not installed, the method will return a legit domain:
https://github.com/odoo/odoo/blob/7adc661be1eb426a90842160b2e062446d3ccc03/addons/stock/models/stock_lot.py#L191-L196
However, if the dropshipping module is installed, an override creates
the same domain (directly in the override, without any call to `super`)
and adds a `OR` condition:
https://github.com/odoo/odoo/blob/7adc661be1eb426a90842160b2e062446d3ccc03/addons/stock_dropshipping/models/stock.py#L62-L70
But it contains an error: the `AND` operator is missing, it should be
```py '&', ('location_dest_id.usage', '=', 'customer'),
('location_id.usage', '=', 'supplier') ``` As a result, for an SM to be
found, its source location usage has to be `supplier`. This is the
reason why, in the above use case, the lot does not have any
`last_delivery_partner_id`: we did not find such an SML.
OPW-3386247
closesodoo/odoo#128558
X-original-commit: 8ecc177478f0ffc8ba9cfc65f47386363bd6cb4a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce:
1. Create a Sales Order for a product whose product category is set to
FIFO and automated. Use route "dropship".
2. Confirm the PO created.
3. Deliver the products (DS transfer)
5. Return, for example, 1 unit of product
6. Return the return
This is a continuation of commit f9a1c1d7bb8234eb96c48dddae9930a419bfb696
If the origin of the move is a dropshipped_returned, then the error describe in the mentioned commit will still happen.
opw-3283436
closesodoo/odoo#127403
X-original-commit: b7a91e3682aad7ecc1a4a8a42b2d6368573ba906
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
To reproduce:
1- Activate dropshipping from settings
2- Create lot tracked product and enable dropship route
3- Add a vendor in product purchase tab
4- Create a SO with the product and confirm
5- Go to generated PO and confirm
6- Go to generated dropship transfer linked to SO /PO
7- Enter a lot name for the product move line validate
8- Go to 'Inventory>Products>Lots/Serial Numbers'
9- Expand the dropshipped product, find the serial number used in dropship
10- Show the 'Transfer To' field if not visible, you will find it empty
Expected:
The 'Transfer To' field should have the last partner the serial was delivered to
in this case the customer in the SO
This commit fixes the issue and adds a test (also imporves the test class)
opw-3225342
closesodoo/odoo#125842
X-original-commit: 27356b1046ab534fec9b5d5fa3380cb7a5eafed5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce:
1. Create a Sales Order for a product whose product category is set to
FIFO and automated. Use route "dropship".
2. Confirm the PO created.
3. Deliver the products (DS transfer)
4. Create the customer invoice
5. Return, for example, 1 unit of product
6. Add a credit note to the invoice for that 1 unit returned (reset to
draft then change qty and post)
Issues:
The value on the valuation layers of the returned picking is 0, posted
entries for COGS and stock interim (delivered) account for credit note
is also 0.
Since #85751, When create valuation layer for return, we take all svls
of origin_returned_move_id into account to calculate the price unit.
However, then dropshiping, 2 svls are created for the original move, and
the sum of them is 0 since there is no impact of the stock when
dropshiping. So when return, the price unit will be calculated as 0.
To fix, when calculate price unit for return of dropshiping, we only
take non-negative svls into account. Note that we use non-negative ones
instead of positive ones because when subcontract dropshiping,
additional negative svls will be added for the cost of the components.
opw-3283436
closesodoo/odoo#124856
X-original-commit: 1c6c163f72301cab29c2f26021bb1ae6fb20dc7f
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@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>
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>
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
Use filters instead of domains for the `stock.picking` lists accessible
from the menu 'Operations', so all pickings can be easily consulted in a
single view when removing said filter.
Part of task-3218314
Part-of: odoo/odoo#119381
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Adds a new picking type code, 'dropship', and adds a new action/menu
item to display only the dropshipping's operations.
task-3076044
closesodoo/odoo#109511
Related: odoo/enterprise#35613
Related: odoo/upgrade#4252
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Removes the constraint of using a pricelist and makes all sales flows
rely on the currency of the sale order (or repair order)
task-2735672
closesodoo/odoo#84920
Related: odoo/enterprise#24716
Related: odoo/upgrade#3642
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Stock moves don't have a `partner_id` if they are created before setting
the picking's `partner_id`
Steps to reproduce (from v15):
1. Create a new transfer with operation type 'Delivery Orders'
2. Add a move, then a delivery address and save
3. Mark as todo and validate
4. Print the delivery slip
5. The warehouse address is printed but it should be the delivery
address
Solution:
Replace `onchange_partner_id` of `stock.picking` by a compute method in
`stock.move`. It assigns the partner_id of the `stock.move` to its
picking's partner_id if the move is part of the picking's
`move_ids_without_package` (in purchase_stock, also check that it is not
a dropshipping)
Problem:
When creating a picking, its moves' `partner_id` is only set if the
picking's `partner_id` was already set in the form
opw-3091139
closesodoo/odoo#107625
Signed-off-by: Tiffany Chang <tic@odoo.com>
The delivery slip of an outgoing picking prints the warehouse address
instead of the delivery address (which should be displayed as it may
be different from the customer address)
Steps to reproduce:
1. Install Contacts and Inventory
2. Open Contacts and add a delivery address named "delivery" to contact
Azure Interior
3. Go to Inventory > Operations > Transfers
4. Create a new transfer with:
- Contact: Azure Interior, delivery
- Operation Type: San Fransisco: Delivery Orders
- Product: Large Cabinet
5. Save the transfer and print the Delivery Slip
6. The warehouse address is displayed and there is no info about the
delivery address
Solution:
Add a method to know if we should print the delivery address. We should
print it if the picking has a delivery address and it is of type
outgoing (or if it's a dropship)
Problem:
Printing the delivery address when the package partner is different from
the picking partner is wrong because the delivery address might be
different from the customer address
opw-3064203
closesodoo/odoo#107355
X-original-commit: ec929f787f629940cd38a4ed25e5012335e2483d
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
When a picking is a dropship type (i.e. having the vendors as source
location and the customers as destination locations), then the
warehouse_id is removed.
This will add consistency between automatically generated "Dropship"
type and the manually created ones.
Part of task-2985735
closesodoo/odoo#106039
X-original-commit: efe7cfb0b94f485908c4e8510bd0ba6ff154018b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Sometimes, no picking type match the domain, but picking_type_id is a required field.
closesodoo/odoo#97278
X-original-commit: afcad067bccc7676b4e40cc57f8d9b5792068802
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
Instead of using sort + groupby of itertools (which group only
consecutive), use only the groupby of odoo.tools which
decrease the complexity of the code and avoid unmatched keys
between sort keys and groupby keys
task-2648449
Part-of: odoo/odoo#76761
Divide "Delivery"/"Incoming Shipment" smart button of "Sale"/"Purchase"
order form between normal "Delivery"/"Incoming Shipment" and a
"dropship" picking.
Also clean a little bit technically
task-2486811
Part-of: odoo/odoo#75041
Allow to produce several serial numbers at once.
Only when BoM do not contain any component tracked by unique serial number
and lot ones are from 1 lot.
Also allow to copy/paste serial numbers.
This applies to manufacturing orders.
Task: 2444742
Part-of: odoo/odoo#71732
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
For customer invoices:
* do not set default date because if you prepare an invoice (and it gets
a default date), then validate it the next day, the date will be wrong
* set the date when posting if it wasn't set, because why not?
For vendor bills:
* do not set default date because you rarely encode a bill at the bill
date. Forcing the user to enter it reduces risks of user error
(duplicated vendor bill)
* do not set it when posting, same reason.
opw-2492862
Related #68368Closes#68367closesodoo/odoo#69639
X-original-commit: 41041d8016d11f017d92d28f32ab2cf42f1349a9
Related: odoo/enterprise#17866
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Add a warning to explain that create a second
warehouse will activate the multi-location automatically.
task-2439909
X-original-commit: 4964a9482b8b195f5b629ea5c91f7d7bfcce2163
When you want to obtain `dropship_picking_type`, it is possible to have
several results. This will lead to an error when doing
`dropship_picking_type.id`.
```
dropship_picking_type = self.env['stock.picking.type'].search([
('company_id', '=', company.id),
('default_location_src_id.usage', '=', 'supplier'),
('default_location_dest_id.usage', '=', 'customer'),
])
```
The fix ensures that `dropship_picking_type` contains only one element.
closesodoo/odoo#61256
X-original-commit: 3e3b1b335ced1ff20129172e6a7b2b0dcbe1a20d
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Same issue than for commit 203bb4d9c11 but for dropship rules instead of
missing dropship types.
closesodoo/odoo#59629
X-original-commit: 1372cc427e9946b3f6ba81b4e895b145468092a2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In the function `create_missing_dropship_picking_type()`, the way to
search companies that already have dropship picking type was not robust
enough as it used the translatable `name` field in a search domain and
the ORM `search` method used the translated value of `Dropship` name value
instead of the raw value.
A better approach is to search `stock.picking.type` with a default source
location usage set to `supplier` and a default destination location usage
set to `customer`.
Related to upgrade request: #54154closesodoo/odoo#59142
X-original-commit: 203bb4d9c113f5c24ad00d39e2ae46b4689117f4
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Allow to add serial numbers as tags on the move in production order and
stock picking. The purpose is to earn time for database with
only tracking installed.
Also when only create_lots is checked on picking type. New lots
could select existing lot and an onchange trigger a warning if
it's used.
closesodoo/odoo#55883
Task: 2280985
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- The deadline of MO generated via procurements is calculated differently.
Now, it doesn't take anymore in account the manufacturing_lead
of the company (Security Lead Time of MO). The computation of planned date remains unchanged.
- The date_expected fields was duplicated with the date fields
except when the move was done. Merge both fields.
The only information lost is: we can't know what was the
scheduled date before processing move (`state` == done).
Indeed, the date becomes the actual move processing datetime.
- The `date` in `stock.picking` field contained the time of
(purchase) order `date_order` (`purchase.order`).
This field is was wrongly used in the kanban view where we
expected to see date_planned instead. Also, the `_order` used
this date instead of date_planned too.
- The `delay_alert` is activate independently of stock rules.
Then it is now activate in all case.
- Remove the auto-reschedulting process of stock move via
the stock rule (`propagate_date` and `propagate_date_minimum_delta`).
Replace it by a automatic deadline date (`date_deadline`) propagation.
The deadline is the promise done to/by vendor/client (SO/PO)
then it is a readonly fields on picking/move and MO.
- Now the Scheduled date (`date`) of stock move is never propagate
and it is only related to the Scheduled date of
related document (MO or picking).
- Now when a move is created from procurement (sale),
`date_planned` = `date_deadline` - `security_lead`.
- The `delivery_date` of sale is no editable after confirmation
and propagate as the deadline to related stock move linked to order_line
- Adapt filter and decoration of MO and picking.
- Because we are the client in case of purchase (PO), the promise of vendor
can be not respected. Then we add the lead security to the deadline
(inverse the sale order logic) of PO picking (promise reciept date
+ security lead) to match with the replenishment.
task-2246665
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180
Gorash