Just had the good fun of going through my OCC reports to make sure all the updates I made yesterday have gone through however the OLDC decided that the pfr it was going to create last night would use the ILR i uploaded on Monday at 8 pm instead of the ILR i uploaded yesterday (Tuesday) at 5:30 pm.
Has anyone else had this problem?
Tried to talk to the data service regarding this however their phone lines are busy.
ChrisFebruary 6, 2013 at 11:24 am #420
I uploaded mine yesterday afternoon and requested a PFR, which has returned, and is from yesterdays submission. However, when you log onto the OLDC website, there is a note to say there were problems with the PFR on Monday 4th, therefore this may be why yours has now only just appeared, instead of the one you requested yesterday?
Sorry I can’t be of any further help.
SandraFebruary 6, 2013 at 11:31 am #421
I uploaded a file at 5.50pm last night and the PFR has come back for the file I uploaded earlier in the afternoon not the most recent one.
Does anyone know if this will cause a problem with the mid year estimates as the PFR is not going to match the most recent file on the OLDC?
PaulineFebruary 6, 2013 at 11:39 am #422SFA STAFF
Hi All, I just had a chat with the Data Service who are aware of this problem and are working to resolve it. I’ll keep you posted on their progress. Cheers, GretaFebruary 6, 2013 at 11:50 am #423
In 2013-14 we will no longer request PFR’s, but they will be automatically generated afresh every time a new data submission is made. At least that is what I have been led to believe. Under such circumstances it would be disastrous if the PFR generation used the wrong file as presumably you will be unable to request a refreshed version to sort it out.
For those who are getting PFR’s with the wrong data, what happens if you request another one today? Will it use the correct file?
CasparFebruary 6, 2013 at 12:13 pm #424
I found this issue last week and reported it to the Data Service yesterday, who told me it was my fault for uploading an ILR after the 6pm cut off period! Admittedly, last week this was the case and when I requested a new PFR, on Monday, it did use the correct ILR. However, I uploaded an ILR at 5:45 on Monday, requested a PFR, checked on Tuesday and it had run on the previous ILR.
I did ask them to log it as an issue but was told I should upload my ILRs well in advance of the 6pm cut off and that was that basically!
Glad to see they are now recognising it is an issue and will resolve it (hopefully)! I uploaded my ILR yesterday afternoon at 2:30 and thankfully the PFR was generated using that ILR.
I fail to see the point in having a return date but having to make the return the day before in order to generate an accurate PFR, which if you upload it too close to the cut off point, you get a previous version anyway.
SarahFebruary 6, 2013 at 12:26 pm #425
I reported this to the Data Service at 8:30 this morning and they knew nothing about it. We had not uploaded a file mid month, yesterday 17:03 was our first submission, the PFR contains no January data, starts or completions. Yet the header details on the PFR sheets hold the correct file number. The LR OLDC report has the January data, all other reports show the correct file name, it is just the PFR has last months learners.February 6, 2013 at 12:41 pm #426
What assurances are we to be given that we will be paid for our actually delivery if this issue is not properly resolved before hard close?February 6, 2013 at 1:00 pm #427
Thanks for raising this with the data service.
I have just uploaded our last ILR so hopefully it will process and produce a PFR correctly this time.
ChrisFebruary 6, 2013 at 1:59 pm #428SFA STAFF
Hi Chris – and Everyone, I just received an update from the Data Service, who have asked me to post the following:
“The Data Service recognises there are some providers who made a request for a PFR on 05 February that did not run against their last file submitted. This was caused by exceptional volumes of ILR files being submitted late in the afternoon of 05 February, resulting in a queue that had not cleared at the time the nightly summarisation for the PFR runs. We apologise for the inconvenience caused. We continue to recommend that data is provided at the earliest opportunity to avoid the impact of queues at the end of each processing period.
Impacted providers should request a further PFR today which will show R07 figures against their final R06 submission.”
Cheers, GretaFebruary 6, 2013 at 2:07 pm #429
The problem is this isn’t just an issue which was happening yesterday. The system can’t seem to cope with providers submitting just before the cut off period of 6pm, regardless of when you submit your ILR return (i.e. just before a submission date or part way through a month).
If you have a cut off point of 6pm, the system needs to be able to cope with providers submitting up to that point and the PFR being produced against that particular return. Its no good saying you can submit up until 6pm, but the system won’t provide you with the correct PFR based on that return because it can’t cope with demand.
SarahFebruary 6, 2013 at 3:29 pm #430
Sarah has it right.
Surely the data service know how many providers will upload every month and should therefore have the capacity to deal with us uploading.
My PFR was created last night at 11.30. My ILR had been uploaded for six hours before that file was created so I do not understand why it had not been loaded.
ChrisFebruary 6, 2013 at 4:02 pm #431
I am not happy with this explanation, I agree wholeheartedly with Sarah and Chris; the system should be able to cope with all of the uploads, otherwise fix it so that it can. This is mid year reconciliation and crucial to providers contracts that everything is uploaded.
My biggest problem is that the PFR contains the submission file name at the top of the page, and that is the correct file. So how is it that the rest of the data on the sheet was run from a different file.
MartinFebruary 6, 2013 at 4:11 pm #432
I agree with Sarah, Chris and Martin.
The “system” MUST be able to cope and this will be particularly important in 2013/14 when everything is move to the new Cloud platform and PFR’s are generated automatically. Such an excuse will be totally unacceptable if this situation should exist then, just as it is not good enough today.
CasparFebruary 6, 2013 at 5:26 pm #433
Sorry but in this instance I feel I must defend the Data Service to a point, processing data does take time. Just think how long it takes to process, validate and produce reports from our data and then multiply this by the number of providers returning data.
We have all been advised of the limitations of the system and how we can ease the system by not leaving sending our returns until the last minute.
Follow the good practice guide by sending data early in the period so that issues can be resolved before the cut-off date and do not leave it to the last day to request a PFR unless it is really necessary to do so.
It works for me.
As a programmer I understand the amount of data processing need to produce the PFR reports, I have replicated this in my own system but it does take a considerable time to calculated and format a report on a PC for a small provider for anything larger than that I would need a mainframe.February 6, 2013 at 5:55 pm #434
Whilst I sympathise with Martin’s remarks about the difficulties with handling large volumes of data, I cannot accept this as any reason for releasing PFR’s that are inaccurate.
If an unforeseen error occurs then fair enough, provided it can be put right.
In 2013/14 PFR’s will be generated automatically and it is surely unacceptable for them to be wrong. If an unforeseen error is made then there must be a mechanism for putting it right. Just waiting until next month’s simply won’t be good enough, especially if payments are driven by the PFR. Doubtless those wrestling with these challenges will have to plan for such contingencies, but I believe it is important that they are highlighted in advance and the scale of the problem and unacceptability is made very plain.
Perhaps the solution will be having to wait 48 hours for the PFR, so as to be sure that all other data processing has occurred, but I am not sure that would be acceptable to end users.February 6, 2013 at 6:42 pm #435
You must be logged in to reply to this topic.