Suppose a product with several suppliers, all with the same partner. On
the purchase order, the product description will always be based on the
last supplier
To reproduce the issue:
1. Create a vendor V
2. Create a product P:
- Type: Storable
- In Purchase, add a line L01:
- Vendor: V
- Vendor Product Name: Name01
- Vendor Product Code: C01
- Quantity: 1
- Price: 10
- In Purchase, add a second line L02:
- Vendor: V
- Vendor Product Name: Name02
- Vendor Product Code: C02
- Quantity: 20
- Price: 2
- Once P is saved, ensure the lines order in the purchase tab:
- L01
- L02
3. Add a reordering rule on P:
- Min: 1
4. Run the scheduler
5. Open the generated PO
Error: The description is incorrect ("[C02] Name02" instead of "[C01]
Name01")
When computing the display name of the product,
https://github.com/odoo/odoo/blob/7691567286869ca65e63fc79c2cee11e1f415fcb/odoo/models.py#L1728-L1730
`name_get` returns a tuples list: `[(37, '[C01] Name01'), (37, '[C02]
Name02')]` where `37` is the product identifier. This list is then
converted into a dictionary and here is the issue: it will use the last
tuple to define the value for key `37`, i.e. "[C02] Name02". Therefore,
`name_get` should return the correct name, and only this one.
Another issue could be highlighted: when the user changes the quantity
of the purchase order line, if another supplier info is selected, the
description won't be updated (for the same reason as above)
OPW-2702616
closesodoo/odoo#82321
X-original-commit: a42608214f2e9ef3f5e59b4b54cd7f72a6019e06
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Expected behaviour
The order date on the Purchase Order report (printable pdf) should be the
confirmation date if available and the order deadline else.
Observed Behaviour
The order date on the PO pdf is the order deadline of the RFQ, no matter
if the oder has been confirmed or not.
Reproducibility
This issue can be reproduced following these steps:
1. Create a new RFQ
2. Set an order deadline different from the current day
3. Confirm the RFQ
4. Download the printable PDF (as pdf) and check the Order date
Related ticket
- opw-2696794
closesodoo/odoo#82267
X-original-commit: 91d0354
Signed-off-by: Arnold Moyaux <arm@odoo.com>
The translation of purchase.order().notes name (Terms and Conditions) is
wrongly done in bulgarian since 2016
(d14efd562b).
opw-2719178
closesodoo/odoo#82005
X-original-commit: b0be51f8b2fc1c9422aa543d03a321936bb8f667
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Scale up game has been printed with the quantity show by default on the
supplier info. So we copy that behavior in standard for educational
purpose and avoid to print again all the scale up.
Also it's better from a usablity point of view since it's an important
information.
opw-fp
closesodoo/odoo#81774
X-original-commit: 4a47727c68a9f5c66ad9d7656f499b4e760f315c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Context
-------
On some database, record rule may be configured in such a way
that user are able to read Purchase/Sale order
with a company_id != user.company_ids
Issue
-----
This commit https://github.com/odoo/odoo/commit/4dd150950274b1d7c3b24b7665443318f94323f6#
introduce a new field tax_country_id that require to be able to read
the fiscal.position as well.
The reading of a sale.order or purchase.order should not require the
right to read the fiscal.position for the computation of a technical
field only use during the modification.
Solution
--------
Compute tax_country_id as sudo
closesodoo/odoo#80049
X-original-commit: b329c3b18197ac6db5ffdf3cb4945a14997a1f0b
Signed-off-by: Olivier Dony <odo@odoo.com>
Signed-off-by: Thibault Francois <tfr@odoo.com>
Since 6f182eeeab UoM should be created through the UoM category tab as the UoM form view is now unusable.
To ensure that this is the case, we remove menu link to the form view and update the other to lead to UoM category instead.
opw-2702953
closesodoo/odoo#81221
X-original-commit: 58a3954d606d48b2a4cf678eb0bf13d6e28b1aef
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
When consulting the Purchase Analysis, the measure "Days to Confirm" may
not be easily understandable
To reproduce the issue:
1. Create a purchase order PO:
- Order Deadline: <today + 10 days>
- Add 2 products
2. Confirm PO
3. Purchase > Reporting:
- Measures: Days to Confirm
- Group By: Order
Error: For PO, the value of "Days to Confirm" is -20, it should be -10
The report computes the sum of the delay (i.e., "Days to Confirm") of
each purchase order line. Computing an average seems more relevant
A similar flow could be reproduce with the measure "Days to Receive"
(i.e., the difference between the Order Deadline and the Receipt Date)
OPW-2678673
closesodoo/odoo#81053
X-original-commit: da3fa1f8887e06e7a86e761ef844f79cc0d06e6f
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
- Adds a default `product_id` only when the supplier info is added from
a product variant form view;
- Adds a domain on `product_id` to constrain the field to its product
template, and only if it has a product template (otherwise, there is
no domain);
- Adds a onchange to remove the product variant if the user changes the
product template and they don't match anymore because before this
commit, it was possible to have a supplier info with a variant who
doesn't belong to its supplier info's product template;
- Replaces the options `no_create_edit` by `no_create`/`no_open` as the
former doesn't work as expected.
task-2581265
Part-of: odoo/odoo#74695
Editable computed fields need to have their own compute
method.
Otherwise, when providing one of the two fields at create/write time
will not be taken into account because the compute method will be
triggered for the other field.
closesodoo/odoo#77912
X-original-commit: e35dc4c87821bbb668657eed99bb51c1f853c208
Related: odoo/enterprise#21685
Signed-off-by: William André (wan) <wan@odoo.com>
RATIONALE
Currently we can specify email used for notification layouting through context
use in mail composer. It is then propagated to message_post, stored on
mail.message and used to encapsulate emails sent based on posted messages.
SPECIFICATIONS
On template model: rename ``notif_layout`` parameter of ``send_mail`` to
``email_layout_xmlid`` to be coherent with naming used in other parts of the
code. Moreover it better indicates we expect an xml id.
On rating model: rename ``notif_layout`` parameter of ``rating_send_request``
to ``email_layout_xmlid``, for the same reasons as above.
In various wizards: support ``email_layout_xmlid`` context key when no field
is available, notably because this is still done manually in some wizards
like survey invite. Keep a fallback on ``notif_layout`` but remove support of
``custom_layout`` deprecated since quite a long time.
Task-2621326 (Mail: add 'view' button in 'light notification template')
Task-2647302 (Mail: add layout field in composer)
Part-of: odoo/odoo#76418
RATIONALE
Currently we can specify email used for notification layouting through context
use in mail composer. It is then propagated to message_post, stored on
mail.message and used to encapsulate emails sent based on posted messages.
SPECIFICATIONS
Get rid of context usage (``custom_layout``) and use a real field on composer
model: ``email_layout_xmlid``. Use now a default value coming from context
(default_email_layout_xmlid) instead of custom_layout.
Support old context key in composer for backward compatibility, working like
a default value for the field itself.
Task-2621326 (Mail: add 'view' button in 'light notification template')
Task-2647302 (Mail: add layout field in composer)
UPG odoo/upgrade#2829
Part-of: odoo/odoo#76418
No longer converts the date_planned of a purchase_order_line to the
middle of the day. In case of multi-steps receipts, this caused a
discrepancy between the actual receipt and the later internal transfers.
Let's say a reordering rule is triggered :
- The date is set to midnight for the procurement, so the internal
transfer's date is set to midnight as well.
- The date is increased to noon for the PO line, which define the PO
planned_date, which define the linked receipt picking.
- So in the end :
- Receipt is planned to day X at noon.
- Transfer from Input -> Stock is planned to day X at midnight.
Task-2656397
closesodoo/odoo#79523
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The "Auto-complete" bills field does not show all POs for the Vendor that are waiting for invoices.
To reproduce the issue:
- Create PO1 Vendor = "Supplier"
- Create PO2 Vendor = "Supplier, John Doe"
- Create Invoice for PO2
- In the PO2 Invoice, "Auto-Complete" field try to select PO1, but it is not shown.
The "Auto-complete" bills field should show all POs for the Vendor that are waiting for invoices.
The problem is that the field's domain filters is using the partner_id
field when it should be using teh commercial_partner_id.
opw-2684409
closesodoo/odoo#79438
X-original-commit: d3002116e665d799ba11b9f94e4b45bc4c39bde5
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Reproduce :
1. Add a default analytical rule: if Coin Gourmand partner then Administrative analytical account
2. Create a PO at the Coin Gourmand supplier, add a product, and select the Internal analytical account.
3. Bill for this product.
Result :
Internal analytical account has disappeared from the invoice line. It has been replaced by Administrative.
Issue :
AccountMove.create() computes an account in the move and this causes the analytic account to be reset at its default value from the rule.
Fix :
Since the account pocalypse in 13.0, account.move is making magic things during the creation of the invoice to create dynamically the invoice lines like account.invoice did before this huge refactoring.
The create is making a 'New' record to simulate the onchange but this code is a hack triggering unexpected recomputation like the analytic account.
To avoid that, we ensure to assign the minimum number of fields to preserve fields like the analytic account.
closesodoo/odoo#79321
X-original-commit: 876e2d1073312fe65cb6b2e3038235aeaa082c8a
Related: odoo/enterprise#22074
Signed-off-by: Laurent Smet <las@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
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>
Adrien Widart