As promised elsewhere I said I would put an update today (although a bit later than I initially indicated, fell asleep after my shift on the maintenance last night).
Apologies in advance, might be a bit of a long one.
So first off, Kevins 5 questions
| Quote from: Townman |
1. Zero value tokens on essential products - fix in progress, release forecast Jan 2014
2. Database token values are wrong
3. Token values displayed on the referral page do not reflect those in the data base
4. The product of token values and number of payments in some circumstances do not match the displayed total payment value
5. Month to month total referral value changes by inexplicable amounts
|
1) Correct - Still planning on January, but as mentioned previously. Hopefully before christmas.
2) Yup - These will be the next things to be addressed after the zero value. Nothing difficult, just a tedious task going through and checking them all. I'd say this should probably be done in January as well. As it's a simple fix I might switch to being the developer on those and get somebody else to test.
3) Yes - Assuming you mean this page -
http://www.plus.net/support/tools/referrals/referrals_discount_info.shtml . Currently waiting on our business analysts to confirm what they should all show and something I'm pestering them about daily. Once we have the values it's something that
needs to will be fixed ASAP as we can't have incorrect info on the site.
4 & 5) Hopefully once the database values are cleaned up this will fix itself. If not we will be able to see clearer what is causing it. At the moment there are that many things going on it's difficult to isolate the cause. Don't have an ETA on this, there will be a period of monitoring after the token values are all fixed to see what happens.
| Quote from: Townman |
I think you would agree that the issues surrounding referrals is a bigger monster than has been previously perceived and proberly needs some additional tasks scheduling as you hinted previously.
|
Yes, definitely! The most likely ones to need additional tasks raising will be 4 & 5 mentioned above.
| Quote from: I |
I would have a guess that the 0.00 value for the current unlimited plan is only showing on referrals that were done after the (very sneaky change by PN) value change from 75 to 50p?
|
| Quote from: David |
Morning Scott/Mike,
This was the unlimited broadband and the lady who took it out is still on the same package, as I set it up for her, and help her with her computer fairly regularly. She hasn't changed from her original package, I appreciate if she does it would drop to 50p.
Phil in support applied a credit to my account, the ticket ref is #72853538 as the value for this was always 0.0p instead of 75p.
I'd be a bit miffed if it wasn't reapplied at 75p once the referrals problem is sorted as this error was at PN's end.
Mike, the 0.0p value of one of my referrals was a 75p one, this is why I imagine it will be reinstated at 50p once they fix the problem.
The line moved over to PN on the 21/6/13 and unlimited broadband was still paying 75p at this time.
Cheers,
David
|
Lumping these two together as they are both related to the 50p & 75p values for unlimited. This is something I've been having a hunt around and I can't find any documentation internally that refers to us having a change of values from 75p to 50p. The only documentation I can find relates to unlimited being a 75p referral. That isn't to say there wasn't a change, I just can't find any evidence of us doing it intentionally.
I've queried this with the business analysts and I'm awaiting a reply on what the value should be and what it should say on the website (as per number 3 above). It's something I keep chasing daily as it's the main thing currently blocking our work on referrals. My gut feeling is that somebody has updated the referrals page and copy and pasted a wrong value in and it should say 75p, all the information so far seems to support that theory. Just need confirmation from the BAs.
As I side note, if it was meant to be 75p all along and never changed (despite what the site says), it makes our clean-up a bit easier as we don't have to deal with token values changing before/after a certain date. Which brings us nicely on to....
| Quote from: Townman |
Scott,
From a business point of view, the above presents an interesting case for your clean-up testing. Will the payment correction scripts detect and adjust for manual correction credits (as noted here by David) or will PN (understandably) consider the cost of doing so to be more than the benefit (to PN), with the consequential bonus to users like David of them getting a double-bubble benefit out of the protracted rectification? Cheesy Grin
Cheers,
Kevin
|
I wondered how long before somebody would pick up on this! This is a discussion that has been going on for a while with myself and the developer.
In all honesty, it looks like there won't be a way of us sorting out who has had a manual refund by CSC and who hasn't. There isn't anything to say that it was specifically a refund done for unpaid referrals. The only thing we could go off would be looking for accounts affected by the token issue and have a manual refund in the past X months that is a multiple of 75p.
If that brought back a reasonable number (for arguments sake, lets say 10), we would be able to go through them manually so there wasn't a double-bubble benefit. If it brought back an unreasonable number (again, for arguments sake, lets say 1000) we would need to figure out a way that we could automate the process.
Realistically, it's probably going to be a double-bubble benefit. It will probably be cheaper to do that than it would cost in development to make sure people weren't credited twice. We just need to get a rough indication of how many are affected by that and get the appropriate people to give it the OK.
Finally, anything that I've missed off or not made clear?
