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
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
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
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
the item quantity should be
decreased.
Kind Regards,
Shi Jinghai
-邮件原件-
发件人: Scott Gray [mailto:scott.g...@hotwaxsystems.com]
发送时间: 2019年8月30日 5:07
收件人: Dev list
主题: Re: ReturnReason: Is this really required?
Hi Suraj,
One good reason for custom enum/type tables is that it allows you
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
Hi Suraj,
I don't remember why it's an entity. It's a pre Apache thing. Maybe because
it's then easier to create customised reasons?
Jacques
Le 29/08/2019 à 07:21, Suraj Khurana a écrit :
Hello folks,
We have an entity ReturnReason in which we have some predefined return
reasons and any
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
