ReturnReason: Is this really required?

[surajk]

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

[Jacques Le Roux]

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 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
>

[Scott Gray-3]

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 <[hidden email]> 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
>

[Shi Jinghai-3]

Scott is quite right.

From my view, the column missing in ReturnReason is implied by the reason labels. A scenario is in inventory tally, when a reason selected in tally operation to an inventory item, we can validate new quantity and reason, for example, if reasonId is STOLEN, then we know the item quantity should be decreased.

Kind Regards,

Shi Jinghai


-----邮件原件-----
发件人: Scott Gray [mailto:[hidden email]]
发送时间: 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 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 <[hidden email]> 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
>

[Suraj Khurana-2]

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 <[hidden email]>
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 <[hidden email]> 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
> >
>

[Scott Gray-3]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
> > >
> >
>

[Suraj Khurana-2]

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 <[hidden email]>
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 <[hidden email]>
> 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 <[hidden email]
> >
> > 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 <[hidden email]> 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
> > > >
> > >
> >
>

[Scott Gray-3]

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, <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <
> [hidden email]
> > >
> > > 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 <[hidden email]>
> 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
> > > > >
> > > >
> > >
> >
>