11-21-2007 8:51 AM
Hi,
Short question: can I safely use a default key date of January 1, 1900 everywhere in Student File/Student Master data? with all organizational structure objects also created using this date?
The rationale behind this decision is to reduce confusion for the end user, which I noticed is more than likely.
A classical example is the possibility to version birth dates in Student Master Data even though logically this should be a single instance of data only. Ever. However, if we set the key date as "today" or the beginning of an academic period, any corrections would be seen as versions. This confuses the end user, which version is the current one and which one is merely a data correction (and shouldn't be visible at all).
However, won't setting the key date to 1900 have unexpected complications somewhere else? One complication I already noticed was with creating faculty as HR personnel (they serve as advisors for students and are later assigned in Student File). Faculty birth dates are not allowed to be entered in this case because (I assume) the system thinks faculty can't be born later than the object created (although student birth dates are OK even though the corresponding objects were also created at January 1, 1900)
Overall, is it possible to eliminate the key date concept from the Student File/Master Data completely? As it feels to do more harm than good.
Janek
12-12-2007 11:04 PM
Janek,
Of course becasue there is validity dating of the data values, it is necessary to use a key date when you display/change the data.
For the issue of fields like birthdate, you are right that any 'change' is pretty much a data correction. It is not possible for a student to really have different brithdates that were valid for different periods!
It really is something that users must be trained to do. If they are doing a data correction, they should change the data from the first data 'period', rather than just as of the current date.
Michael
12-12-2007 11:04 PM
Janek,
Of course becasue there is validity dating of the data values, it is necessary to use a key date when you display/change the data.
For the issue of fields like birthdate, you are right that any 'change' is pretty much a data correction. It is not possible for a student to really have different brithdates that were valid for different periods!
It really is something that users must be trained to do. If they are doing a data correction, they should change the data from the first data 'period', rather than just as of the current date.
Michael