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>
Previous refactoring: odoo/odoo@3b06565 switched move_line.product_qty
to move_line.reserved_qty. This line was missed during the refactoring
so we fix it now.
closesodoo/odoo#85355
X-original-commit: 624c155e77ae1d3fa964a949f17b4d8c73e9b35d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Delivery slip packages contains products not present in the package
Steps to reproduce:
1. Install Sales and Inventory
2. Go to Settings > Inventory > Operations and enable Packages
3. Create and confirm a sale order with product A, B and C
4. Click on the delivery smart button and create and assign different packages for products A and B
5. Set done quantities for products A and B
6. Validate the delivery with no backorder
7. Click on Print > Delivery Slip
8. Product C is in both packages
Solution:
Don't print empty moves when packages are used
Problem:
`_get_aggregated_product_quantities` returns all move lines related to a certain `stock.picking`, even the empty ones
It is called for each package so the same empty lines will be displayed for all packages
OPW-2727659
closesodoo/odoo#84138
X-original-commit: 1b39e170537d48a29a0dda06776cfacef41b9c8f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
When a product has a valid EAN barcode, we would like to include the qty
of the product + its uom in its GS1 datamatrix (dm). There are a lot of
hardcoded values in report in order to fit GS1 standard:
- GS1 UoM codes are ALWAYS 3 digits (to indicate which UoM) + 1 digit
(to indicate number of digits) EXCEPT for Units UoM. Because we cannot
update a dict in QWeb, we check for both whether it's a supported GS1
UoM or a Unit separately rather than 1 general check.
- We hardcode the GS1 units value as '30' in this case (there are 2
options) because the code is specific to qty of a product (not qty of
product within a SSCC GS1 dm, there is a different value for that).
There are some limitations to this implementation due to
incompatibilities between Odoo + GS1, specifically:
- some Odoo UoMs are not included as GS1 UoMs => won't be included in dm
- # of Odoo quantity digits can exceed the number of digits allowed in
GS1 (8 digits for Units, 6 digits for all other UoMs, including
decimal values from rounding precision, e.g. 1 cm with rounding
precision 0.000001 has 7 digits as 1.000000) => won't be included in
dm in this case
- Odoo treats "fl oz" (Volume) and "oz" (Weight) as separate UoMs but
GS1 does not => we only handle weight for now
- Odoo supports non-integer values for Unit UoM but GS1 does not => we
round quantity to an integer value.
Note that implementation includes flexibility for users so they can
add/remove UoMs from the GS1 nomenclature rules as wanted/needed. This
includes user created custom codes (e.g. 90, 92-99 + extra character -
code isn't required to start with these numbers, but it won't be GS1
compliant) to handle UoMs not included in GS1 specifications as long as
they are correctly configured as quantities if user wants to be able to
rescan quantities back in with barcode app and match the 6 digits or
less quantitiy requirement when printing.
Part of Task: 2494740
Related ENT PR: odoo/enterprise#23323
Part-of: odoo/odoo#82389
When a package name is a valid SSCC number, we prefer to auto-print the
datamatrix to be used by shippers, which includes:
- the SSCC number
- the pack date (i.e. when it was put in pack)
- the weight of the package (only when less or equal to 6 digits)
Pack date field was added to accomodate this and defaults to when
package is created (e.g. when buying packaged meat at the supermarket,
it's assumed the pack date is when the package of meat was created).
SSCC datamatrix will auto-print now in 3 package reports:
- Package with contents
- Package Barcode (PDF)
- Package Barcode (ZPL)
Note if ability to create datamatrix appears to not work (only in PDF
versions) then standard 1D barcode will be used.
Part of Task: 2494740
Related ENT PR: odoo/enterprise#23323
Upgrade PR: odoo/upgrade#3202
Part-of: odoo/odoo#82389
This commit adds a new print menu option for pickings so users no longer
have to click on picking form > Packages smartbutton > switch to list >
select all packages > Print "Package Barcode with Content" to have the
same result.
Part of Task: 2494740
Related ENT PR: odoo/enterprise#23323
Part-of: odoo/odoo#82389
When printing Lot/SNs barcodes, it's sometimes desired that we print a
GS1 compliant datamatrix with the following info (when applicable):
Product barcode,
Lot/SN barcode,
Best By Date,
Expiration Date
For flexibility, a setting has been added for when the GS1 datamatrix
should print instead of 1D barcode.
Note that datamatrix will automatically exclude invalid product barcodes
(i.e. non-EAN compliant) and datamatrix size can vary based on amount
of data in datamatrix (so size has been set to accomodate expected
largest gs1 compliant datamatrix possible).
If it appears that datamatrix cannot be created, then default to
standard 1D barcode. Note that zpl printer has built in datamatrix
creation command, so we can always assume they will print correctly.
Part of Task: 2494740
Part-of: odoo/odoo#82389
When a product's barcode is EAN compliant (i.e. EAN-8, EAN-13, GTIN-14})
and feature to create DataMatrix is fully installed then we would like
to print its GS1 datamatrix on the package content report.
Additionally, if the product is tracked, we would like to include its
SN/Lot if assigned one + any "use by"/"expiration date" to make the
overall usefulness of the report go up.
Part of Task: 2494740
Part-of: odoo/odoo#82389
Two updates:
1. Match the ZPL layout, i.e. remove text centering / horizonal lines.
2. Make layout match 4x12 format (same used by Product Labels). Note
that unlike the Product Labels, we expect the lot labels to ALWAYS be
printed in a 4x12 format (i.e. we keep it simple and contained within
1 template).
Task: 2494740
Part-of: odoo/odoo#82389
Fixes a couple of things;
1. Backorder use case when unassigning a move in reception report.
To reproduce:
- Create a Delivery w/ Demand = 8 of a stored product not in stock
- Create a Receipt w/ Demand = 10 of the product
- Assign 8 of product to delivery (don't forget to activate Reception
Report in settings
- Mark 4 of product as done > mark as done > create a backorder
- Open reception report in backorder (shows 6 instead of 4, this is a
known limitation of reception report) + unassign + close report
- Reopen report + assign 4
- Finish the backorder
Expected result: Delivery has 2 moves totaling a demand and reserved
amount of 8
Actual result: Delivery has 2 moves where 1 is fully reserved but the
other isn't and cannot be reserved (even though product in stock).
Issue was due to move split during unassign not taking into account that
the amount being unassigned could be greater than the amount still
assigned (due to backorder amount > demand qty since it doesn't know how
much was done in the original receipt). This would lead to the move
linked to the original receipt's move expecting a greater quantity from
the original move (and therefore not reserving any more quantities.)
2. Trying to unassign from an already done move. (i.e. backordered move
from above unassigned after the delivery is already done) isn't allowed,
so in case of unassigning from a done move, we don't do a split.
3. In case of failure of unassigning, fail gracefully (i.e. don't switch
button status since this is misleading).
Discovered during task: 2662730
closesodoo/odoo#83338
X-original-commit: 3c0c780032ed07da7ec14bdad8df2ff48fc5f4ef
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Allow use of reception report for MOs. Same behavior is expected as with
(non-outgoing) pickings. With exception that procurement group linkage
should be included when assigning.
Original Reception Report Task: 2500844
Follow Up Reception Report Task: 2632884
Task: 2662730
Part-of: odoo/odoo#79627
Two key are used for the same purpose. Remove one and
use its content directly in the report
clean commit bef1765b197a9e9d510a7d20d0364333402473b0
Part-of: odoo/odoo#82312
Steps to reproduce the bug:
- Install inventory and sales
- Create a SO > Confirm
- Click on the delivery > print > delivery slip or picking operation
Problem:
Only the name and phone number are in the report
opw-2697221
closesodoo/odoo#82235
X-original-commit: 35e6abce0e662cae6a55293f31620114ad5ecd8a
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Step to reproduce:
Try to print traceability report
Current Behaviour:
Traceback wrongly generated header
Behaviour after PR:
No Traceback, the header is now correctly generated
opw-2704299
closesodoo/odoo#81673
X-original-commit: 6b567326edc7bc691d87d911759ee30a24a8a1d7
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
commit af13e76629
reworked delivery split to add interwarehouse addresses but also
removed the address in a usual case.
opw-2701998
closesodoo/odoo#80609
X-original-commit: 9b9c4a3433d2a052e70e434b11817b791f38e508
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Steps to reproduce the problem:
- Create a storable product tracked by a unique serial number.
- use the product in a delivery
- try to print the "Picking Operations" document
Problem:
Traceback is triggered because we cannot use two fields in a "t-field"
opw-2692226
closesodoo/odoo#80140
X-original-commit: f478c9f48bc4f8adc0f455df1795de9672a40b78
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When Print Labels was revamped in odoo/odoo#69690 it was decided that
only product barcodes would be printed. Unfortunately we want SN/Lot
barcodes to be printed instead when they are filled in, so we make this
the case when applicable (i.e. when printing Transfer Quantites + qtys
done).
closesodoo/odoo#80079
Task: 2678336
X-original-commit: 105587e9e411442fd8e6d30efaa35b90b0e09959
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Commit d6abfbade9fb7f6dd6b3253551c559b1c7e6ece5 made it so we directly
reference a move's source origin via _get_source_document(). Normally
this is fine when the labels are created because labels would never be
created for a move without a source document, but this isn't safe when
the label is accessed via another way (e.g. test_reports). Therefore,
let's add in a check to prevent a error from trying to access
False.name.
closesodoo/odoo#79585
X-original-commit: 8abba9c3c0c48241e017e87045f392dc403a28e9
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Currently, the order of transfer lines makes no sense for a picker
(it's in the order of the creation of the line). We want to have the
lines of the detailed operation in the same order as the picker will be
picking the products, so we order by source location, destination
location, sequence, and then by id (i.e. creation time) respectively
instead.
Also the printing report of the batch transfer is on too many pages,
it's one page by location, but we always group on 'from location'.
So it would be better not to split by location and keep the report
on the least number of pages possible.
task-2496324
odoo/enterprise#21921closesodoo/odoo#79446
X-original-commit: 9b120caa2a5cd5e2487d663a180b486b5bdb201b
Related: odoo/enterprise#22144
Signed-off-by: Tiffany Chang <tic@odoo.com>
Previously it did not matter that we didn't explictly include the
'res_model' in the action when auto-opening the reception report on
validation. With the barcode OWLification refactoring we now need to
include it otherwise it will never open when a barcode picking is
validated.
Part of Task: 2632884
Related ENT PR: odoo/enterprise#20805closesodoo/odoo#79408
X-original-commit: a966e9d122b6fa91906260e82eaea1ed720bd076
Related: odoo/enterprise#22122
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Simplify user workflow by not showing the "Allocation" button in the
(batch) picking form view if there is nothing to allocate (i.e. when
reception report is enabled).
Also:
- fix the location search condition for the outgoing moves that can
be allocated to (i.e. the same logic used in show_allocation field
compute logic is also used in reception report generation/auto-opening)
- replace ['stock.location'].search() with ._search() for better
performance.
Part of Task: 2632884
ENT PR (for barcode equivalent): odoo/enterprise#20805
X-original-commit: 11ffb85fe7398854e4aefa4f9d0cfbc3b88aad8a
Part-of: odoo/odoo#79408
MerlinGuillaume