[13.0][MIG] stock_account

[MiquelRForgeFlow]

Migration of stock_account.

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

[MiquelRForgeFlow]

Ready @pedrobaeza

[StefanRijnhart]

What a data model nightmare creating these valuation records. Have you got any statistics about the duration of this process, iterating over every done stock move?

[MiquelRForgeFlow]

I have added the tracking_disable=True to speed up a bit.

[StefanRijnhart]

Is the performance now reasonable? Have you got an indication?

[MiquelRForgeFlow]

@StefanRijnhart A client bbdd with 258500 stock moves (221880 done moves) -> 7 hours 22 min (duration of this post-migration)

[kos94ok-3D]

@MiquelRForgeFlow Is product.product call tracking?

[MiquelRForgeFlow]

No, because I disabled tracking as you can see in the code.

[kos94ok-3D]

I ask why you added it

[MiquelRForgeFlow]

Because the tracking is not needed and can generate side issues.

[kos94ok-3D]

Ok, What do you think about use SQL instead of call _compute_value_svl.
I call _compute_value_svl because the product doesn`t have in cache correct value when I create SVL by SQL

[MiquelRForgeFlow]

I don't know. Maybe doable by putting some explicit flush() calls to avoid the cache issue?

[kos94ok-3D]

I tried but don`t work

[kos94ok-3D]

@MiquelRForgeFlow It has to save ~30% time:kos94ok-3D@8c5405f

[kos94ok-3D]

Hi, @pedrobaeza. Do you have a planned date for review it?

[kos94ok-3D]

I think we have to fill it

It was done in my version:

And will be good if we link SVL to Price history

[AaronHForgeFlow]

@kos94ok-3D How did you manage to get the account move information to introduce it in the layer? I think it would be great if we can preserve that information.

[kos94ok-3D]

@kos94ok-3D How did you manage to get the account move information to introduce it in the layer? I think it would be great if we can preserve that information.

def _get_related_account_move(env, svl_vals):
    """ Return Account move related to Stock Valuation Layer"""
    domain = []
    if svl_vals.get('stock_move_id'):
        domain = expression.AND([domain, [('stock_move_id', '=', svl_vals['stock_move_id'])]])
    if svl_vals.get('old_product_price_history_id'):
        env.cr.execute("""
            SELECT create_date
            FROM product_price_history
            WHERE id = %s
        """, (svl_vals['old_product_price_history_id'],))
        create_date = env.cr.fetchone()[0]
        domain = expression.AND([domain, [('create_date', '=', create_date)]])
    if not domain:
        return env['account.move']
    account_moves = env['account.move'].search(domain)
    if len(account_moves) > 1:
        return env['account.move']
    return account_moves

[MiquelRForgeFlow]

@kos94ok-3D If we add your account move filling method, it will affect badly the performance or not?

[kos94ok-3D]

@MiquelRForgeFlow I think my function needs to rewrite to SQL, I sent it just as an example.

[MiquelRForgeFlow]

@kos94ok-3D @AaronHForgeFlow Added the account move information in a neat way :)

[kos94ok-3D]

Required because old_product_price_history_id not filled if first row does not content it

[kos94ok-3D]

It is ok for me

[AaronHForgeFlow]

For the fifo case the quantities of the layers is well migrated for the test I have performed so far. However, for the outgoing stock moves, the value in the layers is not correct. For example in standard Odoo 13:

layer_in_1: qty: 10, unit_value: 25, total_value: 250
layer_in_2: qty: 10, unit_value: 15, total_value: 150

the layer out takes 10 units from layer_in_1 and 2 units from layer_in_2:
layer_out_1: qty: 12 unit_value: 23.33 total_value: 280

In a migrated database:

layer_in_1: qty: 10, unit_value: 25, total_value: 250
layer_in_2: qty: 10, unit_value: 15, total_value: 150

layer_out_1: qty: 12 unit_value: 20 total_value: 240

I will propose the changes that fixes this use case here.

Thanks all for the work.

[AaronHForgeFlow]

I think we can merge this now, and then if any issue appears create another PR for that case.