Purchasing and warehouses

We have lots of purchases, and of all kinds.
There seems to be one key use-case that breaks with Tryton, notably the following

On big projects, during the RFP we will already have solicited major suppliers for project prices on selected materiel. Very frequently the purchase will be confirmed, but the delivery date and destination (e.g. directly to a particular worksite, or another, or to a company warehouse)

Currently it seems that the destination warehouse is locked at purchase confirmation.
Rather, there should be a means to override it on a product line basis as can be done for delivery date where both should be updateable even after confirmation (up until shipment reception).

No one else has come across this problem?

Yes, we’ve seen this before. In those cases customer left the purchase in confirmed state for as much time as possible to avoid problems. Customer could still move back to draft state to make the desired changes.

But that is far from ideal and I agree with you that it should be possible (and easy to change the warehouse).

I do not think we should allow to change the warehouse of the purchase once confirmed because you can still change the destination on the waiting moves.

The design of the module allows to easily implement a custom destination location per line. But I do not think it should be the purchase module (maybe a new module but it looks overkill to support a module so few code).

Here also the delivery date can be updated on the waiting move.

We’ve been trying out modifying the moves for a while now but unfortunately it has considerable drawbacks … notably in that the moves see only the product_template name and variant code but not the suppliers name nor their product name/code - making it at times difficult to find the PO and products involved.

Also there is another use case where this comes up, namely when we will pick the products up ourselves at the suppliers warehouse (typically because of urgent need)… these are invariably with multiple destinations (worksites or warehouse stock).

So, if we are not the only company in the world to issue purchase orders where the location can change then perhaps it should be reconsidered to be able to update the delivery date and/or location on a product line basis… both even after confirmation (because they can change prior to physical reception).

cheers,

When you have a change on the stock move of a purchase, the entry point should be the purchase. From there, I do not think it is complicated to find the right move.
But the search from the stock moves list could be improved, I filled:

For me, this workflow is supported. You can edit the stock move line directly, change the destination location and click on do button.

clicking ‘do’ completes the move making it impossible to include it on the suppliers BL skipping the invoice generation part… this certainly cannot be used as such?

(BTW, I forgot to add the ‘supplier’ indication to the difficult list in the stock move filter, not only the suppliers article name/code)

Since things are purchase order centric, I still believe that’s where the logical place to start is (perhaps ‘stock moves’ needs to be added to ‘relate’ to simplify that).

This is false, the purchase will generate the invoice line if the invoice method is based on shipment.

I tried it prior to replying… no invoice created?
I believe an invoice line is perhaps created but only if purchase_line_invoice_standalone is activated which we find unuseful (at least in our case).
Invoices are based upon suppliers delivery notes (BL), and possibly one or more of them (which is why we needed to create a merge invoice module.

Well you have to process the purchase if you manually do move. But this could probably be improved.

certainly! but it’s a good start.

So if you have delivery notes, you can not use direct move. You must always fill a incoming shipment.

Naturally, there are always delivery notes… That is why ‘do’ on the stock move is dangerous.
There should probably be a means to disable such for non-administrative users.