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
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Due to a typo, dropshipping sequences were created twice. We created a
"stock.dropshipping" sequence if no "stock.dropshippping" sequence was
found.
closesodoo/odoo#47908
X-original-commit: 021268734a5857f47cda5991fbd28abdd41f512a
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In order to improve the navigation between of SO and PO in the case of
MTO, add a direct link between PO<->SO. When the SO is confirmed
(with storable product(s) with MTO + buy),
PO is/are generated, in this case, add a stat button on each model form
to avoid to manually search the related SO with the source field (name).
task-1913392
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
followup of rev [0]
If these wizards are called on multiple pickings, display the list of
the pickings that could be impacted and allow to select which one should
be impacted.
We also adapt the sanity checks at the start of `button_validte` in
order to specify the concerned pickings if needed. We do not enable the
multi behavior for batch at the moment, so it's only enabled for the
validate multi in the list view.
[0] 6ab4b0d496
task-2069646
closesodoo/odoo#41497
X-original-commit: ff276c6484b138982f185ec9c832f2dbf25baaef
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Overwrite the method ``write`` of the model ``product.product``.
When we write on ``standard_price``, if
- the context key ``disable_auto_svl`` is not set
- the ``cost_method`` is not "fifo"
We automatically compute ``stock.valuation.layer``
(before we needed to manually call ``_change_standard_price``)
Task #2031422closesodoo/odoo#41265
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Move the method `_prepare_purchase_order_line` from 'stock.rule' to
'purchase.order.line'. The purpose is to reuse it in approvals_purchase.
task-2040710
closesodoo/odoo#41046
Related: odoo/enterprise#6702
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Fine tuning of this commit: f93fcaffb5
Steps to reproduce the bug:
- Open runbot v11
- Restrict Demo's access to Sales Manager for sales and employee for Employee
- Try to create a new quotation
Bug:
- You got Odoo server Error
Sorry, you are not allowed to access this document. Only users with the following access level are currently allowed to do that:
- Inventory/User
- Accounting & Finance/Billing
- Purchases/User
- Purchases/Manager
- Other Extra Rights/Portal
(Document model: purchase.order.line) - (Operation: read, User: 5)
opw:2120692
closesodoo/odoo#40153
X-original-commit: 1b14af28fec3cae0efc4438e77e6e0925e487b89
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
So we have to adapt
- the sanity checks
- the immediate/backorder wizards
- split the call to _action_done with and without backorder
This is a preliminary work to remove all the override in
stock_picking_batch and to allow choosing the pickings to immediate or
backorder directly in the wizards.
Before this commit, both wizards were calling _action_done and one
another. We make them go back through `button_validate` so that it is
more sane to handle and allow future extensions to add pre-action done
wizards.
Also the first part of button_validate is some sanity check. We adapt
them to be multi (inside of a loop over self) without any other
changes.
Now the wizard can work on the records (immediate: write the done
quantities) or work with the context (backorder: picking ids to not
backorder in the context).
Also we adapt the stock sms weird wizard (a confirmation wizard but the
feature is auto installed? wth). Now there it isn't manually called in
the middle of button_validate but it uses the pre_action_done_hook.
task-2069646
`action_done`on pickings should be a private method,
and called only trough the picking validation process.
task-1938108
closesodoo/odoo#39174
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Now that company_id is required on the picking type, make sure we create
as many dropship picking type/rules/sequence as there are companies
task-1985992
- This commit moves the Payment Term "End of Following Month" from
demo data to data and adds two new Payment Terms: "21 Days" and
"30% Now, Balance 60 Days".
It allows the customer to define less Payment Terms
task-2032586
Steps to reproduce the bug:
- Install stock_dropshipping module and enable Routes on SO lines
- Create a storable product P with a supplier S
- Create a SO with P and set this line with the route dropship
- Confirm the SO ( a PO has been created to S with P)
- Change P on the SO with an other product
Bug:
The product P stayed on the PO.
So a product linked to a PO line cannot be changed on a SO.
opw:2040249
closesodoo/odoo#35383
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Create a quotation and a SO line SOL with one product and route "Dropship"
- Confirm the SO and a PO is created
- Validate PO and process the dropship picking
- Add 4 units to the SO line SOL
Bug:
A new PO was created but the related picking was type "Receipts" instead of "Dropship"
opw:2034398
closesodoo/odoo#35323
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Selling a product you don't have in stock anymore triggers a message
without pertinent information about available quantity.
This commit adds a little widget on sale order line to inform the salesman
there are not enough quantity available. Clicking on it will reveal:
* The estimated delivery date
* The actual quantity on hand
* The quantity forcasted at the estimated delivery date
For kit product, the quantities are the maximum occurence of kit available
regarding components quantities.
Task 2003485
closesodoo/odoo#34336
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Julian Roussieau