You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ofbiz.apache.org by jl...@apache.org on 2008/08/11 18:54:39 UTC
svn commit: r684812 -
/ofbiz/trunk/applications/order/entitydef/entitymodel.xml
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
Modified:
ofbiz/trunk/applications/order/entitydef/entitymodel.xml
Modified: ofbiz/trunk/applications/order/entitydef/entitymodel.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/entitydef/entitymodel.xml?rev=684812&r1=684811&r2=684812&view=diff
==============================================================================
--- ofbiz/trunk/applications/order/entitydef/entitymodel.xml (original)
+++ ofbiz/trunk/applications/order/entitydef/entitymodel.xml Mon Aug 11 09:54:39 2008
@@ -1617,26 +1617,50 @@
<field name="statusId" type="id"></field>
<field name="fromPartyId" type="id"></field>
<field name="priority" type="numeric"></field>
- <field name="custRequestDate" type="date-time"></field>
- <field name="responseRequiredDate" type="date-time"></field>
+ <field name="custRequestDate" type="date-time">
+ <description>
+ Created date and custRequestDate most likely are the same. To be checked...
+ </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.
+ </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.
+ </description>
+ </field>
<field name="lastModifiedByUserLogin" type="id-vlong"></field>
<prim-key field="custRequestId"/>
<relation type="one" fk-name="CUST_REQ_TYPE" rel-entity-name="CustRequestType">
Re: svn commit: r684812 - /ofbiz/trunk/applications/order/entitydef/entitymodel.xml
Posted by Jacques Le Roux <ja...@les7arts.com>.
Yes thanks Christian,
I already amended description following David's comment (same than you)
Jacques
From: "Christian Geisert" <ch...@isu-gmbh.de>
> jleroux@apache.org 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
>
Re: svn commit: r684812 - /ofbiz/trunk/applications/order/entitydef/entitymodel.xml
Posted by Christian Geisert <ch...@isu-gmbh.de>.
jleroux@apache.org 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
Re: svn commit: r684812 - /ofbiz/trunk/applications/order/entitydef/entitymodel.xml
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks David,
I amended descriptions following your comments I adapted to context and put a reference in CustRequestAndRole
Jacques
From: "David E Jones" <jo...@undersunconsulting.com>
>
> On Aug 11, 2008, at 10:54 AM, jleroux@apache.org 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
>
>
>
>
Re: svn commit: r684812 - /ofbiz/trunk/applications/order/entitydef/entitymodel.xml
Posted by David E Jones <jo...@undersunconsulting.com>.
On Aug 11, 2008, at 10:54 AM, jleroux@apache.org 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