Quarterly Report months

[sbradshaw]

I agree that it would be better to report on all the months or the best month of the quarter, rather than always the same four months every year. That makes sure that people are keeping records every month.

[genman]

Why do we need to change counting months? It seems the easiest thing, to me, is to keep the way it is done now with reporting months, but to average counts across the whole quarter.

You may be right. But my main concern was not the lower numbers in some months, but rather the other issues with filing the report in early January for the last month in the previous year. There is at least one software bug that mis-counts the numbers on the report in that case, with no workaround way to correct it. And there are other year-end/new-year clerk-related activities that could be load-spread if the quarterly report for 4Q2012 was filed, say, by 15 Nov (based on Oct data) instead of being filed by 15 Jan (based on Dec data).

If the decision is made to average across all 3 months of the quarter, then I think we are stuck with 15 Jan filing date for 4Q2012. But if we continue with the concept of just using data from one month, then there should be no reason why we could not use 15 Nov filing date for 4Q2012.

The hardest part about going to a 3-month average vs the current 1-month average would likely be getting the home teaching and visiting teaching numbers for all 3 months to average.

[russellhltn]

But my main concern was not the lower numbers in some months, but rather the other issues with filing the report in early January for the last month in the previous year. There is at least one software bug that mis-counts the numbers on the report in that case, with no workaround way to correct it. [...] If the decision is made to average across all 3 months of the quarter, then I think we are stuck with 15 Jan filing date for 4Q2012. But if we continue with the concept of just using data from one month, then there should be no reason why we could not use 15 Nov filing date for 4Q2012.

That would take an even bigger software change then to fix the bug.

And isn't the bug you're talking about only with the website and not MLS? IOW, a valid work around is to use MLS?

[genman]

That would take an even bigger software change then to fix the bug.

How so? For report data months of Jan/Apr/Jul/Oct, the filing of the report would be by the 15ths of months Feb/May/Aug/Nov. Thus all filing months are in the same year as the 4 data months. That makes the bug a don't-care, because we never span a year boundary before filing. That in-effect resolves the bug without a software change. By the way, the bug I'm talking about is the count of Primary children where if you file the report on 10 Jan 2013 for the month of Dec 2012 it uses the count of the children based on their ages on 1 Jan 2013 instead of their ages on 1 Jan 2012, which is used to determine whether or not they are in Primary in the data month of Dec 2012.

And isn't the bug you're talking about only with the website and not MLS? IOW, a valid work around is to use MLS?

Good question. Not sure if it is website-only or both. If it is website-only, then yes using MLS to submit the Quarterly Report would be the workaround. But having to do the workaround either further increases the workload of the clerk (which was part of the issue), or more likely just corrupts the integrity of the quarterly report numbers submitted, as most clerks don't know about the bug.

[aebrown]

That would take an even bigger software change then to fix the bug.

How so?

I listed some of my suggestions as to what the costs would be here. Fixing the bug likely is one fix in one software system. Changing the reporting month would affect multiple systems, as such it seems clear to me that it would cost far more.

[russellhltn]

But having to do the workaround either further increases the workload of the clerk (which was part of the issue),

Call it spin doctoring, but I find it hard to accept that for a job that is run just 4 times a year, to use the process that was the only process until about a year ago "increases the workload". You don't get the latest convenience, but such is the teething pains of new things.

or more likely just corrupts the integrity of the quarterly report numbers submitted

Let's see who reads the reports.

[Gary_Miller]

By the way, the bug I'm talking about is the count of Primary children where if you file the report on 10 Jan 2013 for the month of Dec 2012 it uses the count of the children based on their ages on 1 Jan 2013 instead of their ages on 1 Jan 2012, which is used to determine whether or not they are in Primary in the data month of Dec 2012.

This would be a plus as this is when you would have the most children in primary, due to you would have not yet lost anyone to YM/YW.

[genman]

This would be a plus as this is when you would have the most children in primary, due to you would have not yet lost anyone to YM/YW.

Not sure I understand your point. A child who turned age 12 on 2 Jan 2012 is still counted in the Primary attendance numbers thru Dec 2012.

[Gary_Miller]

I'm not sure that's the case but I'll take your word for it until I find out other wise.

[genman]

I'm not sure that's the case but I'll take your word for it until I find out other wise.

Oh wait. Don't take my word for it. I learned something else new today. Primary kids are only supposed to be counted if they are under age 12 as of the last day of the quarter. That means that nearly the entire Valiant 11 class should not be counted for the quarterly report as of December, although they all continue to go to the Valiant 11 class for the 2nd hour until the end of the year.

Having said all that, not sure how the January numbers bug has anything to do with this.