I have found some problems when trying to renew CRM Contract.
It can be easily reproduced:
We have a user account configured with a typical timezone of Europe (GMT+1
for example).
We create a contract starting on 1/1/2008 and ending on 12/31/2008.
We also create a unique contract line, with same date period.

We invoice contract, and then we renew it, and we get these new dates:
Contract header: from 1/1/2009 to 1/1/2010 (so, new contract has one day
more, which is not what a real user should expect because year 2008 has 366
days)
Contract line: from 12/31/2008 to 1/1/2010 (it's not coherent with header)


Making some deeper investigation on this issue, I find two reasons:
1. CRM takes into consideration only contract duration in days, so, we will
always have problems with 366 day years (as 2008)
2. There is something wrong with timezones, because contract lines are not
coherent with header.

I discovered that it has something to be with timezone, because original
contract dates are stored in UTC (datetime), and what it is supposed to be
1/1/2008, is really 2007-12-31 23:00:00.000.

Looking inside SQL Server, we get these values:
Contract Header:
=============
Activeon: 2008-12-31 23:00:00.000 (this should be correct, because is
exactly one year after first contract).
ExpiresOn: 2010-01-01 22:59:59.000 (it's exactly one second less than 366
days)

Contract line:
==============
Activeon: 2008-12-31 22:59:59.000 (one second less than header)
---> this generates that user see one day before header.
ExpiresOn: 2010-01-01 22:59:58.000 (one second less than header, because
original contract also had one second less than header)



Anyway, our applications needs a very strict treatment of contract dates,
and should be able to automatically renew, and we have made a custom
application (as we are ISV), to provide this.

I post this for your development group can take care of it, because we have
to manually repair dates after calling WebService to renew contract.

Kind regards,



--
Pablo Igualada
Evotec Consulting SL
www.evotec.es/crm

RE: Contract renewal problems by Adrian

Adrian
Tue Sep 23 17:26:00 CDT 2008

We have the same problem - it was in V3 and is also in V4. I tried getting
help from Microsoft but they just were not interested. They simply said it
is the way it is designed.

I advise all our clients not to use the contracts section. It just doesn't
work. If they need to record contracts, then create a custom entity for them
and use custom code to renew etc.

"P.Igualada" wrote:

> I have found some problems when trying to renew CRM Contract.
> It can be easily reproduced:
> We have a user account configured with a typical timezone of Europe (GMT+1
> for example).
> We create a contract starting on 1/1/2008 and ending on 12/31/2008.
> We also create a unique contract line, with same date period.
>
> We invoice contract, and then we renew it, and we get these new dates:
> Contract header: from 1/1/2009 to 1/1/2010 (so, new contract has one day
> more, which is not what a real user should expect because year 2008 has 366
> days)
> Contract line: from 12/31/2008 to 1/1/2010 (it's not coherent with header)
>
>
> Making some deeper investigation on this issue, I find two reasons:
> 1. CRM takes into consideration only contract duration in days, so, we will
> always have problems with 366 day years (as 2008)
> 2. There is something wrong with timezones, because contract lines are not
> coherent with header.
>
> I discovered that it has something to be with timezone, because original
> contract dates are stored in UTC (datetime), and what it is supposed to be
> 1/1/2008, is really 2007-12-31 23:00:00.000.
>
> Looking inside SQL Server, we get these values:
> Contract Header:
> =============
> Activeon: 2008-12-31 23:00:00.000 (this should be correct, because is
> exactly one year after first contract).
> ExpiresOn: 2010-01-01 22:59:59.000 (it's exactly one second less than 366
> days)
>
> Contract line:
> ==============
> Activeon: 2008-12-31 22:59:59.000 (one second less than header)
> ---> this generates that user see one day before header.
> ExpiresOn: 2010-01-01 22:59:58.000 (one second less than header, because
> original contract also had one second less than header)
>
>
>
> Anyway, our applications needs a very strict treatment of contract dates,
> and should be able to automatically renew, and we have made a custom
> application (as we are ISV), to provide this.
>
> I post this for your development group can take care of it, because we have
> to manually repair dates after calling WebService to renew contract.
>
> Kind regards,
>
>
>
> --
> Pablo Igualada
> Evotec Consulting SL
> www.evotec.es/crm