Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
Purpose: improve understanding of partner and product models as well as their
daily use. This is done by improving tooltips and labels of some fields
according to business logic.
This commit is related to task ID 1880696 and closes PR #27133 .
Thanks to @xmo-odoo for its in-depth review.
…eduler"
Steps to reproduce the bug:
- Let's consider P a product with routes "buy" and "mto" and with
purchase_requistion = 'Propose a call for tenders'
- Let's consider a BOM B with P as component
- Create a MO for B
- Run the scheduler two times
Bug:
Two purchase agreements have been created for the the same MO.
opw:1882280
Purchase agreements create request for quotation with prefilled field.
The issue is:
date_planned (on RfQ) is filled from schedule_date (on PA). The first
one is a datetime object. The second one is a date object.
This commit makes a right conversion between datetime and date at the
RfQ creation. This issue was introduced by the datetime refactoring
(#24717)
Task id: 1878136
Purchase orders created from purchase agreement behave differently depending on
the agreement type.
On one hand, if the agreement is a blanket order, the vendor must be set automatically on the
purchase order and be the same as the BO. Changing the vendor is forbidden.
On the other hand, if the agreement is a call for tender, multiple purchase order can be
created with different vendors. It that case, the vendor field must be editable in RfQ states.
This commit is related to task ID 1866975.
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
Steps to reproduce the bug:
- Create a product P with routes MTO and BUY
- Set a vendor V on this product
- Create a BOM B with P
- Create a MO M with B
- A RFQ is created with M as origin
- Create a purchase requisition PR with vendor V
- Set PR as purchase agreement on the RFQ
Bug:
- The field origin with M was erased by the name of PR
- The field partner_ref was erased by the name of PR
The fix is inspired by: c914df5a36
opw:1860430
[IMP] purchase_requisition : add analytic_tag_ids field in purchase requistion
[IMP] sale: set analytic tags on invoice based on the analytic tags defined on SO
[IMP] account_analytic_default: add default analytic tags to invoice lines created from SO for down payment
(#23110)
As the sequence name depends on the requisition type. The name must be
set not when the requisition is in draft but confirmed. In the confirm
state, the type in readonly. The name is also reset when the requisition
is put in draft.
When the user decrease the quantity on the SO it will log the
activity on a the upsteam documents however the user can't easily
find the impacted documents linked to it. In order to achieve that
the _get_upstream_documents_and_responsibles method pass a stack
that remember all the documents browsed in order to return the final
document. This stack is then passed in the _render_method in log activity
in order to use it when rendering the note for the activity.
return the linked requisition line and the responsible for the requisition
instead of returning the origin moves. there should be nothing upper
the requisition itself so we don't need anymore to grind documents in order
to find the upstream one. More information about _get_upstream_documents_and_responsibles
in method _log_activity_get_documents in stock_picking.py
If two blanket order are active with the same vendor, we have to produce
two separate purchase orders even if the two products are ordered in the
same operation.
If the parameter multi currency is enabled, the field currency is added
in the purchase requisition form. The currency chosen will be the one by
default in the PO attached to the BO
If a there is blanket order in 'ongoing' state and linked with the purchase
order's vendor, we can choose associate it to the PO to retrieve the contrat
price and impact the ordered quantity.
If a purchase order is created from a blanket order, the vendor is
linked to the BO reference. So we forbid its edition once its choose.
When creating a blanket order, it will generate a supplier info for the
associated product. If there is already a supplier info for the same product
and same vendor, the sequence should be adapted to take the one created via
blanket order before the other(s) one(s).
The stages workflow of purchase tender is not suitable for blanket order.
the steps bid selection is use only with purchase tender. Now :
PT : draft -> confirmed -> bid selection -> closed
BO : draft -> ongoing -> closed
The blanket order is a contract between you and a supplier on a
different
price (usually lower than normal) for a big quantity of some specific
products.
The goal is to generate a supplier info for each product of the blanket
order and
remove them when the BO is either closed or cancel.
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.
The vendor is now a mandatory field in the blanket order form
because it's directly linked to purchase orders. So Odoo needs
to know to which supplier the PO is addressed.
Instead of just using create_uid as responsible, use a plain user_id
field for the PO and PO agreement responsible. This field is named
purchase representative but works like SO responsible and is now
tracked.
Field is added to various views and filters to ease the daily job
of purchase representative people.
Closes#17788 .
Previously mrp, stock and purchase used _run methon on procurement
group and start with a if checking for the action type. This commit
instead launch a specific method depending the rule's action's type
Also _run method and their submethod used in procurement group
was always called with a rule. Thus we choose to move this method
on the rule object himself.
This removes the procurement.order model. To fufill their needs SO, PO, MO and
stock moves now call the _run method of the relevant procurement.group.
This mecanism is now only used for stockable product, tasks now uses their own
independent mecanism.
The _run method will check all the applicable rules and create directly the
needed model to fufill the need.
The modules stock, purchase, mrp, extends the _run method to implement their
specific strategy relevant for the rule type they define.
If an exception happens the message will be logged as a mail messsage on the
source model, for example, if a sales order cannot be fufilled the salesperson
will now see directly the reason.
OLD commit messages:
[WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
fixup! [WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
[IMP] Basic tests
[FIX] test not necessary anymore
[FIX] remove unnecessary print statement
[FIX] unnecessary test + why passing warehouse worked before?
[IMP] purchase: one move by purchase order line
[FIX] purchase: correct inventory tests and pass move_dest_ids among procurements
[FIX] because of bad cherry-pick merge
[IMP] make mrp pass by adding move_dest_ids there too
[IMP] tests of sale_mrp, no need for cancelpropagation then
[IMP] better to consistently use recordsets also for one2many
[FIX] purchase_requisition
[FIX] Exceptions should trigger errors, which should be caught in the tests
[FIX] sale_mrp: remove usage of procurement.order and use sale order name instead of sol
[FIX] stock_dropshipping: add sale_line_id on purchase_line_id
[FIX] Remove pdb
[IMP] add stock_dropshipping files
[IMP] stock: search carrier through sale line instead of procurement group
[IMP] add procrule test and preision needed when updating sol
[FIX] sale_order_dates + [IMP] procurement exceptions by scheduler
[FIX] No need to return task
[IMP] move file as name changes and add corrections
[FIX] Continue Run Schedulers wizard fix
[FIX] name issues of takss
[FIX] updating sale order line, but there is still a problem with the recompute
Nimesh Jethva