Picking generation using barcode scanning

[AdriaGForgeFlow]

With the current stock barcodes module we are able to manage a certain part of the picking workflow. When the picking is already created we can go to the scanning wizard and start scanning the products that are present in the stock moves increasing the quantity done of the move itself. We can also validate pickings from the scanning wizard.

We have recently encountered with the need of the other part (picking generation using barcode scanning). It would be nice to be able to create the stock moves using the barcode scanner. In this way, a user would create an immediate or a planned transfer and start scanning right away. If the stock move with the scanned product is not already created, we generate a new stock move, otherwise we just add a quantity to the specific picking line.

What do you think would be the best approach to do this? @sergio-teruel @pedrobaeza

cc ~ @jbeficent @joansis @nuriamartinxifre

[pedrobaeza]

For me, there shouldn't be an automatic picking generation, but automatic lines generation. AFAIK, this is already happening for stock.move.line, but not sure about non existing stock.move.

[AdriaGForgeFlow]

For me, there shouldn't be an automatic picking generation, but automatic lines generation. AFAIK, this is already happening for stock.move.line, but not sure about non existing stock.move.

Yes I didn't mean automatic generation for the pickings. The user manually creates the picking and then using the barcode scanner it introduces the products that are supposed to be in the picking generating the corresponding stock moves automatically.

[pedrobaeza]

An extra switch for allowing that should be added. Something like "Free insert", that performs that operation independently from the existing stock.move (but only if not found).

[eLBati]

Adding this functionality to 12.0 with https://github.com/OCA/stock-logistics-barcode/pull/288

[pedroslopez]

For me, there shouldn't be an automatic picking generation

@pedrobaeza Why is this not desired? It seem to me that Odoo's stock_barcode app available in enterprise allows this. You can scan a picking type, then scan all products, scan a location if wanted and validate all by using barcodes.

A client is wanting this flow, I'm curious as to why there shouldn't be auto picking generation and if there are maybe consequences I'm not seeing with this.

[pedrobaeza]

Pickings are generated from their sources (sales, purchases, etc), so there's no point on creating dangling pickings and will create a quick way for doing that instead of looking the proper one.

[pedroslopez]

Pickings are generated from their sources (sales, purchases, etc), so there's no point on creating dangling pickings and will create a quick way for doing that instead of looking the proper one.

Ah, I understand. In our case they wanted to start out using Odoo exclusively for inventory management so sales/purchase orders weren't being created

[pedrobaeza]

That's a mistake IMO, but everyone is free to do what he/she wants.

[eLBati]

There are plenty of use cases where pickings are generated manually, without a source document, especially in complex warehouses. Just think of internal transfers. Also, as in @pedroslopez 's case, Odoo can be used just for inventory management.

[pedrobaeza]

Even in that cases, @eLBati, a base picking should be created IMO with basic information, like source and destination location, and then start scanning. What I don't see is to have Odoo ERP "only for inventory management", but that's my point of view. Anyway, as said, I think the flow should be that one: create the internal picking and then start scanning. If you don't agree, you can expand the module with what you want. That's the good thing of open source and why I haven't closed the issue.

[eLBati]

create the internal picking and then start scanning

Ok, I agree

[github-actions[bot]]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.