When creating an alternative RFQ, set the source document of the
original RFQ as source document of the newly created alternative.
Part of task-3218314
Part-of: odoo/odoo#119381
It should be possible to modify the custom description of a Blanket
Order line without having to reset it to draft to do so.
Part of task-3218314
Part-of: odoo/odoo#119381
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce the bug:
- Create a PO:
- Add a product
- Add a note or section
- Go To Alternatives:
- Click on “Create Alternative”
- Add another vendor
- Try to validate
Problem:
An error is triggered: “The operation cannot be completed: Description
(name) is mandatory”
The “display_type” and “name” fields must be copied in the vals to
create a `purchase.order.line`
opw-3164863
closesodoo/odoo#115070
X-original-commit: 66f806399d173f53b61db80b81d06a93421c75a3
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
This commit is to replace all uses of activeFields in Field components
by passing fieldInfos to extractProps. We will therefore retrieve the
node-dependent information in the extractProps function.
Why?
This ensures that the info used is that of the correct node. Because the
activeFields function contains the information from the last node that
referred to the same field.
Example:
<tree>
<field name="a"/>
<field name="a" context='{'b':"yop"}'/>
</tree>
For the first field:
FieldInfo.context = {}
activeField.context = {'b':"yop"}
For the second field:
FieldInfo.context = {'b':"yop"}
activeField.context = {'b':"yop"}
Part of task: 3179751
closesodoo/odoo#113874
Related: odoo/enterprise#37621
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- The `picking_type_id` field in the pickings form view is not openable;
- Display the `description` field (optional) in the SVL list view;
- Add the `expiration_date` field (optional) in the quant list views;
- Add a description text for the landed cost;
- Renames field `requisition_id`: "Purchase Agreement" > "Blanket Order"
- In Inventory Adjustment, hides the "Apply All" button is at least one
record is selected;
- In `product_expiry`, renames two views to stick to the XML's coding
guidelines: https://www.odoo.com/documentation/16.0/contributing/development/coding_guidelines.html#xml-ids-and-naming
- For the replenishment:
- Places the field `product_id` as the first option when the user
writes something in the searchbar;
- Renames `route_id`: "Preferred Route" > "Route";
- Renames the button "Automate Orders" into "Automate";
- Set the `route_id` field as "optional=hide" until `mrp_purchase` is
installed (in this case, it will be set as "optional=show") because
in this case, there is at least two routes (Buy and Manufacturing).
task-3076044
Part-of: odoo/odoo#109511
currently on confirming a blanket order will generate a reference for the record using the sequence and once the record is moved to cancel state and clicking the reset to draft button is clearing the already assigned reference number.
and on clicking confirm again will generate a new reference number for the same record.
this pr will stop clearing the sequence number on reset to draft button.
closesodoo/odoo#108574
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
before this commit, on closing/confirming a blanket order by a purchase user throws access right on product_supplierinfo model.
after this commit, access right error will not be shown on confirming and closing the blanket order.
closesodoo/odoo#111896
X-original-commit: 9d86621029a478b8e1cbae4f228fe454a184fba3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce the issue:
1. Install Inventory & Purchase apps
2. Toggle on Settings > Inventory > Purchase Agreements and save
3. Go to Purchase
- [Products] > [Products]: add a product w/ internal reference and w/o
- [Orders] > [Blanket Orders]: create a blanket order with the products
- Save, Confirm and click Print icon to generate the said report in pdf
Desired behavior: Do not show brackets for null internal reference
opw-3138636
closesodoo/odoo#110812
X-original-commit: fb0567ee4fe75d3d0ab2475eaf1c7277ee24636a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
in purchase_requisition and stock module, when deleting a requisition and move, the raised warning says,the deletion can be done only in draft moves, where us the deletion is allowed for the cancelled records also.
improving the user error message to include the cancelled records in the message.
closesodoo/odoo#110340
X-original-commit: b71d298dabb4436182c0eb516d5a7b7e76fca437
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Steps to reproduce:
- Create a service that is subcontracted `service_to_purchase` = true
- Create a SO containing this service
- Go to the newly created RFQ
- Go to Alternatives -> Create Alternative and select a new vendor
- The alternative RFQ doesn't show a link to the SO, nor the SO to this
RFQ
Initially, when the alternative RFQ is created, only the `product_id`
and its quantity is copied to the new RFQ. Now we add the reference to
the SO as well so the RFQ is properly linked to the original SO.
Part of task-2985735
Part-of: odoo/odoo#106411
install purchase_requisition module, and create an RFQ in db, check the alternatives tab in the notebook, currently the button Create Alternatives will not be visible unless user click the save button manually. button no longer needs to be hidden when creating a new PO since v16 added in the auto-save feature
closesodoo/odoo#107733
X-original-commit: a6a830e89c724f993b930442573d8d0c4e692b07
Signed-off-by: Tiffany Chang <tic@odoo.com>
Activate Product variants and create a new products with attributes Legs, Size and color.
Now enable Variant Grid Entry and Purchase Agreements from purchase settings and now create a Blanket Order from Purchase -> Orders -> Blanket Orders with any products from above created variants.
Confirm the created blanked order and click on New Quotation, now a new RFQ will be created, and click on add an item button and select the product we have created before, now Choose Product Variants matrix will be opened. Enter some random quantities in multiple lines and click on confirm button.
Exception will be raised
closesodoo/odoo#106572
X-original-commit: ca94ace181675b6e150c0f7486de9495198dc8e8
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce:
- Create a product with both MTO and Buy routes.
- Create a Sale Order containing this product.
- On the created PO, go to Alternatives -> Create Alternative and select
another vendor.
- Go back to the original Sale Order
- Click on the linked Purchase Order
- Go to Alternatives -> Compare Product Lines
When doing this, the `active_id` in the context is the id of the Sale
Order, which raises an issue in the renderer for this list as it's using
the active_id as if it was the Purchase Order.
closesodoo/odoo#106481
X-original-commit: 1b904ece76f55f8e416d868256720f41cba8ceb1
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
the context passed to the method _get_product_purchase_description for the seller_id is wrong. system is expecting to get product.supplierinfo record set in this context key and from this function res.partner record set is passed, which results in the below error:
Record does not exist or has been deleted.
(Record: product.supplierinfo(70,), User: 2)
closesodoo/odoo#105998
X-original-commit: 6e7f778e1d0dbe4795fa9446bfd3542ecec9815c
Signed-off-by: Tiffany Chang <tic@odoo.com>
activate warnings from purchase settings and open any purchase order and click the create alternatives button from alternatives page. in the next wizard, Warning Messages field is visible always, upon checking the view, it seems the visibility condition given is wrong and thus it get visible always.
closesodoo/odoo#105977
X-original-commit: 40ec1fe8fbaf97faccda7dcd87e308277275bae4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Previous commit 0501bbd62e made it so
the `product_uom_id` for the `line_ids` of a purchase.requsition (i.e. a
blanket order) were no longer being saved when the UoM setting is not
active. This would cause an error to occur when the "New Quotation"
button is pushed because the missing uom is expected by purchase
_onchange_requisition_id.
Steps to reproduce:
- Have UoM setting NOT active
- Create a blanket order for any product/vendor
- Confirm the blanket order
- Click on "New Quotation"
Expected Behavior:
New RFQ created
Actual Behavior:
Stacktrace
We also properly restrict the product_uom_id in the form view of the
line_ids to when the uom setting is active.
closesodoo/odoo#104900
X-original-commit: e90200a7b927ecccb8d4d6f31e3ddecba24d0b6d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, when the quantity of a PO line is changed, its unit
price is recomputed, which means it will be set to 0 if there is no
compatible vendor price for the selected partner/product.
It can be annoying because if the price unit was set manually by the
user, this info is lost.
To avoid that, we don't recompute the unit price if the PO line matches
the following conditions:
- The PO line has already a price unit;
- There is actually no vendor price list for the partner (in such case,
we prefer to avoid to stick to a price who doesn't match that list);
- The UoM wasn't changed, because if the UoM was changed, the price
should obviously recomputed (the price unit for 1 unit is not the same
than for 1 dozen).
How to reproduce:
- Install Stock and Purchase modules;
- In purchase settings, enable "Purchase Agreements";
- Create a product and in its vendor price list (in "Purchase" tab), add
a price for Partner A (e.g. 10$);
- Create a PO for Partner B, add a PO line for the created product and
set the `price_unit` higher than the created vendor price (e.g. 15$);
- Confirm the order and go in the "Alternatives" tab;
- Click on "Create Alternative" and select Partner A as the vendor;
- Click on "Compare Product Lines" and choose the line for Partner A;
- Go back in the first created PO (with Partner B as vendor)
-> the PO line's quantity is to 0, which is good, but its unit price
is also set to 0 which is annoying.
Additionnaly, in `_get_stock_move_price_unit`, `float_round` the value
just before it was returned because previously, the rouding was done
before the multiplication by the UoM's factor which can cause some
rounding issue if the rouding is not done after that.
closesodoo/odoo#104206
X-original-commit: f5a24b10cb3a4cf32c6c185df65f3099c8da3ff1
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
The `analytic_distribution` field is a Json.
It was stored temporarily as a char.
Search is not available yet, so we do queries by hand when we need to search on keys.
Also added a constraint on account_analytic_distribution_model,
so we don't have models with accounts specific to a company when the model has no company or another company.
It would cause an issue when looking at the models from another company.
X-original-commit: 7064c95aa04e5138bb12ae97acfee04ebb67cc0e
Part-of: odoo/odoo#103097
Steps to reproduce:
- Connect with a company that uses the dollar as currency
- Go to invoicing → Configuration → accounting → currencies
- Enable euro currency
- Create a new Purchase Agreement:
- Agreement type: “Blanket Order”
- Currency: “euro”
- Add any product:
- Qty: 1
- Price: 10
- save
- Print → Call for tenders
Problem:
The price is displayed in the current company device instead of the
Purchase agreements currency
opw-2991156
closesodoo/odoo#103067
X-original-commit: 8103d501541db07d0b546d5729e66c9a9915a4d1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Add choices for the business domain on applicability rules, so rules are more precise
Also put 'general' as domain from the view when it's what should have been.
Make analytic field visible since owl migration (for sale and purchase)
closesodoo/odoo#102461
X-original-commit: c5867d5009a7fb448fff1be487b9e9c3e7945d4b
Related: odoo/enterprise#32421
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
`activeActions` is a set of boolean values determining what actions
(i.e. 'create', 'delete', etc.) can be performed on the current view or
subview (x2many).
Before this commit, the x2many fields used a different naming convention
than the one set on the views (e.g. 'canCreate' instead of 'create').
This caused mismatches when subviews would try to rely on the parent
view `activeActions` to define their own. This also introduced a bad
design where the "type" of `activeActions` would be determined by that
same mismatch.
Another issue was that the list renderer did not always check for the
existence of activeFields in its props, despite defining them as
optional.
This commit unifies the names of the active actions accross views and
x2many fields, while adding a "type" property to it s.t. its owner
can determine what context it finds itself in.
closesodoo/odoo#102115
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Adapt to the new css grid for groups. Without this, the values in the
`<p>` are squished into a small fraction of their columns.
Part of task-2985735
X-original-commit: 8544fd84916153ffe903a639f3b88b2e83554337
Part-of: odoo/odoo#102495
How to reproduce the problem:
- Install the purchase_requistion, purchase_requistion_stock, and any Localization modules such as l10n_be or l10n_in
(apart from USD currency any localization module)
- error caught only when at the time of module installation but it must have a different currency_id apart from USD
https://watch.screencastify.com/v/1C7GQKHBASyiluGGkFfV
Cause of the problem:
static values Currency USD cause the problem.
the following module will be set the currency value
l10n_be - EUR
l10n_in - INR
l10n_br - BRL
when we installed the following modules then cls.env.user.company_id.currency_id values get changes accordingly
will lead to this error
Traceback (most recent call last):
File /home/odoo/src/odoo/addons/purchase_requisition/tests/common.py, line 70, in setUpClass
cls.env.user.company_id.currency_id = cls.env.ref(base.USD).id
File /home/odoo/src/odoo/odoo/fields.py, line 1217, in __set__
records.write({self.name: write_value})
File /home/odoo/src/odoo/addons/account/models/company.py, line 301, in write
raise UserError(_('You cannot change the currency of the company since some journal items already exist'))
odoo.exceptions.UserError: You cannot change the currency of the company since some journal items already exist
opw-2945581
closesodoo/odoo#98512
Closes: https://github.com/odoo/odoo/pull/98174
X-original-commit: 70b7c57f7ea0a619a149461e0e738ddc25b822f6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
For original specs, see [1].
Some performance changes: the best price/date/unit price fields are now
loaded by JS instead of passed via action context (allows for easier/
consistent reuse of view + now we can refresh without undoing any state
changes due to buttons being pushed).
[1] https://github.com/odoo/odoo/commit/f533e40f0e3f1cd34f1047b70dfdf95837d84501closesodoo/odoo#101502
X-original-commit: 41ae508c2e6fc3c40b29b1bfc4b5dd7c4440a719
Signed-off-by: Antony Lesuisse <al@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
In order to post on a document, ``message_post_with_view`` should be called
on a singleton recordset. Otherwise it is done as a mass mailing which is
not really what is expected here.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#100137
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When generating an alternative request for quotation from a dropship
purchase, the delivery address is not copied
Steps to reproduce:
1. Install Sales and stock_dropshipping module
2. Go to Settings > General Settings > Users > Manage Users, open user
Mitchell Admin and in the Access Rights tab enable 'Manage Multiple
Stock Locations'
3. Go to Settings > Sales > Quotations & Orders and enable Customer
Addresses
4. Go to Settings > Purchase > Orders and enable Purchase Agreements
5. Go to Sales > Products > Products and edit a product (e.g. 'Acoustic
Bloc Screens')
- In the Inventory tab enable routes 'Buy' and 'Dropship'
6. Create a Sale Order for this product with a different Delivery
Address then the Customer and confirm it
7. Go to the purchase order
8. In the Alternatives tab create an alternative
9. The Dropship Address is not repercuted on the new RFQ
Solution:
Add a method `_get_alternative_values` which sets the dest_address_id
and is extended in `purchase_requisition_stock` to add the
picking_type_id
opw-2880042
closesodoo/odoo#94109
X-original-commit: a7ef5d93650c262497d3a02b934284829cfc5021
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Previously the "call to tender" flow involved creating a
`purchase.requisition` record, creating each RFQ via that record, and
then manually going through each RFQ to compare the prices/dates/etc.
By linking the "call to tender" POs within the POs, we remove an
unnecessary `purchase.requestion` record and makes it easier to track
which RFQs are related to each other as an Alternative RFQ.
On top of this, we add some comparision features to make it easier to
determine the best RFQ, specificially the ability to compare PO lines in
the same view with some visual aids (best price/date colored green +
buttons to check these lines to make them easier to view). We also add
an extra feature to set the qty of selected/non-chosen PO lines to 0 to
aid in the RFQ selection process (only applies to non-confirmed/done/
cancelled POs).
Some other features included with this:
- option to cancel alternative POs when confirming one, which purposely
does not cancel ones that have already been confirmed/completed.
- new wizard for creating alternative POs so user can select whether or
not they want to copy the products/qtys from the original PO.
Important Notes:
- JS Customizations:
- custom many2many widget added so user:
- can click between alternative POs in same window + keep breadcrumb.
This is because all alt POs are interconnected and long breadcrumb
chain is possible (+ we want to avoid windows within windows.) It
is expected that user will be aware that unsaved changes will
auto-save when alt PO is clicked on.
- cannot unlink a PO from itself (this is automagically done during
the write) since this will remove all of its linked POs and might
confuse users.
- custom view js for Comparing Order Lines to help highlight best
options, including ensuring that the best options are still
highlighted after clicking on Choose/Clear buttons (since the best
option can change afterwards, we recalc + update via RPC)
- General implementation warnings:
- Anytime any button/alternative PO is clicked on within a PO, the
form will auto-save. This is due to how the current action service
handles changing views.
- POs created via "Create Alternative" button purposely:
- require a vendor to ensure correct lead times/prices
- show all vendor/product warnings in wizard because we cannot
reproduce the pop-up warning that would occur in the PO when
they are selected. We also purposely block the PO creation when a
blocking warning is set since we cannot remove the values
(especially in the case of a blocking vendor message) from a
newly created PO.
- Technical purchase.order.group model created to help with difficult
management of complicated behaviors:
- unlink from self if a PO is no longer linked to any other POs
- linkages must be symmetric (i.e. linkage PO1 => PO2 must
reflect PO2 => PO1 in their form views)
- don't lose existing linkages (i.e. PO1 => PO2 and PO2 => PO3
should auto-link PO1 => PO3)
These last two behaviors are difficult to do without grouping due to
possibility of remove and adding linkages at the same time. To avoid
complex code to ensure these complexities hold when when creating a
new PO, linkaging to alternatives is not allowed when PO is not yet
saved as a record.
Task: 2695116
Upgrade PR: odoo/upgrade#3586closesodoo/odoo#87656
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Instead of having to repeatedly manually call `onchange_quantity` at
different points in the code, it is better to have it be computed
instead.
- Logic is left unchanged,
- onchange calls from other methods are removed, and
- tests are adjusted to properly handle compute. I.e. remove
'date_planned': datetime.today().strftime(DEFAULT_SERVER_DATETIME_FORMAT)
from when PO lines are created since this sometimes resulted in
inconsistent date_planned values for PO line and the PO date_order
(by 1 sec), which could lead to inconsistently created 'date_deadline'
values for stock_moves' created by PO line qty changes. Issue
previously didn't exist because onchange was not always called.
Part of Task: 2695116 (to avoid adding more onchange calls for new
feature)
Part-of: odoo/odoo#87656
This commit removes the call for tender feature via a
purchase.requisition. This feature is to be replaced with the ability to
directly compare prices/options of POs/RFQs within a PO to remove extra
steps to compare them. The linkage between POs previously provided by a
purchase.requistion is replaced by the POs being directly linked to each
other. Feature to auto-create call to tenders via a product option is
removed and the user is expected to know/be responsible for when they
should do a call to tender themselves.
All references to old Call to Tenders replaced with Blanket Order, and
we remove/rename the menu items since Blanket Order is now the only
purchase.requisition.type option (we expect minimal customizated types).
Follow-on refactoring to switch purchase.requisition to
purchase.blanket.order to come later. Follow-on refactoring to switch
purchase.requisition to purchase.blanket.order to come later.
Part of Task: 2695116
Upgrade PR: odoo/upgrade#3586
Part-of: odoo/odoo#87656
Elisabeth Dickinson