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>
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
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
purpose of this task is do not set default purchase representative in the purchase order when the PO is created automatically.
When the purchase order is created automatically, this purchase order would be assigned to odoobot.
Odoobot is not a real user. so nobody notified any activity of that purchase order.
so keep the responsible field empty when the PO is created automatically.
Purchase manager can easily filter "unassigned" purchase order and he can assign unassigned PO to someone (real user).
Task-1940489
closesodoo/odoo#31729
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose of the task is some demo data values are not matching with the products
mentioned so update the demo data values with matching product.
Task: 1892754
closesodoo/odoo#28573
In a multi-company environment, the creation of a purchase requisition
fails in a company with ID != 1 because of an empty name.
This is because the sequence is created for the company with ID = 1
only.
opw-1941552
closesodoo/odoo#31153
The purpose of this commit is to make requisition usable with only services. Stock part is extracted in a new module `purchase_requisition_stock` which allows to create requisition based on product availbility or demand, also
we have moved all security access related stock in this bridge module.
Task ID : 1851286
In the demo data, some requests for quotations are linked to the demo
purchase tender, but this one is in draft state. It is inconsistent with
what can be done in odoo, because draft purchase tender never generate
requests for quotation.
TASK-ID 1864372
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
When creating a draft purchase agreement, a reference number was generated even if
we do not click the 'Save' button.
Now, the reference is filled with 'New' at the creation and overided with a proper
reference number after clicking on 'Save'. Also, the prefix depends now of the
requisition type. BOxxxxx for blanket orders, TExxxxx for call for tenders.
Tiffany Chang (tic)