[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
``import odoo.addons.foo as bar`` doesn't seem to properly trigger the
import hook in Python 3 (it blows up on decimal_precision and
base). Thus convert *all* examples of that pattern to the more
sensible ``from odoo.addons import foo as bar``.
As picking types aren't always used in a picking context, and picking
aren't really meanigful for a lot of people, we rename this concept as
"operation type" in views and in the planner.
ir.needaction_mixin is not used anymore by the webclient.
From 9.0, the concept has changed: this feature is now
available in mail module, with the mail.thread mixin,
and message_neeadction field.
Remove all code handeling needaction bullet and
counter on ir.ui.menu, knowing that since 9.0
webclient does not display the counter anymore.
This code was, thus, useless and some RPC calls
were done for nothing, and adapt accounting
reconcialiation widget.
During the conversion to the new api,
the method `product.uom`.`_compute_price` has had its signature
changed.
Formerly, it was:
`def _compute_price(self, cr, uid, from_uom_id, price, to_uom_id=False):`
Now, it is:
`def _compute_price(self, price, to_unit):`
Basically:
- the first argument `from_uom_id` is removed, and you now should
call this method from the model record directly
- the last argument is no longer a kwargs
Some calls to this method were still done the former way:
- Some have been added during forward ports
- Some are oversights when this method has been converted to the new api
This revision corrects the calls that were still done the former way
to the new way.
opw-694871
product_uom._compute_quantity is an ensure one multi method taking a browse
record as second paramter. It replaces _compute_qty and _compute_qty_obj
to have a single and standard computation method.
product_uom._compute_price() is now an ensure_one multi methods, taking
a browse record as second unit. This helps simplifying and unifying the
various calls and price computation methods.
Christophe Simonis