We support 'returns' in the POS frontend by allowing the user to
specify a negative quantity. Before this patch however, the backend
would always generate a single picking per pos.order. This is
problematic when a pos.order contains both lines with a positive and
negative quantity. The generated move lines would not all have the same
source and destination location and so could not be added to the same
picking.
This commit creates an extra 'return' picking when required and assigns
the generated moves to the correct picking.
Closes#13699Closes#13762
opw-690812
There are multiple scopes giving access to analytics api, like
https://www.googleapis.com/auth/analytics.readonly
Having a space at the end of the queried string prevents correct
scope detection; so a user who has, in fact, access will receive
a faulty error message.
Original commit 64691c7796f92ffda15f5526b83d9b8b21ca149b courtesy of Andrea Stirpe <a.stirpe@onestein.nl>
Removed action 'Open Account Dashboard Menu' from module l10n_nl.
Though it works fine on Odoo Community 10.0, that part of code causes an error when installing the module on an Enterprise installation of Odoo 10.0.
That action 'Open Account Dashboard Menu' was present in various localizations for V9.0, but since V10 it was removed from all the localization modules.
Impacted versions:
- 10.0 Enterprise
Steps to reproduce:
1. install module l10n_nl on Odoo Enterprise 10.0
Module l10n_nz was affected by the same problem.
Since commit dabf82870a, the expense sheet now creates one account.move per expense, so there is no point in grouping per journal. Moreover, the account_move_id m2o is not relevant anymore for expense sheet having more than one line. That's why it is now replaced by a button
Before the ace editor was split so that it can be used in the backend
and the frontend, the displayError function finished by:
website.error(a, b);
As website.error cannot be used in the backend, the method was changed
to return the error and the extensions of the method were in charge
of displaying it. Unfortunatly this return was done like this:
return a, b;
which is not valid javascript.
Now the method return an object with a "title" and a "message" value
instead of wrongly returning two values.
Note: this fix relies on another fix which will be forward-ported from
saas-11.
Before this patch, the debian package depends on `python-pybabel`.
According to the documentation, this is a dummy package for transition
from `python-pybabel` to `python-babel`[1].
This dummy package has thus been removed in debian stretch in favor of
`python-babel`, and the odoo package is thus not installable in debian
stretch.
To fix this, we depend directly on `python-babel`, which is available in
all debian releases[2].
Closes#13905
[1] https://packages.debian.org/jessie/python-pybabel
[2] https://packages.debian.org/jessie/python-babel
Underscore method _.each expects an array like object when a
"length" property is present.
This was an issue with a record having a numeric "length" field set
to a non-negative value.
opw-691070
The `map_account()` method expects a browse_record as
parameter, and returns a browse_record (possibly the
argument if no mapping happened).
It was being called with an account ID instead, so
fiscal position mapping would never match, and would
always return the argument itself.
The `fiscal_position_id` field actually depends on both
the `shipping_partner_id` and the `partner_id` field,
not just the former.
Theoretically the recompute should trigger on both fields
anyway because changing the `partner_id` will automatically
change the `shipping_partner_id`.
Unfortunately this onchange chaining does not work as expected
as of Odoo 9, at least when the `partner_id` field is set
to the same value (was done for optimization reasons).
This special case really happens when you edit the Partner
from a sales order form view, and save the changes.
It triggers a "dummy on_change" for the `partner_id`
value, with the same value as before.
If the edit changed the fiscal position or another
field on which it depends, a recompute is really needed.
Adding the direct dependency works around this limitation,
and is semantically valid, too.
An extra fix of this special case in the framework might still
be nice to have, though.
Ref: feedback ID 29042
Underscore method _.each expects an array like object when a "length"
property is present.
This was an issue with a record having a numeric "length" field set to a
non-negative value. When changing a line the change would not appear on
blur.
This issue was fixed with 0e664c9e9 but introduced back with f0e331e00.
opw-691070
Without this, odoo log outputs to stdout and is catched by journald. We
force the use of a log file to keep the behavior consistent with the
debian package.
This fixes the problem of recomputing that field in a much better way. The
field was stored for the sake of searching; instead we implemented a search
method for it.
This is related to revision
b65c67a259
The field `seller_ids` is a field which is set
on the `product.template`, and this is why
the condition `(x.product_id == product)` is being applied
in the list comprehension searching the current seller
of the product sellers.
The `variant` variable is a string containing
the attribute name of a variant.
Therefore, if a product tempalte has only one variant, without
any attribute (e.g. when you don't use variants),
`variant` will be empty, and therefore the condition
`if variant:` will be `False`, and therefore it won't search
in the product sellers with a specific `product.product`, while it
should, as, even if there are no attributes, there could be a
seller line with this specific `product.product`.
Besides, as we are in the `name_get` of `product.product`, and
not the `name_get` of `product.template`, we are always in the case
of a `variant`, this test is therefore pointless.
opw-682390
These two fixes are now important since the ViewEditor is now also
used in the backend.
* The start method must return a deferred.
* The destroy method must unbind the event on the document element.
Note: in master, the ViewEditor is being refactored.
This grouping was causing problem at the time of bank statement reconciliation, if the expenses were set as already paid by the company, since we had only one account.move related to several bank statement lines although the DB structure wasn't allowing such a case (the link was made as a m2o from account.move to account.bank.statement.line where a m2m would have been needed).
Attendances (model hr.attendance) that overlapped different dates where not
computed correctly in timesheets (model hr_timesheet_sheet.sheet.day).
The difference in dates was not taken into account.
This commit fixes this issue; attendances are now linked with the check_in date
to hr_timesheet_sheet.sheet.day.
(so 8 hours recorded from 20:00 to 04:00 the next day will be recorded as
8 hours on the first day)
In the earlier fix 327f88df, the computation of the amount crashes when the
field `tax_id` is not set. Simply add an 'if' statement to avoid that case.
Case 1: To check schedule date of picking and manufacturing order,
- Configure lead times:
- At a product level set Manufacturing Lead Time and Customer Lead Time
- At a company level set Manufacturing Lead Time and Sales Safety Days
Case 2: To check schedule dates of pickings and manufacturing order,
- Configure lead times:
- At a product level set Manufacturing Lead Time and Customer Lead Time
- At a route level set delay of pull rules
Detailed Use Cases
==================
CASE 01 :
========
(Consider order date : 2016-04-18 11:10:44)
Create Product
--------------
Name : Product A
Product type : stockable
Manufacture : True
Make To Order : True
Manufacturing Lead Time : 5 days
Customer Lead Time : 5 days
Configure your company data
---------------------------
Manufacturing Lead Time : 3 days
Sales Safety Days : 3 days
Create SO
---------
Customer : Asustek
Order Lines : Select Product A with Order Qty : 10
Confirm this SO
Run scheduler
Result
------
Manufacure Order :-- Schedule date : 2016-04-12 11:10:44
Delivery Order :-- Schedule date : 2016-04-20 11:10:44
CASE 02 :
========
(Consider order date : 2016-04-18 11:10:44)
Create Product
--------------
Name : Product A
Product type : stockable
Manufacture : True
Make To Order : True
Manufacturing Lead Time : 5 days
Customer Lead Time : 5 days
Warehouse configuration (YourCompany)
-------------------------------------
Outgoing Shippings : Pick + Pack + Ship
Routes
------
YourCompany: Pick + Pack + Ship
Procurement Rules:
------------------
WH: Output -> Customers :-- Delay : 2 days
WH: Packing Zone -> Output :-- Delay : 2 days
WH: Stock -> Packing Zone :-- Delay : 2 days
Create SO
---------
Customer : Asustek
Order Lines : Select Product A with Order Qty : 5
Confirm this SO
Run scheduler
Result
------
Manufacure Order :-- Schedule date : 2016-04-14 11:10:46
Delivery Orders :--
PICK :--> Schedule date : 2016-04-19 11:10:46
PACK :-> Schedule date : 2016-04-19 11:10:46
OUT :--> Schedule date : 2016-04-21 11:10:46
Case 1: To check schedule date of picking,
- Configure lead times:
- At a product level set Customer Lead Time
- At a company level set Sales Safety Days
Case 2: To check schedule dates of pickings,
- Configure lead times:
- At a product level set Customer Lead Time
- At a route level set delay of pull rules
Detailed Use Cases
==================
CASE 01 :
========
(Consider order date: 2016-04-18 05:34:00)
Create Product
--------------
Name : Product A
Product type : stockable
Customer Lead Time : 5 days
Configure your company data
---------------------------
Sales Safety Days : 3.00 days
Create SO
---------
Customer : Asustek
Order Lines : Select Product A with Order Qty : 10
Confirm this SO
Result
------
Delivery Order :-- Schedule date : 2016-04-20 05:34:00
CASE 02 :
========
(Consider order date: 2016-04-18 05:34:00)
Create Product
--------------
Name : Product A
Product type : stockable
Customer Lead Time : 5 days
Warehouse configuration (YourCompany)
-------------------------------------
Outgoing Shippings : Pick + Pack + Ship
Routes
------
YourCompany: Pick + Pack + Ship
Procurement Rules:
------------------
WH: Output -> Customers :-- Delay : 2 days
WH: Packing Zone -> Output :-- Delay : 2 days
WH: Stock -> Packing Zone :-- Delay : 2 days
Create SO
---------
Customer : Asustek
Order Lines : Select Product A with Order Qty : 5
Confirm this SO
Result
------
Delivery Orders :--
PICK :--> Schedule date : 2016-04-17 05:34:28
PACK :-> Schedule date : 2016-04-19 05:34:28
OUT :--> Schedule date : 2016-04-21 05:34:28
Case 1: To check order date of purchase order and schedule dates of shipment and purchse order,
- Configure lead times:
- At a product level set Delivery Lead Time
- At a company level set Purchase Lead Time
Case 2: To check order date of purchase order and schedule dates of multiple purchase order line of the same purchase order,
we create two procurements for the two different product with same vendor and different Delivery Lead Time
Case 3: To check order date of purchase order and schedule dates of shipments and purchase order,
- Configure lead times:
- At a product level set Delivery Lead Time
- At a route level set delay of push rules
Detailed Use Cases
==================
Consider today's date = 2016-04-21 ( date_planned of procurement = today's date + 10 days)
CASE 01:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Configure your company data
---------------------------
Purchase Lead Time : 3.00 days
Procurement Request
-------------------
Warehouse : YourCompany
Product : Product A
Quantity : 15.00
Planned Date: 2016-05-01 00:00:00
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-04-28 00:00:00
Order date: 2016-04-23 00:00:00
Incoming shipments schedule date :-- 2016-04-28 00:00:00
CASE 02:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Create another Product
----------------------
Name : Product B
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 2 days
Procurement Request
-------------------
Warehouse : YourCompany
Product : Product A
Quantity : 10.00
Planned Date: 2016-05-01 00:00:00
Procurement Request for second product
--------------------------------------
Warehouse : YourCompany
Product : Product B
Quantity : 5.00
Planned Date: 2016-05-01 00:00:00
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-04-28 00:00:00
Order date: 2016-04-26 00:00:00
Schedule date of purchase order line for product A: 2016-05-01 00:00:00
Schedule date of purchase order line for product B: 2016-04-28 00:00:00
Incoming shipments schedule date :-- 2016-04-28 00:00:00
CASE 03:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Warehouse configuration (YourCompany)
-------------------------------------
Incoming shipments : three steps
Routes
------
YourCompany : Receipt in 3 steps
Push Rules:
-----------------
WH: Input -> Quality Control :-- Delay : 2 days
WH: Quality Control -> Stock :-- Delay : 2 days
Create Procurement:
-------------------
Product : Prosuct A
Quantity : 5.000
Warehouse : YourCompany
Procurement Location : WH/Input
Schedule date : 2016-05-01 10:30:43
Notes : 'Test scheduler for RFQ'
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-05-01 10:30:43
Order date: 2016-04-26 10:30:43
Incoming shipments schedule dates :--
In type :-- 2016-05-01 10:30:43
Internal type 1 :-- 2016-05-03 10:30:43
Internal type 2 :-- 2016-05-05 10:30:43
Leonardo Rochael Almeida