The use case is a bit complicated so brace yourself:
OFFLINE
- Make an order, invoiceble with a partner
- Pay it, validate it
- An error popup is shown
=> Before this commit, the payment screen was still on
=> After this commit, the receipt screen is shown proposing to
print the invoice
ONLINE
- Make another order, non invoiceable.
- Pay it, validate it
- Both orders are now pushed to the server
=> Before this commit, it was still possible to click on "Back"
and add some products. The result of this will be that the order in DB (server)
would not have the newly added product, whereas the ticket would state that there was a new product
=> After this commit, we basically block the edition of a paid and validated order, even if the invoice
printing failed
OPW 1971028
closesodoo/odoo#32885
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- Create 2 companies A & B
- Set the superuser in company A
- Create a POS and a user in company B
- Create a product P. The 'Inventory Valuation' must be different in
both companies:
Company A: Periodic (manual)
Company B: Perpetual (automated)
- Connect with the user in company B
- Sell the product P, select a customer and print the invoice
The COGS journal entry is not posted.
This is because `action_invoice_open` is called as `sudo()`, but
ultimately `product.valuation` is called in:
https://github.com/odoo/odoo/blob/0cce154794c8de945805d9b9acc4c33e5258191a/addons/stock_account/models/product.py#L325
`product.valuation` is computed based on the property field
`property_valuation`, which is therefore company-dependant.
Closes#32803
opw-1961861
closesodoo/odoo#32903
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The calendar should send to server:
- for an all day event (all_day field on view): the date in UTC (ie. if
we are on 22 august 2018 on UTC+2, not send 21 august 2018 22:00)
- for a datetime event not all day: the UTC datetime corresponding to
UTC (for 03:25 with UTC+5 timezone, we send 22:25 the day before)
- for a date event: the date in UTC (ie. same as all day)
The current code was alright for datetime, but there was a missing case
if the start_date was a Date field (eg. project task calendar view uses
a date_deadline Date field) and not a Datetime field.
This changeset apply the same behavior as an all_day event to a calendar
with a start date that is a Date field.
Note: the issue happen since 11.0's 03d74f4 (26th march 2019) that
solved a similar case but for datetime (a datetime event at 8:00 with
timezone UTC+9 would be moved the previous day when drag and dropped on
the month view).
opw-1969876
opw-1971106
opw-1971019
closes#32796
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Steps to reproduce the bug:
- Create a consumable or storable final product A with invoicing policy
in "delivered quantity"
- Create two storable products B and C
- Create a BOM kit for A with 1 B and 1 C
- Create a SO with 5 qty of A and confirm it
- Deliver 3 B and 2 C and either on "No backorder" or "With backorder"
Bug:
The delivered_qty on the SO line is of course not automatically updated
(as in this case, a right value is not computable) but the delivered_qty
was not updatable manually and then it was possible to invoice the SO.
Co-authored-by: nim-odoo <nim@odoo.com>
opw:1966170
closesodoo/odoo#32733
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Do a PO in a foreign currency
Invoice it in the same foreign currency
Validate the invoice
Before this commit, The account move of the invoice
contained a price difference line
which is wrong, since the price has not changed in any ways
After this commit, the move has only two lines
one in the stock input, one in the payable
Also, the case where the price does change
due to a change in currency rate is handled
OPW 1955315
closesodoo/odoo#32616
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
* Some accounts have wrong tax tag mapping
* Some fiscal positions don't work properly (mapping of taxes, right tax
keys, right accounts)
* Missing fiscal position "domestic partners" in order to allow
automatic selection of the right fiscal position if it is a doemstic
partner and to make it more clear for customers, otherwise they might
wonder why fiscal position field is empty for domestic partners.
* Issue with fiscal position "Geschäftspartner EU (ohne USt.-ID)" to
detect the right account, tax, tax tags if we sell to a customer / buy
from a supplier located in the EU without valid VAT-ID (for example
private people)
* Issue with fiscal position "Geschäftspartner Ausland" to detect the
right account, tax, tax tags if we sell to a customer / buy from a
supplier not located in the EU.
Closes#31389closesodoo/odoo#32673
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Recommended by GitHub's repository alerts.
We normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 10.0 that would be Debian 8
(jessie) and thus Jinja 2.7.3 (albeit with security backports).
However Jinja2 before 2.10.1 suffers from a few issues that could lead
to crashes of Odoo processes.
It seems it's worth an exception to our rule for pip users, similarly to
previous bump up at d2605bccdb.
closesodoo/odoo#32602
Signed-off-by: Christophe Simonis <chs@odoo.com>
When creating a delivery product from the delivery carrier form.
The delivery product should not be sealable or purchasable.
opw-1958029
closesodoo/odoo#32289
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In this way the description of the delivery method can be used on a SO
line. If the description wasn't set, the name of the delivery method
will be used.
opw-1958029
On the ticket 1961412, the custommer has more than 12 millions
of stock moves. Before this commit, the search request does
not take too much time to execute but fetching the fields on the
recordset takes a lot of time due to the 'in' in the where clause
of the associated SQL request.
This optimization permit to avoid this 'where clause' and decrease
the time to gather all the different fields. The time has been reduce
to less than one minutes where it takes approximately 20 minutes before.
closesodoo/odoo#32520
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Recommended by GitHub's repository alerts.
We normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 11.0 that would be Debian 9
(stretch) and thus Jinja 2.8 (with security backports).
However Jinja2 before 2.10.1 suffers from a few issues that could lead
to crashes of Odoo processes.
It seems it's worth an exception to our rule for pip users, similarly to
previous bump up at d2605bccdb.
closesodoo/odoo#32601
Signed-off-by: Christophe Simonis <chs@odoo.com>
This revision is similar to
605b94e64c
except that instead of an OperationalError
(e.g. a conccurent update),
this is an IntegrityError which is raised,
an sql constraint which is not met,
e.g. a unique or required constraint.
In the case of this opw,
this is the picking name unique constraint
which was not met,
the picking sequence number has somehow been re-used.
Both
`psycopg2.OperationalError`
and
`psycopg2.IntegrityError`
inherits from
`psycopg2.DatabaseError`
We therefore choose to use this Exception class,
to include all kind of psycopg2 exceptions that prevent
the transaction to be committed.
opw-1965679
closesodoo/odoo#32577
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Before this commit, Odoo notifies the user of all the recurring past
events, existing before the installation of the module Calendar (old
events imported when synchronizing with Google, for instance). This
occurs only the first time a synchronization with Google is made. This
occurs because Odoo notify all the events that occurs since the last
time it notified, and the first time you install the module the date of
the last notification is empty.
Now, when the module Calendar is installed, the date of the last
notification is set by default to the current date (the date of the
installation of the module)
opw-1942443
closesodoo/odoo#32535
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In mass mailing access to partners when performing a mass mailing has been
done in batch to speedup computation [1]. Emails are put into a dictionary
allowing to find back the email based on partner_id.
However the matching between the partner and its emails is done using a
shortcut using the current document ID as partner ID. It works when performing
a mass mailing on partners but fails when performing a mass mailing on models
having message_get_default_recipients not returning only emails. Currently
in saas-14 main models return only emails (crm, event, mailing contacts) but
other models may encounter issues (applicants, tickets).
This commit fixes it by correctly matching partner id and its found email.
[1] See 65ed4553a5
_compute_website_url can only be called on singletons
It should not be called with self but the record we are iterating on
closesodoo/odoo#32369
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
For existing installations, creating indices might not always be
possible, e.g. if you have a Text/Char field that has an index=True
set on it in a field override and pre-existing rows longer than
the pg supported size , the index creation will fail.
Instead of failing miserably during the schema modification, simply
log the problem instead and keep going.
closesodoo/odoo#32442
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When a asset is confirmed, it's not allowed to link it to an invoice.
Side effect, it recomputed the depreciation lines of the confirmed asset.
opw:1961468
closesodoo/odoo#32388
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Since 79af654fc61 if we had unexpected configuration of usage such as
being in HTTPS, having a POS hardware in HTTPS but an error is received
(eg. the device is closed) => the POS interface can't be opened being
blocked on an error:
Https connection to IoT Box failed
Make sure you are using IoT Box v18.10 or higher.
Navigate to {proxy_ip} to accept the certificate of your IoT Box.
With this changeset, we have a popup that does not prevent to open the
point of sale interface (and the red disconnected status in the top
left allow to retry connection as before) on first load.
opw-1934413
closes#32306
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Create 2 companies A & B
- For a product P, create a supplier info for each company using the
same partner, with a different price and delay.
- Order the supplier so that the one for A has a higher priority than
the one for B.
- Create a reordering rule for P in company B.
- Run the scheduler as admin (e.g. thanks to the cron).
The price taken is the price for company A instead of B.
`_select_seller` is not company-aware, therefore the first matching
supplier is chosen.
opw-1959263
closesodoo/odoo#32328
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Go to Sales > Configuration > Settings
- Enable "Multiple Sales Prices per Product" and select option "Prices
computed from formulas (discounts, margins, roundings)"
- Go to Sales > Catalog / Pricelists
- Select "Public Pricelist" and set "Discount Policy: Show public price
& discount to the customer"
- Go to the eCommerce, buy "iPad Retina Display" which as a 20 %
discount
In the corresponding SO, the discount appears to be zero, and the
discount is included in the price unit. However, adding the product
directly to the SO in the backend displays the discount as expected.
There should not be a difference in behavior between the eCommerce and
the backend.
Fixes#31337
opw-1943989
closesodoo/odoo#31965
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Deprecated accounts are available in the reconciliation widget, while
they shouldn't be.
opw-1949667
opw-1945585
closesodoo/odoo#32304
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
`res.partner.bank` is ordered by sequence, but:
- there is no default value
- there is no widget handle to set it
Therefore, methods such as `_get_partner_bank_id` might retrieve an
unexpected value.
To avoid this:
- we fallback to sort by ID
- we add a default value
- we add the widget handle
opw-1948964
closesodoo/odoo#32300
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set a company on the inventory location
- Create a stockable product, FIFO, real-time, with a cost
- Receive a unit
The product stock value remains zero.
The fact that the inventory location has a company set should not impact
the product cost. This is useful when a scrap location as a company set.
The domain of move selection is incomplete. It should be, for the 'in'
moves:
- coming from a location without company, or an inventory location
within the same company
- going to a location within the same company
For the 'out' moves:
- coming from to a location within the same company
- going to a location without company, or an inventory location within
the same company
opw-1943384
closesodoo/odoo#31485
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create 2 identical SO: one with a quotation template set, the other
without
- Validate them
- Go to the portal at `/my/orders`, access both orders
The order without template redirects to `/my/orders/<ID>`, while the
order with template redirects to `/quote/<ID>`.
Once the SO is validated, there is no reason to show a different page.
The redirection should only apply to non-validated SO.
opw-1925131
closesodoo/odoo#32262
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Lucas Perais (lpe)