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