In the Netherlands it is customary for small
businesses to configure the Chart of Accounts
with 4-digits account codes.
This scheme is broken when several accounts share
the same 4-digit prefix, which was the case before,
as the truncated codes will not be unique.
Fixes#13853Closes#14175
The default background-size for the s_big_message snippet was not
set to "cover" as the "oe_img_bg" class is missing from the snippet
structure. As this change is not critical but should not be merged
in a stable version, this change will be done in master and this
10.0 fix will only force the "cover" value for the default bg thanks
to LESS.
Commit 19e3757ffb allows to return the product price without the
discount included in the unit price. However, `lst_price` is always in
the company currency, not in the pricelist currency.
opw-692896
The s_parallax snippet was refactored in 10.0 but this refactoring
broke some snippet extensions such as the s_parallax_slider.
This made the texts disappear once the snippet was resized.
If a PO with picking is canceled, then reset to draft and confirmed again
two pickings are created. Indeed when creating the picking, moves related
to the PO are confirmed and assigned, even those which were previously
canceled.
This commit ensures that canceled and done moves stay in their state.
This avoid having two pickings for a single PO.
When there are 3 different lots reserved for 3 different serial
numbers for the final product, if you do the first finished product, the
finished lot is put on all stock.move.lots even if nothing has been
consumed for it.
This results in traceability report for the first finished lot being linked
to all of lots instead of just the one that was consumed.
Now we update lot_produced_id only on stock.move.lots where quantity_done > 0.
That way it will only links with the correct one.
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
After modifying the database schema, if some models do not have a table/view,
attempt to recreate it by calling their method `init()`, following inter-model
dependencies.
Fix the model `board.board` by making it an abstract model.
Add the missing model dependencies on report `crm.partner.report.assign` to make
it depend on report `account.invoice.report`.
overwrite in the context was never passed to update_translations
Loading the translations with the overwrite checked did not overwrite the
previous translations
Introduced at d465346
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
If multiple views had the same name and same priority, the order
of application of their xpath was not deterministic. That may be a
big deal if both of them were doing xpath with position = inside.
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)
The partner of an account move is defined as a related on the partner of
the move lines. This kind of relation implies that the partner of the
account move is the partner of the first account move line. This is
arbitrary and doesn't make much sense.
Closes#14167
opw-693289
To have the right sign, amount = debit - credit
Before the fix:
-Create an invoice in another currency than the currency of your company
-Link the invoice lines to an analytic account.
-Validate the invoice.
Bug:
The analytic lines have a negative amount in the amount currency field
which was a bit stange as it is the opposite sign than the amount in the company currency.
opw:692557
When an asset is set as Prorata Temporis, with a one month period, the
first depreciation amount is computed on the basis of the remaining days
in the purchase year. This doesn't make sense for a monthly
depreciation.
This commit makes the distinction between a monthly and a yearly
depreciation. In the case of a monthly depreciation, the remaining days
in the purchase month are taken into account.
opw-690034
Backport of 0a3899b72c
The fiscal year start date should be taken into account when calculating
the depreciation amount in case of prorata temporis.
opw-678072
Backport of e69d9b8b7d
Steps to reproduce:
- Create a Sales Order with 2 product qty
- Keep Delivery Method as DHL International
- Confirm
- Open Delivery Order
- Edit Qty of the Delivery Order
- Change Carrier (any integrated)
- Validate the transfer
- Process the backorder
- Edit and change the Carrier to normal or free delivery charges
- Validate
Bug:
The price of the free delivery charges was not recomputed and kept
the carrier price set on the SO.
Fix:
When the price of the carrier is "fixed" or "base_on_rule", the price must
be reconsidered in case of change.
opw:691224
Since 1ba91042d monetary fields values could be represented by a
float_precision which is aimed as an improvment for digit precision when
saving a monetary field value to the database.
xmlrpclib (we are using to serialze the response) is handling some
common datatypes, but for custom one we would need to register it with
how it needs to be serialized.
This commit add a convert_to_read method to the Monetary field so when
reading monetary fields value we get the float numbers and not the
float_precision ones.
The float_precision is needed when saving, so it is alright to have float
when reading.
fixes#13857closes#14125
opw-692373
It can happen that the account moves generated during reconciliation
from a bank statement with several lines have the same number.
This is a complement of commit 9365482df0. The order of statement lines
is not derterministic since it is based on `statement_id desc,
sequence`. Therefore, at each call of `process_reconciliation`, the
array `self.statement_id.line_ids.ids` can be different.
opw-690853
Since this commit d025251c7e, a lead
does not use stage anymore. A lead is either alive or archived.
Then the field stage_id is useless in the crm_case_tree_view_leads view
opw:691838
Yannick Tivisse