Page 3 of 3

Posted: Tue Dec 16, 2008 8:58 am
by aebrown
mkmurray wrote:Doesn't LUWS just reflect whoever is head of household in MLS, member or not?
No, LUWS does not have any nonmembers at all. So if the household consists of a member wife, nonmember husband, and children, it will probably appear in MLS with the husband as HoH, wife as spouse, and all the children. But on LUWS, it will appear as if the wife is HoH, with the children listed under her. The husband will not appear in LUWS.

In this post I requested that LUWS should have the capability of including nonmember spouses, and in this post, TomW responded that this was being planned.

Posted: Tue Dec 16, 2008 12:35 pm
by ericb
rhusted wrote:
We've also noticed that the member spouse often shows up as "other" rather than "spouse" in various screens in MLS. So there is another *BUG* somewhere in MLS related to nonmember spouses.

Lastly, we're having difficulty deleting some nonmember records once they've been added.

I've seen these same problems - I'm glad to see someone has taken the initiative to post this.

The first issue was noticed because some listings in the ward directory generated from MLS reflected something similar to 'David & David Smith'. We identified all of the non-member records in MLS and most had a problem with the relationship. We went through and updated them, which had to be done in a certain sequence in order for the spouse to show up as 'spouse' rather than 'other'. I'll have to see if I can locate my notes and update this post.

Update: As Alan indicates in the next post, this topic has already been covered in more depth (I apparently missed this one): http://tech.lds.org/forum/showthread.php?t=1737

Posted: Tue Dec 16, 2008 12:47 pm
by ericb
Greggo wrote: I'm wondering if the problem would possibly go away if MLS only allowed members to be the H of H (which is the way I would prefer it - or at least allow the option to have a female member with a nonmember spouse be the H of H).

Let's not forget the homes where only the children are members (the parents are not). In this case, I think it makes more sense to have a (non-member) parent listed as H of H rather than the (member) children.

Posted: Tue Dec 16, 2008 12:56 pm
by aebrown
ericb wrote:I've seen these same problems - I'm glad to see someone has taken the initiative to post this.
This has been discussed at length in several other threads (and this thread has 20+ other posts to review). The most recent one is:

Non Member Spouses

But older threads also discuss it:

Spouse showing as "Other"
Spouse Listed at Other

MRN Expansion and Significance

Posted: Wed Jun 23, 2010 6:21 pm
by njalsson
I'm new here, so I hope I'm not opening up a whole new can of worms, but if I understand correctly, the MRN is basically a non-significant identifier. Maybe this is causing some of the problems? I'm rusty as to whether there is a significant part of the MRN such as a region identifier in the beginning? Mine started with 058- and I seem to recall (of course, being interested in identifiers of all sorts I started asking about the significance) this being a region identifier?

At any rate, based upon the problems described in this and other threads, would it perhaps be more simple to either modify or expand the identifier system so that "individuals of record" (those who are listed but not members) would automatically have a digit indicating this status in their administrative number or MRN that would be replaced once they are regular members. So the system (once modified) would automatically know what to do with them and not "leak" them into directories or other databases for regular members until the digit change was made. This would of course mean that an individual could have two numbers during the lifetime of their records, however the two identifiers would be related and more simply/accurately deduced by accounting the change in one or at most two (if checksums are being used) digits? The idea would be that it would not be up to ward and other clerks in most cases to try to figure out the status, guess or come up with their own systems and solutions.

Just a thought....

Posted: Thu Jun 24, 2010 8:51 pm
by idjeeper2
Greggo wrote:I'm curious. Is this bug with nonmember spouses only if the spouse is male and therefore is made the H of H?

I'm wondering if the problem would possibly go away if MLS only allowed members to be the H of H (which is the way I would prefer it - or at least allow the option to have a female member with a nonmember spouse be the H of H).
As the membership clerk in my home ward, I frequently ran into this problem. It was exclusively non-member male spouses. Never had a problem with male members married to non-member females.

Your second comment, while making some things easier, potentially creates a different problem in my mind. Too many members forget that as a matter of respect (and I believe church policy), the "man" of the house is always the head of household, member or not. Having them show up on directories helps remind us of that. Also it makes it easier for a Bishop to see the full situation in a household if the non-member is shown as part of it. I would prefer a way to show the spouse on a directory without having to create a non-member record. I know it can be done manually but requires me to remember all of them.

It's a tough issue and I think the Church is trying to be sensitive to mixed families and to the needs of administering a ward.

Non member spouse HOH?

Posted: Thu Jul 01, 2010 4:33 pm
by zaneclark
I have read through all the posts on non-member spouses and but I can't see the answer to my problem. I have an active sister married to a non member but she uses her maiden name. If I use her husband as the head of house, she only appears as his spouse. If someone wanted to contact her via the directory, she is not listed under her maiden name, only as the wife of her husband and most in the ward do not know him and in fact, probably are unaware that she is married. It looks like I am going to have to list her as HOH in order for her to appear in the directory unless someone has a better solution....