We adapted the views to the new stock model, and differenciate two
different views:
- The first one is more adapted for simple operations, or when no
suggestion of location, lot, pack is needed. We have a line with
the initial demand of each product and you can complete the lot
numer, location, etc in the detailed window of a move.
- The second one is more adapted for pick and barcode operations, all
each line is fully detailed with the system reservation, you can see
the lot, location, etc you must scan in the list view.
You can choose the view you want to use in the picking type settings by
check the box 'Show Operations'
The big change is that we have now a many2many between the move and a
one2many between a move and its pack.operation (note: this model is
renamed as stock.move.line in a further commit).
Due to these changes, `action_done` had to be rewritten intierely, as it
depended and stock.pack.operation.lot and stock.move.operation.link,
that are now removed. This method was laregly inspired by the one in the
mrp module, and a further commit will make MRP uses all the core of
stock.
Due to the previous commit that refactored the stock.quant
implementation, the new concept is that the `product_qty` that will
always be in the uom of the quant (`product_qty` is a computed field in
the same style as the one of stock.move).
This commit also implements the logic that a manager is able to edit
done stock.pack.operation.
The stock.move has now a "partially_available" state (it was previously
a flag). The "split_from" field is removed now that we have a many2many
between moves (a sibling move is always a move that was splitted, or
with the backorder_id field).
The done quantity of a stock move is computed across the done quantity
of the move lines. There is an inverse method that allows user to fill
the done quantity directly on a stock move.
The reserve quantity of stock move is computed accross the
`product_qty` of the linked pack operations.
`do_unreserve` will simply unlink the associated pack operation.
Unlinking a pack operation will unreserve.
`force_assign` will mark the move as available, in order to allow the
user to create pack operations (none are created because nothing was
reserved).
`action_assign` is rewritten and splitted in two parts: if the move has
a parent (mto) or not (mts). In the mto, we'll check the available move
lines and only reserve accordingly. In the mts, we'll reserve directly
on the quants.
`action_cancel` has changd a lot: in case of a delivery, the first step
does not anymore propagate cancellation to following moves and SO. As a
result it does not propagate in the other side in case of MTO or production.
It does not delete them if we delete the related sale order for example. In
order to correct this next activities will be added in the future. Technically
action cancel on move is based on procurment rule, this commit will set
the propagate field to false on the rule if the picking_type is 'pick'
or if we are in one step delivery.
We use this commit to reimplement `action_assign` (wiped by the new
quant implentation). A move is reserved if its move lines exist, so we
introduce a one2many between stock.move and stock.pack.operation (note:
a further commit renamed this model into stock.move.line)
We use this commit to implement `action_done` (wiped by the removal of the
models making the link between stock.move and stock.pack.operations). We
can use the one2many to the pack operations.
blabla manymany au lieu de one2many
blabla mto mts
Remove get_ancestors, as orig_ids will be used instead
validation
when we are creating some packe operation with lot name, the
pack_operation are unlink and a new picking is craeted.
This is caused the function _create_lot_for_picking that unlink pack
operation having no quantity reserved instead of ones having no quantity
done.
To fix this we changed product_qty to qty_done and move the code from
action_done of picking to action_done of move
fixup! [IMP] Merge_moves functionality + many2many procurement and original moves instead of one2many
fixup! [REF] stock: basics of new model and stock.move reservation
edit reserved move line
This is the 1st commit message:
[REM] stock: stock.pack.operation.lot, stock.move.operation.link
These models will become useless once a one2many will be made between
stock.move and stock.pack.operation.
The `action_done` method on stock move has been wiped, as it depended
completely on the removed models.
Joint work with Josse Colpaert <jco@odoo.com>, amoyaux <arm@odoo.com>
and Pierre Masereel <pim@odoo.com>
The main idea of this new implementation is that stock.quant is now a
cache of the quantity per location/lot/pack/owner key. We removed every
identity per record, such as `history_ids` or `inventory_value` so that
we can now avoid the linear creation of stock.quant records and are able
to work with only one record per key.
The algorithms to retrieve the quantity per key are made to work with
multiple records, this way we can implement strategies to workaround
postgres locks if concurrent transactions try to work on the same quant
row.
Quants will not be linked to moves anymore, this is in order to be able
to edit stock moves more easily/freely. We removed the links with this
commit and wipe out the `action_assign` on stock move. This will be
implemented in a followup commit, once the relations between stock.move,
stock.pack.operation and stock.quant are clarified.
This commit seems to have unecessary diff, but it was done in order to
run tests on the new implementation.
We adapt the views by removing the fields not present anymore in the
model. This include the complete removal of the inventory valuation
view, as the implementation of stock valuation will be refactored and
moved on stock.move in a following revision.
We wipe out `action_cancel`, `recalculate_move_state`,
`move_quants_by_lot_v10` and `quants_unreserve`.
* `get_removal_strategy` moved from `stock.move` to `stock.quant`
Stock quant model:
* qty renamed to quantity
* history_ids: because the quants are not moved
* inventory_value: implementation moved to stock.move
* packaging_type_id: doesn't seem to be used (in filters?)
* propagated_from_id: because we do not split forced quants
* reservation_id: because the reservation are not linked to
the stock.move.line
We remove the `lot_ids` computed field, as it depended on the link
between stock moves and quants and could be replaced by a related
to the move lines once the new relation between stock.move,
stock.pack.operation and stock.quant is clarified in a further commit.
Furthermore, the field was not displayed to the user.
When a user edit a record, then click on a stat button, the web client was a
little too aggressive in avoiding to reload data. It was assuming that
even if the server overrides the create method, the web client did not
need to know anything about the record before executing the action from
the stat button.
However, that assumption is incorrect: the display_name property is
needed to correctly display the breadcrumbs. For example, here is a scenario
that was not correct: open a res.partner in a form view, edit its name, then
click on one of the stat button. You will see that the breadcrumb is not
properly updated.
To fix this issue, we have to reload the record, and to properly update
the title property. In this commit, we also add a getName method in the
model.
With the new views, we introduced a system where some fields could
notify immediately the rest of the system that they have been changed.
It is really cool, it allows real time edition (with onchanges).
However, this was a little too much. In some cases (an onchange that
returns a warning), it was counterproductive. So, we decided to simply
remove the feature. This commit only make sure that it does not happen,
and we will do a deeper pass later to make sure that no useless code is
left behind.
Note that this means that we can reintroduce the functionality really
easily later, eventually protected by an attribute.
Since commits 3afb78371f and e79eb01a67 the layout of the customer
portal has been updated. However the 'My details' page was still using
an old layout, leading to several issues: double breadcrumb, badly
displayed items, big headers. This commit fixes that and make the My
Details page use the portal layout and portal breadcrumb.
A tour is updated because a title content has been changed.
Various conditions were incorrectly computed and using states is not
always a good option when having also invisible attribute. Let us use
directly the invisible attribute and override it when necessary and
get rid of the magic of states.
When registering a payment token, validating it using a payment of a small amount followed by a refund
allows ensuring that the method is valid (i.e. checksumming the card number simple ensure the number
is valid but not that the card exists). This commit introduces a generic approach that must be implemented
for each acquirer that has tokenization support. This commit also introduces a generic payment token registration/usage template that can be adapted according to one's need.
payment_ogone: add support for tokens validation
Before this revision, pressing ENTER when inside a many2one field
triggers a 'focus out' event. In particular, if one creates a many2one
record and uses the ENTER key to click "Create and Edit", two dialog
windows appear: one to actually create the associated record, and a
second to alert the user that they are creating an associated record.
The latter appears every time the many2one field loses focus.
This commit changes the 'key up' event for many2one fields to ensure
that the ENTER key does not trigger a 'focus out' event.
We can now select a new localization module in place of the existing one, if no accounting has been done yet.
This allows to set a default CoA for Germany and China, by choosing arbitrary one of the existing localization package at the installation since they can directly switch if needed.
Was PR #16605.
Lot of features were not working and this commit fixes that
- Create entries upon reconciliation
- Add buttons at the end of the process to view/close bank statement
- Fix partial reconcile
- When changing partner, correctly fetch counterpart account and fix search domain
- Add ability to reconcile without choosing a line (will automatically create a line)
- some other small fixes
- Set up a product with 'Real Price' costing method, in real time
valuation
- Receive 1000 units at $0.10 each
- Create a landed cost of $456.70, validate => it creates a quants of
999 units at cost $0.56 and 1 unit at cost $-2.74.
- Perform an inventory adjustment, and set the quantity to 0 instead of
1000, post inventory.
An error arises due to the constrain debit + credit >= 0.
This is caused by the method `_prepare_account_move_line` from
`stock.move`, which cannot handle negative cost for quants.
opw-752063
Fixes#17707
Clicking on the discard button in a form view whose previous view is
another form view wouldn't do anything.
This is fixed by making the view_manager trigger_up a history_back event
and then the history_back callback will handle cases in which there is
only one view and only one action, which used to be rejected
- [x] remove 'available' field:
- [x] availability is computed only based on country/state/zip rules
- [x] also in ecommerce
- [x] remove 'price' computed field
- [x] remove context hack for computing price
- [x] price is not computed on save anymore, but with a get/set price button
- [x] errors/warnings are now displayed in a special message box
- [x] carriers return values are now more versatile
- [x] delivery_grid is now a generic shipper
- [x] fixed price is not a particular case of a grid anymore but a simple product price
- [x] as a consequence of previous 2 points, a lot of duplicated code has been removed
- [x] we can now save SOs even when a webservice has failed to return a price
- [x] no more hacks on name_get/context
- [x] "free over" an amount is now a generic feature
Having price and availability as computed fields of a delivery.carrier
may sound handy.
Actually, it comes with is batch of lame hacks, poor performances and
terrifying heisenbugs.
We will try to make something better. It has to start with a breaking.
The check register report is the same as the general ledger except it only displays
account in type cash. On report, a "totals" line appears when only one journal is selected
but it's value is computed based on the whole accounts without filtering. Then, we need a
way to compute this totals only based on specific accounts
task: https://www.odoo.com/web#id=28656&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
The commit 5854bb7d12 introduces a new option
to drag element without dropping them.
But it's not allowed to start a new drag and drop until the first one is
completely done.
So when the element is removed from the dom (the test is finished), we complete
the drag and drop in order to let next tests perform drag and drop.
This fix 2332df6bc7 has been done in stable and some customers
wants to keep the button "Post Inventory" available all the time.
Now the button is just visible in developper mode.
opw:748347
On the CRM dashboard, the shortcut 'exp. closing' is the same than the
'overdue' shortcut. However, the number of opportunities in these
categories is computed differently (see method
`retrieve_sales_dashboard`).
We introduce a new filter "Overdue Opportunities" which reflects this
difference.
Backport of 9d2f48dc7f
opw-704173
opw-751165
Simon Lejeune