hi dale,
bug testing update.
If you use the Z value with networking, it doesn't show up anything on the 'back room' register.
All the regular registers show up their individual Z values.
On that thought, I thought of another of another inspired idea.
If we can have Z value to calculate total sales, could their be possible to have other Z values?
I like the idea of:
Z Transactions
Z Taxes
Z Items
Z Returns
Z Payouts
Z No Sales
This idea would be accessible from some menu function only available for only the global computer.
Any suggestions, what do you think?
barry.
'Z' value
Moderators:daleadmin, Dale Harris, Alan, Andrew
Barry,
The backroom register or server, doesn't make sales so it doesn't store a Z value - the purpose of a Z value is to track total funds passed through that register which is why it works this way.
The storage of permanent values such as # trans etc would consume a lot of space after a while - and if you retain your closing receipts and enter these somewhere such as a spreadsheet, this would provide a solution.
If I were using DHPOS in a real business, I would be entering the summary data from each closing receipt onto a spreadsheet or database each night - this way you have a quick and easy reference.
You could then also record the amount of cash etc in tills and perform quick calculations in the spreadsheet to perform balancing etc.
The backroom register or server, doesn't make sales so it doesn't store a Z value - the purpose of a Z value is to track total funds passed through that register which is why it works this way.
The storage of permanent values such as # trans etc would consume a lot of space after a while - and if you retain your closing receipts and enter these somewhere such as a spreadsheet, this would provide a solution.
If I were using DHPOS in a real business, I would be entering the summary data from each closing receipt onto a spreadsheet or database each night - this way you have a quick and easy reference.
You could then also record the amount of cash etc in tills and perform quick calculations in the spreadsheet to perform balancing etc.
DHPOS Veteran (from v3.46, July 2002)
-
ChrisKraus
- Forum Regular
- Posts:351
- Joined:Wed Dec 31, 2003 11:10 am
- Location:Dedham, MA - U.S.A.
-
Dale Harris
- Forum Owner
- Posts:1171
- Joined:Sun Dec 28, 2003 10:19 pm
- Location:Chicago
- Contact:
"Z" reading, the concept.
Shopping malls do not want to be cheated and do not want to do anymore work than neccessary.
When you first open your store the mall representative will take a "Z" reading on your register, this reading will be stored by the mall. Since most malls base their rent on monthly sales the mall rep will come back in a month and take the "Z" reading again. Subtract last month's "Z" from this month's "Z" and they have the month's sales from your store. Since there is no way to reset or change the "Z" reading (other than by sales, returns or void transactions) the mall does not have to look at your journals or check transaction numbers or worry that you have done something "cute" to hide any sales you may have had. If you rang up all of your sales then the difference between "Z" readings will be your sales for the month.
Since the mall does not care what your taxes, transactions, or anything else comes to there is no point in keeping track of them.
The reason it works like an odometer is that even on a computer it will be difficult for the sales to increase forever. Eventually the numbers will become too large to be stored in a simple variable. On the POS program the number is very large, it will probably be your great, great, grand children who will see the counter roll over, but it will happen eventually. So the mall needs to know that if last month's "Z" was 999999994351.52 and this month's "Z" is 000000001452.28 then your sales for the month were then 7100.76.
Another weird thing that can happen is that on your first day you could have had a sale of 21.63 but you screwed up the customer's merchandise and had to pay him 50.00 for it. Your "Z" reading then would be 999999999970.64. Weird huh?
When you first open your store the mall representative will take a "Z" reading on your register, this reading will be stored by the mall. Since most malls base their rent on monthly sales the mall rep will come back in a month and take the "Z" reading again. Subtract last month's "Z" from this month's "Z" and they have the month's sales from your store. Since there is no way to reset or change the "Z" reading (other than by sales, returns or void transactions) the mall does not have to look at your journals or check transaction numbers or worry that you have done something "cute" to hide any sales you may have had. If you rang up all of your sales then the difference between "Z" readings will be your sales for the month.
Since the mall does not care what your taxes, transactions, or anything else comes to there is no point in keeping track of them.
The reason it works like an odometer is that even on a computer it will be difficult for the sales to increase forever. Eventually the numbers will become too large to be stored in a simple variable. On the POS program the number is very large, it will probably be your great, great, grand children who will see the counter roll over, but it will happen eventually. So the mall needs to know that if last month's "Z" was 999999994351.52 and this month's "Z" is 000000001452.28 then your sales for the month were then 7100.76.
Another weird thing that can happen is that on your first day you could have had a sale of 21.63 but you screwed up the customer's merchandise and had to pay him 50.00 for it. Your "Z" reading then would be 999999999970.64. Weird huh?
Dale
Chris
A Z reading is a standard feature on most electronic cash registers and POS software. As Dale explains above - it's a way of maintaining a non-resettable record of the register's activity.
Just like an odometer is a way of maintaining a (supposedly but not always) non-resettable record of a cars mileage.
A Z reading is a standard feature on most electronic cash registers and POS software. As Dale explains above - it's a way of maintaining a non-resettable record of the register's activity.
Just like an odometer is a way of maintaining a (supposedly but not always) non-resettable record of a cars mileage.
DHPOS Veteran (from v3.46, July 2002)
-
ChrisKraus
- Forum Regular
- Posts:351
- Joined:Wed Dec 31, 2003 11:10 am
- Location:Dedham, MA - U.S.A.
-
Dale Harris
- Forum Owner
- Posts:1171
- Joined:Sun Dec 28, 2003 10:19 pm
- Location:Chicago
- Contact:
A long time ago in a galaxy right here...
In my youth (i.e., a long time ago) I had to ring up sales on old mechanical NCR cash registers that were made even before I was born. (A REALLY long time ago.) They would have keys, either push-button keys or actual keys, that you used to take either an "X" reading that could be reset or a "Z" reading that could not.
The register also had other letter keys for each employee. For example one employee would have to press the "A" key before ringing his sales and another employee would have to press the "B" before ringing his sales.
Elsewhere on the register there would be counters for each employee's sales labeled "A", "B", "C", etc. or the sales for each employee would be printed on the closing receipt labeled with each letter. All the registers I used had 5 to 10 employee letter keys but there were registers with many more.
Since you would not want to use the the same letters for the "total" keys as the "employee" keys, and you wanted to use the same letters on different registers for the "total" keys no matter how many employee keys were on a particular register the easiest solution was just to use two letters at the end of the alphabet for the two "total" keys. Since "X" and "Z" are more exotic than "Y" they used "X" for the resettable total key and "Z" for the unresettable "total" key.
Then of course if you pressed the "Z" key to get the unresettable total it was called the "Z" reading.
Yep the old mechanical or electro-mechanical registers would do many things that modern POS systems would do. Plus if the electricity went out that would be no problem for the mechnical registers and for the electro-mechanical registers you would just get out a big crank and spin the gears with arm power. Your store stayed open. Now with PC powered POS systems if the power goes out the term "totally screwed" seems to apply.
Ain't history fun?
The register also had other letter keys for each employee. For example one employee would have to press the "A" key before ringing his sales and another employee would have to press the "B" before ringing his sales.
Elsewhere on the register there would be counters for each employee's sales labeled "A", "B", "C", etc. or the sales for each employee would be printed on the closing receipt labeled with each letter. All the registers I used had 5 to 10 employee letter keys but there were registers with many more.
Since you would not want to use the the same letters for the "total" keys as the "employee" keys, and you wanted to use the same letters on different registers for the "total" keys no matter how many employee keys were on a particular register the easiest solution was just to use two letters at the end of the alphabet for the two "total" keys. Since "X" and "Z" are more exotic than "Y" they used "X" for the resettable total key and "Z" for the unresettable "total" key.
Then of course if you pressed the "Z" key to get the unresettable total it was called the "Z" reading.
Yep the old mechanical or electro-mechanical registers would do many things that modern POS systems would do. Plus if the electricity went out that would be no problem for the mechnical registers and for the electro-mechanical registers you would just get out a big crank and spin the gears with arm power. Your store stayed open. Now with PC powered POS systems if the power goes out the term "totally screwed" seems to apply.
Ain't history fun?
Dale
Dale,
At the supermarket I worked at - each checkout was powered by a UPS in event of a power failure. If after a few minutes power was not restored - the entire store would be automatically switched to the generator and the UPS recharged.
To furthermore ensure the store remained running - if the network or checkout server went down - each register had a copy of the stock table which was refreshed at a set interval (I'm not sure how often, perhaps hourly).
They would run in an offline mode until the server came back up when they would get a new copy of the stock table and push their offline sales back onto the server.
PS: I think a basic offline mode would be awesome for networked DHPOS, probably not too difficult either... hint hint
At the supermarket I worked at - each checkout was powered by a UPS in event of a power failure. If after a few minutes power was not restored - the entire store would be automatically switched to the generator and the UPS recharged.
To furthermore ensure the store remained running - if the network or checkout server went down - each register had a copy of the stock table which was refreshed at a set interval (I'm not sure how often, perhaps hourly).
They would run in an offline mode until the server came back up when they would get a new copy of the stock table and push their offline sales back onto the server.
PS: I think a basic offline mode would be awesome for networked DHPOS, probably not too difficult either... hint hint
DHPOS Veteran (from v3.46, July 2002)
Who is online
Users browsing this forum: No registered users and 24 guests