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
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>
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
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>
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>
Improved usability & code cleaning:
- Support for blanket orders, in addition of purchase tenders
("Purchase Agreements")
- Create a RfQ in one click, no wizard anymore
- Control of quantities really purchased
- Better control of side-effects thanks to purchase requisition types
- JS code removed (not necessary)
- Workflow removed
Closes#11666
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
clesgow