Community mailing list archives
Re: Cancel done delivery orderby
2015-03-19 11:02 GMT-06:00 Joël Grand-Guillaume <firstname.lastname@example.org>:
Have you any preferred solution between 1) and 2) ? Or you wouldn't use any of them ? Why ?
I always let user make the choice and invest a lot of effor (a lot is between 1 or 5 meetings is enought frequently depending of the profile of the user) to make the decistion.
Basically, there are cases where simply it is a little customer and you do not need the traceability but this is a subjective point, which must be decided in the moment itself, or may be it was an human error and simply the user wants to make a cancellation to fix and start again (both cancelled and redone picking will be linked and it is some times enought traceability for such cases).
We strongly beleive that the point of a good system is trainning, coaching, mentoring and if I forget tell it trainning again, and as exactly how you mentioned so many options to make mistakes, but experiences with big customers is that as far as you automate more they simply try to "think" less and always problems are "Because the system-----".
Then I understand we need some improvements in terms of process in some places, but I think it is more dangerous a "bad automated process" than a "boring solid process".
I have many examples in different areas, but IMHO, the user must understand all impacts of every single click he/she does in the system, then automate something must be helped by good manual, good document, easy interface and so on, and we as programmers/consultants must be able to always offer a way to "track things.".
That's why IMHO in the case of this thread (which has become more and more interesting) "Cancel a done picking + a sale order" MUST be done with the reverse process, and IMHO document by document.
Make a "magical button" that cancel everything will bring problems hidden that "When the customer realize they happen" WILL be under the responsability of the programmer/consultant it means "The system".
But now, as you mentioned also, IF in some specific return process we face errors/inconsistencies/leak of features, that subprocess must be fixed.
When you make strong documentation and teach a defined process (let say the 3 simpliest steps, cancel revert and re-invoice) then the customer (user) will be in touch over all what happen and will be abel to take the decistions by itself (because the mixture of cases is huge).
I remember when I return elements to stores like home depot and sears and others.
The return process take like 3 hours to be done and frequntly even days if things are older, "why?" because it IS a comple process.
Again I can give other examples, but in the way you automate more and more process jumping out more and more steps decistions as being taken by consultants/bosses over theoretical situations that frequently (frequently not always) do not fit with the reality, and Kabum! a time bomb in the system.
I remember we solved partially the issue of fix "post mortem" with a double validation on sale orders (alá double validation in purchases) where we asked to the customer 24 hours after the order "Are your REALLY sure this process can not be undone and you have a compromise with us." just until the answer was YES we started the logistic process (we have this module in addons-vauxoo I think).
Well I hope it helps. :-)
my 2 cents.