lobster
Member of DD Central
Posts: 636 
Likes: 467
|
Post by lobster on Apr 30, 2016 7:17:46 GMT
A slightly different funny: I just moved £100 from Cash Account to MLIA, which has succeeded. However, looking in the transaction log, it say £100 has gone into 30 Day account (7), even though it has actually gone into MLIA - I assume it really means QAA ... Dermot Very similar problem for me too. My MLIA statement has the following entry , timestamped at 17:11 on 29th April "Investment into 30 Day Access Account" £ -1,944.35 I'm not even sure what this is supposed to say, but I have certainly not invested in the new 30 day account, and I have checked that my balance in the 30 day account is zero. I like AC but have to say that this sort of thing happening repeatedly on a live platform causes me to lose confidence. There have clearly been a few glitches with the implementation of this new account. This sort of implementation simply has to be thoroughly checked out in a test environment prior to release. I know this takes time, and if this results in a delay for the new account to go live , then so be it. That's a helluva lot better than their clients starting to doubt the integrity of the platform.
|
|
|
|
Post by chris on Apr 30, 2016 7:30:02 GMT
A slightly different funny: I just moved £100 from Cash Account to MLIA, which has succeeded. However, looking in the transaction log, it say £100 has gone into 30 Day account (7), even though it has actually gone into MLIA - I assume it really means QAA ... Dermot Very similar problem for me too. My MLIA statement has the following entry , timestamped at 17:11 on 29th April "Investment into 30 Day Access Account" £ -1,944.35 I'm not even sure what this is supposed to say, but I have certainly not invested in the new 30 day account, and I have checked that my balance in the 30 day account is zero. I like AC but have to say that this sort of thing happening repeatedly on a live platform causes me to lose confidence. There have clearly been a few glitches with the implementation of this new account. This sort of implementation simply has to be thoroughly checked out in a test environment prior to release. I know this takes time, and if this results in a delay for the new account to go live , then so be it. That's a helluva lot better than their clients starting to doubt the integrity of the platform. Unfortunately you cannot perfectly replicate a live environment when you do your testing. We have a good approximation, but the go live script failed to deploy a couple of simple lookup functions on the live system and silently failed where it had worked perfectly on the development, staging, and mirror (clone of live) systems. I cannot run the test suite against the live site without involving real money, and as platforms aren't allowed to invest in their own loans I'm not allowed to do that unless I put my own cash into the system solely for testing purposes. These bugs are all identical in that they involve the virtual banking system looking up the name of the investment account to put into the textual description of the transaction. Using the old functions the 30 day account and the QAA clash in this lookup, so the database could return the name of either at random although in practice that randomness tends to return the most recently updated of the two records - in this case the 30 day account. There's a single line of code (replicated in 3 different functions) that needed to be changed to look up the correct account that hadn't deployed correctly to make sure it always matches the correct one of those two accounts. This has only ever affected the textual description of the transactions. I believe I have correctly deployed all the functions involved in this but again I cannot run a test suite to make sure. I'll keep an eye out on this thread for any more reports.
|
|
|
|
Post by chris on Apr 30, 2016 7:35:01 GMT
on my dashboard at least it is possible, click on "On Repayment" and the usual options box comes up just press deisred button. (I have about 50p in account, so maybe this doesn't show till you have funds) HTH Brian Thanks... I'd not put cash here yet as I thought I would try looking before leaping for a change! As brianac says there's a control at the bottom of each account that lets you choose how repayments are handled.
|
|
lobster
Member of DD Central
Posts: 636
Likes: 467
|
Post by lobster on Apr 30, 2016 7:54:56 GMT
Unfortunately you cannot perfectly replicate a live environment when you do your testing. We have a good approximation, but the go live script failed to deploy a couple of simple lookup functions on the live system and silently failed where it had worked perfectly on the development, staging, and mirror (clone of live) systems. I cannot run the test suite against the live site without involving real money, and as platforms aren't allowed to invest in their own loans I'm not allowed to do that unless I put my own cash into the system solely for testing purposes. These bugs are all identical in that they involve the virtual banking system looking up the name of the investment account to put into the textual description of the transaction. Using the old functions the 30 day account and the QAA clash in this lookup, so the database could return the name of either at random although in practice that randomness tends to return the most recently updated of the two records - in this case the 30 day account. There's a single line of code (replicated in 3 different functions) that needed to be changed to look up the correct account that hadn't deployed correctly to make sure it always matches the correct one of those two accounts. This has only ever affected the textual description of the transactions. I believe I have correctly deployed all the functions involved in this but again I cannot run a test suite to make sure. I'll keep an eye out on this thread for any more reports. OK Chris , thanks for this and reassuring to know that it's definitely just a "lookup issue" rather than the possibility of any actual funds being incorrectly handled. On a personal note I certainly wasn't expecting a reply from you at 08:30 on a Saturday morning !!? Seriosuly impressive - I have no idea how many hours per week you work, but it's not 37.5 , thats for sure !
|
|
|
|
Post by chris on Apr 30, 2016 8:00:22 GMT
On a personal note I certainly wasn't expecting a reply from you at 08:30 on a Saturday morning !!? Seriosuly impressive - I have no idea how many hours per week you work, but it's not 37.5 , thats for sure ! I'm sure stuartassetzcapital will take that into account when my salary is next reviewed 
|
|
dermot
Member of DD Central
Posts: 863
Likes: 517
|
Post by dermot on Apr 30, 2016 8:27:24 GMT
On a personal note I certainly wasn't expecting a reply from you at 08:30 on a Saturday morning !!? Seriosuly impressive - I have no idea how many hours per week you work, but it's not 37.5 , thats for sure ! I'm sure stuartassetzcapital will take that into account when my salary is next reviewed Fixed my log retrospectively, thanks. Have a quiet weekend off .... D
|
|
|
|
Post by stuartassetzcapital on Apr 30, 2016 9:24:38 GMT
On a personal note I certainly wasn't expecting a reply from you at 08:30 on a Saturday morning !!? Seriosuly impressive - I have no idea how many hours per week you work, but it's not 37.5 , thats for sure ! I'm sure stuartassetzcapital will take that into account when my salary is next reviewed I will ;-)
|
|
bigfoot12
Member of DD Central
Posts: 1,817
Likes: 816
|
Post by bigfoot12 on Apr 30, 2016 9:27:37 GMT
Unfortunately you cannot perfectly replicate a live environment when you do your testing. We have a good approximation, but the go live script failed to deploy a couple of simple lookup functions on the live system and silently failed where it had worked perfectly on the development, staging, and mirror (clone of live) systems. I cannot run the test suite against the live site without involving real money, and as platforms aren't allowed to invest in their own loans I'm not allowed to do that unless I put my own cash into the system solely for testing purposes. These bugs are all identical in that they involve the virtual banking system looking up the name of the investment account to put into the textual description of the transaction. Using the old functions the 30 day account and the QAA clash in this lookup, so the database could return the name of either at random although in practice that randomness tends to return the most recently updated of the two records - in this case the 30 day account. There's a single line of code (replicated in 3 different functions) that needed to be changed to look up the correct account that hadn't deployed correctly to make sure it always matches the correct one of those two accounts. This has only ever affected the textual description of the transactions. I believe I have correctly deployed all the functions involved in this but again I cannot run a test suite to make sure. I'll keep an eye out on this thread for any more reports. Another small error: the pie chart is showing me investing in the 30DAA, which I haven't. The 30DAA correctly shows zero.
|
|
|
|
Post by chris on Apr 30, 2016 9:30:09 GMT
Unfortunately you cannot perfectly replicate a live environment when you do your testing. We have a good approximation, but the go live script failed to deploy a couple of simple lookup functions on the live system and silently failed where it had worked perfectly on the development, staging, and mirror (clone of live) systems. I cannot run the test suite against the live site without involving real money, and as platforms aren't allowed to invest in their own loans I'm not allowed to do that unless I put my own cash into the system solely for testing purposes. These bugs are all identical in that they involve the virtual banking system looking up the name of the investment account to put into the textual description of the transaction. Using the old functions the 30 day account and the QAA clash in this lookup, so the database could return the name of either at random although in practice that randomness tends to return the most recently updated of the two records - in this case the 30 day account. There's a single line of code (replicated in 3 different functions) that needed to be changed to look up the correct account that hadn't deployed correctly to make sure it always matches the correct one of those two accounts. This has only ever affected the textual description of the transactions. I believe I have correctly deployed all the functions involved in this but again I cannot run a test suite to make sure. I'll keep an eye out on this thread for any more reports. Another small error: the pie chart is showing me investing in the 30DAA, which I haven't. The 30DAA correctly shows zero. Interesting... will have to get the guys to look into it on Tuesday.
|
|
bigfoot12
Member of DD Central
Posts: 1,817
Likes: 816
|
Post by bigfoot12 on Apr 30, 2016 9:38:46 GMT
Another small error: the pie chart is showing me investing in the 30DAA, which I haven't. The 30DAA correctly shows zero. Interesting... will have to get the guys to look into it on Tuesday. FYI it is exactly the same size as money being swept from MLIA. (Money being swept from cash account isn't included.)
|
|
|
|
Post by oldnick on Apr 30, 2016 14:31:07 GMT
Now I think I must step in here in chris 's defence stuartassetzcapital.Please don't cut his salary because of a coding error
|
|
|
|
Post by bluechip on May 1, 2016 18:14:47 GMT
Hi Chris - I have a simple idea which will help with the testing before you go live and potentially do less damage if a mistake occurs with the script etc (apologies in advance if already considered). I'm not techy at all, but why don't you ask for volunteers to be guinea pigs, a lot of us are investors via Seedrs so I assume would be more patient and willing for you to trial new accounts with our live accounts than Joe Public. Any errors such as the numerous ones above can be ironed out before you go live to the masses. Ultimately people worry if their money appears to vanish or doesn't appear where it should without explanation, so you can avoid all of this by having some free guinea pigs that have their eyes open and interests aligned to your own. The last thing you want is people losing confidence needlessly.
It will avoid any bad PR and will limit threads likes this becoming a problem solving thread rather than people taking about the benefits and merits of such an account. Just a week before you go live send 100 or so "volunteers" an email and let them move their money about and report problems so any issues are resolved before official launch. I'm assuming this is possible of course, but I am sure you can work on the idea so it can potentially make new launches smoother - use the investors you have to your benefit is my advice.
|
|
mikeb
Posts: 1,072
Likes: 472
|
Post by mikeb on May 1, 2016 18:56:54 GMT
bluechip about a year ago, maybe more, a beta testers group was set up to trial all this sort of stuff before it went live. A "special" extra forum was set up for it. Some strangely worded NDA agreements were sent out to members. And that's as far as it went. So good idea, already been had 
|
|
|
|
Post by bluechip on May 1, 2016 19:03:39 GMT
Thanks for letting me know Mike, I thought it may have seemed too obvious - clearly could have helped here.
|
|
|
|
Post by chris on May 1, 2016 19:19:46 GMT
bluechip about a year ago, maybe more, a beta testers group was set up to trial all this sort of stuff before it went live. A "special" extra forum was set up for it. Some strangely worded NDA agreements were sent out to members. And that's as far as it went. So good idea, already been had It's being resurrected. Last time I ended up not having enough capacity to organise it all myself. This time around we're going to have a special access area of this forum, similar to the pink pages, where we'll run a small invite only beta testing group. I'm on holiday from this coming Friday for two weeks but will start pulling this group together when I return.
|
|
