I will put in my task list and research the code to make sure there are not other uses. :)
Jacques Le Roux sent the following on 8/2/2008 2:45 PM: > I guess we should wait for reactions and if you are right, BJ, we should > put these information as fields descriptions > > Thanks > > Jacques > > > From: "BJ Freeman" <[EMAIL PROTECTED]> >> I did review those. >> my take is they are when the customer service person responsible for the >> request opened it for action and closed it as resolution is when >> openDateTime and closedDateTime. >> then you take the customer requestdate and openDateTime to see the >> efficiency of the customer service people. >> Created date and custRequestDate most likely are the same. >> Last modified date can be till the closedDateTime which is when the >> customer service people say it is resolved. This gives when the last >> action was done to see if the steps to resolve the request are happening >> in a timely manner. >> >> Now in some customer response systems, the openDateTime adn >> closedDateTime can happen more than once as the customer is not satified >> with the resolution. >> >> responseRequiredDate is the time the customer needs a response. >> >> since a lot of these fields can not be seen used in code, it is usually >> falls to how ever utilizes them first as to thier true definition, I >> have found. >> >> :) >> >> >> Jacques Le Roux sent the following on 8/2/2008 2:07 PM: >>> From: "BJ Freeman" <[EMAIL PROTECTED]> >>>> just a guess >>>> this defines when the request was made and when it was closed. >>> >>> Yes, not easy to infer between >>> custRequestDate >>> responseRequiredDate >>> openDateTime >>> closedDateTime >>> createdDate >>> lastModifiedDate >>> >>> We may try togheter but I thinks it's better to wait for with a real and >>> complete knowledge about those fields >>> . custRequestDate may refer to a date the customer entered when he/she >>> made his/her request (I suppose by default its the time the >>> user created the request) >>> . responseRequiredDate obviously refer to the last time this request >>> will be helpful for the customer >>> . openDateTime mmm ... may refer to the date thi request should be >>> considered (or implies different status like created, open, ... >>> ? But in this case would be openedDateTime) >>> . closedDateTime the date when the request was closed >>> >>> . createdDate may refer to the date the request was 1st created (implies >>> different status like created, open, ... ?) >>> . lastModifiedDate last time the request was modified >>> >>> The purpose of this post is to underline the trouble you can get >>> sometimes in OFBiz. Obviously some comments to differentiate those >>> dates (or more creative names for some of them, namely custRequestDate , >>> openDateTime, createdDate) would not have been luxury (as >>> some may find this post ;o). IMHO, it happens that we find ourself in >>> such situations, not only with entities fields, and we should >>> try to avoid it. Like I said long before, the best API is nothing >>> without its documentation,. And in this respect we have still a >>> long way to go with OFBiz... OFBiz is great but it can be greater :o) >>> >>> Thanks and sorry for the long, but I hope not complaining, post. >>> >>> Jacques >>> >>>> >>>> Ashish Vijaywargiya sent the following on 8/2/2008 1:18 AM: >>>>> Hello, >>>>> >>>>> Can anybody of you tell me the purpose of the following two fields >>>>> from >>>>> "CustRequest" entity ? >>>>> >>>>> <field name="openDateTime" type="date-time"></field> >>>>> <field name="closedDateTime" type="date-time"></field> >>>>> >>>> >>> >>> >>> >>> >> > > >
