Omega Owners Forum
Chat Area => General Discussion Area => Topic started by: TheBoy on 17 June 2014, 20:57:52
-
...to drive over to my bro's and slap some of his staff with Sammy. Spent most of last night and tonight sorting out a cocked-up refund in his database.
Upon quizzing them how they managed to make such a mess (I write the code :-[ so have a natural interest in closing the hole they fell through), but they don't know what they did. Grrrrrr >:(
-
did you log the transactions in seperate tables.. with columns like time, user, action like insert update delete and other necessary fields..
but with this you can only reverse the action to a specific time point.. may be of some help to what they have done.. :-\
sql logs generally not helpful
-
Can you reprint the receipt, or view the transaction as the till would display it, rather than from the database side-if so, can you then recreate it?
This is normally what I end up doing to figure out the marvellous ways retail staff manage to screw things up, as trying to look at it logically within a database makes little sense as it lacks context.
-
Why would counter staff be expected to repeat a fault they didn't know was about to happen? If the fault occurred again, then they might look out for it, maybe.
That's a system testers job. Not the end users job.
Poor implementation. System fail. Don't blame the staff.
-
It's not an expectation of them to repeat the fault, more for them to tell you what they actually did so you can figure out where the fault is.
From experience, 99% of till issues are down to user error, the till only does what they've told it to, so figuring out what they told it is the first step.
Looking at transactions in a database makes this hard-you may have one table to hold user info, one for stock info, one for tender type and so on, or even one column that holds the summary of the whole sale that gets broken out by specific queries. Piecing all this together is much easier if you can replay the transaction.
I would expect that in most retail environments refunds are signed off by at least a supervisor, and I'd at least expect them to be able to tell me what they put through the till. Sadly this isn't always the case, and seems to be what's added to TB's issue.
It may well be a system issue, but without knowing what the till was told that's hard to determine.
Testing also involves recreating the initial fault if possible.
All this makes the huge assumption it's not a systems fail due to poor implementation as suggested though :D :P
-
Why would counter staff be expected to repeat a fault they didn't know was about to happen? If the fault occurred again, then they might look out for it, maybe.
That's a system testers job. Not the end users job.
Poor implementation. System fail. Don't blame the staff.
Chris, even on a small application database you may have 10 to 50 tables (different entities in computer language) in which there may be more than 30-40 to hundreds of different transactions that includes mutiple table updates, inserts , deletes.. As applications change as a function of time, the initial design considerations are mostly altered but the application itself is bound with lots of old data/relational parent or child tables .. Generally the problems occur after this new implementations are added as there will be minimal time for testing the unknown number of probabilities on a production database.. :-\
-
Poor implementation. System fail. Don't blame the staff.
Absolutely it appears to be a coding error, in that it allowed an operator to do something that caused problems. But some clue as to what was down might be helpful, so we I can fix the loophole.
-
I would expect that in most retail environments refunds are signed off by at least a supervisor, and I'd at least expect them to be able to tell me what they put through the till. Sadly this isn't always the case, and seems to be what's added to TB's issue.
That's the idea, but they all have been granted till supervisor permissions, with reporting metrics being used to identify any staff abusing it :-X
-
Why would counter staff be expected to repeat a fault they didn't know was about to happen? If the fault occurred again, then they might look out for it, maybe.
That's a system testers job. Not the end users job.
Poor implementation. System fail. Don't blame the staff.
Chris, even on a small application database you may have 10 to 50 tables (different entities in computer language) in which there may be more than 30-40 to hundreds of different transactions that includes mutiple table updates, inserts , deletes.. As applications change as a function of time, the initial design considerations are mostly altered but the application itself is bound with lots of old data/relational parent or child tables .. Generally the problems occur after this new implementations are added as there will be minimal time for testing the unknown number of probabilities on a production database.. :-\
I don't recall Bill Gates phoning me up asking what I did, every time his gay operating system crashed. Although clearly they installed logs via a back door later on. If he did, I'd tell him, I just looked at it and it had crashed. I don't know when it decided to crash, or what I did that might have caused it to crash. That's not my job, its yours! ::)
(It does also continually insist on blocking me using the machine, whilst updating, though. How many bloody updates per day is acceptable? )
Anyway, it's not a pc so I'll shut up now. ;D
-
(It does also continually insist on blocking me using the machine, whilst updating, though. How many bloody updates per day is acceptable? )
Your little netbook? A bit underpowered, so the updates (2nd Tues of the month) will hammer the poor thing a bit I'm afraid.
Anyway, it's not a pc so I'll shut up now. ;D
/Panto mode
Oh yes it is
-
(It does also continually insist on blocking me using the machine, whilst updating, though. How many bloody updates per day is acceptable? )
Your little netbook? A bit underpowered, so the updates (2nd Tues of the month) will hammer the poor thing a bit I'm afraid.
Anyway, it's not a pc so I'll shut up now. ;D
/Panto mode
Oh yes it is
No not just the netbook. Maybe I dont use pc's enough.
I love my little netbook though. :)
-
(It does also continually insist on blocking me using the machine, whilst updating, though. How many bloody updates per day is acceptable? )
Your little netbook? A bit underpowered, so the updates (2nd Tues of the month) will hammer the poor thing a bit I'm afraid.
Anyway, it's not a pc so I'll shut up now. ;D
/Panto mode
Oh yes it is
No not just the netbook. Maybe I dont use pc's enough.
I love my little netbook though. :)
MrsGixers PC should be more than man enough to install updates in the background :-\
-
As hard as we try to make things foolproof, unfortunately, the fools are winning. :-[ :o :o :o
-
Poor implementation. System fail. Don't blame the staff.
Absolutely it appears to be a coding error, in that it allowed an operator to do something that caused problems. But some clue as to what was down might be helpful, so we I can fix the loophole.
programmers dont make error , they use "different" logic ;D
other kind of problems are unexpected data field entries (values) which effect the conditional branching and order of ops.
-
As hard as we try to make things foolproof, unfortunately, the fools are winning. :-[ :o :o :o
As I have said many times, the pace of development is only beaten by the human races ability to produce a better idiot
-
As hard as we try to make things foolproof, unfortunately, the fools are winning. :-[ :o :o :o
As I have said many times, the pace of development is only beaten by the human races ability to produce a better idiot
;D ;D :y
-
Given the last few weeks I'm fairly sure they're increasing in number and gradually taking over :-\
-
As hard as we try to make things foolproof, unfortunately, the fools are winning. :-[ :o :o :o
As I have said many times, the pace of development is only beaten by the human races ability to produce a better idiot
;D ;D :y
A view of pure arrogance frankly. Accept that many a genuine situation arises that the manufacturer has not seen.
.....Or join the ranks of idiots ;D. (Like Nokia)
-
It would appear to be a fact though sadly, as technology advances and more is 'done for us' with little thought required, it becomes even more challenging to design/develop as people are less aware of surroundings and actions.
-
As hard as we try to make things foolproof, unfortunately, the fools are winning. :-[ :o :o :o
As I have said many times, the pace of development is only beaten by the human races ability to produce a better idiot
;D ;D :y
A view of pure arrogance frankly. Accept that many a genuine situation arises that the manufacturer has not seen.
.....Or join the ranks of idiots ;D . (Like Nokia)
nothing to do with arrogance imo.. its a fact.. a biologic thing limited by space and resources irreversibly breeds and then poisons the only space we have and then kills others for getting more space and resources.. even an "idiot" definition insufficient imo
-
So, back in the room then....
It would appear to be a fact though sadly, as technology advances and more is 'done for us' with little thought required, it becomes even more challenging to design/develop as people are less aware of surroundings and actions.
Equals budget. Penny wise, pound foolish etc etc....? I like a challenge personally. :-\
Arguably though, it seems to me? a situation that's a result of development. People always expect more. What can it do for me? Oh it does that. That's brilliant..... Can it do this....? Yes it can. Wow. Ok, what about this... No, it can't. :( and disappointment follows.
Or, oh it does all these things. Good. I can go off and do something else. I can trust it, while I'm more efficient elsewhere.....oh look. I've trusted it to do all these things and poxy thing has crashed. I don't expect to sit there and hold its hand in case the developer hasn't done his job.
If the product needs it hand holding, has it failed? Or does it need further development. Or...should the designer tell the user to hold its hand?
Most of us appreciate if a car develops a fault the surrounding circumstances can help diagnose that fault. Although "I was driving to the shops" often comes up ;D But we here are all mechanically minded, to a point. What about those that are not mechanically minded? I bet most of us are not particularly interested in how a till system works.
....unless of course, somebody is hiding something when using the till.
-
Most of us appreciate if a car develops a fault the surrounding circumstances can help diagnose that fault. Although "I was driving to the shops" often comes up ;D But we here are all mechanically minded, to a point. What about those that are not mechanically minded? I bet most of us are not particularly interested in how a till system works.
Any time something breaks, be it a car, washing machine, TV, boiler, human body, etc. the first question is "What were you doing when it went wrong?".
The first step in diagnosing anything is to gather all the information you can surrounding the problem. I would have thought this would have been firmly entrenched in peoples' common sense by now, since they get a much better outcome if they are able to supply this information than if they just shrug their shoulders.
Oh, silly me! Assuming common sense... :-[
-
Most of us appreciate if a car develops a fault the surrounding circumstances can help diagnose that fault. Although "I was driving to the shops" often comes up ;D But we here are all mechanically minded, to a point. What about those that are not mechanically minded? I bet most of us are not particularly interested in how a till system works.
Any time something breaks, be it a car, washing machine, TV, boiler, human body, etc. the first question is "What were you doing when it went wrong?".
The first step in diagnosing anything is to gather all the information you can surrounding the problem. I would have thought this would have been firmly entrenched in peoples' common sense by now, since they get a much better outcome if they are able to supply this information than if they just shrug their shoulders.
Oh, silly me! Assuming common sense... :-[
Common Sense (http://www.politicallyincorrect.me.uk/commonsensedeath.htm)
:( :(
-
Most of us appreciate if a car develops a fault the surrounding circumstances can help diagnose that fault. Although "I was driving to the shops" often comes up ;D But we here are all mechanically minded, to a point. What about those that are not mechanically minded? I bet most of us are not particularly interested in how a till system works.
Any time something breaks, be it a car, washing machine, TV, boiler, human body, etc. the first question is "What were you doing when it went wrong?".
The first step in diagnosing anything is to gather all the information you can surrounding the problem. I would have thought this would have been firmly entrenched in peoples' common sense by now, since they get a much better outcome if they are able to supply this information than if they just shrug their shoulders.
Oh, silly me! Assuming common sense... :-[
Common Sense (http://www.politicallyincorrect.me.uk/commonsensedeath.htm)
:( :(
So the answer in this case would be, along the lines of, serving customers.( the equivelant to driving to the shops. ) why would they care? They're retail staff. Not mechanically minded you see.
Not everyone's brain works the same. :)
-
A valid point-the right questions need to be asked to get the information needed for testing, not everyone will know what, or how to express, what the tester or programmer needs to know.
At the same time, if you went to a garage and said my car stopped working on the way to the shops it would be reasonable to tell them hiw fast you were going, maybe what gear you were in, was there oil, water, petrol in the car, did you hear any noises or so on. Normally you'd volunteer this info when telling them the car stopped working-to help them diagnose the fault.
Expecting the sales person to say I did x, y, and z and then this happened is no different.
The trouble is people roaming around oblivious to all except how long till there next break so they can check Facebook or the like.
-
I meant their break. The grammar nazi in me is appalled!
-
A valid point-the right questions need to be asked to get the information needed for testing, not everyone will know what, or how to express, what the tester or programmer needs to know.
At the same time, if you went to a garage and said my car stopped working on the way to the shops it would be reasonable to tell them hiw fast you were going, maybe what gear you were in, was there oil, water, petrol in the car, did you hear any noises or so on. Normally you'd volunteer this info when telling them the car stopped working-to help them diagnose the fault.
Expecting the sales person to say I did x, y, and z and then this happened is no different.
The trouble is people roaming around oblivious to all except how long till there next break so they can check Facebook or the like.
If I went to the garage yes.... If my Mum went to the garage, no.
Why are they are oblivious to all. Purely because they don't have the info needed...? It's the systems fault. Nobody else's.
Who put the system in place? Typical IT tech expecting everyone else to know what they know. Understand what they understand. They are counter staff. They deal will people. Not some half baked till system done on the cheap.
-
Equals budget. Penny wise, pound foolish etc etc....? I like a challenge personally. :-\
<snip>
If the product needs it hand holding, has it failed? Or does it need further development. Or...should the designer tell the user to hold its hand?
In this case, its not penny pinching or budget related, though see your point of view talking more generally :)
In this case, yes, the product failed. No piece of software out there, beyond the simplest program, is bug free. That's generally a well known fact, but you won't hear the marketers admit that ;D
However, as Kevin Wood says, the first part of finding the fault (or even accepting that one exists - in this case clearly one does) is to gather the evidence, and the eye witnesses are key. Surely they must have known what they were doing at the time... ...surely... :-\
-
Apparently not, in order to have broken it in the first place... :-\
-
Who put the system in place? Typical IT tech expecting everyone else to know what they know. Understand what they understand. They are counter staff. They deal will people. Not some half baked till system done on the cheap.
I put the system in, lock stock and barrel. The expectation is that the staff will not know why something goes wrong, but what they were doing when it went wrong. That's not an IT skill.
Flip it around, they sell (rather nice) watches amongst other things. If I bought one and it went wrong whilst I was doing something with it, its reasonable to expect that, whilst I wouldn't understand what had broken, I would know what I was doing when I broke it. IMHO anyway.
As for "on the cheap", cost isn't the factor here (within reason, including the industry standard (for his line of business) product at £16k per shop to buy, plus £700pm support contract). The reasons for me writing it is because nothing else as an integrated solution for stock control and performance reporting exists.
-
Take The SLady bitshorpe Incident, as an example... The issue wasn't my blind faith in the wordfilter but rather the immediate side effect of not being able to modify the post to correct the vocabulary.
Had I previewed the post, noone would be any the wiser, but I knew what I had typed and so pressed Post mollycoddled in the assumption that the word filter would do its thang ::)
Is it my fault that I typed it? Clearly.
Could I have reasonably expected the filter to pick it up? Yes.
Having just posted, could I have reasonably expected to be able to edit it? Yes.
With that in mind, with whom does the fault lie? Operator? Programmer? Both?
Working on the basis that both Operator and Programmer are Human, and therefore falible, the Programmer can only fix bugs as they arise, for example when the Opertator does summat unexpected, usually without thinking.
You're mission, should you wish to accept it, is to try and work out what, exactly, the Operator did to expose the glitch... Good luck :y
-
Who put the system in place? Typical IT tech expecting everyone else to know what they know. Understand what they understand. They are counter staff. They deal will people. Not some half baked till system done on the cheap.
I put the system in, lock stock and barrel. The expectation is that the staff will not know why something goes wrong, but what they were doing when it went wrong. That's not an IT skill.
Flip it around, they sell (rather nice) watches amongst other things. If I bought one and it went wrong whilst I was doing something with it, its reasonable to expect that, whilst I wouldn't understand what had broken, I would know what I was doing when I broke it. IMHO anyway.
As for "on the cheap", cost isn't the factor here (within reason, including the industry standard (for his line of business) product at £16k per shop to buy, plus £700pm support contract). The reasons for me writing it is because nothing else as an integrated solution for stock control and performance reporting exists.
Probably randomly pressing buttons, so they havent a clue what they did ::) ;D
Im sure you must see it when you food shopping for example, i know i have.
Item wont scan, so operator tries entering the barcode manually, till still wont have it....so calls supervisor over, supervisor tries and what looks like to me, randomly pressing buttons, gives up, puts the supervisor key in the till, whacks a few more buttons and item goes thro as 'misc item'. So, ok, im happy as im on my way, but if the supervisor keeps doing that....thats buggered the stock inventory up ::)
-
Who put the system in place? Typical IT tech expecting everyone else to know what they know. Understand what they understand. They are counter staff. They deal will people. Not some half baked till system done on the cheap.
I put the system in, lock stock and barrel. The expectation is that the staff will not know why something goes wrong, but what they were doing when it went wrong. That's not an IT skill.
Flip it around, they sell (rather nice) watches amongst other things. If I bought one and it went wrong whilst I was doing something with it, its reasonable to expect that, whilst I wouldn't understand what had broken, I would know what I was doing when I broke it. IMHO anyway.
As for "on the cheap", cost isn't the factor here (within reason, including the industry standard (for his line of business) product at £16k per shop to buy, plus £700pm support contract). The reasons for me writing it is because nothing else as an integrated solution for stock control and performance reporting exists.
there are, but the license fees are astronomical (6 digit in US$) and you always have to connect to a remote server.. ridiculous prices imo..
and when something goes wrong they send you a specialist who can interpret nothing >:(
-
The stock management side isn't normally the hard part to fulfil-it's getting a system that can report usefully that's the trick. Most decent management systems expect you to have 3rd party software to deal with the reporting, but the costs wrack up quickly-especially as you're only wanting to analyse on data you already have!
With access to the DB you can pull info out and report with your own queries-or dumping in to another DB you've built to run reports off-but if you're doing this then you'd do what TB has done and build the whole thing!!
I quite like clikview as a third party option though, free trial download If you ever fancy a play.
-
Saw this today and was reminded of this thread (esp. the "stupid user" part) ;)
(http://imgs.xkcd.com/comics/people_are_stupid.png)
;D