Hi Suraj, I think cancelling an order is quite a different scenario from returns. I can't think of a use case for customized behaviours depending on an order cancellation reason. So personally I think using enumerations would be sufficient.
Flexibility is good, but only if we have a good use for it. Otherwise it's just unnecessary complexity. Regards Scott On Thu, 5 Sep 2019, 20:43 Suraj Khurana, <[email protected]> wrote: > Yes, agreed. > > So what do you propose for to manage cancel reasons? A new entity or > something similar in pattern of ReturnReason. > My thought process was started with something for cancel reason, than I > looked into ReturnReason and started this discussion, actual need is we > should have something available to manage cancel reasons as well in similar > fashion we are managing return reason. > > I think we should have a similar entity in the same fashion we have > ReturnReason. It will be more scalable in future to manage behavior of > cancellation reasons as well. > > Please let me know your thoughts on this. > > -- > Best Regards, > Suraj Khurana > Technical Consultant > *HotWax Systems* > *Enterprise open source experts* > cell: 96697-50002 > http://www.hotwaxsystems.com > > > > > > > On Thu, Sep 5, 2019 at 12:40 AM Scott Gray <[email protected]> > wrote: > > > Hi Suraj, > > > > It really depends on what the data will be used for. If you simply want > to > > be able to categorize cancellations into groups for reporting then an > > Enumeration is fine for that IMO. If you want to define the behavior of > > parts of the cancellation depending on the reason selected then a new > table > > is better. > > > > Regards > > Scott > > > > On Mon, 2 Sep 2019 at 17:33, Suraj Khurana <[email protected]> > > wrote: > > > > > Thanks Scott, > > > > > > Agreed with your points, in addition to this, there can be some other > > > scenarios in e-commerce as well, let me try to put some more light on > > this, > > > like currently, we are using ReturnReason to capture customer response > > > while returning an item, someone can require one more as CancelReason > to > > > capture customer response while cancelling order. > > > There can be another XYZReason entity created for any other specific > > > requirement. > > > > > > I was thinking of some kind of generic entity to be used to fulfill the > > > purpose, so first thought was enumeration, we can have some other > entity > > to > > > use for this purpose that can serve better. > > > > > > Or we can agree that for such kind of requirement, there should be > > always a > > > new entity to be use, for example CancelReason. > > > > > > Please share your thoughts on this. > > > -- > > > Best Regards, > > > Suraj Khurana > > > Technical Consultant > > > *HotWax Systems* > > > *Enterprise open source experts* > > > cell: 96697-50002 > > > http://www.hotwaxsystems.com > > > > > > > > > > > > > > > > > > > > > On Fri, Aug 30, 2019 at 2:37 AM Scott Gray < > [email protected] > > > > > > wrote: > > > > > > > Hi Suraj, > > > > > > > > One good reason for custom enum/type tables is that it allows you to > > > > specify behaviors for the values. > > > > > > > > As a quick made-up example: > > > > I could add columns like "storeCredit", "exchange", "replace", > > > "fullRefund" > > > > to the ReturnReason table and then set those flags to Y/N depending > on > > > the > > > > return reason. Now I can easily configure that "Do not want" as a > > return > > > > reason is only eligible for store credit, while "Arrived with damage" > > > > return reason is eligible for replacement or a full refund, while > > "Wrong > > > > size" is eligible for exchange. Adding behaviors like this to > > > enums/types > > > > allows a user to introduce new records with a unique combination of > > > > behaviors without the need for code changes (assuming all of the > > desired > > > > behaviors are already supported). > > > > > > > > Although for the above example one could argue that the configuration > > > > should be made in conjunction with a ProductStore or Product rather > > than > > > > globally, in which case you could also consider adding productStoreId > > and > > > > productId to the ReturnReason table and have the returnReasonId > simply > > > > become a sequenced id rather than an enum. > > > > > > > > So even if OFBiz doesn't make use of it currently, I think there's a > > > solid > > > > use case for return reasons not simply being Enumeration records. > > > > > > > > Regards > > > > Scott > > > > > > > > > > > > On Thu, 29 Aug 2019 at 17:21, Suraj Khurana <[email protected]> > wrote: > > > > > > > > > Hello folks, > > > > > > > > > > We have an entity ReturnReason in which we have some predefined > > return > > > > > reasons and any custom projects and add more reason to it. > > > > > My question is do we really need an entity for this, it can be > easily > > > > > managed through any enumeration data as well of certain enum type. > > > > > > > > > > Are there any other cases that I am missing here for which we need > > this > > > > > specific entity? > > > > > Please share your thoughts on this. > > > > > > > > > > -- > > > > > Best Regards, > > > > > Suraj Khurana > > > > > Technical Consultant > > > > > > > > > > > > > > >
