Re: svn commit: r684812 - /ofbiz/trunk/applications/order/entitydef/entitymodel.xml

[David E Jones-2]

On Aug 11, 2008, at 10:54 AM, [hidden email] wrote:

> +      <field name="custRequestDate" type="date-time">
> +        <description>
> +          Created date and custRequestDate most likely are the  
> same. To be checked...

These are not necessarily the same. The custRequestDate is when the  
customer (or whoever) submitted the request and the createdDate is  
when it is actually stored in the system. They will usually be at  
least a few milliseconds apart, and in the extreme case of a paper-
based system failure handling situation they could be days apart.

> +        </description>
> +      </field>
> +      <field name="responseRequiredDate" type="date-time">
> +        <description>
> +          responseRequiredDate is the time the customer needs a  
> response.
> +        </description>
> +      </field>
>       <field name="custRequestName" type="name"></field>
>       <field name="description" type="description"></field>
>       <field name="maximumAmountUomId" type="id"></field>
>       <field name="productStoreId" type="id"></field>
>       <field name="salesChannelEnumId" type="id"></field>
>       <field name="fulfillContactMechId" type="id">
> -          <description>
> -              Field to support a location of a cust request--ie,  
> product literature sent to an address, service call at a localtion,  
> etc.
> -          </description>
> +        <description>
> +          Field to support a location of a cust request--ie,  
> product literature sent to an address, service call at a localtion,  
> etc.
> +        </description>
>       </field>
>       <field name="currencyUomId" type="id"></field>
> -      <field name="openDateTime" type="date-time"></field>
> -      <field name="closedDateTime" type="date-time"></field>
> +      <field name="openDateTime" type="date-time">
> +        <description>
> +        Used when the customer service person responsible for the  
> request open it for action.
> +        Then you take the customer requestdate and openDateTime to  
> see the efficiency of the customer service people.

This won't necessarily be a "customer service person", it could be  
anyone assigned to handle the incoming request. The same goes for  
closedDateTime.

-David

> +        </description>
> +      </field>
> +      <field name="closedDateTime" type="date-time">
> +        <description>
> +          Used when the customer service person responsible for the  
> request close it as resolution
> +          In some customer response systems, the openDateTime and  
> closedDateTime can happen more than once as the customer is not  
> satified
> +          with the resolution.
> +        </description>
> +      </field>
>       <field name="internalComment" type="comment"></field>
>       <field name="reason" type="description"></field>
>       <field name="createdDate" type="date-time"></field>
>       <field name="createdByUserLogin" type="id-vlong"></field>
> -      <field name="lastModifiedDate" type="date-time"></field>
> +      <field name="lastModifiedDate" type="date-time">
> +        <description>
> +          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.

This isn't necessarily true as the request record could be modified  
even after the request is closed/resolved.

Just remember that the createdDate and lastModifiedDate are meant to  
be managed by the system and NOT by the user. In fact, they should  
really be removed (and all fields in other entities like them) because  
the entity engine now keeps fields like those automatically for all  
entities that don't have that feature disabled.

-David

[Christian Geisert]

[hidden email] schrieb:
> Author: jleroux
> Date: Mon Aug 11 09:54:39 2008
> New Revision: 684812
>
> URL: http://svn.apache.org/viewvc?rev=684812&view=rev
> Log:
> Some fields descriptions from BJ comments on user ML

[..]

> +      <field name="custRequestDate" type="date-time">
> +        <description>
> +          Created date and custRequestDate most likely are the same. To be checked...          

Doesn't have to be the case all the time. Maybe the system is offline
just when the customer calls or the salesmen is sending his reports once
a week...

--
Christian

[Jacques Le Roux]

Thanks David,

I amended descriptions following your comments I adapted to context and put a reference in CustRequestAndRole

Jacques

From: "David E Jones" <[hidden email]>

>
> On Aug 11, 2008, at 10:54 AM, [hidden email] wrote:
>
>> +      <field name="custRequestDate" type="date-time">
>> +        <description>
>> +          Created date and custRequestDate most likely are the  
>> same. To be checked...
>
> These are not necessarily the same. The custRequestDate is when the  
> customer (or whoever) submitted the request and the createdDate is  
> when it is actually stored in the system. They will usually be at  
> least a few milliseconds apart, and in the extreme case of a paper-
> based system failure handling situation they could be days apart.
>
>> +        </description>
>> +      </field>
>> +      <field name="responseRequiredDate" type="date-time">
>> +        <description>
>> +          responseRequiredDate is the time the customer needs a  
>> response.
>> +        </description>
>> +      </field>
>>       <field name="custRequestName" type="name"></field>
>>       <field name="description" type="description"></field>
>>       <field name="maximumAmountUomId" type="id"></field>
>>       <field name="productStoreId" type="id"></field>
>>       <field name="salesChannelEnumId" type="id"></field>
>>       <field name="fulfillContactMechId" type="id">
>> -          <description>
>> -              Field to support a location of a cust request--ie,  
>> product literature sent to an address, service call at a localtion,  
>> etc.
>> -          </description>
>> +        <description>
>> +          Field to support a location of a cust request--ie,  
>> product literature sent to an address, service call at a localtion,  
>> etc.
>> +        </description>
>>       </field>
>>       <field name="currencyUomId" type="id"></field>
>> -      <field name="openDateTime" type="date-time"></field>
>> -      <field name="closedDateTime" type="date-time"></field>
>> +      <field name="openDateTime" type="date-time">
>> +        <description>
>> +        Used when the customer service person responsible for the  
>> request open it for action.
>> +        Then you take the customer requestdate and openDateTime to  
>> see the efficiency of the customer service people.
>
> This won't necessarily be a "customer service person", it could be  
> anyone assigned to handle the incoming request. The same goes for  
> closedDateTime.
>
> -David
>
>
>> +        </description>
>> +      </field>
>> +      <field name="closedDateTime" type="date-time">
>> +        <description>
>> +          Used when the customer service person responsible for the  
>> request close it as resolution
>> +          In some customer response systems, the openDateTime and  
>> closedDateTime can happen more than once as the customer is not  
>> satified
>> +          with the resolution.
>> +        </description>
>> +      </field>
>>       <field name="internalComment" type="comment"></field>
>>       <field name="reason" type="description"></field>
>>       <field name="createdDate" type="date-time"></field>
>>       <field name="createdByUserLogin" type="id-vlong"></field>
>> -      <field name="lastModifiedDate" type="date-time"></field>
>> +      <field name="lastModifiedDate" type="date-time">
>> +        <description>
>> +          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.
>
> This isn't necessarily true as the request record could be modified  
> even after the request is closed/resolved.
>
> Just remember that the createdDate and lastModifiedDate are meant to  
> be managed by the system and NOT by the user. In fact, they should  
> really be removed (and all fields in other entities like them) because  
> the entity engine now keeps fields like those automatically for all  
> entities that don't have that feature disabled.
>
> -David
>
>
>
>

[Jacques Le Roux]

Yes thanks Christian,

I already amended description following David's comment (same than you)

Jacques

From: "Christian Geisert" <[hidden email]>

> [hidden email] schrieb:
>> Author: jleroux
>> Date: Mon Aug 11 09:54:39 2008
>> New Revision: 684812
>>
>> URL: http://svn.apache.org/viewvc?rev=684812&view=rev
>> Log:
>> Some fields descriptions from BJ comments on user ML
>
> [..]
>
>> +      <field name="custRequestDate" type="date-time">
>> +        <description>
>> +          Created date and custRequestDate most likely are the same. To be checked...          
>
> Doesn't have to be the case all the time. Maybe the system is offline
> just when the customer calls or the salesmen is sending his reports once
> a week...
>
> --
> Christian
>