-amount_currency in model account.analytic.line is a related field to move_id.amount_currency
where move_id is an account.move.line
-amount_currency is computed in function create on model account.move.line by considering that
amount = debit - credit (since 8.0)
-amount in model account.analytic.line is computed by considering that
amount = credit - debit (since 8.0) in the function _prepare_analytic_line.
So when creating a customer invoice with an analytic account in another currency, the created
analytic line has an amount which is the opposite of its currency_amount.
This commit also reverts the commit 7fca8ad89e to keep the same
behavior as in 8.0 for the creation of an analytic line from:
- an expense
- an invoice
- a task
The computed not stored field analytic_amount_currency displays the currency amount with the right sign.
opw:694085
Without this patch, when a product was added to cart, if this addon
was installed, it always landed in English in the SO.
This happened because the context, containing the current language,
was being aborted here (`context=None` instead of `context=context`).
This commit closes#14340
When a picking is partially available, and the company works in 'just in
time', they often need to re-check the availability of some products
just before sending them.
In 8.0, it was totally possible, to recheck the availabilty of products.
To fix this, we just add a button when the picking state is 'partially
availbale', which does exactly the same as 'Reserve', but is secondary
and contains the label 'Recheck availability'.
This reverts commit 897290dd3f.
It seems it breaks other use case, since this was fixing more a
usability thing (need to click back on code view to save code view
changes) it is better to revert than to add drawback.
A better fix should be introduced, or the solution would be to not fix
it and have a warning indicating what needs to be done.
opw-693052
Commit a572b8115c removes the inverse function of the `date_planned`. This
is necessary to avoid unexpected changes of the scheduled dates.
However, this removes the ability to set the scheduled dates of all
lines at once.
This commit introduces back the functionality thanks to a new button.
This way, the functionality remains without unexpected behavior.
Backport of rev: https://github.com/odoo/odoo/commit/2cf80e00752c68e443b0cd442ee50f7d6daaa455
opw-692873
A misleading behavior occurs with the recomputation of scheduled date.
Here is the use case:
- Create a PO with 2 products
- For the product 1, set the scheduled date to today + 7 days
- For the product 2, set the scheduled date to today + 14 days
When saving, the scheduled date of product 2 is reset to today + 7 days.
This is of course unexpected, but moreover, a different behavior can
happen depending on how the scheduled dates are modified. In the
previous case (both products have now the same scheduled date), one can
observe 2 situations.
Case 1.
For the product 2, set the scheduled date to today + 14 days and save.
In this case, the scheduled date of product 2 is not reset.
Case 2.
- For the product 1, set the scheduled date to today + 8 days
- For the product 2, set the scheduled date to today + 14 days
In this case, the scheduled date of product 2 is reset to today + 8 days
when saving
The reason of a different behavior in the 2 situations is that the
scheduled date of the PO is changed in case 2 and not in case 1. Since
the scheduled date of the PO is changed, it triggers the inverse
function `_inverse_date_planned`.
When saving, it is not possible to know whether the scheduled date of
the PO was changed on purpose by the user or recomputed. There are 2
solutions to get a consistent behavior:
- Force the scheduled date of each line to be the same than the
scheduled date of the PO. However, this makes the scheduled date of
the line useless.
- Do not change the scheduled date of the lines when the schedued date
of the PO is changed. However, this removes the ability to reset
automatically the scheduled date of the all lines at once.
This is the second solution which is chosen with this commit.
opw-682934
opw-684063
Closes#12904
Backport of rev: https://github.com/odoo/odoo/commit/4326d864d83125abc8f82dfb0089021abf22f9ca
opw-692873
When Anglo-Saxon accounting is activated:
- Use two different accounts for Input/Output for Stock Valuation
- Create a vendor bill ==> by default, the Input Account for Stock
Valuation is used
- Validate the vendor bill
- Refund the vendor bill
When the refund is created, the Output Account for Stock Valuation is
used. There is actually no obvious reason to use this account instead of
the account originally used.
opw-691571
It seems Paypal does not always send the same responses on auto-return
even when PDT is off. Although not reproducible on a Paypal sandbox,
sometimes the system auto-return to /payment/paypal/dpn without any
meaningful POST data. This seems to only happen with new accounts
that use the 'Hermes' web application of Paypal.
The correct thing to do would be to add a new field on the paypal
payment provider for PDT token and make the PDT flow available
to users; but this is a stable branch and this fix is already
sufficiently delicate. This shall be done in master though.
From this revision on, users can then activate PDT on their paypal
account, set the PDT token as an ir.config_parameter value (WITH
GROUP RESTRICTION SET TO ADMIN/SETTINGS GROUP!!!) and the system
will process these requests correctly.
There is a multi-company record rule on `res.partner.bank`,
meaning you cannot see the bank accounts of other companies.
Making a constraint on `sanitized_acc_number` alone prevent
to create a same bank account into different companies,
while you cannot see this bank account from the other
companies.
In this case, the user tries to import its bank statement,
and it contains a bank account which already exists
in the database but for another company than the one
he is currently importing the statement, and,
- it cannot find it because of the multi-company rule,
- it cannot create it because of the constraint
The constraint must take into account the company
opw-690969
The revision
a1d6c2d631
has been ported with an oversight:
except_orm is no longer imported in this file,
besides, the new way to raise these warnings is to
use "UserError" instead.
opw-693779
If the graph view was left while a nvtooltip was shown (thanks to
keyboard shortcuts or during loading time), the nvtooltip remained
and was only destroyed when leaving the action.
Now they are automatically removed with the view as they are now
placed inside of them instead of inside the body element.
When there is a shipping address, this is the second select tag which
is used(defined in website_same_delivery/views/website_same_delivery.xml)
opw:693127
On an accounting journal, when checking "Dedicated refund sequence",
choosing the refund sequence is mandatory. This is the subject of the
below revision:
d94c449547
Since the refund sequence field was available only for with the debug
mode, the user was not forced to choose the sequence, while he must be.
This is not possible to use the dedicated refund sequence if you do not
choose it there.
opw-693955
Instead of hardcoding the IN & OUT endpoint
addresses for the ESC/POS printers, we now
attempt to auto-detect them.
This should increase compatibility with many
compatible thermal printers that are simply
using a different address, such as the
- STMicroelectronics POS58 Printer USB
- HU HAI SUNCSW Receipt Printer Co.,Ltd. Gprinter USB Printer
Fixes#12890
The scenario when using the code view is the following :
- click on code view button to use code view
- make changes
- click on code view button to get back to wysiwyg view
- save from the wysiwyg view
If the 3rd step is not done:
- for the inline editor, we lose the changes that have been done in code
view,
- for the iframe editor, we lose the entirety of the content.
At one time the user was forced to go back to wysiwyg before being able
to save, but this have been removed hence the present usability issue.
With this fix, when the editor content is saved, if the user is in code
view he is automatically set back to wysiwyg view.
closes#14339
opw-693052
Before, it did a search to see if the package existed,
but the only thing it needs to do is see if the package
on the pack operation corresponds to that of the quant. (no need to check children also)
There is a test added:
A picking with 120 pieces incoming, 120 in pack 1, 80 in pack2
When we deliver those in a picking out, with product pack operations: (by taking them out of the pack)
120 from pack 1 and 80 from pack2,
we should only have 2 quants and links between moves in the end
And before, it generated 3 because it matched the wrong quants and made the wrong links.
opw 693760 closes#13836
In 9.0 when the pos user was not at least in the group Accountant
(group_account_user), he was not allow to close or open the balance
when the pos session was configured in cash control.
ps:be carefull with the old rule: Point Of Sale Cashbox Line POS User
deleted with a26b805f5e
opw:69251
This commit fixes the driver to respect the new device
registration mechanism via hw_proxy.rs232_devices.
It also refactors the code to more easily support multiple
scale protocols, and introduces support for the ADAM Equipment
AZExtra scale protocol. (Might be compatible with other ADAM
Equipment scales)
Support for th AZExtra scale is experimental at the moment,
especially given two annoying problems with this model:
- they do not support proper probing (stays mute until a
non-zero weight is measured), so they have to be probed
last and *assumed* to work
- the scale beeps when a read attempt is made and the
weight is not stable yet, or the weight has been already
read previously. This constant beeping during operation
is mitigated by extra delays between readings, but might
still prove to be a major issue for supporting this scale.
RS-232 drivers now need to register any device
they are handling in the hw_proxy.rs232_devices map.
This will prevent other drivers from probing them,
possibly messing up with the device.
Any update to rs232_devices must be done while holding
the hw_proxy.rs232_lock.
The hw_scale driver will be updated to use this mechanism
in the next commit, that will also handle a new RS-232
scale protocol.
- ngrok download URL has changed
- default kernel for raspbian image has changed and needs to match
- remove pre-existing git checkout to avoid conflicting
- wait a few seconds after setting up loop dev with kpartx to access image
contents - sometimes required to let the device appear in /dev
Some banks, like ING, create a line for free charges.
We just skip those lines as there's a 'non-zero' constraint
on the amount of account.bank.statement.line
The tests are running on consumable product, it means that there is no
resevation of quants and verification of reserved quants when you create
and assign moves. So the tests are not really usefull with consumable
products.
To make the tests efficients, we set the products as stockable. And we
use 'reserved_availability' instead of 'availability' in tests
'test_10_pickings_transfer_with_different_uom' and in
'test_00_picking_create_and_transfer_quantity' be cause the assert is
done after the move reservation.
In test 'test_00_picking_create_and_transfer_quantity' when we check the
move_lines state after the action assign, the first and last should be
only 'confirmed, because they are partially available. When product
were not stockable, all lines were assign, because there was no check of
the reserved quants.
In 'test_10_pickings_transfer_with_different_uom' we removed the call
'picking_out.action_confirm()' and 'picking_out.action_assign()',
because they already have been called before.
The price set for the non integrated carrier must be the same either when you
set it on the SO with button "set_price" or when you set it on the stock picking.
The field "carrier_price" must be in readonly when the state of the picking is done.
opw:691224
Hypothesis:
- We have a product 'pa' managed by lot.
- We don't create lots, when we receive products.
- We create lots when we deliver products.
- We don't have any units of product 'pa' in stock.
- We recieve 4 units of product 'pa' in one picking.
- We create a picking to deliver 3 products 'pa' (stock.move).
- We actually deliver 4 units of product 'pa' (1 in 'LOT1', 1 in 'LOT2' and 2 in 'LOT3').
- The problem also occurs when you just have 2 products in and 2 out in
different lots, but we based the example on the tests defined in
'test_stock_flow.py'
Thesis:
- We don't have anymore quants of product 'pa' in stock after delivering the 4 units
Problem:
- We actually have 3 quants of product 'pa' in stock, two having the 'lot_id' corresponding
to 'LOT3' and 'qty=-1', and one having no 'lot_id' and 'qty=2'.
Origin:
- This problem is caused by a bad condition in the function '_move_quants_by_lot' defined
in the model 'stock.move'.
Explanation:
When we reserve the 3 units of product 'pa' in the picking out, the quant in stock having
'qty=4' is splitted in 2 quants, one having 'qty=3' and a 'reservation_id' equals to the id
of the move in the picking out. And one with 'qty=1', having not reservation id.
So once the products are reserved, we will complete the pack operation present in the picking.
We will add 4 units of product 'pa' dispatched in Lot as 1 in 'LOT1', 1 in 'LOT2' and 2 in 'LOT3'
to the pack operation.
Then when we validate the picking, the quants with references to 'lot_id' must be created, and
then moved to the client.
Because we have set 4 units of the product 'pa' in the pack operation, an extra move of 1 unit of
product 'pa' is added to the picking to have a total of 4 untis of 'pa' moved to the customer
location.
When the function '_move_quants_by_lot' is called, it gets in parameter 'false_quants' which contains
the quant reserved by the first move, it means the quant in stock with the reservation_id to the first
move, and 'qty=3'.
The function, will now split this quant in 2 different quants:
- one with 'lot_id' corresponding to 'LOT1' and moved to customer location.
- one with no 'lot_id' staying in stock location still reserved to the first move.
Then, the function should reset the 'false_quants' with the quant containing the 2 last units reserved
in the quant from the last split in order to complete the next operation (create a quant with lot_id 'LOT2').
But the condition to find this new reserved quant contains (x.package_id.id != ops.package_id.id) where x is
a quant which is wrong, because when we don't manage package, x.package_id.id is 'False' and ops.package_id.id
is 'False' too. So it doesn't find the remaining quant.
So to fix it, we changed this part of the condition as the quant package_id should be equal to the pack operation
package_id (if no packages, False = False)
Christophe Simonis