Replies
No one has replied to this post.
I agree, it would be good if they would change the validation. In the short term, we have a method where we non-ILR individual aims (it's just a tick box per enrolment in our MI system). We record a "why" for every aim not in the ILR anyway, and we have one reason called "Temporary non-ILR - Needs to be fixed". Every month, we check those to see if we can/need to re-include them for the next return.
I could do but the danger of defaults is that it can lead to complacency. It's difficult to tell the actuals from the defaults whereas I know who to chase up when it's blank.
Don't be too impressed though, we're not 100% complete at the start. Learners fill in their objectives at the start when they do their ILP. It then has to be inputted so it is usually a week or so after the start when the data is in the system. Same for the outcomes, if I'm honest. I'd rather there was a 30-day grace period for both to give us chance to get the stuff back from the community venues and inputted.
My R04 had nearly 300 missing Purposes and 100 missing Outcomes which meant the ILR had loads of invalid learners. Yes, we recognise there is some work to do in some areas to minimise the delay between the enrolment starting/stopping and the Purpose/Outcome going on but in many cases it just isn't possible. Plus there were loads that haven't actually started yet.
I think it would be useful to have warnings for those that start in the future, Purpose to error 30 days after the start date and Outcome to error 30 days after the end date.
I did suggest (verbally) that the Outcome field should have a delay to the error at one of the recent Technical User Groups, but it was a bit "AOB" rather than a formal request, so we'll have to see...
(also, I wish we'd been smart enough to say "Outcome should only be for courses over 9 hours", doing it for super short tasters is the worst...)
Right, I guess that answers that....
"We cannot change the validation on Tailored learning to introduce a time delay as this would be a costly development change. Although tailored learning requires a purpose code to be recorded at the beginning of learning, these codes can be updated later if the purpose changes. The TLout code should be added when the learner has completed or withdrawn from the planned learning activities, as this should be known when closing the aim."
There are so many jobs that would be more efficient to run centrally, but we all spend many hours doing separately. Also, if the problem is a result of them not having thought this through or consulted properly, that's just tough? It wouldn't have been costly if they'd set it up sensibly in the first place.
I'm reluctant to default the source data because we'd then not know the difference between defaults and actual learner responses. However, I can amend the ILR without affecting the source just for the purpose of getting it valid for the return. It's an extra step in my ILR processing but hey-ho.
Simon France
Tailored Learning Purpose - Future starts causing errors
Created
Hi all,
At the moment, the ILR error LearnDelFAMType_126 is triggering for all Tailored Learning aims that do not have a TL Purpose entered. I think this should be amended so that it only triggers for learning aims that have started.
The error is triggering for learning aims that start in the future. However, we collect the Purpose from the learner when we set their objectives in their ILP once the course has started. We do not collect it when the enrolment is initially created. I think it would be better if it was a Warning if it starts in the future and then an Error once the aim has started. It isn't something we necessarily know before the class has started.
What do others think?