In master , some places the string "Lot" is used and at some places
"Serial Numbers" is used , which is very confusing for the user.
Make a common string "Lots / Serial Numbers" everywhere for the uniformity.
Purpose:
When we create a return transfer, the return location should be selected as
the default destination location of the "Picking type for return". Odoo should
be using that return location as the default return location during reverse transfer,
but only if the default destination location of the "Picking type for return" is a
return location
Specification:
For all transfers, if the default destination location of the "Picking type for return"
is a return location, then the return location should be selected as the default
destination location during reverse transfer.
1/ In Return form Change the string 'To Refund in SO' to 'To Refund'.
2/ Return form wizard: Reduce the space in header.
3/ Change the button string name 'Reverse' into 'Return'.
PURPOSE:
The source document should be in the chatter and clickable
NEW MAIL TEMPLATE:
mail: new template 'message_origin_link' with clickable link to origin
Variables to pass:
- origin: the record from which the current record had been created
- self: The current record
Optional:
- edit: If true, the record has been modified. Otherwise it has been created
from the origin
SPECIFICATION:
Source Document is available in following models
1) After creating SO then Sale to Invoice -> Source Document (After creating Sales Order and then clicking on Create invoice)
2) When procurement is created after SO or MO or Order Point(procurement.order) - > Source Document
3) Stock.picking -> Source Document ( After Creating SO or PO)
4) When Manufacturing Order is Created (mrp.production) -> Source Document (Coming after creating a sale order of product)
5) Event -> Attendees(event.registration) -> Source Document
6) Request For Quotation -> Source Document (After creating Purchase Tender, SO)
7) In Purchase Tender(purchase.requisition) -> Source Document (When a new Purchase Tender is Created)
8) After creating PO then create invoice(vendor bill)-> Source Document
9) After creating Invoice from contract (subscription) - > source Document.
10) Refund invoice from Invoice --> Source Document.
11) Return picking from picking --> Source Document.
12) sale use POS to create invoice and picking --> Source Document.
MESSAGES TO DISPLAY:
-In Customer Invoice, there is a source document of Sale Order.
"This Invoice has been created from Sale Order(s): SO001, SO002"
-In Procurement, the source document can be either of Sale Order or Manufacturing Order or Order Point.
"This procurement is created from: SO001 or MO0001 or OP/0001"
-In Stock Picking, the source document can be either of Sale Order or Purchase Order.
"This transfer has been created from sales order(s): SO001 or PO0001"
-Create new Sales order of manufactured product , there will be Source Document with that Sale Order number
"This production has been created from procurement(s): WH: Stock -> CustomersMTO"
-When registering for Event from website, Sale Order is Created and it is stored in Source Document,
"The attendee has been created from Sale order: SO001"
-In RFQ, the source document can be either Purchase Tender or Sale Order or Order Point,
"This purchase order has been created from purchase requisition(s): TE0001 or SO001 or OP/0001"
-In Purchase Tender, the source document can be either of Sale Order/ Manufacturing Order/ Order Point.
"This Purchase Requisition has been created from: WH: Stock -> CustomersMTO"
-In Vendor bill, there is a source document of Purchase Order.
"This Vendor bill has been created from Purchase Order(s): PO0001, PO002"
-When creating refund of invoice
"This customer invoices refund has been created from customer invoices: INV/2016/0001"
-when create invoice and picking form pos.
"This invoce has been create from point of sale: MainXX"
This sentence was turned in a way that was making the user reluctant to click on
Apply while this is a normal flow to follow most of the time.
Closes#11763
Wizard models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
General remarks concerning cleaning commits preparing the stock migration
=========================================================================
Small update / cleaning before moving and migrating. This commit contains
the cleaning of stock_picking_type and stock_picking models.
The first cleaning performed is to clean methods having a browse record or
a list of records replacing ids parameter. Those are converted into classic
old API methods using cr, uid, ids. This eases the migration as they are
then migrated into multi methods.
Another cleaning concerns naming things. Some methods are renamed to ease
the code readability. Some parameters are also renamed as well as some
variables. This kind of change is performed only when the readability
is improved. Otherwise the code is kept as it is to avoid rewriting too
much of the code.
Finally unnecessary stuff is also removed. This concerns dead code (methods
not used in community nor in enterprise) and unnecessary code splitting
(tools methods called once without real added value are directly put into
their called method).
- stock.move: no specific changes; note that a method called only in mrp
has been moved to mrp.
- product: no specific changes
- config settings: no specific changes
- wizards: no specific changes
stock.quant main changes
========================
- ``apply_removal_strategy`` method updated to return only the removal
strategy instead of having a mix of several things (overrides updated)
- ``quants_get_**`` methods renamed to ease code understanding
- quants_unreserve from stock.quant to stock.move model because its primary
record is a move, not quants
stock.inventory and stock.inventory.line main changes
=====================================================
- stock.inventory: ``move_ids_exist`` field remove. Unused.
stock.picking and stock.picking.type main changes
=================================================
- stock.picking: ``move_lines_related`` is removed. Indeed it is used only
to display a slightly different view of moves contained inside a picking.
However this field causes a lot of issues when migrated into the new API.
The view is updated to keep the same look and feel while avoiding an
unnecessary field.
- stock.picking.type: complete_name field is removed. Using display_name is
sufficient for the existing use cases.
stock.warehouse and stock.orderpoint main changes
=================================================
- stock.warehouse: removed ``resupply_from_wh``, unused field
stock.pack.operation main changes
=================================
- stock.pack.operation: ``processed_boolean`` fields renamed to ``is_done``
to match its use in the code.
stock.location main changes
===========================
Note that in this commit a strange override in create has been replaced by a
cleaner override in default_get in order to have something more understandable
procurement main changes
========================
- in this commit some code located in procurement has been moved to the
orderpoint model. Indeed those methods take an orderpoint as main
argument, making it more orderpoint methods than procurement methods
- ``_prepare_orderpoint_procurement`` method has been merged with its
strange override in stock_calendar to have something a bit more modular
1) Configure the warehouse "Your company" to pick-pack-ship operation
(you'll need to activate the advance route on WH config + set up the
correct process through the warehouse configuration wizard.
2) Create a SO with a product (on stock) and confirm it
3) Display the deliveries, you'll have 3 : pick, pack, ship
4) Take the pick, force availability if needed, and confirm it
5) Return the pick and validate (e.g. imagine you missed something like
puting the lot, so you want to reverse the pick).
6) Go back to the SO, click to view the deliveries
7) You create another, new, pick here (which is correct). Take it and
confirm it.
8) Look at the pack => his state is "Waiting another operation"... This
is not good ! We should have it "Ready to transfer" (now "Available")
because we just (re)confirm the pick operation.
Odoo don't know he should make the next operation (pack) available.
- Separate group_stock_multiple_locations into 2 groups:
o group_stock_multi_locations
o group_stock_multi_warehouses
- Add a selection fields to manage the 3 levels of warehouses management complexity:
o Manage 1 WH with 1 location
o Manage 1 WH with multi locations
o Manage multi WHs with multi locations
- Display the menuitems and fields accordingly
- On a company creation : Create a related Warehouse
- stock.location : Add a helper on the parent location
- stock.warehouse : Add a helper on the company_id field
When the user validates a picking without going through the manual
reservation process, Odoo tries to assign the picking then performs the
transfer. However, if the picking could not be assigned, no pack
operation is created and the picking will simply be set to done.
The fix raises an error if the picking could not be assigned completely.
Another solution is to use a force_assign instead of action_assign, but
that could lead to the creation of negative stock moves without warning
the user. We therefore prefer to stay on the safe side and force the
user to manually handle the reservation.
Note: the original issue was that the Owner of the picking was not
copied on the quant when validating right away. The reason was that no
pack operation was created.
opw-654423
In a multi-company environment, you might not
have the access to the stock location
`stock.stock_location_stock`,
in such a case, you should not set it as default value.
This is a regression of revision 9bf6f0310e
opw-652387
The button Mark As Todo should be before the button Validate because
most people check things when they transfer stuff in their warehouse.
Moreover, it creates confusion, because people will think Validate means Confirm
(or Mark As Todo).
When validating an empty picking, it will give an error now.
On_change of product on stock moves and pack operations should return
a domain for the UoM.
Among a lot of views tweakings and cleaning, some changes are listed here.
product
- add currency_id, taken from the company
stock
- procurement request and inveotry adjustement wizards now correctly work
on product and templates with 1 or more variants. With one product the product
field is readonly, with a template and/or a product with variants the
product field is limited to the existing varians.
- valuation and cost method fields on the templates now come from property
fields defined on the template, or from property fields defined on the
product category. It allows to define those fields directly from the
category.Among a lot of views tweakings and cleaning, some changes are listed here.
membership
- details not visible in the default product view. However there is a specific view
to use in (membership / configuration / create member product)
When scanning multiple serial numbers e.g., the list of pack operations
can become quite long. In order to avoid that, we make it possible
for pack operations to contain multiple lots.
The implementation is done in the way that the links between moves
and pack operations remains the way it was. The important difference
is that on action_done, it will check all the reserved quants and their lots at
once first and only afterwards, it will check the lots one by one to check what
it can reserve.
As the details for the lots for the pack operation became a real object, the wizards related
to the pack operation details are not necessary anymore and were replaced
by a form view of the pack operation.
- delivery: rename cost price to shipper price to ease the understanding.
- product_email_template: fixed space issues in help of email_template_id.
- stock: labelling reordering wizard
- stock_account: labelling (inventory at date) + shorter and cleaner help
messages. The main menu for this wizard has been put in technical group.
- stock_landed_costs: fields labels update
When a location is marked as return location,
upon a return it can be put it in the possible return locations,
when it is in the same warehouse or under the same parent location.
The push rules are also applied on returned moves now, but
only when the push rule does not return the return to the original location
The lot in the return line is removed as it does not make sense
(better to change it on the pack operations)
and the views are cleaned
The returned picking is also automatically reserved.
Instead of having only outgoing, manufacturing, incoming, all... traceability on the product,
we can define on the product if there is no tracking, lot tracking or unique serial number tracking.
On the picking type we can define whether we will only create lots for the picking type or use existing lots.
The lots are required when the product and the picking type demand it.
The option for serial number will check that each piece (quantity 1) has its
own serial number.
A lot splitting wizard is added on the pack operations in the picking form.
We want to be able to handle the case where we receive a lot of iPads e.g. and we
only assign a serial number when the product is delivered. For this, when the product is
delivered, we see that we only have products with no lots. When we see that we take something
without lot for something that needed one, we assign the lot to that piece of stock.
For negative quants: a positive quant with no lot can reconcile with a negative quant with/without lot,
a positive quant with lot, will preferably reconcile with a negative quant with the same lot, afterwards
with that without lot.
Pack operations will not appear in a transfer wizard or bar code interface anymore, but
in the picking form itself. Some wizards are still needed however to ask whether a
backorder needs to be created and whether we need to do an immediate transfer
The biggest change in the model is in the picking where the locations of the picking
are not a related anymore, but need to be set. That is why the tests need to be changed.
This allows also to have pickings without moves initially and just move one pack e.g.
Locations won't be visible on stock moves in a picking either. (as they should be those of the picking)
In order to avoid confusion, the pack operations are created immediately when stock is reserved and we
are not waiting until the wizard or the bar code interface is launched anymore.
The recompute button previously in the barcode interface will only appear when the reservation changed
and the user indicated in the pack operations that something was moved already. Otherwise it will
recompute the pack operations. That way the reservation on the stock moves, is reflected by the pack operations.
Return pickings are not confirmed automatically when confirming the return wizard.
That should make it possible to choose another location for the return. (Don't return in output e.g.)
Barcode scanning is not in this commit.
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
We force the user to select only one picking at a time. The reason is that we
can choose the number of products to return for every picking, so it does not
make sense to group the returns in one picking.
opw-640030
Transfers were slowed because of the continuous
computation of pickings remaining quantities.
This revision delay the computation at the end of the transfer,
so the computation is performed only once, and it
therefore leads to a huge performance improvment.
opw-634416
Jainik Patel