Proper use of thruDate

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Wai
Reply | Threaded
Open this post in threaded view
|

Proper use of thruDate

Wai
Hello,
What is the best practice in using the thruDate of an item.
I know that when deleting or expiring an item, it is best to just fill in the thruDate.  The reason behind this is to have a record of deleted/expired items.

What if an item needs to be reused again.  Is it a matter of emptying out the thruDate or setting it to a future expiry date?  If this is the best practice, how would ofbiz keep track of whether an item has ever been expired?

Thanks in advance
Reply | Threaded
Open this post in threaded view
|

Re: Proper use of thruDate

Jacques Le Roux
Administrator
From: "Wai" <[hidden email]>

> Hello,
> What is the best practice in using the thruDate of an item.
> I know that when deleting or expiring an item, it is best to just fill in
> the thruDate.  The reason behind this is to have a record of deleted/expired
> items.
>
> What if an item needs to be reused again.  Is it a matter of emptying out
> the thruDate or setting it to a future expiry date?  If this is the best
> practice, how would ofbiz keep track of whether an item has ever been
> expired?

Sometimes you would want to simply remove the old value. It's done for example for the ProductPrices. In simple-methods
<remove-value is used for that, Look for delete in services names.
Most of the time you would want to duplicate the expired item and just set the thruDate to null or a future date. They are examples
of this in code. Look for expire in services names.

Jacques

> Thanks in advance
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Proper-use-of-thruDate-tp2290914p2290914.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Proper use of thruDate

Atul Vani
In reply to this post by Wai
Hello Wai,

It depends on your requirements, whether you want to keep record of that
particular thing or not.

For ex:
for a customer you would like to keep track/record of his contact details
like for what time period what was his shipping address
even if he changes it and swaps back to the same shipping address,
then also you won't just remove the thruDate and use old record (or in
other words erase his history)

but if its a promotion (may be seasonal) then you would just use
thruDate to turn it on/off

--
Thanks & Regards
Atul Vani
Enterprise Software Developer
HotWax Media Pvt. Ltd.
http://www.hotwaxmedia.com/
We are the Global Leaders in Apache OFBiz, Google 'ofbiz' and see for yourself.

Wai wrote:

> Hello,
> What is the best practice in using the thruDate of an item.
> I know that when deleting or expiring an item, it is best to just fill in
> the thruDate.  The reason behind this is to have a record of deleted/expired
> items.
>
> What if an item needs to be reused again.  Is it a matter of emptying out
> the thruDate or setting it to a future expiry date?  If this is the best
> practice, how would ofbiz keep track of whether an item has ever been
> expired?
>
> Thanks in advance
>  
Reply | Threaded
Open this post in threaded view
|

Re: Proper use of thruDate

James McGill-5
In reply to this post by Wai
On Thu, Jul 15, 2010 at 8:34 PM, Wai <[hidden email]> wrote:

>
> Hello,
> What is the best practice in using the thruDate of an item.
> I know that when deleting or expiring an item, it is best to just fill in
> the thruDate.  The reason behind this is to have a record of
> deleted/expired
> items.
>
> What if an item needs to be reused again.  Is it a matter of emptying out
> the thruDate or setting it to a future expiry date?  If this is the best
> practice, how would ofbiz keep track of whether an item has ever been
> expired?
>
>
I would recommend creating some kind of detail record to track this kind of
"on-off-on" change.

The framework has a built-in way of dealing with valid date range states, as
you know, but to get the next level of accountability you probably want to
extend the model in order to store the transaction history.  I would look at
ProductPriceChange or PartyNameHistory for examples of this idea.

--
James McGill
Phoenix AZ