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 <suraj.khur...@hotwax.co> 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 <scott.g...@hotwaxsystems.com> > 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 <sur...@apache.org> 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 > > > > > >
