Behavior prior to this commit:
If I have a pre-existing order (confirmed, but without available
product) on a product with an MTO route, and I now place a new order on
that product then confirm the generated PO, in the forecast report the
quantities from the PO will be shown as being applied to the
pre-existing order first.
For example:
- create a product with an MTO route (set a vendor)
- create a SO (SO1) for 5 units of that product and confirm it. Verify that
a PO (PO1) was generated. Cancel the PO.
- create a new SO (SO2) for 10 units of the product and confirm it. Confirm
the PO (PO2) that is generated.
- run the forecast report. It should show:
| Replenishment | Quantity | Used By |
|------------------------------------|
| PO | 10 | SO2 |
| Not available | -5 | SO1 |
But instead it shows:
| Replenishment | Quantity | Used By |
|------------------------------------|
| PO | 5 | SO1 |
| PO | 5 | SO2 |
| Not available | -5 | SO2 |
When the product is received for PO, the quantity received is correctly
applied to SO2, not SO1.
Behavior after this commit:
- when generating the forecast report, we have to tie each outgoing
shipment with 0 or more incoming shipment. After this commit, the
computation will be made without considering candidate incoming
shipments that are linked (via `move_dest_ids`) to a different
outgoing shipment.
- for receipts that are not tied to another move (move_dest_ids is
empty), there is no change of behavior
- for receipts that are "over-delivering", for example if there was a
generated PO for 10 units but they manually increased it to 15 to cover
both SO, there is no change of behavior: it will still show as
replenishing both SO.
Note:
- in a multi step environment the report does not correctly allocate
quantities once some steps of the order are processed (the quantity
will be shown as coming from stock, but in fact not all steps have been
processed), this is accepted as a known limitation to prevent making
too much of a performance hit for the MTO case (this behavior is the
same as what was present before the commit)
opw-2412137
closesodoo/odoo#63529
X-original-commit: 95435c056236438c61688855748b3afac57416a2
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
In the DB with a warehouse with a lot of stock location.
The forecasted widget return a traceback due to a memory error due
to the `_get_domain_locations_new`
(`_get_report_lines`->`read(['qty_available'])`->`_compute_quantities`
->`_compute_quantities_dict`->`_get_domain_locations`)
how returns a extremely long domain (one expression
by location in the context) to compute child location.
But the locations (put in the context) contain already
children locations because of
`('id', 'child_of', warehouse.view_location_id.id)`.
TO SOLVE
Instead of adding location in the context
(for fix 1aa6a323e04232d24175593718637c6dac295eb9),
add the warehouse in the context before
calling the `_get_report_lines` in the `_compute_forecast_information`.
closes#61666closesodoo/odoo#63377
X-original-commit: f8861e6a63fcd85295affdea4b525af753234b14
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Behavior prior to the fix:
- when adding a filter on "Quantity < 0" (or > 0) on the forecast
inventory report the quantity reported becomes incorrect: for example if
there is a restock on Tuesday and a shipment on Friday that drives the
forecasted quantity into a negative, the forecasted inventory report
instead reports a negative quantity on Monday.
- the problem occurs because the view the report is based on is built
using positive and negative entries that are supposed to cancel each
other when accounting for stock items (quant). This way the quantity is
reported as 0 before the quant is moved in the inventory (there is a
positive entry for the quant, and a negative entry for the move up to
the move effective date). But when a filter on quantity is placed the
"cancelling" entries are not loaded and the report ends up with just the
negative value
Behavior after the fix:
- the quantities are reported as expected: with a negative on Friday,
and 0 on the days before
- to achieve this the view was modified to perform the grouping of
forecast entries inside of the view. This way we have one row per
product / day / state and we don't risk selecting only part of the
report.
- as the view is only read in aggregate there will not be any visible
changes to its consumers
opw-2379098
closesodoo/odoo#62574
X-original-commit: c16d4b5e7b9181c2c792f595a117de10510d45be
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
see and set priority on sales orders and manufacturing orders in forecasted report
without having to go to the SO/MO
add the priority star icon in front of the SO/MO reference
changing priority should reload the page with reordered SO's/Mo
add a unreserve button next to 'reserved from stock' in the replenishment column
add total order and customer amount in used by column
remove time in delivery/receipt dates
change column headers (Quantity -> the UoM of the product, Expected Receipt -> Receipt, Expected Delivery -> Delivery)
change 'Draft SO' -> 'Quotations' and 'Draft PO' -> 'Requests for quotation' and add links
mobile view: display KPI's on new line
check decimals on quantities, must be 2
closesodoo/odoo#60578
Task: 2349142
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In the forecast data computation of `stock.move`,
the warehouse wasn't take in account in the call of `_get_report_lines`
for the quantity available computation. Add the `location` key to the
context with all location related to the warehouse in
the `_get_report_lines`.
X-original-commit: 1aa6a323e04232d24175593718637c6dac295eb9
Add reservation information in the forecasted report.
Also this information is used by the forecasted information in
stock move.
closesodoo/odoo#57814
X-original-commit: 87b16dab35c2326220d5bbd51bb7f07e876352d1
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Remove the json_forecast of the sale order line,
it was a duplicate of information with the qty_at_date_widget.
But improve this one:
- Use the forecasted move information in case of confirmed SO.
- Change the icon (i) to chart.
- Link to the forcasted change to target new forcasted report
(Unfortunately we loose the feature to see components product forcasted
of a kit)
- Change information print in the popover in case of confirmed SO.
Also refactor the json_forcasted of `stock.move` into multiple fields
to avoid to dump/loads for other model who needed the forcasted data.
task-2324039
closesodoo/odoo#56425closesodoo/odoo#57526
Related: odoo/enterprise#13063
Related: odoo/enterprise#13160
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Add a minus before quanity if it describes a output move.
- Remove intermediate section "Pending Incoming Documents" and
"Pending Outgoing Documents". Change other label to be more descriptive.
- "Current Stock" in "Inventory On hand".
- Add line "Inventory On Hand - 0" If no other line
specific it explicitly.
task-2324039
Creates a generic barcode template that prints the record name + its
associated barcode (if it exists). Generic template is a combination of
previously existing stock.picking.type and stock.location barcode
reports.
Updates stock.picking.type and stock.location barcode reports such that:
- they have a title (for clarity when combining them in the same pdf)
- they use the same (newly created) generic barcode template for an
aligned look
Also adds some formatting changes (proper indentation for legibility).
Supports a review comment of overall barcode improvement task
Task: 1884520
Enterprise PR: odoo/enterprise#12086Closes: odoo/odoo#55096
- 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
- MO/picking/PO/stock.move have now the "same" `priority` fields
(Boolean logic: Normal or Urgent).
These models are now sort by priority first. Note that the priority field of
stock move is a technical one.
- For MO and picking, the set of `priority` field change priority of
the related stock move. The prioriry field on stock move is
used by the scheduler for reservation ('Urgent' before 'Normal')
- The Stock Replenishment Report also take in account the priority
to be consistent with the reservation.
task-2246665
Replace wrong usages of any(list|recordset), by any(generator)
to speed up computations, avoiding list creations and/or looping twice on a recordset
for nothing.
any([generator]) => any(generator)
any(filtered) => any(generator)
closesodoo/odoo#55768
Related: odoo/enterprise#12360
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Adds the Replenishment Report, a printable report on product variants
and product templates. This report displays all draft and planned moves.
It has also the purpose to be overridden to handle purchase and sale
lines, and product's consumptions/productions of manufacturing orders.
Documents listed in the report can be accessed by clicking on their name.
task-2058495
Co-authored-by: sle-odoo <sle@odoo.com>
This commit extends the delivery slip so that products added as a kit
component to a stock.picking are grouped together by kit (or non-kit)
when at least 1 kit exists. Kit grouping occurs for products from a kit
without a package assigned. Non-kit section appears only when no
packages are assigned.
Implementation notes:
- Sub-kits (i.e. kits within kits) of kits are purposely not included
- Duplicate product names with different BOMs will be merged into one
since there is no straightforward way to distinguish them within
current db structure
- There are some cases where this doesn't work as expected and may lead
to components being grouped together under the same kit even if they
are from different kits (e.g. kit1 has bolts and so does kit2 => on
slip bolts will only show under kit1 section). Two cases where this
happens is when kits are added before 'Operation Type' is specified
and 'Operation Type = Manufacturing'
This completes subsection 1 of overall Improve delivery slip task.
Task: 2039720
This commit makes it so if a delivery slip contains 1 or more packages
then move lines will be split by package (and non-package) groups with a
"section line" between them. This only applies to when a stock.picking
is 'State=Done'.
In order to accomodate complexity of splitting by package + grouping by
product unless printing serial numbers/lots + template inheritance,
reoccurring parts of the template are split into their own templates and
called. Relevant inheritance has been updated to match.
Additionally, picking.shipping_weight calculation has been updated so if
a pack.weight = 0 then calculation will default to the calculated
product weight. This prevents inconsistency between the "Total Weight"
at the top of the Delivery Slip and the package sections' displayed
weights. To distinguish which value is being used, package sections that
use the total product weight rather than the pack.weight have
"(estimated)" after it.
This completes subsection 3 of overall Improve delivery slip task.
Task: 2039720
This commit makes it so move_lines with the same product+description+uom
are grouped together ONLY WHEN serial numbers/lots are not to be
printed. This is the case when the setting "Display Lots & Serial
Numbers on Delivery Slips" is not active or when there are no
lots/serial numbers assigned in the picking. This is only applicable for
stock.pickings that are 'state=Done'.
In order to implement this, some clean up of lots/serial numbers printing
was also done.
This completes subsection 2 of overall Improve Delivery Slip task.
Task: 2008609
This commit fixes an issue with deliveries slip
when time < 10 AM in autraslian timezone.
If datetime is 22/06/2020 5AM,
it will be 21/06/2020 on the delivery slip.
This is due to the fact that we use
widget=date on a datetime field.
OPW-2277194
closesodoo/odoo#53425
X-original-commit: c8ec8b4ffbaceb9a58a5ca48bd5a087e779edcc9
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Delivery slip updated to include the backordered products (not
canceled or already done) in a new table. Note that this only goes
1 level deep (i.e. backorders with backorders will not have their
backordered values included).
To support table alignment, small changes were made to existing delivery
slip table.
This covers specification 4 of inventory usability task.
Task: 2206279
Related Enterprise PR: odoo/enterprise#10723
Rename "Inventory" to "Count Sheet" under print dropdown and add in a
"Print Count Sheet" button to inventory adjustment.
This covers specification 2 of inventory usability update.
Task: 2206279
Related Enterprise PR: odoo/enterprise#10723
Commit 324db18dc9d5774d714 introduced the date formatting on the
traceability report. A side effect is that the line sorting is done on
the formatted value, leading to lines not appearing in chronological
order.
We format the line after sorting.
opw-2243432
closesodoo/odoo#52497
X-original-commit: 52e04dc3362830874a9f868d8e35a3da441320d7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
Steps to reproduce the bug:
- Let's consider a consumable product P with an internal note IN in Dutch
- Create a SO with dutch partner P and confirm it
- Process the delivery and validate it
- Print the delivery slip
Bug:
The internal note IN was displayed on the delivery slip.
The internal note must never appear on a delivery slip.
opw:2227613
closesodoo/odoo#50689
X-original-commit: 4b8d9806c6ee0a85812041f25080617daa7b10f1
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Usecase to reproduce:
- Install stock with demo data
- Go on drawer form view.
- The quantity forecasted and the report for forecasted quantity do not
indicate the same quantity
It happens because the quantity on forecast is wrong. It's due to the
part that select the quants. The condition wh IS NOT NULL remove all
the quants. Also using a not null on a table is probably not a good
practice.
Also complete the request is order to take quants in transit
closesodoo/odoo#49941
X-original-commit: 405522de1f97cfb7571d6096f727a4a2d03561d6
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
During the upgrade of some databases to 13.0, the following traceback
was reported:
`psycopg2.errors.AmbiguousColumn: column reference "product_id" is ambiguous`
This commit fixes this issue by prefixing product_id with the table name alias 'm'.
closesodoo/odoo#49927
X-original-commit: 0e3c5d3ee1726db2641cd683a84fe59e867d4319
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce the bug:
- Let's consider a consumable product P with an internal note IN
- Create a SO with P and confirm it
- Process the delivery and validate it
- Print the delivery slip
Bug:
The internal note NI was displayed on the delivery slip.
Fine tuning of https://github.com/odoo/odoo/commit/038221f3180a7a8888503553dbb5eb57875ef3a6
opw:2227613
closesodoo/odoo#49860
X-original-commit: 9b6ea1cdbed02c0f2ccd3e2608e4caf12c8c24ac
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Let's consider a consumable product P with an internal note IN
- Create a SO with P and confirm it
- Print the delivery slip
Bug:
The internal note NI was displayed on the delivery slip.
opw:2227613
closesodoo/odoo#49277
X-original-commit: 038221f3180a7a8888503553dbb5eb57875ef3a6
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Fixes#33309
Before this commit, Traceability report displays raw datetime.
This commits consider User's TZ + Datetime format configured in language.
closesodoo/odoo#47827
X-original-commit: 324db18dc9d5774d714c4b178468971b8bb36d6c
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Currently the quantity outside warehouse in the forecast report is erroneous.
It only takes the quants and not the stock.move incoming and outgoing for those location.
So the qty is only correct for the current datetime.
Remove this functionality and remove the filter 'warehouse is set' since it's always the case.
closesodoo/odoo#47997
Task: 2217047
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
At the moment, when a rule has a supply method "Take from stock, if
unavailable, trigger another rule", it is displayed as a "take from
stock" rule
In order to differentiate the rule supply method, we should rather show,
thanks to a vertical bar, when a rule is in take from stock, and use
both a vertical bar and the three dots when it is in "take from stock,
if unavailable, trigger another rule"
task-2205748
closesodoo/odoo#47541
X-original-commit: e1c1093c3d5fb7be69e8d1d26bcac184b5dc07b2
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This commit makes it so the order of the products in the Operations tab
of a transfer (stock.picking) form is the same order in the "Picking
Operations" report. Previously the products were being printed by
product id in the report and this is no longer desired as it makes it
more difficult for stock managers/workers to work. This addresses
specification 4 of overall usability improvement task.
Task: 2041853
Before this commit, the description of the move was displayed on the
Delivery Slip report, even if the description is exaclty the same as the
product name (which is the case by default).
Now, as it's somehow ugly to have the repetition, they will not display
the description if it's the same as the product name.
opw-2205325
closesodoo/odoo#46550
X-original-commit: e6ee4824a6e422960c648e9a1f684e56e6dabd89
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Create an immediate transfer for a receipt, add a move, set a quantity
done and due to rev[0], an initial demand is set, then
_autoconfirm_picking is called and action_confirm of picking calls
_action_assign if the location source bypasses the reservation. Set
again an inferior qty_done, the initial demand is also updated due to
rev[0] and somehow the system tries to write on a now unlinked move
line.
fixes
- never reserve an immediate transfer
- never update the initial demand if the move is reserved to fix the
existing databases.
- adapt _compute_state so that immediate transfer moves considered
reserved so that they're always "ready"
- adapt the test that was working on an immediate transfer picking and
setting the initial demand while it's not possible through the
interface, the user can only set the done quantity.
[0] 8303b1aclosesodoo/odoo#45317
X-original-commit: 357e0a862744f1bc23a9643a1822d2ee4a2eb7a2
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Since 94a3919, the report_location_barcode.scss asset is never loaded.
The report_stock_rule has the same template id than the report_location_barcode
one. This later is so always overridden.
This commit delete the barcode location css as it was not really usefull
closesodoo/odoo#45340
X-original-commit: 9b610d066d25007561ac469f7caf5919c0aa4092
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Usecase to reproduce:
- Set the lot_stock_id as a view location
- Create a PO and validate it
-> The forecast quantity on stat button is correct but it's missing in
the forecast quantity report.
It happens because the condition for stock_move is based on valuation
strategy. However it's not correct since it's not True that a product
is in the stock if it's valuated (as subcontracting, owner, ...)
In order to fix it uses the warehouse in order to define if a move is in
or out (the same way than the _get_domain_locations on product).
X-original-commit: d7da1b733b4cece73d26805e6371499026bed0cd
The delivery slip report on stock picking always read the product
description not the one the picker set on stock moves.
This commit takes the stock move description for the report when displaying
stock moves and stock move lines
Task : 2180347
closesodoo/odoo#44182
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This removes the measure_type field which has become unused and
causes issues when users try to add new uom categories.
Task-2043927
closesodoo/odoo#41056
Related: odoo/enterprise#6945
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Install stock, go to Configuration>Settings, activate "Storage
Locations". Go to Configuration>Locations select locations and print
The reported will not follow the documentation, barcode will be one
after the other and not side by side, arranged in a 2x2 grid.
Fixing require to apply style changes since new bootstrap
code is not handled well by wkhtmltopdf
opw-2162698
closesodoo/odoo#42967
X-original-commit: 7ac26d0ef5631cee38c29535531053fed6afce85
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If a module add a state field on another table used by this report,
PostgreSQL will report a:
```psycopg2.ProgrammingError: column reference "state" is ambiguous```
closesodoo/odoo#41350
X-original-commit: 16ae8aed10c72586a3a3e8b7484099263b0d7804
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>
On a quotation, the forecast report is opened with a default filter on
the warehouse of the quotation. If you remove this filter, quantities
not below warehouses (eg in subcontracting or in a repair location) are
displayed. From the product form, it's not the case, you never see these
quantities. We now add a "warehouse is set" filter that is enabled by
default (so you have the same value in the stat button forecast and in
opening the report) but you can remove it to see all quantities.
task-2061825
The only good solution is to set `show_reserved` to `True` to avoid any
kind of weirdness...
This reverts commit eed3171f2f057223c3fbedd95ce6bcde2124f46c.
closesodoo/odoo#41303
X-original-commit: de962efb8a531c69c098ae1706aa5c99d34a808a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When printing the 'Picking Operations' report in case of a receipt,
lines are duplicated.
This is because we need to print the `move_line_nosuggest_ids` as
displayed in the view.
opw-2125049
closesodoo/odoo#41168
X-original-commit: eed3171f2f057223c3fbedd95ce6bcde2124f46c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
On a delivery type picking, adds a button to able the partner to sign
the delivery on receipt.
task-1878607
closesodoo/odoo#39183
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Co-authored-by: sle-odoo <sle@odoo.com>
Nicolas Galler