We find actually quite frequently that there are additional and/or replacement products shipped.
Sometimes the quantities are simply adjusted… Blame good reactivity on the part of suppliers;-)
If we select the originally intended article for in a shipment reception, and rectify the product/quantity/price,
it appears that we have to manually select the invoice [line] generated and correct it there too!
(actually, the quantity seems to be the only thing corrected)
Perhaps this has something to do with the origin? Can’t seem to select the replacement product now in the moves of the reception tab…?
Anybody else have these issues and I wonder what would be the best approach to entering these?
That is, on one hand, it would be nice to be able to statically amend purchase orders, on the other, given some of the capabilities of using move and/or reception operations it would be nicer to be able to more fully manage the purchase order data over its real lifetime… including origin/invoice [lines] generation.
Trying 8366 on 5.2… in tests/scenario_purchase_history.rst it seems that one should be able to reset the purchase order back to ‘draft’ with a button, but the only button presented is ‘process’… something missing in the gui?
seems like the state ‘processing’ cannot go back to ‘draft’ according to the state transition tables and cls._buttons.update() … update to this omitted?
Once processed you can not go back to draft state. Only a quotation or confirmed purchase (or sale) order can go to draft state.
But take care with confirming becaues if you do no have setup a pool of workers and a processing delay, the purchase/sale order will be processed when confirmed.
This is indeed the case. Actually, it is not ‘processed’ but ‘in process’…
The processing has not, and can not, yet be completed.
It’s a real-world situation… even in processing state, orders should be amendable.
Once revision history is maintained, why limit artificially its use?
Sorry Sergi, you lose me. As indicated above, I’ve applied and am testing with the patch in Add history and revision (#8366) · Issues · Tryton / Tryton · GitLab, hence my observations.
Perhaps its an omission this detail fixing the state transition table… I hope so, we need it asap!