[14.0][ADD] account_invoice_purchase_picking_selection: New module to auto-…

[carlos-lopez-tecnativa]

…complete invoice lines from picking originating from a purchase order.

TT55594

@Tecnativa @pedrobaeza @victoralmau @sergio-teruel @chienandalu could you please review this?

[giarve]

Great module. Can improve productivity on raw material reception when the vendor is billing on their own pace and not all pickings altogether. No need to re-type all line quantities by hand based on the vendor bills (manual unnecesary work).

This is welcomed as the other picking invoice module in this repo is for the Brazilian way of invoicing pickings (no connection with the purchase order), which does not make sense anywhere else (I think). Also, this does not break any existing Odoo process at all.

Also, the solution to this is good, due to the fact that there is a separate field for pickings, simplifying lots of things. Is there any reason to use context instead of a separate model, such as the "purchase.bill.union" one? Not that I am complaining, the speed impact is probably minimal.

Functional test is OK on most common cases

is there any reason why is it still draft?

[giarve]

Ok. Amending to my previous comment. After a few trials, this module is not as I would wish it would work.

It would be interesting to grab the quantities from the selected pickings, not from the POs, as otherwise it makes no sense to extend the functions as much as it is done here. Only extending search and adding columns to the autocomplete PO field would work.

However, selecting a picking has the advantage of translating to the bill the EXACT amounts from the picking, not the PO. Why? Because you want the vendor bill to match the quantities received at the vendor's bill, if they invoice by picking. This way you save time, as you can create one bill per vendor picking (just as they do in these cases) without having to review validated quantities on reception and saving huge amounts of time on big POs.

Otherwise Odoo flow is better, just select the PO and it is no different to selecting a picking.

[giarve]

Suggested change

	line_vals.update({"sequence": sequence})
	line_done_picking = line.move_ids.filtered(lambda m: m.picking_id == self.autocomplete_purchase_picking_id).mapped('product_uom_qty')
	line_vals.update({"sequence": sequence, "quantity": sum(line_done_picking)})

[giarve]

This is how I would do it. Maybe we could expose in config a parameter to select this? otherwise I would extend the module, as the rest is fine for me

[carlos-lopez-tecnativa]

@giarve Thanks for your review and comments. I have marked this PR as ready for review and adapted the code to take the quantity from stock.move. Please review it again. Thanks

[giarve]

The only issue I find is that once the picking is billed, it still appears again in the autocomplete field.

What this means is that you could be able to bill infinitely the same picking, and it would let you still fill the quantities, whereas through the PO autocomplete it does not allow you.
With the previous code you had + my suggestion I do not remember this happening but I could be wrong.

I still find nice that you created the prepare values function.

[carlos-lopez-tecnativa]

The only issue I find is that once the picking is billed, it still appears again in the autocomplete field.

What this means is that you could be able to bill infinitely the same picking, and it would let you still fill the quantities, whereas through the PO autocomplete it does not allow you. With the previous code you had + my suggestion I do not remember this happening but I could be wrong.

I still find nice that you created the prepare values function.

The picking is displayed if the purchase order is pending invoicing. When the PO is fully billed, the pickings do not appear. I fixed this because when there were no more purchases, the filter was not applied. Now, the filter is applied—please try again.

When a purchase order has more than one picking, if you invoice the first picking while the second is still pending, the first picking will still be displayed because the purchase order is still waiting to be billed. The stock.picking or stock.move does not have a field to track the invoiced quantity, and adding this field could require many recomputations. Please let me know if I must add this field to stock.move or stock.picking @pedrobaeza.

[pedrobaeza]

@carlos-lopez-tecnativa there's no need of such field. What you have to do through the inverse of account.move.line~picking_invoiced_id field (which should be a reference to the stock.move, with a possible picking related field), and with a field summing the invoiced quantity at stock.move level for showing the picking or not.

[carlos-lopez-tecnativa]

@giarve @pedrobaeza I updated the code to add new fields for traceability to track the invoiced quantity and invoiced status. This way, we can ensure that pickings are displayed correctly when still pending invoicing and do not appear when fully invoiced.

[giarve]

@giarve @pedrobaeza I updated the code to add new fields for traceability to track the invoiced quantity and invoiced status. This way, we can ensure that pickings are displayed correctly when still pending invoicing and do not appear when fully invoiced.

There are a few modules in this repo that are related to this link PO line <-> stock (move or picking?), I will assume you took a look at them before.

Nonetheless, I think extra fields are not needed to check whether the PO line is fully billed or not. It is true traceability is lost without those fields, but also they are not required for this check to be done, it's like extra new functionality. Whether it goes together in this module, I do not care, but they are different functional objectives.

If they can be a good fit in this module for anybody else (they come as a pack when you install it), I will approve. Some people might dislike, as it is not related to the autocompletion of the picking lines quantities.

[pedrobaeza]

@giarve how do you propose to discard "already invoiced" pickings in an efficient way without that tracking fields?

[giarve]

@giarve how do you propose to discard "already invoiced" pickings in an efficient way without that tracking fields?
Sorry, the solution is good, and it does not need any additional deps + it is compatible with other modules.

I had a half-baked idea in my mind of using the PO already billed lines quantities to filter out pickings related to these quantities. but i was wrong.

Additionally, I thought that already another module in this repo was adding these fields, and they were not needed to add to the model in this module, but doing it like with the same name still makes it compatible with the rest without creating a dependency, so it is totally fine.

Using a stored field is not only the most efficient (even though I would not care about performance in this auto complete) but also the only possible, otherwise invoiced quantities could refer to multiple stock moves and not match 1:1.

Sorry. I approve.