In the inventory form view, the stock move table into the inventory
adjustment tab shows useless
columns. This commit add inventory adjustment related columns only.
Task : 1857705
- use the `gather` method instead of calling search with a custom domain
- expose the method so that the barcode client action is able to call it
when a line is added without being backed by an inventory line (yet).
This is a backport of 3210f10827
With this commit, when we perform a close action, we can provide infos to
the `on_close` handler, so that it can handle different cases that caused
the close action.
Note: stock moves are created from multiple objects. In case of inventory
adjustments, some field are useless like the initial quantity or the
reserved quantity. This commit hides those useless fields in the stock_move
kanban view in case of move related to inventory.
These fields aren't use in the main form views because we prepare the
context before opening the move lines wizard, but we need them in the
barcode client action because it is using a form view on this model
without clean possibility to prepare the context.
Steps to reproduce:
- activate the multi-currency option in the Accounting App
- activate the EUR currency (USD being the base currency)
- create a EUR Bank Journal with an EUR account
- on 31/07 ==> rate = 1.1
- on 08/08 ==> rate = 1.2
- create a vendor bill for Asustek on 31/07 for 39794,40 EUR
- create a vendor bill for Asustek on 31/07 for 61668,00 EUR
- create a vendor bill for Asustek on 31/07 for 33487,70 EUR
- create a supplier payment for Asustek for 134950,1 EUR
- use the payment matching smart button
- match the 3 invoices you entered;
Bug:
Odoo says there is an open balance to write-off and prevents you from reconciling
Expected Behavior: the payment total amount in EUR matches the 3 vendor bills total
amount in EUR so I would expect Odoo to consider I have a perfect match between the
payment and the vendor bills and the difference in USD (base currency) should be
automatically reflected through an exchange difference entry.
if you follow the same operation with 3 invoices of 115EUR each and a payment of 345EUR,
it will work as expected.
opw:1872978
The commit cfbfaf38be283e68c5a923ff2aafd1293135c4f1 remove the views and
menus related to mrp.message. This commit complete it by removing the
model, all the related fields and the access rules
Related to f89d4201c7
Since the invoice policy is becoming more and more simple, it is
always nice to add as much logic as possible to make things even more
simple.
For the record, 5 fields are taken into account when it comes to
invoicing policy:
service_policy
service_type
service_tracking
invoice_policy
expense_policy
They are partially linked one with the other, and not all make sense for
a given product type...
When more than one mail.channel.partner have been linked to a given user, he may
be unable to open some discussion channel because of a traceback.
The issue is that we access a channel_partner field while the recordset is not a
singleton.
We limit the search to 1 to ensure that this recordset is a singleton.
When a move line is not linked to a move, it'll be linked to the first
move of the same product at validation time. We slightly improve this
logic by linking it to the first non-completed move. To be completely
correct, we should split the move line if necessary and link it to all
needed moves, but at this time we don't want to make the logic too
complex.
Use case: create a sale order with three sale order lines of the same
products, use the detailed operations view and add three move lines of
the same products, validate the picking. Before the patch, all move
lines were linked to the first move and thus only the first sale order
line had delivered quantities.
Fixes#25488
opw-1861765
Due to the side effect on related fields that are not readonly, the value is saved
in project although not changed. Putting it readonly avoids the problem.
Fixes#26156Closes#26171
This is not expected since it leads to an inconsistent result: the user
and the access rights do not match. Better add a PIN to the manager.
This reverts commit bb8bb3cbfe.
- Create an order from the eCommerce
- Choose to pay with Stripe
- Enter the credit card info, validate
There is a short window of time (before the reload of the page) where
the user can click on 'Pay Now' again.
This is because the HTML is completely replaced, including the button.
We restore it when necessary.
opw-1866332
Introduced at e434690fe3
The button should be displayed when the order is paid to generate the invoice
Once the invoice is generated, the state is invoiced and a statbutton lead to
the generated invoice.
Remove the readonly attrs as it has no effect on a button
Create an account_move, with at least one move line having an analytic account on it
AND no label
Save and Post
Before this commit, the post failed because an analytic.line should have a label (required)
After this commit, we fill in a default name for the analytic line, composed of the data of the line,
if available, or '/'
OPW 1863418
closes#26013
Before the fix price control only worked like should on initialisation of a pos section. On switching cashier during a setting manager would lose price change rights and normal users would gain them.
Same reason as 8d948d92.
In firefox if barcode is installed, for example on a form view the keys
to navigate the possible scrolling PageUp/PageDown/Home/End don't work
at all.
This is caused by the interface barcode catching and differences of the
key event handling between firefox and other browser.
So in this change, we add these keys so they are not catched by barcode.
note: aso backport 5bc29744c so the code is the same between 10 and 11.
related to opw-706352
closes#26219
The to_refund attribute is set to copy=False.
However when splitting a move to create a backorder, a new move is created as
a copy with the remaining work to do.
This attribute is needed so that the backorder refund is consistently applied.
Essentially a backport of commit:
https://github.com/odoo/odoo/commit/c5ffca151160f9d99bec036330def108e4e91e0b
opw 1865324
Steps to reproduce the bug:
- connect as the demo user
- go to the Leaves app
- check the Leaves Summary menu: by default, it is empty
- go to Allocation Request
- create one Allocation Request for 1.00 day using the Compensatory Days type
- repeat the operation several time
Bug:
Only the first Allocation Request appears in the Leaves Summary
opw:1872365
- Set the currency to a rounding of 0.001
- Create a POS order:
Unit Price: 0.12
Quantity: 0.1
- Pay and validate
- From the backend, return the products on the create order
- Click on 'Payment'
The proposed amount is 0.01, not 0.012. It is not possible to complete
the payment process since the field is rounded at DB level to 2 digits
of precision.
We make consistent the `amount` field with the various amounts on the
`pos.order`. By using a `digits=0` and forcing the rounding, we avoid
inconsistent rounding between the order and the payment.
opw-1864344
The other overrides are working with multiple records but not event_sale.
The ensure_one() is not needed if you make a proper loop
Replaces and closes#26078
William Henrotin