-changing the date_invoice field do not reset anymore the sequence_number_next (it now only affects the prefix)
-the date_invoice is now passed as ir_sequence_date AND ir_sequence_date_range in the context, for sequences that use the date_range feature in prefixes
When re-launching Odoo on an existing database in Python 3.6[0] it's
possible that the scheduler will preempt the main thread
mid-module-import and run the cron thread which causes registry (and
module) initialisation with only a subset of the Python files loaded
and thus e.g. tries loading auth_crypt with a registry in which none
of res has been loaded makes for interesting situations.
Delay spawning the cron thread until *after* the registry preload at
least, though I don't think that actually entirely fixes the issue.
[0] and probably in any Python >= 3.3, I'm guessing it's related to
the per-module import locks which replaced the old global lock:
https://docs.python.org/3.3/whatsnew/3.3.html#a-finer-grained-import-lock
though since ir.cron has little reason to import anything it could
also just be Python 3 scheduler changes which allow/cause a
context-switch during imports while the Python 2 scheduler would
not allow that. IDK.
The function that checks if we need a back oder or not compares
the initial demand and the quantity processed on the picking.
When unit of measure are activated the initial demand (product_qty)
uses the uom of the product. However the quantity processed on the move
(quantity_done) uses the uom of the move.
This commit uses product_uom_qty instead of product_qty. Product_uom_qty
represents the initial demand transformed with the uom of the move.
It also add a small test with a back order that ensure the quantities
are correct.
It also repairs the test stock flow where in some case immediate transfer
return the back order wizard instead of processing the move. In these cases
we catch the back order wizard and run it.
1. Create a product A, set to stockable product, set its UOM and
purchase UOM to Unit(s)
2. Create SO with A, but use a different UOM than Unit(s) (e.g. Dozen)
3. Validate, go to delivery, validate, and print the delivery slip
Ordered quantity shown on delivery slip is in SO UOM but listed as
product UOM.
opw-766914
Resetting the key 'test_barcode_handler' to its value before the
test was technically the best solution, as a test should leave the
environment unchanged. However, in this case, the widget is
undefined (there is obviously no 'test_barcode_handler').
Whereas this should not be a problem (the fields in the registry
are supposed to be accessed using get(), and the presence of a
key mapping undefined is equivalent to the absence of the key in
this case), this breaks a test in Studio if the latter one is
executed after the barcode test. This is because Studio browses the
map of the field registry to access each field's prototype. When it
encounters an undefined value, it crashes.
When used on a large db with lots of records to process, `last_run`
date that was written on the base.automation could be a few seconds
later than `now` that was used to check whether to run the automated
action. This caused some small time frames to be never checked, and some
records to be missed. We fix this by using exactly the same timestamp.
opw-766182
This was the case about 15minutes ago. But before pushing we
decided to change the Barcode override of FormController to
directly use handlers of the FormController when it could (e.g.
to handle 'Edit', 'Discard' actions). This wasn't a good idea as
those handlers don't return anything, and the barcode mechanism
requires its handlers to return a deferred. So basically, it
crashed when such a barcode was scanned. Having a test suite is
nice, but you should not forget to relaunch it before pushing...
Organize the displayed fields to help users understand more what's going
on behind the scenes, especially with the remaining_qty and
remaining_value things.
The approach we tried with the current implementation lead to a replay
of all the next moves since a move had to be corrected, and posting an
account entry with the valuation difference.
This proved to be slow and complicated, and moreover the resulting
account entry could be very difficult to understand and justify.
So we moved away from this strategy and implemented the following points:
For FIFO
* If a move goes into negative (sent more than availabale, we do not
counterpart directly at the next in move: we valued it at the last
fifo price and only when running `_fifo_vacuum` (which is called at
every openning of the valuation report), we use some units currently
in stock and post an account entry with the difference between the
fake value and the real one used.
* When editing a done move and increasing its quantity, the new quantity
is available now and will be used at the next move out. We do not try
to replay the history to make the new values go away directly.
* When editing a done move and decreasing its quantity, it acts as a
return to the supplier at the price unit of the move.
On average price:
* Don't replay anything, if we fall under the negative stock usecase,
value at the last average price.
We restore the previous code that set the average price on the standard
price and we slightly patch it to continue to update the average price
if quantity in stock is negative.
We also add a link between stock moves and account moves. A stat button
on the stock move's form redirect directly to them. It's therefore a
little easier to understand what happened.
We remove the separate fifo and average price fields that were added in
saas17, we keep the single standard price (that should be renamed
cost_price for consistency). In the same idea, remove the cumulated
value that was stored on the move. If we need it, just recompute it
(it's not a frequent operation). We remove last_done_move_id,
last_done_remaining_qty and last_done_qty that were added in saas17 to
help in the replay method, as we just got rid of it. We also remove the
code that compensate the negative stock directy at the next in.
What the fifo vacuum does is essentially the same thing as what an out
move do: find a candidate and take units from it. In this case, the
candidates are newer than its concerned stock move. We stored on the
concerned stock move the value at which we sent it (remaining_value) and
post the difference with the real value on a real product.
Do not inline the average price calculation in `action_done`, as there's
a computed field that handle correctly the negative stock (does not
trigger division by 0). Also, complete this compute method by also
looking on transit locations and implement two fallbacks if the quantity
in stock is null: return the latest cost, if not found return the
standard price.
Also, make sure that `remaining_qty` is only set on fifo moves.
rename `_get_candidates_out_move` to `_get_fifo_candidates_out_move`
and `_get_candidates_move` to `_get_fifo_candidates_in_move` as it's
more explicit that they're only used in FIFO costing.
Fix `_update_future_cumulated_value` to filter only on internal moves
and to remove the value added in the past (self is always an out move to
which we added some value) and rename into
`update_fifo_future_cumulated_value`.
In `action_done`, rename `qty_taken_for_candidate` to
`qty_taken_for_candidate` as it's the qty we take to compensate the
candidate and not a quantity we take on the candidate (in this case,
some old out moves that we could not valuate in time because the stock
was negative). We fix the write on the value and cumulated value to
decrease the qty_taken_for_candidate*move.price_unit, because an out
move has always a negative value and we actually substract the value of
`move` which is always an in move and has always a positive value.
We fix the purchase test where negative out moves were valued positively
and add `test_fifo_negative_1` that tests the sending of goods we do not
have and the receipt encoded afterwards.
We expose a serie of functions that return domains to find in and out
moves and, as opposed as before, the transit locations who have a
company id set (i.e. the inter warehouse transit) do not impact the
valuation of a company.
We rename the `not_move` argument of `_get_latest_cumulated_value` to
`exclude_move`, which is more explicit.
This method is used to set `qty_available`, `virtual_available`,
`incoming_qty` and `outgoing_qty`.
We change the depends because only looking on stock.move is enough (all
changes on quants are made through stock moves, and we de not support to
edit directly quants anyway).
This method will call `_get_domain_locations` and we make sure that,
when the `company_owned` key is present in the context, we also return
domains to find products that are in a location that belongs to the
current user's company. This is done in order to include transit
location.
Also, remove the comment from tde. As these fields are displayed in
view, only using the context could alter the behavior.
The barcode mechanism is supposed to handle commands PAGER-FIRST
(go to first record referenced in the pager) and PAGER-LAST (go
to last record). Before this rev., it wasn't the case.
We needed to add an option 'notifyChange' to the updateState
function of the pager, to ensure that the form is correctly
reloaded when the pager cursor is manually set (by the barcode
handler) on the first or last element.
The barcode mechanism is optimized to (in certain conditions),
directly increment the quantity of a numerical field inside an
x2many, without performing any RPC, and then re-rendering the
x2many to display the new value.
Before this rev., it seemed to work fine, but when the view was
saved, those changes of quantity were lost. This was because the
changes weren't correctly notified to the model (the quantity
field being inside an x2many, the correct update command for the
x2many should be generated).
When a barcode field with widget="barcode_handler" is in a form
view, an onchange RPC should be done each time a barcode is
scanned.
Before this rev., it worked by chance because the views using it
don't define a 'pack_operation_product_ids' field.
Anyway, this widget is meant to be generic, so it shouldn't
hardcode a fieldname.
Before this rev. a warning was displayed when a barcode mapping an
invisible button was scanned. It shouldn't, for the following
reason. In the stock.picking form view, two buttons with
barcode_trigger='validate' are in the page ('Start Inventory' and
'Validate'), and there is always at least one of them that is
invisible. So when scanning the 'validate' barcode, we don't want
a warning to be displayed, as there is potentially another button
that is able to handle the request.
When scanning a command barcode, the view shouldn't be redrawn
after the operation corresponding to the command is executed,
for two reasons: first, it is useless as the view has already
been reloaded, and second, it may cause issues if it has been
destroyed meanwhile.
For example, when scanning barcode O-CMD.MAIN-MENU from a
picking form view: a do_action is performed to go back to the
main barcode client action (so the current form view is destroyed),
but an handler tried to redrawn the destroyed form view, which
produced a crash because the session was required by Date fields,
and it couldn't be provided (there were no more parent listening
to provide it).
When a keypress event is triggered in a 'field_float_scannable'
widget, the event is first catched by the barcodes mechanism, and
then manually re-triggered. However, the way it was done implied
that the environment was notified of each keypress event, so if
there was an onchange on that particular field, an onchange RPC
was done at each keypress.
Moreover, the focus was lost at each keypress as well.
When creating a new picking and adding a new product operation, the operation was
disappearing. As the field `product_id` is readonly in some conditions, its value
wasn't sent by the client on the picking write rpc.
This behaviour of not sending readonly fields in x2many has been correctly
implemented with the new views but some views (like this one) was basing their
behaviour on this breach.
See rev. https://github.com/odoo/odoo/commit/3b3f6f04af79d7dcc4461262e14e05096d76180b for more details.
The key `form_view_initial_mode` can be set in the action context, to
open the action in edit mode, mainly.
This key wasn't supported since the new view refactoring so this commit
restores its support.
This option has been removed with the new views but was used in barcode.
The form renderer was also dealing with some part of the autofocus
but this should only be handled by the controller.
The logic is now only in the controller and a test case has been added.
Since the new views, most of the barcodes feature was
broken. This commit re-enables the support of commands like
'edit', 'save', 'cancel', 'previous' and 'next'.
Also changed javascript event handler to jquery event handler to
make barcodes testable in phantomjs.
In case where the product is of invoice_type 'order' and not 'delivery',
we allow the user to edit the anlaytics lines / timesheet.
Previously, an employee was unable to edit an timesheet line once saved.
When you work on prepaid pack / long task, it is frequent to edit
existing timesheet line.
Stock picking batch was introduced in saas-17 instead of
master as planned. However I missed one field that has been renamed on
stock picking called scheduled_date inseatd of min_date.
This commit make the inverse change in order to be compatible with saas-17
qdp-odoo