PDSAT 21A-216

Yeah, looks like 21.8.0.0 has got an update to 21A-216, but the logic as written at the top of the report doesn't seem to have changed (it looks like it's only bringing back programme aims now rather than all aims)?

Thanks Steve Hewitt 

Will take another look

You can always drop the PDSAT helpline an email if you're completely stuck. Are they kind of borderline learners? So year-long 278 OTJ?

We were confused as to why a couple of learners appeared and it turns out the calculation was (is?) counting weeks, based on the number of Sundays between start and planned end (despite this not being written down as a way to do the calculation anywhere)!!! (this is not an April Fool ;))

Hmm...I have always seen this as reference data report for sampling purposes, when I have some time on my hands (!), based on the numbers.  Have other providers many on this report, or just a small number? (our is approx 8% of live cohort).  

Um, no, these are very much to look at because the KPMG calculation thinks the Planned OTJ you've entered isn't sufficient for the duration of the programme and the intensity of the employment. According to them, this is what it does:

Regarding the details surrounding some of steps the report takes currently:

• For determining the minimum weekly employment hours, this is done using EII in the following way:
• When EII = 1, then minimum weekly employment hours = 16
• When EII = 2, then minimum weekly employment hours = 1
• When EII = 3, then minimum weekly employment hours = 16
• When EII = 4, then minimum weekly employment hours = 20
• When EII = 5, then minimum weekly employment hours = 1
• When EII = 6, then minimum weekly employment hours = 11
• When EII = 7, then minimum weekly employment hours = 21
• When EII = 8 and LearnStartDate >= 01/08/2020, then minimum weekly employment hours = 30
• When EII = 8 and LearnStartDate < 01/08/2020, then minimum weekly employment hours = 31
• Otherwise, minimum weekly employment hours = 0
• For determining the minimum total employment hours, this is done using the difference in weeks between LearnStartDate and LearnPlanEndDate, multiplied by (1 – 5.6/52), multiplied by the minimum weekly employment hours determined above. The (1 – 5.6/52) is the adjustment for annual leave.
• The minimum planned hours required is then 0.2 multiplied by the minimum total employment hours calculated above.

(so I asked if it's always looking for an integer because, eg 366 days at 30 hrs/wk comes out at 278.4) and got this extra tidbit)

Regarding the difference in weeks, I believe this will always be an integer and does not count partial weeks. I believe the way it is calculated is like a “DATEDIFF”, such that the number of weeks goes up by 1 each time you pass a Sunday.

Which, as I mention above is NOT USUAL or written down anywhere...

Thanks...I think! :)

Since the confusion in 2019, has it now categorically been confirmed that the 20% minimum relates to the actual hours if over, not 30 hours as a FTE benchmark?

hahaha, man, that 72 hours when it was the rule will HAUNT US FOREVER...

I can confirm that it's the learner's actual hours, not 30 ;)

Hi Both

Just a quick update... PDSAT confirmed the two changes as follows: 

1. Change to the derivation of the minimum weekly employment hours
2. Only return the ZPROG learning aims (previously the report returned all component aims within the programme, too)

We think it's point 1 affecting this learner i.e. previously on 30 hours, but now in the report this lists them as 31!

Steve Hewitt I am now in the process of interrogating this report.  You were kind enough to provide me with the alternative report logic used by the DSATs, but would you have a formula I can add into the DSAT to enable me to identify the planned hours that their own logic arrives at, as their alternative minimum please?

Sorry Ben, not had the need up to now, only had a couple of learners show up on it.

Steve Hewitt No worries...we'll make the corrections we think are right and know if we have met their magic figure by their glorious removal or stubborn remainder on the report :)

All I'd say is there is no canonical way to do the calculation, beyond what's on the model commitment statement (which definitely doesn't count Sundays!!!), so if you're happy with how you've done it (and you've checked the EIIs are correct etc) then I wouldn't change it just because they're on the PDSAT report. They are "Are You Sure?" reports after all...

Hi,

I have a number of learners who have appeared on (21A-216) on the same issue

All learners are down as 31+ hours (EII =8)

>01/08/2019 on ZPROG001 (Generic code to identify ILR programme aims): Aim level X

Please can you advise me on the best way to resolve this issue, so they don’t appear on the PDSAT?

Do I need to recalculate the hours with the formula on the above post? . Sorry still a bit confused.

thanks 

No, you need to understand why the (consistent) formula you have used has come up with a number that is less than the, frankly wacky, formula KPMG have decided to use.

There is NO REQUIREMENT to clear PDSAT reports.

Ok thanks for letting me know.

Ben,

Just for interest I use the following to compare the ILR calculated MinOTJ hrs to the ILR PHours:

MinOTJ: Int((Choose((DLookUp('ESMCode','EmploymentStatusMonitoring20','Id=' & DLast('Id','LearnerEmploymentStatus20',' LearnRefNumber=' & Chr(34) & [LearningDelivery20]![LearnRefNumber] & Chr(34) & ' And  EmpStat=10 And IsNull(EmpId)=False') & ' And ESMtype=' & Chr(34) & 'EII' & Chr(34))),0,0,16,20,0,11,21,31)*([Wks])-[Holl])*0.2)

Where:

Wks= DateDiff('w',[LearningDelivery20]![LearnStartDate],[LearningDelivery20]![LearnPlanEndDate])

Holl= ([Wks]/52)*Int((Choose((DLookUp('ESMCode','EmploymentStatusMonitoring20','Id=' & DLast('Id','LearnerEmploymentStatus20',' LearnRefNumber=' & Chr(34) & [LearningDelivery20]![LearnRefNumber] & Chr(34) & ' And  EmpStat=10 And IsNull(EmpId)=False') & ' And ESMtype=' & Chr(34) & 'EII' & Chr(34))),0,0,16,20,0,11,21,31))*5.6)

This normally matches with PDSAT