Sometimes it's difficult to track the price of a product, with the
different discounts you can obtain.
Price of products might change often and it's very practical to track
the price at the moment of the order to verify that it's in line with
what you paid in the past.
Also hides the Forecast Report button when a new line is created (and
not yet saved) as the button is disabled anyway without any feedback).
New purchase history button will also hide at creation.
Task-2658786
closesodoo/odoo#78438
Signed-off-by: Tiffany Chang <tic@odoo.com>
- Fix typo in accrued_orders.py
- Remove fields.Date.today() from purchase test
- Make more use of common resources
closesodoo/odoo#79159
X-original-commit: 31570e185dcb36145e28e42cda765284dc373294
Signed-off-by: Laurent Smet <las@openerp.com>
Before, when a foreign VAT fiscal position was used on a purchase order or sale order, no filtering was applied on the available taxes. We now make their behavior consistent with the invoices'.
Part-of: odoo/odoo#79144
When printing a sale order or a purchase order using a foreign VAT fiscal position, the domestic VAT was always used on the pdf report instead of the foreign one.
Part-of: odoo/odoo#79144
Steps to reproduce:
* Create PO
* Confirm Receipt Date
* Cancel PO
* Draft and Confirm again
Current behavior:
* Button for Confirm Receipt Date is not visible
Expected behavior:
* Button for Confirm Receipt Date should be visible
This is happening as we are not resetting the value of `mail_reminder_confirmed` on cancelling PO.
With this commit, we reset value of `mail_reminder_confirmed` so use can Confirm Receipt Date again.
closesodoo/odoo#79122
X-original-commit: 9e48afe5bf4f52b7cc2705fe434b4647df752a59
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Selection of multiple companies to view multi-company data was added
in v13, but at the time there was no way to have reports correctly
take into account currency rates when also working with multi-currency.
v14 onwards is able to correctly apply the currency rates, therefore we
fix the purchase report to do so.
Steps to reproduce:
1. Start with existing demo data + add a new company with currency = EUR
2. Activate multi-currencies + set a currency rate (not 1) for Euro to $
3. Open Purchase Report (Purchase > Reporting > Dashboard)
4. Activate demo company + new EUR company
5. Switch between USD and EUR company as selected company
Expected result:
Dashboard monetary quantities switch between $ and EUR, i.e. both the
amount changes according to current exchange rate and symbol.
Actual result:
Currency symbol changes, but amount stays the same.
closesodoo/odoo#79001
X-original-commit: 083a3776835b471dbbd6dedc44f233a6cf5d7cc8
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
It seems that this long dereference causes a MemoryError for accounts
with many associated line_ids
```
select count(*) from account_analytic_account a join account_analytic_line l on l.account_id = a.id join account_move_line ml on ml.id = l.move_id where a.id=7
+---------+
| count |
|---------|
| 131672 |
+---------+
```
The solution we propose is to use search_read inverting the order of
dereferences.
Shortened Traceback:
```
Traceback (most recent call last):
...
File "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/15.0/addons/purchase/models/analytic_account.py", line 15, in _compute_purchase_order_count
account.purchase_order_count = len(account.line_ids.move_id.purchase_order_id)
...
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 893, in update
field_cache.update(zip(records._ids, values))
MemoryError
```
Observed during the upgrade of 41031
We can reproduce this pref issue locally.
On the menu Accounting > Configuration > Analytic Accounting > Analytic Accounts, with 1 million account moves
```
test_15.0=> select account_id,count(*) from account_analytic_line group by account_id
+--------------+---------+
| account_id | count |
|--------------+---------|
| 1 | 1000002 |
+--------------+---------+
```
We get (shortened):
```
2021-10-19 07:39:33,807 53565 INFO test_15.0 werkzeug: 127.0.0.1 - - [19/Oct/2021 07:39:33] "POST /longpolling/poll HTTP/1.1" 200 - 9 0.077 50.063
2021-10-19 07:39:33,888 53565 INFO test_15.0 werkzeug: 127.0.0.1 - - [19/Oct/2021 07:39:33] "POST /longpolling/im_status HTTP/1.1" 200 - 4 0.038 0.044
2021-10-19 07:40:05,916 53565 WARNING test_15.0 odoo.service.server: Thread <Thread(odoo.service.http.request.140269940897536, started 140269940897536)> virtual real time limit (178/120s) reached.
2021-10-19 07:40:05,921 53565 INFO test_15.0 odoo.service.server: Dumping stacktrace of limit exceeding threads before reloading
2021-10-19 07:40:06,296 53565 INFO test_15.0 odoo.tools.misc:
File: "/usr/lib/python3.8/threading.py", line 890, in _bootstrap
...
File: "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File: "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File: "/home/odoo/src/odoo/15.0/addons/purchase/models/analytic_account.py", line 15, in _compute_purchase_order_count
account.purchase_order_count = len(account.line_ids.move_id.purchase_order_id)
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 2605, in __get__
return self.mapped(records)
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1176, in mapped
self.__get__(first(remaining), type(remaining))
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 2603, in __get__
return super().__get__(records, owner)
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1081, in __get__
recs = record._in_cache_without(self)
File: "/home/odoo/src/odoo/15.0/odoo/models.py", line 5901, in _in_cache_without
return self.browse(ids)
File: "/home/odoo/src/odoo/15.0/odoo/models.py", line 5149, in browse
ids = tuple(ids)
File: "/home/odoo/src/odoo/15.0/odoo/api.py", line 952, in get_missing_ids
if record_id not in field_cache:
```
closesodoo/odoo#78615
X-original-commit: 6077c9358fe650bcdc23e8d6a9432f639fca1b40
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
steps to reproduce the bug:
- Go to inventory > products > Create a new Product from ```product.template```
- Assign two vendors to the record
- Go to inventory > products > product variants > select the newly created product
- Remove any vendor and save
Problem:
An error indicating that the record ```product.supplierinfo``` does not exist or has been deleted will be triggered
In the ```product.product``` model, we have two One2Many fields ```seller_ids``` and ```variant_seller_ids```
which both point to ```product.supplierinfo```.
When we save, the write method will be called and will first delete the seller with seller_ids
and then try to update with variant_seller_ids but as both fields point to the same field,
the seller will already be deleted and an access error will be thrown
Solution:
As the two fields are never displayed at the same time in the view.
We can use the same invisibility condition to make them read only to prevent them from being both updated at the same time
opw-2661082
closesodoo/odoo#78464
X-original-commit: acdd6ef720e837097d68032082209b619dba44d9
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
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
* order lines are now not grouped anymore by account. That allows a more detailed label on the accrual entry line, as it's now directly related to a single order line
* we now create a single accrual entry counterpart, instead of one per order previously. That reduces the 'noise' in the accrual entry, at the cost of not having the sum per ordre anymore easilly but it doesn't seem to be important to audit that account
closesodoo/odoo#76037
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
*: mrp_subcontracting_purchase,payment,purchase_(stock)
BEFORE THIS COMMIT
fa-shopping-cart was used for different purchase-related contexts.
This icon should only be used for online shopping / ecommerce.
AFTER THIS COMMIT
Wa make sure one icon is used for one concept.
- fa-shopping-cart : ecommerce / add to cart
- fa-credit-card : purchases
- fa-credit-card-alt : replaces other uses of fa-credit-card
- fa-pencil-square-o : quotations in marketing modules
Icons are updated accordingly. Other icons are also changed to
increase readablity.
--- Links ---
Task Id - 2593306
COM PR - odoo/odoo#75694
ENT PR - odoo/enterprise#20478
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We clean various graph archs taking into consideration that:
- the default type of a graph is "bar".
- a bar chart is by default stacked.
- the field attributes type="row" and type="col" does not make sense for
a graph view (since its implementation was separated from the pivot
implementation a long time ago))
- the boolean attributes should now take 1 or 0 as value (but the other
values are accepted for retrocompatibility).
Part-of: odoo/odoo#76065
This allows to solve the following use case:
* we are in March
* a SO created during January shows currently a delivered quantity (timesheet on service or delivered goods on storable products): timesheets/pickings were done in February
* creating the accrued entry for January 31 should display accordingly an amount of 0 by default since everything was done in February
Invoices invoice_dates are also taken into account:
* day 0 : delivered 10
* day 2 : 5 invoiced
* accrued entries for 10 if accrual date = day 1, accrued entries for 5 if accrual date = day 3,
followup of task 2255642
closesodoo/odoo#75886
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
A new field on tax groups makes it now possible for this group to be displayed under a subtotal label. If not set, this defaults instead to "Untaxed Amount", keeping the traditional behavior. This is intended for withholding taxes, which can now be implemented with negative taxes and a tax group with this field set.
To do that, this commit entirely refactors the way amount_by_group worked, and replaces it with a more complete json field called tax_totals_json. It also streamlines the way taxe totals are displayed on invoices, PO and SO and makes it so that a common code is called instead of copy-pasting the same block 3 times as before.
[IMP] purchase: always display tax totals by groups on purchases orders
Before, tax totals on purchase.order's form were not shown by group, and were instead all aggregated in a single "Taxes" category. The same went for the pdf export. The portal view, though, did show the totals by group. We now display the tax groups in the same way all the time.
closesodoo/odoo#74138
Task: 2457374
Related: odoo/enterprise#19802
Related: odoo/upgrade#2670
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
* = crm_livechat, hr, hr_holidays, im_livechat, mail_bot, purchase, sms,
snailmail, survey, test_discuss_full, test_mail, web_editor, website,
website_livechat
- Create new model `mail.guest` for guests.
- Rewrite some RPCs to target routes rather than model methods so that
guests are able to use them.
- Patch JS and python models to support guests.
- Create a stand-alone page and boot the channel in it.
task-2494829
closesodoo/odoo#75496
Related: odoo/enterprise#20417
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The raised error currently displays the internal state (e.g. 'purchase'
instead of 'Purchase Order') and therefore is not translated.
Task-2428819
Part-of: odoo/odoo#74364
Be able to search origin and move origin in a notebook page to avoid
issue if the origin is too long (in case of multiple MO with semi
finished products)
opw-2625476
closesodoo/odoo#75144
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Accrued liabilities, or accrued expenses, occur when you incur an expense that you haven’t been billed for (aka a debt).
For example, you receive a good now and pay for it later (e.g., when you receive the invoice). The same opposite approach for sales.
Why do accountants need such entries ?
- Accounting must give a fair view of the financial situation of a company. The loss/profit must be booked regarding the effective deliveries of goods/services, not on the paperwork only.
- On a fiscal point of view, if you want to be allowed to deduct a loss from your taxable basis, it has to be in the right period. If you didn't announce it on time, the loss might be rejected by fiscal authorities. Same goes for the augmentation of the taxable basis, it has to reflect real deliveries and not only paperwork.
was Task: 2555642
was PR #73707
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
In this commit some reorganization is performed within mail compose message
code. Purpose is to reorder a bit methods by main usage: onchange, CRUD,
actions, values generation with rendering and template management.
Some renaming is performed on action methods, notably send_mail that has some
impact on sub-addons. Finally we also set onchange and sub-onchange methods
private.
No functional change should be implied by this commit.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
On the purchase dashboard(s) the context would never be passed on the
rpc calls that load the upper panel, which caused the result to always
be as seen from the default company.
Closesodoo/odoo#74882
Task ID: 2610547
Related: odoo/enterprise#20145
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce the bug:
- Go to purchase app > create a request for quotation
- click on confirm > Lock
Problem:
Date confirmation becomes invisible, and date order becomes visible
Solution:
As we have already confirmed the purchase order and the lock button only appears when the PO is confirmed,
it makes sense to leave the confirmation date visible
https://github.com/odoo/odoo/blob/13.0/addons/purchase/views/purchase_views.xml#L138-L139
opw-2612608
closesodoo/odoo#75014
X-original-commit: ebf6708b5962a54e9fbed133596dcdfdd204e33d
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
- A typo has been introduced by the PR https://github.com/odoo/odoo/pull/61035
This forbids to display the "Waiting For bill" tag on the portal
page for the purchase orders.
closesodoo/odoo#74888
X-original-commit: 0b9d9ff95d2ee9a72b10ddff006399a054bfa56c
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
When the Product Price precision is greater than the currency precision,
it can lead to incorrect data
To reproduce the error:
(Enable debug mode)
1. Settings > Technical > Database Structure > Decimal Accuracy, edit
Product Price:
- Digits: 3
2. Create a PO
- Add a product:
- Quantity: 12
- Unit Price: 0.001
3. Save, Confirm, Edit the PO:
- Qty Received: 12
- (Note that the total is $0.01)
4. Create a bill:
- Add the PO to the field "Auto-Complete"
Error: The unit price is $0.000 and so does the total
The rounding of the unit price should be based on the Product Price
precision, not the currency precision.
OPW-2601867
closesodoo/odoo#74813
X-original-commit: 1123856c77cce4b69059b63c2bcbb382c7f0719e
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Steps to reproduce:
- Install purchase and accounting apps
- Set the database to a language that is not English
- Create a purchase order
- Remove purchase representative from PO (otherwise, no issue)
- Action -> Create Vendor Bill
- From the vendor bill, print invoice
Issue:
The pdf is in English (country names, date labels, etc...)
Cause:
If invoice type is `in_invoice` or `in_refund`, it will use the
`invoice_user_id` language (object.invoice_user_id.sudo().lang).
In the above case, there is no invoice_user_id on invoice.
Solution:
While preparing invoice values, set invoice_user_id to
self.env.user.id if not user_id on PO.
opw-2510134
closesodoo/odoo#74671
X-original-commit: 4b7569ce641a6fb20d5df676bf0b315d9b9d485d
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Steps to reproduce:
- Create Bill from Purchase order
- Raise Refund for the Same Bill
Current Behavior before commit:
Field Unit Price is readonly in PO line as invoice is already created.
Expected behavior:
Price should be editable as Qty Invoiced is Zero after Refund.
With this commit, Price unit will be readonly based on `qty_invoiced`
closesodoo/odoo#74526
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to Reproduce Bug:
- Create PO
- Remove default Currency
- Add a Line
Bug:
```ValueError: Expected singleton: res.currency()```
With this Commit, we are using default currency to round amount.
closesodoo/odoo#74234
X-original-commit: d9ff2e8ec7200aa15830e92e5083251c4e81dd1c
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Currently, there are many useful pivot views on reporting models but most
of them lacks the dedicated list view. Dedicated list views will allow users
to see useful information when one directly drill down to the records from
the pivot table in odoo spreadsheet [1].
With this commit
1. we remove 'disabled_linking' attribute from the very important pivot
and graph views (see the full list on task pad);
2. we added dedicated list views for the following reporting models
- account.invoice.report
- fleet.vehicle.cost.report
- hr.timesheet.attendance.report
- purchase.report
- project.profitability.report
- report.membership
- report.pos.order
- report.project.task.user
- sale.report
Task-2547881
[1] See task-2506116
closesodoo/odoo#72394
Related: odoo/enterprise#19122
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit: when purchase order kanban view grouped then it is not displayed
below dashboard value div, it is displayed besides it so grouped kanban view is not
displayed and screen has horizontal scroller, to view kanban view user have to
scroll screen.
after this commit: purchase order grouped kanban view will be displayed below
dashboard value div.
task-2366797
closesodoo/odoo#74408
X-original-commit: 067bb35a9aee5db750a6cc4e0d42022b6b7c3e02
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Purpose of this commit is to avoid forcing mail_post_autofollow to True when
it is set to False. It eases inheritance and custom behavior.
Task-2612911
PR odoo/odoo#60792
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>
Steps to reproduce the bug:
When sharing the RFQ link to a vendor, the price unit was displayed.
The price shouldn't be displayed if the PO is not confirmed.
opw:2547660
closesodoo/odoo#73681
X-original-commit: 4e2fd7552d5fd7fb1daeb65abffe11d42add09fb
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When adding several PO to a bill, if they don't have the same currency,
it will lead to incorrect amounts
To reproduce the error:
1. In Settings, enable "Multi-Currencies"
2. Invoicing > Configuration > Currencies:
- EUR: Active, Current Rate = 2
- USD: Active, Current Rate = 1
3. Create a PO:
- Currency: USD
- Products:
- One product, no taxes, unit price 1000
4. Confirm PO
5. Edit PO:
- Qty Received: 1
6. Repeat 3 -> 5 with EUR instead of USD
7. Open a new Bill
8. Add the first PO to the field "Auto-Complete"
9. Add the second PO to the field "Auto-Complete"
Error: Both invoice lines are now expressed in EUR and both subtotals
are equal to 1000 even though the exchange rate isn't 1
This commit suggests not to change the currency of the account move if
the latter already has some AML. Moreover, the amounts must be converted
if they come from a PO that uses another currency
OPW-2573748
closesodoo/odoo#73483
X-original-commit: b299e880417026688b2fbde23307bd011de8c44d
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Issue:
For purchase user, which doesn't have the "Contact Creation" can't
create a purchase, get a AccessError.
The fields `receipt_reminder_email` and `reminder_date_before_receipt`
should be writable also for purchase user which doesn't have access
to write and create `res.partner`.
closeodoo/odoo#64135closesodoo/odoo#73131
X-original-commit: f29b1e81e6adf8532ecf90f9ecb675ec56eb4c61
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
clesgow