Several reports don't include product packing info on them. This is
useful for customers to see that what they bought matches what they
expected and for pickers who need to know which product packaging they
should be selecting from stock. Reports this was added to are:
- Sales orders,
- purchase orders (including RFQs),
- picking operations,
- delivery slips.
Note that we purposely exclude backordered moves since they weren't
deemed to be necessary at the time this feature was created.
Also includes light refactoring to remove repeated code for conversion
of product qty to packaging qty and to make it easier to do this
conversion in the future (i.e. can pass product.packaging without
original record that it was assigned to)
Task id 2927379
closesodoo/odoo#96858
Signed-off-by: Steve Van Essche <svs@odoo.com>
Product's display_name can be too long and might not fit in small
labels. A decision was made to split it into default_code and actual
product name, and display both in separate lines.
Unfortunately, the logic of joining those 2 strings is embedded in the
model, so it had to be duplicated in the label.
Task: 3290154
Part-of: odoo/odoo#122511
Includes several modifications to better work with the new editor:
- add placeholders on t-field/t-out nodes
- add several div.oe_structure containers in key places for easier user
edition
- add branching options for several t-if directives without a t-else to
display for users (e.g. displaying the payment QR code if the value is
set vs. when the value is not set). These branching options are set to a
default value (the t-if node) which is what users see by default in the
report editor; the t-else node is a version they can manually toggle if
they wish)
- avoiding 'naked' t nodes as child of table/thead/tbody/tr elements, as
these break the table layout in chomium-based engines (that we know of);
instead, try to have foreach loops on tr or td nodes directly, or hoist
t-set directives above the table node
- replace several div or p (block) nodes by span or other inline nodes
to make it easier for users to insert content in their vicinity
X-original-commit: 567b8d676b3b6dc747df4d9bf10e7a91b4cb61bb
Part-of: odoo/odoo#129492
Improve the returns process by adding the following improvements:
- Removal of the 'return' operations type. Returns of deliveries now
become receipts.
- Update of the `stock_picking_return` wizard by removing the onchange
on picking_id.
- Show returns in the sale portal, with a new 'return label' PDF report
- Enable returns for multi-step receipts on purchases
Community PR: https://github.com/odoo/odoo/pull/118568
Enterprise PR: https://github.com/odoo/enterprise/pull/39761closesodoo/odoo#118568
Task: 3081370
Related: odoo/upgrade#4660
Related: odoo/enterprise#39761
Signed-off-by: Tiffany Chang <tic@odoo.com>
Currently, Storage locations and Operations type barcode are printing in 8x3 layout.
So in this commit, I have changed Report of Storage locations and Operations type
barcode print into 4x7.
TaskID - 2579195
closesodoo/odoo#116844
Related: odoo/enterprise#38901
Signed-off-by: Steve Van Essche <svs@odoo.com>
Steps to reproduce:
- Configuration -> Settings -> Activate multi-locations.
- Configuration -> Warehouses -> Three-step delivery.
- Generate a three-step delivery (like through a sale order).
- Select either PICK or PACK pickings.
- Print the delivery slip.
- There is a "warehouse address" field with the customer's adress in it.
It makes little sense to display the current warehouse for internal
transfers, as they keep being in the same warehouse after all.
This doesn't impact inter-warehouse transit as in this case, an outgoing
picking is done from one warehouse to the transit location and an
incoming picking is done from the transit location to the other
warehouse.
In both cases the addresses are correctly displayed and didn't use this
'warehouse address'.
opw-3335185
closesodoo/odoo#123903
X-original-commit: 4c5b08e89e7c623dbd34498739f52e3258d807f6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Before this commit, when printing a The picking operation or delivery slip
reports for outgoing transfers, both the delivery and customer address are displayed
showing the same address.
The expected behavior is to have customer address only of there is a commercial
partner behind the delivery address, thus the customer address is hidden
if its not the case.
opw-3289441
closesodoo/odoo#123365
X-original-commit: 5802295f3935648c4f2c5f9a45f223dcb1f7a7b8
Signed-off-by: Ahmed Khalaf (ahkh) <ahkh@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The report_stock_quantity model defines a view in its init method
to compute quantity information related to stock. This view
is made of two CTEs and a three-part query separated by UNION ALL.
The first CTE, existing_sm, retrieves the stock_move data
from the database that are later used by the remaining of the query.
One of the where conditions of existing_sm is (m.state != 'done' or
m.date >= ((now() at time zone 'utc')::date - interval '3month')).
m.state != 'done' is translated to m.state <> 'done' by the query planner.
This type of operator has the side-effect of turning off index scan.
Therefore, the scanning of the existing_sm CTE performs a Seq Scan
and applies the where conditions in a Filter node. This can be quite
ineffecient if the stock_move table is big, and if the selectivity
of the m.state != 'done' condition is high enough to theoretically
justify an IndexScan.
To fix that, we take the inverse of m.state != 'done', i.e. an IN cond.
This allows postgres to use Bitmap Scan, which
is usually better under these specific conditions.
E.g. speedup: db with 7M stock_moves, select from report_stock_quantity
with conds for state, date, product_id, warehouse_id, company_id
4.5s -> 2.5s
opw-3288364
closesodoo/odoo#123221
X-original-commit: aad458e5c5ecf8e843bbe8ddb7710b93eb95b362
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>
Steps to reprodue:
- Create a dropshipped product
- Sell the product to a client with a different language set
- Print the delivery slip
Bug:
delivery slip is currently being printed in the vendor's language
Fix:
Print the delivery slip in the client language when possible
opw-3193015
closesodoo/odoo#123047
X-original-commit: 0ad04a80b1f99feda2fdefbf24cbc3c494110a8d
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
When creating a scrap order on a product which has at least one kit BoM, an option is added to create a scrap order for this kit.
The user can select from the kit BoMs of this product and the scrap order will add stock moves for all the components of the selected kit instead of for the product itself.
Task: 2479234 (nr 9)
Community PR: https://github.com/odoo/odoo/pull/114315
Enterprise PR: https://github.com/odoo/enterprise/pull/37764
Part-of: odoo/odoo#114315
When using the Reserve / Unreserve buttons on the forecast report, this
will [un]reserve every move of the picking / production. We want to be
able to do it on a product base, so that when using the [un]reserve from
the forecast of a product, it will only affect the said product.
Part of task-3218314
Part-of: odoo/odoo#119381
Currently `report.stock.quantity` has a field defined in it called `move_ids`:
`move_ids = fields.One2many('stock.move',readonly=True)`
This virtual field has no corresponding inverse field so when performing a search_read on the model, it fails
in fields.py when trying to do: `inverse_field = comodel._fields[inverse]`
In addition, this field is apparently not used anywhere in the source code and not queried in the SQL View.
This means the model can never be search_read by default.
Since this field is never used, it isn't stored, and the model is `_auto = False`, removing it won't break any database.
closesodoo/odoo#120715
X-original-commit: e3b1a887a772333ebdb1682ffbbb695fe86030c1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrew Gavgavian (andg) <andg@odoo.com>
Before this commit, if there is a demand for quantities and they are
available but reserved in transit (not yet in a stock location) they are
shown as not available.
To reproduce:
1) Have 2/3 step incoming shipments in warehouse
2) Purchase a quantity to create the incoming transfer
3) Validate the first step so that quantity is now in Input location
4) Create a MO with the component with quantity only in Input location
5) Go to forecast report of component, the quantity is shown not available.
closesodoo/odoo#117372
X-original-commit: 39ff1feae9f44b64ee3fff6ccee837ac4922ad1e
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
Step to reproduce:
1. create a product
2. duplicate it and change its translation (but DO NOT change the product name)
3. create a transfer for that new product without a contact
4. print delivery slip
Bug:
the db's product name is used instead of the translated name
(i.e. "original product name (copy)")
FIX:
when partner id is not set in picking, then default to the user's language
opw-3141202
closesodoo/odoo#116610
X-original-commit: e56b955fbd7963709b9547eb50d97cf105f9d430
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
When printing the label of a lot, the datamatrix may overlap the
product/lot name and will overlap the 'best before' date.
To reproduce the issue:
1. In Settings:
- Barcode Nomenclature: GS1
- Enable "Print GS1 barcodes for lots [...]"
2. Create a product P:
- Name: a long name
- Type: Storable
- Barcode: 1111111111113
- Tracking: USN
- Expiration Date: True
- Dates > Expiration Date: 1 days
3. Process a receipt with 1 x P
- The serial number should be long
4. Print Labels
- To Print: Lot/SN Labels
- (Confirm)
- Format: 4 x 12
Error: the datamatrix overlaps the product name, the serial number,
and the 'best before' date
For the product/lot names, we can only improve the situation. If the
user define a too long name, the issue will still happen and nothing
can be done
For the dates, we can shorten the labels. That way, the dates will
always be correctly displayed
OPW-3193836
closesodoo/odoo#116541
X-original-commit: f175897cefd1db149e94a50882d9e7babfc6293d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Currently, transfer barcode is not available in reception report.
So in this commit, I have added transfer barcodes. Also, align the barcode and
transfer name according to the report.
TaskID - 3081077
closesodoo/odoo#112773
Signed-off-by: Steve Van Essche <svs@odoo.com>
This commit is to convert the "stock_report_generic" client action into owl.
closesodoo/odoo#112064
Taskid: 3175084
Related: odoo/upgrade#4309
Signed-off-by: Steve Van Essche <svs@odoo.com>
Add a way to disable the read() done in the forecast report. While those
are useful to send the right data to the client, they have no use and
even slow down the process when the forecast report lines are generated
for a python-side use.
Part of task-3059467
Part-of: odoo/odoo#113394
Before this commit, the reserve and unreserve buttons did not appear
for MOs.
Another bug was also fixed, removed the 0 Inventory on Hand line that appeared
when there are no moves in the report.
closesodoo/odoo#112981
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, the reserve/unreserve buttons did not work / were
hidden with multi-step delivery settings. The report now works with the
entire linked chain of moves, it displays which step is reserved,
if more than one is reserved in the chain the later move is shown.
Because reservation works differently on chained moves (they reserve
quantities brought by previous move in the chain) any extra unreservable
quantities are shown as on stock in transit.
closesodoo/odoo#112162
Taskid: 2858139
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Refactoring of report_stock_forecasted to owl
Since it wasn't really a report (no print action),
it changed from a report to a client action.
Task: 2885757
See Upgrade : odoo/upgrade#3926
See Enterprise : odoo/enterprise#32116closesodoo/odoo#101247
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
'State' field on stock move is indexed. Some domains on stock move state
are expressed like (state, not in, ('a', 'b', 'c')) instead of (state,
in, ('d', 'e', 'f', NULL)). The 'not in' domain won't the index and thus
will be relatively slower
closesodoo/odoo#109201
X-original-commit: 96f8321e894a9b7284cca8f201e5a2877b0b3a76
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The delivery slip of a picking with an operation type where 'Move Entire
Packages' is enabled doesn't print the delivery address
Steps to reproduce:
1. Go to Settings > Inventory > Operations and enable 'Packages'
2. Go to Inventory > Configuration > Warehouse Management > Operations
Type
3. Open operation type 'Delivery Orders' and enable 'Move Entire
Packages'
4. Create a new transfer with operation type 'Delivery Orders', add a
delivery address and a move and save
5. Mark as todo, put in pack and validate
Solution:
Always use the partner of the `move_lines` in the delivery address
Apply the same logic to the address used in the picking operations
report
Problem:
The delivery slip always uses the partner of `move_ids_without_package`
but there might not be any if the picking uses packages
opw-3091139
closesodoo/odoo#108465
X-original-commit: d113e0d7a5aa1c1f6bb933771cda4a3365361ba0
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
When checking if a line in traceability report is unfoldable,
`_get_move_lines` is a costly operation and should be executed last when
all other conditions are satisfied.
closesodoo/odoo#108119
X-original-commit: 36697278b6130e066deb994d879a8567e45d3451
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Install mrp
- Enable Allocation Report for Manufacturing Orders in settings
- Go to WH/MO/00003 from the demo data in runbot
- Click on the “Allocation” button
Problem:
Traceback is triggered, we try to format the info from the source
("Manufacturing order") and send it in an HTML request, but we access
the `partner_id` field, while this field does not exist in the
"mrp.production" model:
https://github.com/odoo/odoo/blob/f310d8f16b57c776ad92406bd52daa707ad45a88/addons/stock/report/report_stock_reception.py#L373-L374
The first element is always considered as a `stock.picking` but it
can be the `mrp.production`
opw-3063172
opw-3086714
closesodoo/odoo#107942
X-original-commit: 2008cb69dca14d0fe9fbd4484b52912fd4ea68b4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The delivery slip of an outgoing picking prints the warehouse address
instead of the delivery address (which should be displayed as it may
be different from the customer address)
Steps to reproduce:
1. Install Contacts and Inventory
2. Open Contacts and add a delivery address named "delivery" to contact
Azure Interior
3. Go to Inventory > Operations > Transfers
4. Create a new transfer with:
- Contact: Azure Interior, delivery
- Operation Type: San Fransisco: Delivery Orders
- Product: Large Cabinet
5. Save the transfer and print the Delivery Slip
6. The warehouse address is displayed and there is no info about the
delivery address
Solution:
Add a method to know if we should print the delivery address. We should
print it if the picking has a delivery address and it is of type
outgoing (or if it's a dropship)
Problem:
Printing the delivery address when the package partner is different from
the picking partner is wrong because the delivery address might be
different from the customer address
opw-3064203
closesodoo/odoo#107355
X-original-commit: ec929f787f629940cd38a4ed25e5012335e2483d
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
This reverts commit 3ebe1185a4.
The code ECC200DataMatrix already exist in reportlab (that is already a dependance).
Some differences:
- ECC200DataMatrix only supports a Type 12 (44x44) C40 encoded data matrix.
(214 alphanumeric characters and 14 to 27% of error correcting rate)
- pylibdmtx support more type and add a default to 24x24. So it means a
(52 characters and 20 to 35% error correcting rate). It's also smaller
to display.
We consider the gain too small compare to maintain an extra lib.
It also fix blured datamatrix in stock report if they contains too much
data.
*If you want to test 001234560000000018 is a valid sscc for package
closesodoo/odoo#106620
X-original-commit: 54ef19f41ffc4a6f715474b65a4183a7fa75feea
Related: odoo/enterprise#34422
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit there is no clean/easy way to do nice xpath's on the divs.
By giving them a name we can do a xpath expr with @name=''] which is not as errorprone.
closesodoo/odoo#105142
X-original-commit: f37251ff76359a4b8c05facc1f7449a2e1eea7fb
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Reading only 'id' with `search_read` is equivalent to use `search` but
complexify the result usage. Fix all these bad usages.
Part-of: odoo/odoo#104838
Co-authored-by: Julien Castiaux <juc@odoo.com>
The delivery slip of a receipt picking with a vendor uses the vendor
details as the delivery address
Steps to reproduce:
1. Install Inventory
2. Go to Inventory > Operations > Transfers and create a new transfer
with:
- Contact: Azure Interior
- Operation Type: San Francisco: Receipts
- Product: Large Cabinet
3. Save the transfer and print the Delivery Slip
4. The delivery address is wrong: it is the partner's address
Solution:
Change the conditions used to print the delivery address and the
warehouse address to print the warehouse address when the delivery
address is the same as the partner address
opw-2992693
closesodoo/odoo#104051
X-original-commit: 99d04c20896dd06b4d083fe6c079a90e840e3ca2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Converts the legacy reception report into WOWL.
Fixes 'Assign All' buttons disappearing from the report until it is
reloaded when clicking on them.
Removes references to 'report_type == html' from xml since it is only
used as PDF now.
Part of the global conversion of stock to WOWL.
Task-2885757
closesodoo/odoo#102687
X-original-commit: f310d8f16b57c776ad92406bd52daa707ad45a88
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Minor UX updates to forecast report:
- add missing space (between # and unit + before |) also removed
superfluous uoms (only need it at the end now that an equation is
displayed)
- move On Hand Value to under product link (+ variants if they exist)
and make it a link to the valuation report of the product(s) in
question
- add link from Quantity on Hand to the locations (i.e. inventory/quants)
report for the relevant product(s). Note that product template was
added to Search in order to support default searching due to
forecasting report structure
- redo the top right forecast values to be On Hand + Incoming - Outgoing
= Forecasted so we provide more explicit and transparent values.
Additionally, these values are made to not display decimal digits if
all of those digits are 0. Note that forecasted values in table are
untouched (i.e. Forecasted Inventory = Forecasted is unchanged and
Forecasted with Pending still shows in table)
Also did some t-esc => t-out replacement and other small cleanup since
templates were already being edited.
"forecasted report" part of b2b task: 2882539
Part-of: odoo/odoo#97109
The Forecasted Inventory view has become obsolete, therefore we delete
the code associated with this view. Note that the Forecasted Report
still uses the graph view of this view so we leave it. Because the
Forecasted Report still uses this view + stock.warehouse.orderpoint
relies on the report.stock.quantity model, we leave the model as is.
"forecast inventory" part of b2b task: 2882539
ENT PR: odoo/enterprise#29974
Upgrade PR: odoo/upgrade#3819
Part-of: odoo/odoo#97109
Reproduction:
1. Install Inventory and Sales, enable customer address in the setting
of Sale
2. Create a quotation, choose a customer which has different contact
address and delivery address, add a storable product.
3. Confirm the order and click the delivery in the status bar
4. Click print->delivery slip, the Customer Address and Delivery Address
are the same
Reason: The Customer Address isn’t correct in the template
Fix: replace the partner setting in the customer address part as either
the partner or its parent partner_id, e.g. the commercial_partner_id
opw-2851158
closesodoo/odoo#96800
X-original-commit: 500687e45e83a8bf7c4ab31e659c7eb9dc83aa4c
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
3-steps delivery. A user confirms a SO with a storable product, it
generates 3 pickings (pick, pack, ship). On the Forecasted Report of P,
there is a line for that SO. A button is available (Reserve) but if the
user clicks on that button, it won't do anything (even if there are some
P in stock).
The Reserve button is linked to the ship SM, so trying to assign it is
useless, we first need to process the pick/pack steps.
In such situation, displaying the button is confusing.
OPW-2784998
closesodoo/odoo#95578
X-original-commit: 71769d536118da8e35dd18672b5d6c74a2180310
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
When moving some products between two warehouses thanks to an internal
transfer, the forecasted inventory becomes incorrect
To reproduce the issue:
1. In Settings, enable "Multi-Warehouses"
2. Let WH01 be the existing warehouse. Create a second one WH02
3. Create a storable product P
4. Update the quantity of P:
- 3 in WH01/Stock
5. Create a planned and internal transfer T:
- Source: WH01/Stock
- Destination: WH02/Stock
- Ignore the warning
- Operations:
- 1 x P
6. Mark T as todo
7. Open the Forecasted Inventory:
- Filters:
- Forecasted Stock
- Product: P
- Group By: Warehouse
Error: The report is incorrect, it says there are 3 P in WH01 and 0 in
WH02 (should be 2 and 1). It becomes worst if T is done (the quantities
in the past become incorrect)
We should be able to move a product between two warehouses thanks to an
internal transfer (so the warning of the step 5 should be removed).
Moreover, the `report.stock.quantity` should consider that use case.
When processing a stock move, the SQL view translates it as an in-move
or out-move for a specific warehouse. For instance, if the SM comes from
a warehouse and goes to a location without any warehouse (e.g., customer
location), the SM is considered as an out-move. But here is the issue:
in case of an inter-warehouse SM, both source and destination have a
defined warehouse.
Therefore, we need to:
- Duplicate the inter-warehouses SM (so we have one in and one out)
- Fake the values (no destination warehouse for the out move, no source
warehouse for the in move)
Also, before duplicating all SM, we filter out some useless SM:
- Draft and cancelled ones
- SM done more than 3 months ago (because the report only works for [-3
months; +3 months])
Considering some tests:
(SM are confirmed. Each test has been repeated 5 times to get an
average)
| | |
|:-------------------------------------:|:--------:|
| 5000 SM, 0% inter-wh, without the fix | ~715 ms |
| 5000 SM, 0% inter-wh, with the fix | ~710 ms |
| Impact | 0.99x |
| | |
| 6666 SM, 0% inter-wh, without the fix | ~911 ms |
| 5000 SM, 33% inter-wh, with the fix | ~999 ms |
| Impact | 1.10x |
| | |
| 7500 SM, 0% inter-wh, without the fix | ~1004 ms |
| 5000 SM, 50% inter-wh, with the fix | ~1097 ms |
| Impact | 1.09x |
The impact is not that significant
OPW-2752017
task-2822157
closesodoo/odoo#91772
X-original-commit: b1efc0243bbf886bbef42a32587f4a818fa34e64
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
Steps to reproduce the bug:
- Go to Inventory > Transfers > Select a ready transfer with no qty done
- Print > barcodes (ZPL) or barcodes (PDF)
Problem:
The file is empty because there is no qty_done.
Solution:
If no qty is done, then print all barcodes as if picking is done.
It makes sense, for example, when a user wants to print the barcodes before the product is delivered
but if at least one move_line has a Qty_done then do not print the other move_lines which have a qty_done of 0
opw-2780365
closesodoo/odoo#87151
X-original-commit: 3229d73dd11ddb02415d61c47f41e857742887b7
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The contact widget supports displaying VAT but it was added manually in the reports after contact. This commit fixes this behavior and results in fewer code and an easier way for the l10n modules which may modify VAT display.
closesodoo/odoo#83733
Related: odoo/enterprise#25195
Signed-off-by: Laurent Smet <las@odoo.com>
The total ordered quantities on a delivery slip with order lines of the
same product was wrong + this PR
https://github.com/odoo/odoo/pull/83591 was incorrect, the undelivered
products should be displayed once
Steps to reproduce:
1. Install the Sales and Inventory app
2. Create and confirm a sale order with two order lines, both with the
same product
3. Go to the delivery and confirm it with all demands met
4. Print the delivery slip
5. The ordered quantity of the product is wrong, it should be equal to
the delivered quantity
Solution:
Use all empty moves in package-less products
`qty_ordered` = `qty_done` when in a package (the potential remaining
quantities will be displayed in the package-less products or in the
backorder section) or when there is no backorder (as the undelivered
products will either be added to the package-less products section or
the ordered quantity will be incremented later)
If we are not in a package and there is a backorder, adapt the ordered
quantity to remove the quantity of the packages considered before
Convert `qty_done` to the UoM of the stock move
opw-2722203
opw-2758840
opw-2782572
closesodoo/odoo#87072
X-original-commit: 332ec796ac77c8383a04a924508013c735f67d1e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
'Delivery Slip' report with the document layout 'DIN5008' needs to have
the delivery address in the hole of the envelope
Steps to reproduce:
1. Install Sales app as well as Drop Shipping and l10n_de module
2. Go to General Settings -> Document Layout and select
external_layout_DIN5008
3. Specify a Dropship route for a product
4. Create and confirm an order for that product
5. Open the purchase order with the 'Purchase' tab
6. Confirm the corresponding purchase order
7. Open the 'Receipt' tab
8. Print the Delivery Slip
9. The document reference is above the address instead of under it
Solution:
Add the `l10n_de_addresses` computed field and set the addresses through
`<t t-set="address">` and `<t t-set="information_block"/>`
OPW-2709866
OPW-2715851
closesodoo/odoo#86039
X-original-commit: 2f7ad40d7480742a4e42875a4eec744db45a3914
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Triet Ngo