Year End and History Question

Discussions around using and interfacing with the Church MLS program.
User avatar
PNMarkW2
Member
Posts: 66
Joined: Thu Jun 11, 2009 1:44 pm
Location: Portland, Oregon, USA
Contact:

Year End and History Question

Postby PNMarkW2 » Wed Jun 16, 2010 8:59 pm

This problem was previously posted about in two other threads, I'm starting it again here because it is not yet resolved, and I believe the two problems are connected and I wanted to present the core information in a single thread to help facilitate any responses.

Background:
When we did the annual year end update our MLS locked up for over 3 hours. Closing MLS, rebooting the computer, and attempting to the year end update again resulted in the same error. At the time is seemed to hang while "deleting old batches". (I believe this an important point)

After confirming here that this was not normal behavior I was preparing to phone local unit support the following morning when I tried it again, and it appeared to close without an issue. Because it seemed to work I did *not* phone local unit support at that time.

Move forward to February 2010:
While trying to reconcile our December statement we find some odd unreconciled balances (Tithing $66,295.03, Fast Offering $6,893.67, Missionary of $10,836.96). These unreconciled balances appear not just for the month we were working on, but also for any month we choose to review.

After posting this issue to the forum the general view was our year end caused an error, and we should phone local unit support. Our Financial Clerk, a veteran clerk of at least 30 years, made the call and report that Local Unit Support refused to talk to us about this, and said we should speak with our Stake Clerk and/or Stake Financial Clerk.

Enter our Stake Financial Clerk who review our reconciliation problems, and if I remember correctly he made some year end adjustments to attempt to balance our accounts. He was unsure if this would work, or if it was correct, and was going to phone local unit support himself to verify.

Current:
After not hearing from our Stake Financial Clerk for sometime, and knowing we could still not properly reconcile, I contacted him again and he returns. All we accomplish is to discuss the problem further, only now he says the adjustments I'm looking at for 31 Dec 2009 were not made by him, but were made by Salt Lake instead. When he leaves he is going to contact Salt Lake because these adjustment were not, in his view, made to the correct categories.

My Questions:
1) Just out of curiosity, I know it's most likely possible, but is it likely that Salt Lake would make an adjustment without sending a message to the local unit?

2) I believe this is a result of the year end update failure, not some other issue. To verify this I've been trying to trace back and see if a possible error could have come from any other source. When I look at our 2006 data there are no transfers shown for our tithing, leaving us a balance $66295.03 (the exact amount we're showing off today). When, if ever, does history drop off MLS? Could this have been the "deleting old batches" that our year end update froze on?

Any other thoughts or suggestion on trying to isolate this problem?
~Mark
Ward Clerk
Colonial Heights Ward
Portland Oregon Stake

-----
"For a list of all the ways technology has failed to improve the quality of life, please press three."
---Alice Kahn

User avatar
aebrown
Community Administrator
Posts: 14693
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

Postby aebrown » Wed Jun 16, 2010 10:07 pm

PNMarkW2 wrote:1) Just out of curiosity, I know it's most likely possible, but is it likely that Salt Lake would make an adjustment without sending a message to the local unit?


That probability is approximately zero. Church Headquarters cannot make adjustments to MLS (unless they capture a backup of the database, make adjustments, and then send a database update script). CHQ will never do that without your knowledge, because the update has to be done within a tight time window, or you can lose data entered between the capture and the update.

All CHQ does in this regard is to make adjustments to their records. But such adjustments will always appear on a Church Unit Financial Statement. That CUFS will be for the month in which the corrections occur -- CHQ will never reach back into the past and make adjustments.

So although it's good that you're thinking of all the possibilities, I really don't think there's any point in exploring this particular option any further.

PNMarkW2 wrote:2) I believe this is a result of the year end update failure, not some other issue. To verify this I've been trying to trace back and see if a possible error could have come from any other source. When I look at our 2006 data there are no transfers shown for our tithing, leaving us a balance $66295.03 (the exact amount we're showing off today). When, if ever, does history drop off MLS? Could this have been the "deleting old batches" that our year end update froze on?


Old batches are removed from MLS at the end of the financial record retention period. Since you are in the USA, that is 3 years plus the current year. That means that as you were closing the 2009 year when you first logged into MLS in 2010, the 2006 batches were removed, along with other obsolete records. Or at least the 2006 batches should have been removed. If you are still able to see 2006 data (which you mentioned), then that is an indication that indeed the closing of the 2009 financial year did not work properly.

It really sounds to me like your data is corrupted to some extent, and you need to have CHQ examine your database, so I would recommend that you contact Local Unit Support.
Questions that can benefit the larger community should be asked in a public forum, not a private message.

User avatar
jltware
Member
Posts: 68
Joined: Sun Feb 03, 2008 12:24 am
Location: Australia

Postby jltware » Sun Jun 20, 2010 3:58 am

I agree that the chances of somebody in Salt Lake playing with your finances is very remote. However, Salt Lake have a (somewhat annoying) habit of sending through updates without any notification, sometimes without the operator even realising they have come through. I mention this because we received an update recently that caused nearly all my budget subcategories to be deleted and my budget to be overwritten completely with nil values. This was not overly helpful, and it would have been nice if somebody had notified us this was coming through so we could have run a backup before the patch was allowed to run. I believe it is even possible to generate a remote backup automatically from SLC / area offices now, and this would have given us something to fall back on. This update also caused several significant changes in finances (categories being moved to different parent categories, expenses having different budget categories etc.) Some of these changes are things that are completely impossible to fix at our end. Our area support office told us this was supposed to be an update that only affected the back end and made some invisible changes to our system to help it communicate with the new back end. Clearly this didn't work properly though, and it is very annoying having to spend many hours reentering details you know you've done before and that you know could all be deleted again at a whim from the MLS tech team.

So all in all, if something weird is happening with your finances right now, I would suggest that an update patch should be considered as a possible culprit. I would also respectfully suggest to anyone involved in rolling out such patches that we would like to know about them ahead of time, even if you do think they won't affect us. Unanticipated side effects of the changes you make can be very annoying and are easier to fix if we know the cause.

We also have seen several updates of the type described by Alan_Brown come out unexpected and overwrite all the changes made that day, including some wards' tithing batches. This is because the refresh from CHQ will always take precedence over what you already have on your machine, even if your information is more accurate and up to date. When this was queried with area support, an email was sent out telling people (paraphrasing) that they are supposed to be send/receiving at the start and finish of each session anyway, so it was the wards' fault for not following policies and to make sure this policy is always followed to avoid a future such incident. While this is entirely true, it is also true that it is standard policy (or at least good practice) to notify local units when changes like this are being made to prevent such problems, and the holier than thou approach doesn't really help much when you're trying to tell the ward clerk why all the work he did that day magically disappeared without warning. So again, please, a little communication goes a long way!

I do love our MLS team, really, and appreciate what they do. Just wish sometimes we knew what they were doing a little more.

But PNMarkW2, in these cases, the database hadn't had changes made of the nature you're describing. I am quite confident nobody deliberately goes through and deletes entries or twiddles balances to see how long it will take you to notice. But it is always possible some changes made in the back end could have had some undesired and unanticipated side effects. It is highly unlikely though that anyone will undo the changes to help you fix it though, so the cure is still the same regardless of the disease source. Pick through entries one by one and find the anomalies.

Sorry :(

User avatar
jltware
Member
Posts: 68
Joined: Sun Feb 03, 2008 12:24 am
Location: Australia

Postby jltware » Sun Jun 20, 2010 4:08 am

Just one other idea, if the mismatch was caused by an incomplete, inaccurate or otherwise flawed deleting of old batches, then refreshing your financial database may cause the incorrect entries to be overwritten (deliberately this time, not accidentally). It should at least make what you have match with what CHQ has, and therefore will make your recondiliations work properly again. Be sure if you are going to attempt this though that you send / receive first, then do something to be sure nobody can use the database in the meantime (could range from a note to temproarilly changing the windows login password depending on how compliant people in your unit usually are with those types of requests). Then make the request, and make sure you do a send / receive and that the refresh has come through before allowing any other changes to be made. Otherwise you will be creating the very problem you are trying to correct.

Not an ideal fix, but it may present a solution if all else fails.

Good Luck

User avatar
aebrown
Community Administrator
Posts: 14693
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

Postby aebrown » Sun Jun 20, 2010 4:49 am

jltware wrote:Salt Lake have a (somewhat annoying) habit of sending through updates without any notification, sometimes without the operator even realising they have come through. I mention this because we received an update recently that caused nearly all my budget subcategories to be deleted and my budget to be overwritten completely with nil values.


This whole post (plus the one that follows it) is based on a misunderstanding of how the financial system in US/Canada works. So it really doesn't apply to the issue at hand. See this post for an explanation of the difference.
Questions that can benefit the larger community should be asked in a public forum, not a private message.

User avatar
jltware
Member
Posts: 68
Joined: Sun Feb 03, 2008 12:24 am
Location: Australia

Postby jltware » Sun Jun 20, 2010 6:01 am

I have no doubt there are differences in the systems involved. But I happen to know that the updates that were the culprit in our problems were pushed out from Salt Lake, not from our local offices. Our own offices weren't privy to the details until they started investigating complaints from the local units. So the people involved behind the scenes are the same. Therefore I am somewhat skeptical of a claim of zero probability of Salt Lake making changes without giving notice first. If they're content to push changes to the other side of the planet without so much as an email, I can't see them hesitating to push them next door.

I don't claim that the errors are caused by the exact same update, merely that an unannounced update patch should be considered as a possibility.

As far as database changes go, if somebody made changes to the backend that needed modifications to be pushed through, it seems the problem could still result in data being lost in the process. You yourself said that doing such a push without sticking to a tight time window would cause changes to be lost. The claim that Salt Lake would never do this seems optimistic, given that the database pushes causing problems for us again originated in Salt Lake, not the area offices.

Again, I don't think you would have been affected by the specific changes that hit us, but don't assume just because something should be done a certain way that it has been. There are too many examples in recent history where this clearly hasn't been the case. Consider all possibilities, and hopefully prove me wrong. When everything that is impossible has been eliminated, that which remains, not matter how improbable, must surely be the truth.

User avatar
PNMarkW2
Member
Posts: 66
Joined: Thu Jun 11, 2009 1:44 pm
Location: Portland, Oregon, USA
Contact:

Postby PNMarkW2 » Mon Jun 21, 2010 11:29 am

Resolution:
I got off the phone with Local Unit Support a few minutes ago, and here is the result.

First, Salt Lake had done nothing to cause our original problem, or with any attempt to correct said problem.

The problem was caused by our 2009 year end update not completely removing 2006 data, and having those balances carry forward causing us to be out of balance today.

The support specialist started by removing the adjustments that had been entered for 31 Dec 2009 by our Stake Financial Clerk in an attempt to correct this problem. It's not the these were wrong as such, but they were entered for the wrong date, and they were not extensive enough.

Her solution was to make adjusting entries for each category that had a balance being carried forward from 2006 for 31 Dec 2006. Basically at the source of the problem, instead of three years later, and she made at least a dozen entries compared to the four that our Stake Finance Clerk made. The only exception was out Other category, she made just one entry here and told us to make transfers to balance within the category. I suspect our Ward Missionary category will also need some internal balancing.

Again, clearly our Stake Finance Clerk was on the right track, but he didn't quiet go back far enough.
~Mark
Ward Clerk
Colonial Heights Ward
Portland Oregon Stake

-----
"For a list of all the ways technology has failed to improve the quality of life, please press three."
---Alice Kahn


Return to “MLS Support, Help, and Feedback”

Who is online

Users browsing this forum: No registered users and 1 guest