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.
This merge adds a real view of invoices on customer portal. It is based
on the invoice report layout and replaces the pdf-only support of current
customer portal. Future commits will add payment means notably in invoice
portal and therefore further enhance the feature.
Closes#19015.
This commit adds a page view for invoices on the customer portal. Layout
is based on the invoice report to closely match what is already done in
Odoo. It replaces the old controller that returned only the pdf.
Customers should now be able to receive both.
Future commits will improve invoice page view notably in account_payment
while adding payment options in account customer portal.
Purpose is to allow customers to access their invoice without having an
user account created. Using an access token they will be able to see
their invoice on the customer portal, like what is already done for
quotations for example.
Invoices now inherit from portal.mixin. This means they have a share url
and a method that generates correctly the /mail/view url using the
access token and signup parameters. This url is used in the email template
used to send email in the invoicing flow.
Purpose is to have methods on transactions can be called and that handle
correctly transactions linked to a sale order, but also in a near future
to an invoice, a subscription, several of them, none of them, ...
This commit already checks that sale order related code for payment
transactions is run only when a sale order is linked to a transaction.
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
- Fixed 500 errors when trying to display payment form because of variables partner_id/acquirer_id missing.
- Accepted credit cards are now display next to the acquirer name on the payment form
Commit 3cfd64f63f moved the frontend chatter from a website-based module
website_mail to portal. Purpose was to allow its use in customer
portal independently from the website.
However some renaming done during the move was not properly propagated
resulting in the chatter not being loaded. This commit fixes that by
correctly using the new class node as well as widget name when
instantiating the widget.
- model renamed: stock.picking.wave -> stock.picking.batch
- Class renamed: StockPickingWave -> StockPickingBatch
- .xml files: changed XML IDs according to module guidelines, reindented code and removed commented code
This commit only rename every string from picking wave to batch picking.
Model rename will only be pushed on master(saas-18) once the forward port
will be done.
* rename some files according to guidelines;
* clean template name to clean their ordering and ease template browsing;
* use html type for mail templates body instead of cdata;
* clean html for mail templates introduced at 96da10de6cc20486b3e37fd4c6c88eb61cbb919c;
No horse has been harmed and no functional change performed.
Integration in customer portal of this module has not been updated with
last changes done in customer portal. This commit fixes that.
* update breadcrumb use;
* update titles;
- Replace 'Use Cash Basis' checkbox by 'Tax Due' having two radio buttons,
- Based on Invoice (default)
- Based on Payment
- "Tax received account" display only when we select "Based on Payment"
- Changed the field name 'use_cash_basis' into 'tax_exigibility'.
Was PR #17326
tbe-odoo