Hi Christian,
nice to have you back!
Sure we can use that too, but the note is meant for some extra info?
The main story should be as close to the request as possible.

Initially the request was meant to have information at some kind of
product list therefore the items so it could be easy converted ino a
quote.

A customer service request most of the time is not like that. However as
usual we can work around it as you can see in the commits  I did
today...but still i am not sure it is the best way of doing it.

Regards,
Hans
-- 
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.

On Fri, 2010-03-12 at 11:14 +0100, Christian Geisert wrote:
> I think it makes sense to have a story/text for the header (for all 
> items), but why not using CustRequestNote for this?
> 
> Christian
> 
> Scott Gray schrieb:
> > Hi Hans,
> > 
> > I would recommend using the custRequestItem for the story, the 
> > implementation can be simple enough by using a service to create the header 
> > and item in a single call and a view entity could could them back to you as 
> > a single record.  Conceptually what you really have is a customer request 
> > with a single item.
> > 
> > I don't like the idea of modifying the data model when it is already quite 
> > capable of meeting your needs.
> > 
> > Regards,
> > Scott
> > 
> > On 11/03/2010, at 7:19 PM, Hans Bakker wrote:
> > 
> >> At the moment i am looking to create a customer service component.
> >>
> >> The usage of the custRequest entity in this case never will need
> >> custRequestItem's
> >>
> >> The long description field called 'story' is however only available in
> >> the custRequestItem and not on the header.
> >>
> >> In order to simplify the implementation i would like to have the story
> >> field also on the header in order not to have to use a 'dummy'
> >> custRequestItem to use the story field.
> >>
> >> Any objections?
> 


Reply via email to