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 < > upadhyay.ratn...@gmail.com> 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 > > >
