• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 211
  • Last Modified:

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.
0
header
Asked:
header
  • 2
  • 2
  • 2
  • +2
1 Solution
 
aeklundCommented:
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.
0
 
rkot2000Commented:
you can try to use triggers to enforce additional rules, such as kill transaction (rollback) if send date or some other flag is on
0
 
mcoopCommented:
I would consider a couple of alternatives...

first - keep a field whoch records who last modified the record along with the date... (I do this as a matter of course for all user modifiable tables.

or for more proof of changes, when a change is is being made, flag the original record as 'void' but keep it for auditing purposes (the voic flag stops it being reprocessed for billing etc), while a new copy is made and kept alive - whcih will contain the new modified data.

Then if an audit is required of the billing / transaction history, you can go back and recover those 'voided' records to show what happened at what time, and by whom.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
nutwissCommented:
"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.

0
 
nutwissCommented:
yup,

mcoops idea is a good one (his comment wasn't there when I submitted mine :)

implementing it shouldn't be much of problem

0
 
headerAuthor Commented:
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.
0
 
mcoopCommented:
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.
0
 
headerAuthor Commented:
Another great idea mcoop, thanks!
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 2
  • 2
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now