Yes its not a problem to reopen them. There are no closing transaction or such created, so it wont mess up your system. Test it though in case your db has some customizations that assume the POs wont reopen.
I ask you if it is possible to reopen a purchase order closed by mistake of user.
Anyway, just rename the production order in question. Unless in the future you need a way to do this more often.
But as David said, first do it in a Testdb, and that is: no posting, release and then finish a production order. Then release it again and finish it again. See if it made any changes in the db (posting and other lines) and then rename your production order (in case it didn't generate new content).
This because
A: if there are modification that posts lines in the finishing of a production, then reopening is a bad idea.
B: see A
|Pressing F1 is so much faster than opening your browser| |To-Increase|
I don't understand too much what you advice.
I try to write what you mean:
1) create a new db from actual backup for test
Following operations in test db:
2) rename (from table??) closed Prod. Ord. number X to Y where Y is a new free number. Prod Ord. X will not exist anymore.
....??
3) make necessaries operations and test on Prod. Ord. Y
4) if all is ok rename ok from Y to X (original number)?
If all is ok make all same step in real / productive database?
the key in the production order consists of 2 fields: namely status and number
which means you made 2 actions out of one (rename)
1) create a new db from actual backup for test
Following operations in test db:
2) rename (from table Production order) closed Prod. Ord. status finished to released where X stays the same number.
Prod Ord. finished X will not exist anymore.
3) Rename the production order back to finished X trough the original method of using the statuschange form including all the code that might (i hope not) create posts. and check if something like that happened.
4) if all is ok, it can be done in the live
|Pressing F1 is so much faster than opening your browser| |To-Increase|
Ok, now it is more clear but between point 2 and 3 users and our interface developed from scratch should make the operations for examples consumption, output, capacity before to close again the order with standard step.
yes, your gui developped from scratch instead of the form closing.
But what is really important is to determine if any posts have been made already for that specific production in the live and see if the change status to finished has to do anything with it.
In a standard NAV the rename is no problem, but modifications in manufacturing might change this behaviour, so unless you know it doesn't do anything, testing is recommended.
|Pressing F1 is so much faster than opening your browser| |To-Increase|
The system (form) is following business rules.
Because one of the users has made an infraction towards this rule, you are facing this problem because the system is not made to rectify infractions on business rules (if the production order is finished, it's finished and nothing may alter it)
That's why we let the user know that they are still responsible for their actions, it will allow infractions to business rules because the system is not allknowing.
(Sometimes the user expects that the system knows that an order has not been shipped and should stop the users when they try to ship the order) (same case here)
and that's why the system won't allow to revert to a previous stage if it's in the finished stage (business rules).
Also this doesn't explain why you can revert it !!without much risk!! (there is always a risk), but standard nav does not make a whole lot of changes when changing the status on the purchase order.(only thing I found was costing) (speaking of standard NAV, your customizations should be known to you)
|Pressing F1 is so much faster than opening your browser| |To-Increase|
Comments
Thank you
Sorry I assmed that you knew the code to write, and wer asking if it would cause any problems in the system if you "Un Finish" them
Anyway, just rename the production order in question. Unless in the future you need a way to do this more often.
But as David said, first do it in a Testdb, and that is: no posting, release and then finish a production order. Then release it again and finish it again. See if it made any changes in the db (posting and other lines) and then rename your production order (in case it didn't generate new content).
This because
A: if there are modification that posts lines in the finishing of a production, then reopening is a bad idea.
B: see A
|To-Increase|
I corrected now my first post (it was a mistake).
I don't understand too much what you advice.
I try to write what you mean:
1) create a new db from actual backup for test
Following operations in test db:
2) rename (from table??) closed Prod. Ord. number X to Y where Y is a new free number. Prod Ord. X will not exist anymore.
....??
3) make necessaries operations and test on Prod. Ord. Y
4) if all is ok rename ok from Y to X (original number)?
If all is ok make all same step in real / productive database?
Thank you
which means you made 2 actions out of one (rename)
1) create a new db from actual backup for test
Following operations in test db:
2) rename (from table Production order) closed Prod. Ord. status finished to released where X stays the same number.
Prod Ord. finished X will not exist anymore.
3) Rename the production order back to finished X trough the original method of using the statuschange form including all the code that might (i hope not) create posts. and check if something like that happened.
4) if all is ok, it can be done in the live
|To-Increase|
But what is really important is to determine if any posts have been made already for that specific production in the live and see if the change status to finished has to do anything with it.
In a standard NAV the rename is no problem, but modifications in manufacturing might change this behaviour, so unless you know it doesn't do anything, testing is recommended.
|To-Increase|
Do you want to change the production order status from Finished to Released ?
If yes , check this link
viewtopic.php?f=23&t=21568&hilit=change+status+of+finished+production+order&start=15
The system (form) does not allow that...
Because one of the users has made an infraction towards this rule, you are facing this problem because the system is not made to rectify infractions on business rules (if the production order is finished, it's finished and nothing may alter it)
That's why we let the user know that they are still responsible for their actions, it will allow infractions to business rules because the system is not allknowing.
(Sometimes the user expects that the system knows that an order has not been shipped and should stop the users when they try to ship the order) (same case here)
and that's why the system won't allow to revert to a previous stage if it's in the finished stage (business rules).
Also this doesn't explain why you can revert it !!without much risk!! (there is always a risk), but standard nav does not make a whole lot of changes when changing the status on the purchase order.(only thing I found was costing) (speaking of standard NAV, your customizations should be known to you)
|To-Increase|