- Create a PO, order 5 items
- Validate Receipt with 5 items
- Return 1 item to Vendor
- Update Order Quantity on PO, from 5 to 8
A picking of 3 units is created.
If the same workflow is used in Sales, a picking of 4 units would be
created, which is the expected behavior.
We adapt the logic of Sales [1] to Purchase.
[1] https://github.com/odoo/odoo/commit/8a3284685856b6980e3b620abdbbb3e2c79f57c4
opw-2233826
closesodoo/odoo#51174
X-original-commit: 74e8b9ab2311ed2c1c9cea53d09e3b352db3dbe6
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create a product P with a subcontracted BOM
- Create a PO for P, 10 units
- Receive 10 units
- Return 3 units and specify 'To Refund'
13 units are considered received.
The reason is that we don't return to a vendor location, but an internal
location.
We subtract the quantity when the following conditions are met:
- we ask for a refund
- we return to an internal location
- the return location is not in the warehouse of the move
The solution is similar to odoo/enterprise#9647
opw-2235157
closesodoo/odoo#50119
X-original-commit: 5fd6c5b65e00dcac77b232b9f47b2292d86c6b0f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Set the padding on the write for date. Modify the text to be consistent
with the manual and automatic orderpoint. Explains the min, max
and quantity to order mechanism.
closesodoo/odoo#48536
Task: 2161378
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Allow to set a BoM or a vendor on an orderpoint. In this case it's
passed to the values and will be processed by _run_buy and
_run_manufacture to use them.
Task: 2161378
Set a default route on orderpoint created by the replenishment report.
First it select the first route on the product if it exists (it's
uselss since it's a preferred route on the report but it's used for
clarity). If the product has no route then it tries to guess it
with vendor pricelist or BoM on the product.
Task: 2161378
New report to easily order missing products in each warehouse.
Orderpoint have a new type: 'manual'. Manual orderpoint are not
trigger by the scheduler but the user could create replenishment
from the report directly. The report use the forecast report in
order to detect missing quantity for today (it does not search
depending the lead time for each product warehouse due to lake
of performance). It compares missing quantity with incoming RFQ
and other ongoing orderpoint. If it still missing a new entry
for replenihsment is created (it's also automaticaly deleted if
the replenihsment has been done another way).
Task: 2161378
Added new values "Average Days to Purchase" and "Average Receipt Delay" to be
used in purchase enterprise reporting tab where:
Days to Purchase = confirmation date (i.e. 'date_approved') - creation date
Receipt Delay: effective Date - ('date_planned' or 'expected_date' if
no 'date_planned)
Note that these 2 new values are specific to purchase orders only.
Because of this the standard query result cannot be used since it is
done at the purchase order line level. This means duplication of PO
values occur and results in incorrect aggregation calculations. A hack was
done to ensure that these value will aggregated correctly when used at the
enterprise level. Therefore these 2 new values should only be used in
aggregate.
To support these new measures the following updates were also done:
- Addition/improvement of help descriptions for other date related
measures to avoid confusion
- Change state string to "Status" to match purchase.order (for
consistent filtering purposes)
This commit supports "Adapt Reporting" subsection of Purchase KPIs task.
Upgrade PR: odoo/upgrade#877
Enterprise PR: odoo/enterprise#8945
Task: 2198420
Adds "Expected Date" and "Effective Date" fields to purchase orders to
match what exists in sales orders. "Effective Date" mirrors sales logic
(= first completed stock move). "Expected Date" has simplier logic due
to simplier nature of receiving stock vs shipping (= earliest "Scheduled
Date" of all PO lines). Form view has been updated to include these new fields.
Additionally code was changed to not have PO 'order_line.date_planned' be
overwritten by the 'purchase_order.date_planned' value. Previous behavior
was both confusing and made it so info was lost. Also logic for related
stock move picking line expected date values has been updated to now consider
'purchase_order.date_planned' value if set. Related changes include:
- not overwriting when PO is edited+saved (this only occurred in write()
logic, not create() which caused inconsistent behavior anyways.),
- updating related tests,
- removing PO line date_planned editing restriction when PO date_planned
is set
- updating of relevant stock moves/picking expected date due to
PO.line.propogate_date = True ('purchase_order.date_planned' if
exists, otherwise 'order_line.date_planned')
This change also includes some small related improvements:
- Removal of outdated code comment.
- Addition of Help strings to better explain fields.
- Prevent copy of 'date_planned' value into new POs (now mirrors sales
logic).
This change corresponds to "Receipt Date on PO's" subsection of Purchase
KPIs task.
Task #2198420
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
========
Purpose
========
Currently, purchase missing some billing functions that we have in sale
invoicing:
- Create credit note when necessary
- Create vendor bill in batch in list view
========
Spec
========
- In case of retures, when create a bill for a purchase order, we check
the total amount we want to bill to decide whether it's a vendor bill or
a credit note.
- In the list view, add a new action to create vendor bill/credit note
for all selected order.
========
Links
========
Task 2170715
PR #44210
Related: odoo/upgrade#919
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
1. Create a product with a category AVCO + Automated and set a price
difference account
2. Create a Purchase Order for 1 unit at a value of 1000,
3. Stock entry at receipt
D C
Stock interim received 1000
Stock valuation 1000
4. Create a vendor bill for a Landed cost, post it
D C
Stock interim received 100
5. Create the landed cost from the bill and apply it on the receipt of
point 3
D C
Stock valuation 100
Stock interim received 100
6. Create the vendor bill for the initial PO
Current entry is not correct:
D C
Stock interim received 1000
Price difference account 100 --> Shouldn't take place
Stock interim received 100 --> Shouldn't take place
This happens because the valuation layers of the landed cost are taken
into account when computing the unit price of the product.
This shouldn't be the case: when computing the price difference between
the invoice price and the stock move price, LC should be filtered out.
opw-2183511
closesodoo/odoo#47804
X-original-commit: 9bd3feb7f8778ba65e1974ef012ca3a4608878b1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose of this commit is to update incoterms list
base on new incoterms guidlines and add incoterms in RFQ/PO
and invoices/venderbills reports
task-2179236
closesodoo/odoo#43883
Related: odoo/upgrade#922
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Allow to propagate custom information to upper document. It could be
usefull in many buisness that do custom stuff for people
(t-shirt with user defined text, poster with own pictures...)
The customes values are pass throught procurements'values and are
display on MO or purchase order line.
Task: 1970476
Product purchases triggered by a stock rule currently searches existing
draft RFQs for matching 'partner_id' and 'company_id'. This commit makes
it so it also takes into account 'user_id' (i.e. "Purchase Representative")
and only selects ones without a user_id so as to not randomly add lines
to POs of different Purchase Representatives.
Supports Task: 2041853
Make it so documents auto-generated by other actions have Odoobot set as
the creator rather than the user triggering the action. This includes
the following documents:
1. Delivery (stock.picking) - generated by Sales orders (including MTO)
2. Purchase orders - generated by dropshipping, manual replenishment,
and run scheduler
3. Manufacturing orders - generated by made to order (MTO)
This is addresses specification 2 of overall usability improvement task.
Task: 2041853
- Create a product A with UoM set to 'Units(s)'
- Create a product B with UoM set to 'Liter(s)'
- Create a BOM of type kit, 2 Liters of B to create 1 Unit of A
- Create a PO with A, validate
- Validate the corresponding picking
An error is raised since we try to compute the quantity received in
Units based on a quantity in Liters.
In case of a kit BOM, an override exists in `purchase_mrp` to compute
correctly the quantity. Therefore, we can skip the line.
Corresponding fix for SO: 47959438b6Closes#45871
opw-2205970
closesodoo/odoo#46748
X-original-commit: 2ad4621c03a1885f2bb210960ebe8b5ae277e439
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
allowing to force the vendor to be used in the procurement batch.
This does not change any default behavior.
closesodoo/odoo#46678
X-original-commit: 8bff35182c38522bbd6fc218956fe0f8fe99eca4
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Missing context key in case of reverse of a vendor bill
it was then adding the anglo-saxon move lines.
opw-2172562
closesodoo/odoo#45432
X-original-commit: 48809f0c1b848142441063371d762a435836b6ec
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Increasing the quantity on a purchase order line will create a stock
move with the delta quantity. In case the purchase order has a return
among its picking_ids, the delta will be wrong.
This is due to the fact a return move is considered like a move_dest
of the original incoming move. The delta quantity will be computed
from the return move which doens't make sense.
This commit excludes outgoing moves from move_dest to avoid taking
return move into account.
closesodoo/odoo#44551
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
With a product configured as buy on order and a warehouse configured as
receipt in two steps, if the user increases the quantity on a po line
generated by a sale order before confirming it, the system will send all
the quantity to input but only the ordered quantity to customer. The
issue is that the "extra quantity" will stay in input.
We fix this issue by creating a new move with the extra quantity to the
input location so that push rules will send the extra quantity to stock
while the ordered quantity will be sent to the customer.
There was also an issue when incrementing the quantity on the po line
after confirmation if the po line was the result of a reordering rule:
only a move from supplier to the location of the reordering rule was
created.
This commit also introduces a change of semantic:
`created_purchase_line_id` is cleared after confirming the RFQ. This
allows to merge more in `_merge_moves`.
task-1981355
closesodoo/odoo#43545
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Create RFQ with an order by date in futur. It will allow to
discuss RFQ before validate them and to be in time for the need.
today Order by Sheduled date of receipt
|_______________|___________________|_____________________|
days to purchase vendor LT security days
Task: 1849912
When the scheduler runs, each orderpoint will check the forecast stock
for an infinite time. As example, if we plan a receipt of 10 products in
4 months and need to deliver 5 products next month, procurement will not
be launched since we have a forecasted quantity of 5.
In order to improve it, the orderpoint will compute the total lead days
from rules, suppliers/production delays, security days,...
Those lead days will be added to today in order to know at which date
the forecast stock should be checked and trigger the replenish document
for today in order to be delivered at the correct date.
Task: 1849912
Currently orderpoint run one request at a time. However it's not
efficient since compute are some private methods could be executed
one time in batch instead of record by record.
The strategy in order to improve it is:
- Still cut the orderpoints in batch of 1000 (usefull when using a new
cursor with intermediate commit)
- For each batch of 1000, create a list of procurement values and run
them in batch (commit a2a6b099a4 for more info)
- Each time a procurement exception is raised, catch the failing
orderpoint and rollback to the state before run. Remove the failing
order point from the current set and run it again.
- run method try to catch a maximum errors by continuing to process even it
finds error in order to stack them. It would avoid to run the same set
again and again each time an error is raised.
test_orderpoint_1 took 975s before this patch and 100s after.
Task: 1849912
Currently when a procurement fail it will raise a user error.
Some function as run in stock_rule catch the errors and merge
them in a single error.
Also since commit a2a6b099a4 procurements
are executed in batch and in some cases, we would like to have more
information about the error. For example in orderpoint we would like to
know which orderpoint is responssible for which error.
It would also be possible to return an object with the details but
procurements pass through a lot of different method that already have
their own return signature and a simple exception is easier to manage.
Task: 1849912
Orderpoint reference are only set on the first object that is created
from the procurement request. However sometimes we would like to access
it from further object or define another behavior if we come from an
orderpoint.
Now that the we propagate the orderpoint_id, it's important to ignore
po line with an orderpoint AND a chained stock move, else the quantities
will be counted twice by the orderpoint in a 2 steps receipt scenario
Task: 1849912
Steps to reproduce the bug:
- Let's consider the current user U logged in company C
- Let's consider two operation types OT1 and OT2 with code = 'incoming' and warehouse_id.company_id = C
- Let's define OT2 as default value for field picking_type_id in model 'purchase.order'
- Try to create a new RFQ
Bug:
The default picking_type_id was OT1 instead of OT2
opw:2124083
closesodoo/odoo#41700
X-original-commit: d49abf3c8f21ccd56c12f9835520deaf715ffcc0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The delay alert is only triggered when writing on the date,
We want also to trigger it when themove is created.
Task #1970595closesodoo/odoo#41953
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Add a field `delay_alert` on the purchase order line, and set in in `_prepare_stock_moves`.
So, we can use this new field to set the value (`delay_alert_date`) on the stock moves.
Task #1970595
Move the method `_prepare_purchase_order_line` from 'stock.rule' to
'purchase.order.line'. The purpose is to reuse it in approvals_purchase.
task-2040710
closesodoo/odoo#41046
Related: odoo/enterprise#6702
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- the oderpoint_id field on the purchase order line wasn't used to not
merge the po lines
- if the orderpoint_id field is set, use the orderpoint location to
create the move
- if multiple stock moves with different source locations go through
`_merge_moves`, they should obviously NOT be merged
- `virtual_available` computed field was not being invalidated when the
context keys "warehouse" and "location" changed
task-2001462
closesodoo/odoo#40573
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Current activity types master data cannot be unlinked through a quite harsh
override of unlink using xml id existence, introduced at 2602642a78.
Some of them are real master data, other could be unlinked if users want it.
Finally custom activity types may cause errors when removed if used in some
side models like server actions or automated actions.
To allow more flexibility we remove the removal constraint and implement
a fallback mechanism. It is implemented in mail.activity.mixin when calling
activity_schedule(xmlid, ...). If the given xmlid is not found
_default_activity_type() specifies the default activity to use. It can
be overridden in modules if some specific behavior is wanted.
e.g.
def _default_activity_type(self):
"""Define a default fallback activity type when xml id not found
only used in in activity_schedule() for now.
"""
try:
return self.env.ref('mail.mail_activity_data_todo')
except Exception:
return False
In this commit we also
* restrict deletion of activity type (hr.plan and ir.actions.server);
* fallback on default activity type if xmlid ref not found in
activity_schedule;
* correct calls to activity_schedule and replace some manual creation calls
by activity_schedule;
Task ID 1961156
PR #39013
Related: odoo/enterprise#6238
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Install stock and purchase. Make a RFQ for just one product, coonfirm
and receive in one transfer. Click on the delivery (should be only 1).
The picking will display. Open studio, select view, activate list view.
Javascript traceback will popup. Moreover the view of the stock
module will be altered in a faulty way (can be recovered from "Window
Actions", looking for the stock.picking action with external id
"stock.action_picking_tree_all" and removing the last added tree from
"View Mode").
This is caused by studio not detecting all the active views, thus giving
the possibility to add an already active view, because when there is just
one picking all other views are filtered out.
Changing the way the form view is retrieved in case of a single picking
fix the issue.
opw-2076241
closesodoo/odoo#38093
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When .with_context() is called with a dictionary as 1st positional
argument, it will replace context (and not modify the referenced keys)
It may create bugs when losing the content of the context (e.g. remove
partner's language)
This is a cherry-pick to saas-12.5 of odoo/odoo#36164 of the logistic
part as discussed
closesodoo/odoo#36690
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce the bug:
- Let's consider two company C1 and C2 and a user U allowed for this two companies
- Create a storable product P tracked by serial number
- Create a PO in C1 with P and deliver it with a serial number SN
- Go to Inventory>Master data>Lots/Serial Numbers
- Change your current company to C2
- Click on SN
Bug:
An access rights error was raised because the system tried to compute SO and PO linked to SN
with the moves of all the companies. So the record rule "stock_move multi-company" was
raised.
opw-2049093
closes#35694
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Nicolas Martinelli