Mike, I am doing two one name studies that are heavily UK, and I am not in the position, like many of us, to order a certificate for every BMD event I can use in my study. So, I wanted to create a protocol for recording vital event information based just on the BMD registration information and make sure that it was clear visually that this registration info was the source of the vital event information.
I have created a series of events: Birth, Marriage, and Death Registrations. This is where I record the UK BMD registration records. Unless I have a better date for the actual birth, marriage or death, I will use those registration Q dates for birth, marriage, and death. BUT, if I have a more accurate date, I will use the more accurate date. --> When I record a Registration event, I use the Registration District (RD) as the location. If I use a registration date for a vital event date, I will also use the RD location as the vital event location, unless I have a better location from census or elsewhere. For instance, if I have a baptism date, I will record the birth dates as "before <baptism date>", unless the birth registration date was in a previous quarter to the baptism date. I will follow a similar protocol with a death date if I have a burial date. If I have a death date, I record a burial date as an after <death date> (unless I have the burial date) so that date field is not empty and chronology reports are accurate. Yes, when a death date is a Q date, a burial date cannot be created using this approach. Yes, the death registration event is setup so it is not included in a problem report as it logically should always be after death. BTW, a lot of work went into assuring that the Q dates and other approximate dates do the right thing when doing PP Alerts. There may be some conditions we did not test and some that logically could never be 100% right, but we have definitely minimized the number of cases where users will need to do the exclusions and the number of cases where you miss a problem that should have been caught. john. At 08:19 AM 11/30/2013, Mike Fry wrote: >On 2013/11/30 14:50, Michele/Support wrote: > > > Under Problems > > Buried date before death date > > > > This one definitely catches the typos:) > >Gives false positives when there's an actual burial date but the >only death date >has been taken from the GRO in England and entered as Mmm Q yyyy. Even though >the quarter covers the burial date, the program still thinks the burial is >before the death. > >-- >Regards, >Mike Fry >Johannesburg (g) Legacy User Group guidelines: http://www.LegacyFamilyTree.com/Etiquette.asp Archived messages after Nov. 21 2009: http://www.mail-archive.com/legacyusergroup@legacyusers.com/ Archived messages from old mail server - before Nov. 21 2009: http://www.mail-archive.com/legacyusergroup@legacyfamilytree.com/ Online technical support: http://www.LegacyFamilyTree.com/Help.asp Follow Legacy on Facebook (http://www.facebook.com/LegacyFamilyTree) and on our blog (http://news.LegacyFamilyTree.com). To unsubscribe: http://www.LegacyFamilyTree.com/LegacyLists.asp
