Behavior prior to this commit:
When a PO is generated (via reordering rule, mto rule, or manual replenish),
the description on the PO line includes the internal notes.
Behavior after this commit:
The description on the PO line does not include the internal notes.
Note:
Per c324526ad0, the description on the picking also does not include
the internal notes (anymore), and the test has been updated to reflect
that.
opw-24222438
closesodoo/odoo#64883
X-original-commit: 5db67fb2931517ae94fe0396ef80e9ad997e59cd
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
In order to easily compare delivery slip from vendor and receipt, vendor
product name and reference should be visible on the receipt operations.
The receipt description was just the name of the product before, it is
now taking the same description as the PO line, using vendor product
name and reference if it exists.
Task ID-2411544
closesodoo/odoo#62967
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The picking_type and currency were taken from the current company, even if the
purchase order is created in another company.
Fixes#35026closesodoo/odoo#64481
X-original-commit: 75936208c6e76a012027952f43b598e9d20180f3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently stock moves are auto-assigned (i.e. reserve free stock) both
when the scheduler is run and when a corresponding stock move that can
assign a move is completed. This strictness was causing issues for
prioritization of moves to assign, for example a picking with a
scheduled_date far in the future could automatically reserve all stock
if it was created before another picking that an immediate
scheduled_date. To ease this, an extra setting has been added to
stock.picking.type to let users choose how reservations should occur for
moves assigned to that picking_type (or picking with that picking_type):
1. 'at_confirm' = automatically when:
- stock is available when the move's associated picking/MO is
confirmed,
- when new stock becomes available,
- when the scheduler is triggered (+ stock available).
2. 'manual' = user must always manually click "Check Availability"
button (scheduler will no longer reserve).
3. 'by_date' = automatically when within the move's reservation_date
and:
- stock is available when the move's associated picking/MO is
confirmed,
- new stock becomes available when move is already confirmed, or
- the scheduler is run (+ stock is available).
'by_date' has an extra option of # days before the move's scheduled
date that affects the move.reservation_date.
Task: 2359317
Upgrade PR: odoo/upgrade#1868
ENT PR: odoo/enterprise#15050
- Create a product P with a MTO Reordering Rule (Buy Route)
- Add a supplier to P with a specific vendor code
- Create a SO for 1 unit of P, validate
A PO is created for the supplier but without using the vendor code.
It happens because the vendor code is overridden by the product
description.
To avoid losing information and redundancy, we add the line description
only if different from the product name.
opw-2383418
closesodoo/odoo#62037
X-original-commit: 0b138ffa5a1b2b03f03fb5dc51994a3bfc4e5dea
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Behavior prior to this commit:
In a multi-lingual setup, when entering a SO for a customer set in
a non-default language with a product that has translation in both
languages and is set up to replenish on order, the description in the
generated RFQ is duplicated, for example: "Product test Test Product in Dutch"
The problem stems from the fact that the description on the generated
stock move is set to the translated name of the product. When
generating the PO, the stock move class removes the product name to
avoid duplicating the description, but it uses the non-translated name
in the comparison.
Behavior after this commit:
The description on the RFQ line is included only once (using the default
language for the database)
opw-2368562
closesodoo/odoo#61138
X-original-commit: d013f8641ae2ed8c12d30ba5650c8e6ff2f1d5fd
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When a Purchase Order is created by the replenishment report, doesn't
pass the origin ("Manual Replenishment" or "Replenishment Report").
task-2328830
closesodoo/odoo#59398
X-original-commit: 170729ee58b199041d7545e7789ac9474e86f998
Related: odoo/enterprise#13876
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Create stockable product P: FIFO, Automated Valuation
- Set the price difference account
- Configure Decimal Accuracy for Product Price to 6 digits
- Create a PO
- Add a line with:
Product P
Quantity: 100,000
Price unit: 0.005
- Confirm the PO, receive the product and create the invoice
- Set a price unit of 0.006 on the invoice line
- Post the invoice
No price difference booking is generated, while a price difference of
100 should be created.
It happens because we compare the price units with the currency
precision.
Comparing the price units, even with the proper Product Price precision,
is not a good idea. Indeed, in case discounts are applied the price
unit computed ends up with a larger precision.
As a solution, we check if the subtotal of the journal entry is
different from zero.
opw-2341181
closesodoo/odoo#58364closesodoo/odoo#58888
X-original-commit: 654be58894c51d2c5384ead67a5a7c68fdebf0a7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create stockable product P: FIFO, Automated Valuation
- Set the price difference account
- Configure Decimal Accuracy for Discounts to 5.
- Create a PO
- Add a line with:
Product P
Quantity: 10,000
Price unit: 100
A tax
- Confirm the PO, receive the product and create the invoice
- Set a discount of 0.92431 on the invoice line
- Post the invoice
The journal entries for the invoices contains the price difference move,
the amount must be 9,243.10 but is 9,200.00.
In case taxes are defined on the the invoice line, we call `compute_all`
which will round the `price_unit`. In this case, we don't want to round
it.
Fixes#56832
opw-2329028
X-original-commit: 286ea6b681e9ba77357f91b546052449f6342f20
date_deadline of the stock move has been reviewed:
- Now, it represents the datetime when the operation must
be done to be in time for the uppest document (SO/PO/MO/RR).
- At the creation of stock move the date_deadline is computed in
the same way than the sheduled date expected that it is not include
security days (inverse the logic for PO).
- When we update the delivery date (or lead time) of SO (or PO).
The deadline of related stock move is updated and the delta is propagate
between origin and dest moves.
task-2324039
The test test_update_date_planned issued starting just before midnight.
a purchase was created at 23:59:59 then the variable `today` was
assigned to 00:00:01. When comparing the activity generated by the test,
taking 23:59:59.today() and 00:00:01.today() gave two different values.
This commit force the test time to 09:00:00.
Task : 2325270
closesodoo/odoo#56681
X-original-commit: 70c223eebe7edfa26564598c898cb9a8541e349b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
PURPOSE
Lessen use of mail-specific calls and variables
SPECIFICATIONS
Use mail_new_test_user tool in tests, lessening use of mail-specific context
keys in tests.
LINKS
Task ID-2326281 (context keys use cleaning)
PR odoo/odoo#56631
PR odoo/enterprise#12707
X-original-commit: 910559c092dc7dfa00b91339a5423e16cd4668e1
This provides a better API to search for records by name without the
formatting part (`display_name`).
This also simplifies all the overridings of `_name_search` that no
longer need to call `name_get()`. The call to `name_get()` is done in
method `name_search` in a generic way.
- Avoid to truncate the hour/min/sec in the computation of the
effective date which is related to the `date_done`
of the first incoming picking.
- With manufacturing in 3-step (pbm_sam), the store picking
had a source document == "New". It was the case because
the `_get_move_finished_values` was call before the create
and the name is set only on create.
To fix this issue, during the `create` set the origin of all move.
- To avoid to maintain old views unused,
remove unused view of stock move.
- The computation of the products_availability json is too expensive
to be in tree view (2.5 times long with it) of picking.
It will be hard to optimize because the half the time
is due to _get_report_lines method - already in batch (on 80 records).
- Review buttons of the replenishment list to be more Odooer.
- In some cases the delay alert date was wrongly compute:
- If we new dest_move_ids of a existant move, the delay alert date
won't be compute.
- If the state (to done) and the date are save in same write call
the alert date of next move won't be reset.
To avoids these issues, refactor the alert date to be a compute stored
fields.
- To avoid any confusion between date expected in the replenishement
(in date) and the purchase order receipt date (datetime),
we put the receipt date at the middle of the day.
Also On-Time Delivery Rate computation counts
only when date are bigger effective date trunced to date.
Also used the timezone of the company by default (if not user timezone)
task-2246665
closesodoo/odoo#55379
Related: odoo/upgrade#1586
Related: odoo/enterprise#12309
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- The deadline of MO generated via procurements is calculated differently.
Now, it doesn't take anymore in account the manufacturing_lead
of the company (Security Lead Time of MO). The computation of planned date remains unchanged.
- The date_expected fields was duplicated with the date fields
except when the move was done. Merge both fields.
The only information lost is: we can't know what was the
scheduled date before processing move (`state` == done).
Indeed, the date becomes the actual move processing datetime.
- The `date` in `stock.picking` field contained the time of
(purchase) order `date_order` (`purchase.order`).
This field is was wrongly used in the kanban view where we
expected to see date_planned instead. Also, the `_order` used
this date instead of date_planned too.
- The `delay_alert` is activate independently of stock rules.
Then it is now activate in all case.
- Remove the auto-reschedulting process of stock move via
the stock rule (`propagate_date` and `propagate_date_minimum_delta`).
Replace it by a automatic deadline date (`date_deadline`) propagation.
The deadline is the promise done to/by vendor/client (SO/PO)
then it is a readonly fields on picking/move and MO.
- Now the Scheduled date (`date`) of stock move is never propagate
and it is only related to the Scheduled date of
related document (MO or picking).
- Now when a move is created from procurement (sale),
`date_planned` = `date_deadline` - `security_lead`.
- The `delivery_date` of sale is no editable after confirmation
and propagate as the deadline to related stock move linked to order_line
- Adapt filter and decoration of MO and picking.
- Because we are the client in case of purchase (PO), the promise of vendor
can be not respected. Then we add the lead security to the deadline
(inverse the sale order logic) of PO picking (promise reciept date
+ security lead) to match with the replenishment.
task-2246665
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
Improve onboarding by removing the replenish on order route.
Companies that do MTO process could unarchive the route in
order to have a basic configuration.
closesodoo/odoo#55147
Task: 2245882
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180
1. When reservation can't be done for some products, we automatically
evaluate their reordering rules and create the corresponding
replenishment document.
2. When receiving products in stock, automatically check if some stock
moves are available and assign them.
Task 2244230
PR #52433
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Also, this commit fixes the usage of the 'invoice_policy' field in test that is introduced by the 'sale' module.
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
1. Show only date not datetime on update portal. When update the
scheduled date, set it to be the last minute of that date.
2. Send updated date immediately when user pick a date.
3. If an activity for update the date already exist, update the
note instead of creating a new one.
Task #2265912
PR 52809
1) Before this commit, propagate date on 1st receipt move was always False
if PO was created manually.
After this commit, move will be assigned with propagte_date of buy
route of warehouse only if there is not move_dest_ids.
2) Default settings on routes as -
1) If receipts in 3 steps > the alert on the receipt
(+ propagate) and the propagate rescheduling on the followings
2) If receipt in 1 step > the alert on the buy rule
(no propagate rescheduling)
Task-2209541
closesodoo/odoo#51853
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When set scheduled date on PO line, set it to be the last minute of
that day to correctly decide the late of the receipt.
Task 2265912
PR #52693
Related: odoo/enterprise#11034
Related: odoo/upgrade#1323
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- 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>
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
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
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
Issue
- Install purchase_product_matrix, Inventory
- Create a (storable) Product P with default_code e.g. VOB2A
with a vendor V who uses a product_code e.g. VOB2a
- Create a PO/RFQ for vendor V
- Add a product, search "vob2" (copy/paste)
Infinite loop
Cause
purchase_product_matrix replace purchase.order_line.product.product
by product.template so the name_search is different and the
product.template's name_search loop doesn't support the case where
you have default_code == product_code
Solution
Check if the product's name_search returned a product containing
product_template_ids that we did not wanted (as mentionned in the
domain). If yes, it means that we will have an infinite loop so
we should break.
Additional note: the issue could be in versions < 13 but
purchase_product_matrix is only in 13.0 and this is not a
very common case.
OPW-2193005
closesodoo/odoo#47576
X-original-commit: 9d5d80f77bc04be83d5b2ca0569a6ea50e26a07e
Signed-off-by: Jason Van Malder (jvm) <jvm@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
- Install Inventory, Purchase
- General Settings/tick Multi-step routes
- In Warehouses/YourCompany
Incoming Shipments: Receive goods in input, then quality and then
stock (3 steps)
- Create a PO and add the same products on 2 lines. One has a scheduled
date in the future
- Go to transfers, where "Picking List" or "Procurement Group"
correspond to your PO
=> the 3 scheduled_date correspond to Datetime.now()
- Validate the first picking (WH/IN)
The scheduled_date (resp date_expected) in the remaining pickings WH/INT
(resp. stock moves) are changed to the past.
This is due to the fact that both moves are merged in subsequent
pickings. The cleanest solution would be to avoid the merge in case the
expected dates are different. Although this makes sense, that also
implies a change of behavior.
Therefore, we avoid such situation by preventing the propagation of an
expected date in the past, which does not make much sense when
propagating.
opw-2171509
closesodoo/odoo#47155
X-original-commit: c7b2341b35aabe394a34e14c48a913a8595737fc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Arnold Moyaux <arm@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>
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>
- 'partial' payment state corresponds to invoices whose payable/receivable move line has been partially reconciled with some other line.
- 'reversed' payment state corresponds to entries that have been cancelled by the creation of a single reverse entry (using the dedicated button on the form view). This state can be set on invoice as well as on regular entries.
=> To stay consistent with the naming conventions, this commit also renames invoice_payment_state field to payment_state, since it's no longer only applicable on invoices.
closesodoo/odoo#41723
Related: odoo/enterprise#7202
Signed-off-by: Quentin De Paoli (qdp) <qdp@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
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
Usecase to reproduce:
- Set a product with routes: MTO + Buy
- Create and valide a SO
- Cancel the delivery
- Cancel the RFQ linked
-> The delivery will be switch to confirmed state while it should remain
cancel.
It happens because the button_cancel on purchase.order call
_recompute_state on move. _recompute_state modify the state to confirm,
partially_available or available depending the reservation status.
Howver it should never be call on 'draft', 'cancel' or 'done' moves
since it would modify their state.
A fix would be to filter the set of moves in order to exclude moves that
are cancel, done or draft before using _recompute_state. However this is
easy to forget and the issue would be probably redo in the future.
A more stable fix is to add the filter in the _recompute_state directly.
closesodoo/odoo#42471
Task: 2157543
X-original-commit: 0619415c17dc810aea67890cd3415c3f05dd2290
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before
======
If a product is FIFO, the standard price is the unit cost of the last released.
```
+ 1 product @ 10€
+ 1 product @ 15€
- 1 product
-> Actual standard price is 10€
```
After
=====
If a product is FIFO, the standard price of the ``product.product`` is the
unit cost of the next product which will be released
```
+ 1 product @ 10€
+ 1 product @ 15€
- 1 product
-> Actual standard price is 15€
```
Task #2038418
Nicolas Galler