Community mailing list archives
Re: Cancel done delivery orderby
RU3IX Pty Ltd
On 10 Mar 2015, at 5:08 pm, Eva Pinter <firstname.lastname@example.org> wrote:
Hello Naran,The whole point about an ERP is also to keep track of what is happening. Just deleting documents because someone makes a mistake is not best practice. After that, the documents are just gone and nobody knows why. The effort to find such problems are so much higher than the ease to press three times a button. Not everything that is possible by programming should be done, even when the customer asks for it. For many customers, they consider the ERP as a better excel and the same way they would delete something in Excel, they want to delete it in the ERP.It should not be the case.To delete documents in an ERP should be a very controlled process, so that the system can still be audited. It is mostly enough to cancel the document and leave it in the system.Good luckOn 10 Mar 2015, at 05:47, Naran M <email@example.com> wrote:I agree to Kyle in a way I haven’t come across from any of our customers where they haven’t asked about it. It would be nice to have easier (smarter) option to delete the delivery order and edit the sales order if required, this operation is not meant for every user to perform and also every time, but when they need, it should allow them to do in a easier way leaving the complexity to system to handle in a smarter way. Generic scenarios would be 1) The warehouse operator has done a mistake and need to correct the delivery order 2) Customers has requested to add/delete products or quantities before they been shipped.Cheers,Narannmoturi@ru3ix.com.au
RU3IX Pty Ltd
http://www.ru3ix.com.auThis e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. RU3IX Pty Ltd is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.On 10 Mar 2015, at 4:08 pm, Eva Pinter <firstname.lastname@example.org> wrote:
Hello OpenERP Master,The fact that the customer requires a functionality does not make it a good practice.To have to recreate multiple times the delivery means that the company processes are somehow not correct, from a pure functional point of view. So, the best would be to not create the delivery order automatically instead of deleting delivery orders created. In other systems, like SAP, the creation of deliveries is done manually and there is no deleting of deliveries, that brings as specified by Nhomar a lot of inconsistency.So, my advice is: try to change the workflow to have the delivery order created separately by the user on selected sales order.Good LuckOn 10 Mar 2015, at 04:51, OpenERP Master <email@example.com> wrote:Every single client I have ever worked with demands this functionality.There is a legitimate business case for the ability to delete a delivery order and recreate it. By not allowing it, it causes severe workflow problems with business users. One could easily say that they are stupid and should do a better job of checking, but in my experience this happens all of the time. Another case would be an order going all the way through to shipment and then the customer has changed their mind. Some businesses care enough to accept the customers request and make these changes. By not allowing the cancellation/deleting it forces a nasty workflow and creation of unnecessary documents.Of course you shouldn't let the users have a free for all, this should be very controlled, and also you should not allow any edit/delete from a closed period, or if there is some other dependency that cannot be reversed.Hello,Thanks for your input. Unfortunately, this does happen and also unfortunately other enterprise software supports this easily and it comes out of box. To give you an example, in Netsuite ERP when you confirm shipment the sale transforms into whats called an item fulfillment. You can at any time go to the fulfillment and click delete. There is no trouble. You can easily go back to the sales order and click fulfill as many times as you want and the software handles it beautifully. You can even cancel and delete an invoice or both fulfillment and invoice. This creates a very workable workflow from a business process standpoint.On Mon, Mar 9, 2015 at 11:42 PM, Nhomar Hernández <firstname.lastname@example.org> wrote:2015-03-09 20:47 GMT-06:00 OpenERP Master <email@example.com>:I assume some would like appreciate this workflow, however this is pretty standard stuff and is one of the most common things I get asked by almost every client.Be careful, It is pretty "standard" for people who does not care about consistency of the data and _only_ works if the product has not incoming after the move is confirmed.Some time ago I did a development for that based on a work done by camp2camp for V7.I decided not share publically such workflow because it encourage a very bad practice, Confirm a Picking must not have a cancelling process because consistency and security reasons.Bad things happen when you do not understand that.BTW as I said before there is only 1 case where my statement is false "You just confirm and any product of the picking has any future movement/compromise" but even if you confirm now and cancel day after procurement rules were triggered and you will fase a false planning on the product.Be careful, If ypou need the development we migrated (based on *_cancel modules done by camp2camp) I can share the link, they are pretty straight forward on v7 and fairly simple, but not absolutly complete, we never finished to be deliverable without take care about functional danger (I think it is the same reason c2c never finished because it is NOT an standard, it is an "exceptional" feature, I recommend as much as you can use teh return process you just mentioned.Regards.