[Proposal] Ability to Record Return Communication

[Ratnesh Upadhyay-2]

Hi Devs,

In OOTB we are having the ability to record order specific communication in
*CommunicationEventOrder* and the user can retrieve/review them from party
> communications screen but we don't have such support for return
communications. So It would be great to have an ability to record return
specific communication in the system.

We have to implement following items to establish this feature :

*Data Model Details:*
- We will have to create new entity *CommunicationEventReturn* to record
return communication. It should have returnId and communicationEventId
along with other necessary fields.
- We have to implement following view *CommunicationEventAndReturn* to
fetch return communications over screens as needed.

*New Implementation Details:*
- We have to add *CRUD* services for the new entity.

*Existing Implementation Details:*
- We have to extend *createCommunicationEvent* service definition with
retunId field and extend the existing implementation to create the record
in *CommunicationEventReturn* based on supplied returnId parameter.
- Also, we have to extend return related email services to provide returnId
in service context.

*User Interface Details:*
- In the current system we have Party > Communications > Find Communication
By Order screen, in the same way, we can add another screen to find
communication by return.
- We can add return communication screenlet over Order Manager > Return >
Return History screen or we can add communication tab under Order > Return
screen, this is just a thought still thinking on it.
- We can also provide communication tab in order component as well.

Please have a look at details and let me know your inputs. I'll log Jira
ticket to implement this feature soon.

Thanks!!

Regards,
Ratnesh Upadhyay
HotWax Systems | www.hotwaxsystems.com

[Deepak Dixit-3]

Hi Ratnesh,

I like you idea, but instead of adding new entity can we define some
generic way to use CommunicationEvent along with all kind of activity.
Like  CommunicationEvent is generic DataModel, it applicable for invoice,
workEffort, marketing campaign, contact list, order , return, etc.

As per current implementation some values are exists in CommunicationEvent
entity and some are in assoc pattern.

So creating new entity for each model will be too much.  Any other opinion?


Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Sat, Sep 23, 2017 at 3:44 PM, Ratnesh Upadhyay <
[hidden email]> wrote:

> Hi Devs,
>
> In OOTB we are having the ability to record order specific communication in
> *CommunicationEventOrder* and the user can retrieve/review them from party
> > communications screen but we don't have such support for return
> communications. So It would be great to have an ability to record return
> specific communication in the system.
>
> We have to implement following items to establish this feature :
>
> *Data Model Details:*
> - We will have to create new entity *CommunicationEventReturn* to record
> return communication. It should have returnId and communicationEventId
> along with other necessary fields.
> - We have to implement following view *CommunicationEventAndReturn* to
> fetch return communications over screens as needed.
>
> *New Implementation Details:*
> - We have to add *CRUD* services for the new entity.
>
> *Existing Implementation Details:*
> - We have to extend *createCommunicationEvent* service definition with
> retunId field and extend the existing implementation to create the record
> in *CommunicationEventReturn* based on supplied returnId parameter.
> - Also, we have to extend return related email services to provide returnId
> in service context.
>
> *User Interface Details:*
> - In the current system we have Party > Communications > Find Communication
> By Order screen, in the same way, we can add another screen to find
> communication by return.
> - We can add return communication screenlet over Order Manager > Return >
> Return History screen or we can add communication tab under Order > Return
> screen, this is just a thought still thinking on it.
> - We can also provide communication tab in order component as well.
>
> Please have a look at details and let me know your inputs. I'll log Jira
> ticket to implement this feature soon.
>
> Thanks!!
>
> Regards,
> Ratnesh Upadhyay
> HotWax Systems | www.hotwaxsystems.com
>

[Rishi Solanki]

+1 for the proposal, I'll be happy to discuss and finalizing the things.

Assuming that you have already consider ProductStoreEmailSetting and
EmailTemplateSetting for sending the different notification for return.

Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com
www.hotwax.co

On Sat, Sep 23, 2017 at 3:44 PM, Ratnesh Upadhyay <
[hidden email]> wrote:

> Hi Devs,
>
> In OOTB we are having the ability to record order specific communication in
> *CommunicationEventOrder* and the user can retrieve/review them from party
> > communications screen but we don't have such support for return
> communications. So It would be great to have an ability to record return
> specific communication in the system.
>
> We have to implement following items to establish this feature :
>
> *Data Model Details:*
> - We will have to create new entity *CommunicationEventReturn* to record
> return communication. It should have returnId and communicationEventId
> along with other necessary fields.
> - We have to implement following view *CommunicationEventAndReturn* to
> fetch return communications over screens as needed.
>
> *New Implementation Details:*
> - We have to add *CRUD* services for the new entity.
>
> *Existing Implementation Details:*
> - We have to extend *createCommunicationEvent* service definition with
> retunId field and extend the existing implementation to create the record
> in *CommunicationEventReturn* based on supplied returnId parameter.
> - Also, we have to extend return related email services to provide returnId
> in service context.
>
> *User Interface Details:*
> - In the current system we have Party > Communications > Find Communication
> By Order screen, in the same way, we can add another screen to find
> communication by return.
> - We can add return communication screenlet over Order Manager > Return >
> Return History screen or we can add communication tab under Order > Return
> screen, this is just a thought still thinking on it.
> - We can also provide communication tab in order component as well.
>
> Please have a look at details and let me know your inputs. I'll log Jira
> ticket to implement this feature soon.
>
> Thanks!!
>
> Regards,
> Ratnesh Upadhyay
> HotWax Systems | www.hotwaxsystems.com
>

[Ratnesh Upadhyay-2]

Thanks for your inputs Deepak.

Agreed that CommunicationEvent is way generic and this is the main use case
to keep the order and return separately from this model as they are using
most frequently in each business.
Imagine if we use the generic data model to record each kind of
communication and when the system tries to pull a specific email or
specific type email communication from this model then system has to browse
a lot of data and due to this most of the time, it gets ended up with slow
query/browsing issue. So to avoid such performance issue instead of
extending CommunicationEvent entity, I proposed to make a separate entity.

Definitely, we can think more on it to find the more generic way to record
this information in the system.

Regards,
Ratnesh Upadhyay
HotWax Systems | www.hotwaxsystems.com

On Sat, Sep 23, 2017 at 4:05 PM, Deepak Dixit <deepak.dixit@hotwaxsystems.
com> wrote:

> Hi Ratnesh,
>
> I like you idea, but instead of adding new entity can we define some
> generic way to use CommunicationEvent along with all kind of activity.
> Like  CommunicationEvent is generic DataModel, it applicable for invoice,
> workEffort, marketing campaign, contact list, order , return, etc.
>
> As per current implementation some values are exists in CommunicationEvent
> entity and some are in assoc pattern.
>
> So creating new entity for each model will be too much.  Any other opinion?
>
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
> www.hotwax.co
>
> On Sat, Sep 23, 2017 at 3:44 PM, Ratnesh Upadhyay <
> [hidden email]> wrote:
>
> > Hi Devs,
> >
> > In OOTB we are having the ability to record order specific communication
> in
> > *CommunicationEventOrder* and the user can retrieve/review them from
> party
> > > communications screen but we don't have such support for return
> > communications. So It would be great to have an ability to record return
> > specific communication in the system.
> >
> > We have to implement following items to establish this feature :
> >
> > *Data Model Details:*
> > - We will have to create new entity *CommunicationEventReturn* to record
> > return communication. It should have returnId and communicationEventId
> > along with other necessary fields.
> > - We have to implement following view *CommunicationEventAndReturn* to
> > fetch return communications over screens as needed.
> >
> > *New Implementation Details:*
> > - We have to add *CRUD* services for the new entity.
> >
> > *Existing Implementation Details:*
> > - We have to extend *createCommunicationEvent* service definition with
> > retunId field and extend the existing implementation to create the record
> > in *CommunicationEventReturn* based on supplied returnId parameter.
> > - Also, we have to extend return related email services to provide
> returnId
> > in service context.
> >
> > *User Interface Details:*
> > - In the current system we have Party > Communications > Find
> Communication
> > By Order screen, in the same way, we can add another screen to find
> > communication by return.
> > - We can add return communication screenlet over Order Manager > Return >
> > Return History screen or we can add communication tab under Order >
> Return
> > screen, this is just a thought still thinking on it.
> > - We can also provide communication tab in order component as well.
> >
> > Please have a look at details and let me know your inputs. I'll log Jira
> > ticket to implement this feature soon.
> >
> > Thanks!!
> >
> > Regards,
> > Ratnesh Upadhyay
> > HotWax Systems | www.hotwaxsystems.com
> >
>

[Ratnesh Upadhyay-2]

Your assumption is correct, Rishi thanks for the inputs.

Regards,
Ratnesh Upadhyay
HotWax Systems | www.hotwaxsystems.com

On Sat, Sep 23, 2017 at 4:05 PM, Rishi Solanki <[hidden email]>
wrote:

> +1 for the proposal, I'll be happy to discuss and finalizing the things.
>
> Assuming that you have already consider ProductStoreEmailSetting and
> EmailTemplateSetting for sending the different notification for return.
>
> Rishi Solanki
> Sr Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
> www.hotwax.co
>
> On Sat, Sep 23, 2017 at 3:44 PM, Ratnesh Upadhyay <
> [hidden email]> wrote:
>
> > Hi Devs,
> >
> > In OOTB we are having the ability to record order specific communication
> in
> > *CommunicationEventOrder* and the user can retrieve/review them from
> party
> > > communications screen but we don't have such support for return
> > communications. So It would be great to have an ability to record return
> > specific communication in the system.
> >
> > We have to implement following items to establish this feature :
> >
> > *Data Model Details:*
> > - We will have to create new entity *CommunicationEventReturn* to record
> > return communication. It should have returnId and communicationEventId
> > along with other necessary fields.
> > - We have to implement following view *CommunicationEventAndReturn* to
> > fetch return communications over screens as needed.
> >
> > *New Implementation Details:*
> > - We have to add *CRUD* services for the new entity.
> >
> > *Existing Implementation Details:*
> > - We have to extend *createCommunicationEvent* service definition with
> > retunId field and extend the existing implementation to create the record
> > in *CommunicationEventReturn* based on supplied returnId parameter.
> > - Also, we have to extend return related email services to provide
> returnId
> > in service context.
> >
> > *User Interface Details:*
> > - In the current system we have Party > Communications > Find
> Communication
> > By Order screen, in the same way, we can add another screen to find
> > communication by return.
> > - We can add return communication screenlet over Order Manager > Return >
> > Return History screen or we can add communication tab under Order >
> Return
> > screen, this is just a thought still thinking on it.
> > - We can also provide communication tab in order component as well.
> >
> > Please have a look at details and let me know your inputs. I'll log Jira
> > ticket to implement this feature soon.
> >
> > Thanks!!
> >
> > Regards,
> > Ratnesh Upadhyay
> > HotWax Systems | www.hotwaxsystems.com
> >
>

[Jacques Le Roux]

Le 23/09/2017 à 13:14, Ratnesh Upadhyay a écrit :
> Imagine if we use the generic data model to record each kind of
> communication and when the system tries to pull a specific email or
> specific type email communication from this model then system has to browse
> a lot of data and due to this most of the time, it gets ended up with slow
> query/browsing issue. So to avoid such performance issue instead of
> extending CommunicationEvent entity, I proposed to make a separate entity.
Hi Ratnesh,

Are you sure about that? What would the bottleneck? If you think the DB would slow down I don't think it's an issue.

My take is that I prefer a generic data model rather than sacrificing for hypothetical performance and end up with data model like competitors with
thousands of entities (OFBiz is currently still around 800+)

Jacques

[Ratnesh Upadhyay-2]

Hi Jacques,

Thanks for the response. I was thinking that retrieval gets slow down when
we have a lot of data in communication event entity. Actually, I've
prepared this proposal based on the current implementation of
CommunicationEventOrder on this assumption that it's an approved feature
that's its there in the system.

I am also in agreement with you and Deepak to use the existing (generic)
data model to achieve this. I'll give it another thought and further
analyze it to fit in existing data model.

Thanks!!

Regards,
Ratnesh Upadhyay
HotWax Systems | www.hotwaxsystems.com

On Sat, Sep 23, 2017 at 5:37 PM, Jacques Le Roux <
[hidden email]> wrote:

> Le 23/09/2017 à 13:14, Ratnesh Upadhyay a écrit :
>
>> Imagine if we use the generic data model to record each kind of
>> communication and when the system tries to pull a specific email or
>> specific type email communication from this model then system has to
>> browse
>> a lot of data and due to this most of the time, it gets ended up with slow
>> query/browsing issue. So to avoid such performance issue instead of
>> extending CommunicationEvent entity, I proposed to make a separate entity.
>>
> Hi Ratnesh,
>
> Are you sure about that? What would the bottleneck? If you think the DB
> would slow down I don't think it's an issue.
>
> My take is that I prefer a generic data model rather than sacrificing for
> hypothetical performance and end up with data model like competitors with
> thousands of entities (OFBiz is currently still around 800+)
>
> Jacques
>

[Jacques Le Roux]

Le 23/09/2017 à 16:29, Ratnesh Upadhyay a écrit :
> Hi Jacques,
>
> Thanks for the response. I was thinking that retrieval gets slow down when
> we have a lot of data in communication event entity. Actually, I've
> prepared this proposal based on the current implementation of
> CommunicationEventOrder on this assumption that it's an approved feature
> that's its there in the system.
Thanks Ratnesh, I see your point now

> I am also in agreement with you and Deepak to use the existing (generic)
> data model to achieve this. I'll give it another thought and further
> analyze it to fit in existing data model.
I finally think we can go with your proposition, following the same way than CommunicationEventOrder, if it eases the introduction of the feature

Jacques

>
> Thanks!!
>
> Regards,
> Ratnesh Upadhyay
> HotWax Systems | www.hotwaxsystems.com
>
> On Sat, Sep 23, 2017 at 5:37 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Le 23/09/2017 à 13:14, Ratnesh Upadhyay a écrit :
>>
>>> Imagine if we use the generic data model to record each kind of
>>> communication and when the system tries to pull a specific email or
>>> specific type email communication from this model then system has to
>>> browse
>>> a lot of data and due to this most of the time, it gets ended up with slow
>>> query/browsing issue. So to avoid such performance issue instead of
>>> extending CommunicationEvent entity, I proposed to make a separate entity.
>>>
>> Hi Ratnesh,
>>
>> Are you sure about that? What would the bottleneck? If you think the DB
>> would slow down I don't think it's an issue.
>>
>> My take is that I prefer a generic data model rather than sacrificing for
>> hypothetical performance and end up with data model like competitors with
>> thousands of entities (OFBiz is currently still around 800+)
>>
>> Jacques
>>

[Rishi Solanki]

+1 for both the points, first introduce the feature with design proposal
shared by Ratnesh. And in a separate discussion/effort we can discuss and
finalize the generic data model approach. Even this thread is also good
start for discussing the generic data model proposal.




Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com
www.hotwax.co

On Sun, Sep 24, 2017 at 2:05 AM, Jacques Le Roux <
[hidden email]> wrote:

> Le 23/09/2017 à 16:29, Ratnesh Upadhyay a écrit :
>
>> Hi Jacques,
>>
>> Thanks for the response. I was thinking that retrieval gets slow down when
>> we have a lot of data in communication event entity. Actually, I've
>> prepared this proposal based on the current implementation of
>> CommunicationEventOrder on this assumption that it's an approved feature
>> that's its there in the system.
>>
> Thanks Ratnesh, I see your point now
>
> I am also in agreement with you and Deepak to use the existing (generic)
>> data model to achieve this. I'll give it another thought and further
>> analyze it to fit in existing data model.
>>
> I finally think we can go with your proposition, following the same way
> than CommunicationEventOrder, if it eases the introduction of the feature
>
> Jacques
>
>
>> Thanks!!
>>
>> Regards,
>> Ratnesh Upadhyay
>> HotWax Systems | www.hotwaxsystems.com
>>
>> On Sat, Sep 23, 2017 at 5:37 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>> Le 23/09/2017 à 13:14, Ratnesh Upadhyay a écrit :
>>>
>>> Imagine if we use the generic data model to record each kind of
>>>> communication and when the system tries to pull a specific email or
>>>> specific type email communication from this model then system has to
>>>> browse
>>>> a lot of data and due to this most of the time, it gets ended up with
>>>> slow
>>>> query/browsing issue. So to avoid such performance issue instead of
>>>> extending CommunicationEvent entity, I proposed to make a separate
>>>> entity.
>>>>
>>>> Hi Ratnesh,
>>>
>>> Are you sure about that? What would the bottleneck? If you think the DB
>>> would slow down I don't think it's an issue.
>>>
>>> My take is that I prefer a generic data model rather than sacrificing for
>>> hypothetical performance and end up with data model like competitors with
>>> thousands of entities (OFBiz is currently still around 800+)
>>>
>>> Jacques
>>>
>>>
>