header
asked on
Opinion about Editing POS records
This isn't a technical question, rather one of opinion. I have just installed a POS system that acts as a billing system for a Golf Country Club. They are having trouble with needing to edit/delete the reciept records due to putting them under the wrong member, wrong item #, and a million other things. I want to give access to the office personel to be able to edit/delete records at will so the bills can be correct without having to make correcting entries all the time. I also do not want to sacrifice the integrity of the system. My question is how do I balance the two out and does anyone have any suggestions?
It's sort of a loose system so the records aren't marked as "Invoiced", if they were I would only allow them to change non-invoiced records. What worries me most is that someone could change a record that has already been sent as a bill to someone.
It's sort of a loose system so the records aren't marked as "Invoiced", if they were I would only allow them to change non-invoiced records. What worries me most is that someone could change a record that has already been sent as a bill to someone.
If the backed is a SQL or ORACLE database then you want to make sure you have primary keys and foreign keys to keep the data integrity. You might want to right triggers for cascading deletes and updates to keep the data inegrity as well. This way when you give access to the data on the front end, you shouldn't have to worry about data integrity.
you can try to use triggers to enforce additional rules, such as kill transaction (rollback) if send date or some other flag is on
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
"It's sort of a loose system so the records aren't marked as "Invoiced""
add an invoiced field ASAP.
and then check it (as you suggest) before allowing updates.
I don't know how your POS system works particularly, but in this country (UK) your system would need to be auditted regularly to ensure your system matches 'the books'.
Your concerns are justified, so it really would be in your long-term interest to add the functionality outlined.
add an invoiced field ASAP.
and then check it (as you suggest) before allowing updates.
I don't know how your POS system works particularly, but in this country (UK) your system would need to be auditted regularly to ensure your system matches 'the books'.
Your concerns are justified, so it really would be in your long-term interest to add the functionality outlined.
yup,
mcoops idea is a good one (his comment wasn't there when I submitted mine :)
implementing it shouldn't be much of problem
mcoops idea is a good one (his comment wasn't there when I submitted mine :)
implementing it shouldn't be much of problem
ASKER
mcoop, I think that is a great suggestion. It also provides documentation on why changes are being made to records and may identify trends. (If one person continually makes a certain type of error, it can be identified and corrected.)
nutwiss, I have wanted to add an 'Invoiced' field since the beginning (I wish I had) but it hasn't been much of an issue until now. It will be a good investment to add it now. This particular company was just audited a few years back and was hit with multiple fines for charging tax on things they should not and not charging tax on things they should be. (A little internal confusion and mis-communication) Their still recovering (financially) from those fines. So the more documentation, the better.
nutwiss, I have wanted to add an 'Invoiced' field since the beginning (I wish I had) but it hasn't been much of an issue until now. It will be a good investment to add it now. This particular company was just audited a few years back and was hit with multiple fines for charging tax on things they should not and not charging tax on things they should be. (A little internal confusion and mis-communication) Their still recovering (financially) from those fines. So the more documentation, the better.
another hint:
Make the invoiced field an integer - default zero
When an invoice is printed, increment the value - so you can tell when more than one invoice has ben sent for that item.
Alternately, add a table of invoices - with date (and username again). Link this to the items table one (invoice) to many (items)
This will allow you to re-create a previously issued invoice in the future, as well as picking an item then listing all the invoices it has appeared on.
Still keep the counter idea for the invoice link table - then you can see how many times a specific invoice (of multiple items) has been printed.
Make the invoiced field an integer - default zero
When an invoice is printed, increment the value - so you can tell when more than one invoice has ben sent for that item.
Alternately, add a table of invoices - with date (and username again). Link this to the items table one (invoice) to many (items)
This will allow you to re-create a previously issued invoice in the future, as well as picking an item then listing all the invoices it has appeared on.
Still keep the counter idea for the invoice link table - then you can see how many times a specific invoice (of multiple items) has been printed.
ASKER
Another great idea mcoop, thanks!