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 >
