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
add option in res_config to have advance mode for call for tender (option was lost in commit: 3d8f7c2f24)
+ fix errors in method that used old po_line state
+ change icon to font-awesome icons
The module system needs to know the dependencies of a given module
before executing the function. This is why the dependencies were
defined once in an array, and then were described one more times in the
call to require.
But a trick can simplify this: the boot function can parse the string
representation of the module and extract the calls to require from it.
It is more work for the processor, but it leads to simpler module
definitions.
this is due to commit 6ed774de61 and a37bad205b which removes the active_id from context if the target==curent which is the case of this widget, we therefore can not use active_id here.
fix#2385
Romeo Fragomeli