invalidating a purchase order doesn't remove connection to receipt

Description

having by error two purchase orders for the same real order and selected the wrong one when creating the receipt. Then the wrong purchase order was invalidated to get the correct one connected to the receipt but the receipt was connected to the invalidated order.

Environment

None

Activity

Martin Schönbeck
July 28, 2023 at 8:20 AM

hi , maybe it’s no good idea to invalidate an order which is connected to a receipt. But than invalidating must be forbidden in this situation. If it is allowed, to do it, than it must release connections to other documents at least where this connection hinders to do the correct connection.

Regards,

Martin

Norbert Bede
July 28, 2023 at 5:31 AM
(edited)

hi,

let me write down some ideas around.

Firstly: Don’t want to tell do not resolve this ticket, just want explain my experience.

This use case is technically possible, but in our practice void and reverse make documents complicated IMHO the original business case can be resolved less radical way,

We keep instead since 2005 a common rule we are still applying . Documents must be corrected in reverse order/flow as they was created. Good and simple example is we are disallow re-activate payment until allocation exists.

So in this case first matching should be - “deleted“, then you have independent PO and MR.
We have denied as default void and reverse, allowing only in specific users/roles.

in 2012 we had a project where user starts void many documents and the customer went out-of-control and project leaded to instability. (we lost the customer later, we got wrong rating from known international auditor company ) IMO this is danger functionality, make code complicated (storage, costing make uncontrollable), and these use cases are never-end.

so my question is is this right direction tune these scenarios or instead give easier workflow (check inherited document, more re-activate allowance for correction etc.) ? Say another word, instead technical solution apply knowledge based and better interaction workflow ?

Maybe i wrote this into wrong ticket, then ignore it. Don't want break this thread.

nb

Heng Sin Low
July 28, 2023 at 4:27 AM

hi ,

I re-test the use case you posted and the reversal of match PO is created as expected. I did notice that M_InOut.C_Order_ID is not reset to null and I’ve push a fix for that.

If you think that’s not sufficient and we should reverse the Material Receipt document instead of just the Match PO document, I can make that adjustment as well (I don’t have a hard requirement for this).

Regards,

Low

Heng Sin Low
July 27, 2023 at 2:27 PM

The pull request doesn’t reverse the MR, just create a reversal for the match PO.

Will re-test to confirm later but unless my memory is bad, I did the exact 4 step you posted and the match PO reversal does happens for me.

Carlos Ruiz
July 27, 2023 at 2:17 PM

Hi - I tested manually the pull request 1942 following the steps provided here by - but the issue seems not solved:

  1. Create purchase order 800003 for 35 Azalea and complete

  2. Create purchase order 800004 for 35 Azalea and complete

  3. Create Material Receipt 10000511 based on PO 800003 for 35 Azalea and complete

  4. Void PO 800003

  5. Material receipt 10000511 is still complete and the related Match PO 10000000 points to 35 Azalea on PO 800003 - which is now zero quantity

 

I tried the same test without the second step and it seems to behave different creating a reversal record for the MatchPO, but not sure if that’s the intended behavior.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

Created August 17, 2020 at 6:56 PM
Updated September 1, 2023 at 12:04 PM
Resolved July 31, 2023 at 1:20 PM