Best practice forum (Archived)

Certification due date issue

I already sent a more detailed report of this problem to our partner, but I thought this might be interesting for others as well.

We have certain trainings that need to be retaken each year before the end of the year and I have created a certification for this.

The certification uses a dynamic audience to enroll users to the certification and I used the fixed expiry date option (fixed, 1 year validity, 5 months window, 5 months minimum active) in the certification. At first I set the "complete by"-date to 31/12/2014 for the audience to be able to have the last year's recurrent training in the system and for it to trigger the certification. This of course resulted in an exception, which was then dealt with so that the certification actually showed 31/12/14 as the due date.

After this, I triggered course completion for the last year's recurrent training, which was successful. What's interesting, now the certification shows a completion date of 24/08/2014 but the new due date is 31/12/2016. This means I will not be able to have course completion for this year's recurrent training as the window opens next year.

As this was not what was expected, I deleted the certification and created it again, this time with the due date of 31/12/2015 to be able to have this year's recurrent training in the system. This worked as expected, but now I will not be able to get course completion for the last year's recurrent trainings.

I also tried to import the certification details for people not yet certified. The CSV file had completion date of 24/08/14 and due date set to 31/12/15. This also produced a certification with a due date of 31/12/2016.

Is this how this is supposed to be working? Any ideas on how I could get an audit trail in the certification so that it would show both last year's and this years completion dates? The fixed due date of 31/12/YEAR would be ideal as the actual training also expires at the end of the year, but can be completed 5 months prior to expiry.

Running 2.7.6 (Build: 20150818.00)

Permalink | Reply

Hi Iiro.

The "fixed expiry date" calculations are working the way they were designed. The reason it sets the expiry date to 31/12/2016 rather than 31/12/2015 is because TODAY is less than 5 months away from 31/12/2015, so it extends it by a further active period.

But I've had a think over this whole scenario and the code and I think maybe we could make a change. I'm pretty sure that we should change the calculation to ensure that users are granted the minimum active period from the date of completion, rather than today's date. In your scenario, if users were given an expiry date of 31/12/2015 then their certification would have been active for 16 months, which is more than the minimum active period. For anyone completing their certification within Totara, the completion date should be the same as the current date (or very close), so the change should not affect those users.

When this change is made, if a completion date further in the past is provided in upload (and assuming no existing completion records for the user) then a user's window open date and/or expiry date may be calculated as having occurred in the past. In this case, the window opening and expiry events will occur the next time the relevant scheduled tasks are executed. For example, in your setup, it would calculate expiry date Dec 2015, the window would open when cron ran, and when the user manually completed inside Totara some time before Dec 2015 (or even up to July 2016), they would get a new expiry date of Dec 2016.

Until the change has been made available, there may be a simple solution. I think you can change the minimum active period (and window period will need to be changed as well) to less than the time between now and December 31 (maybe 105 days), then upload your completion data, then change the minimum active period (and window) back to 5 months. This should allow the function to set the expiry date to the end of this year, and those users' windows will open soon.

Nathan

Permalink | Show parent | Reply

Thanks Nathan,

this is how I imagined this to be. I agree that the date of completion should be the date used for calculations rather than the date of change (today).

I tested the workaround and got the due date of 31/12/15 and the window opens tomorrow. I will see tomorrow if I can get course completion for this year's training, which was actually already completed two weeks ago.

The same problem also occurs if there is a course where course completion requires a score. The completion date will be the date when the score was introduced to the system, rather than the date when for example the f2f session took place. To be able to have correct dates in the system I have had to leave the score out of completion criteria although there is a minimum score requirement in the actual real life training. This will look silly to the auditor, but correct dates are more important.

Kind regards,

Iiro

Permalink | Show parent | Reply

Hi Iiro.

I'm not sure about the score thing. Maybe the scores can be manually added after completion has been triggered? If you think that Totara should be able to cope with this situation in a more automatic way then I suggest you either post a feature request or a support ticket.

Nathan

Iiro

Permalink | Show parent | Reply

Hi Iiro.

I just came across this thread again while checking some things and I noticed something I missed the first time. When you do a certification completion upload, the "due date" field should be the date on which the user WAS due to complete their certification. Assuming an active period of 1 year recurring at the end/start of the year, and window of 3 months, if a user completed on 1 November 2014 then the due date in the CSV should be 31 December 2014. Totara then calculates the expiry date using the specified due date, adding one active period to it. This could also have resulted in the same behaviour you were observing. I think, to fix your situation, you need to check the due date you are providing, and also upgrade to 2.7.8 (when it comes out) which will contain the change that I discussed in my previous message (the change has already passed review and testing, so will definitely be included in 2.7.8). Hopefully there will also be a change in 2.7.8 to add some info about what the due date provided is supposed to contain.

Nathan

Permalink | Show parent | Reply