New in 2005
Moderators:daleadmin, Dale Harris, Alan, Andrew
- Dale Harris
- Forum Owner
- Posts:1171
- Joined:Sun Dec 28, 2003 10:19 pm
- Location:Chicago
- Contact:
Well it is now a new year. What do you all want most added to POS in 2005?
Please realize that over the next several posts (including yours) that far more features will be mentioned than I could possibly add in a year. This means that the usual winnowing rules will be in effect.
1. It has to be possible.
2. It has to be possible for me to do it.
3. The higher percentage of users that can use the feature will move the feature up the list.
4. The harder the feature is to create, or the longer it will take, or the size of the code it will use, will move to feature down the list.
5. It is seems really cool, or interesting, or a challenge to me then it gets moved up the list.
6. The decisions of the judges (who all happen to be me) are final.
7. Begging, pleading, whining, threats of violence, or the offer of large financal rewards will affect the judging.
8. Offers of large financal rewards are encouraged. I can be bought, don't be shy.
So what do you want? Vote early, vote often.
Please realize that over the next several posts (including yours) that far more features will be mentioned than I could possibly add in a year. This means that the usual winnowing rules will be in effect.
1. It has to be possible.
2. It has to be possible for me to do it.
3. The higher percentage of users that can use the feature will move the feature up the list.
4. The harder the feature is to create, or the longer it will take, or the size of the code it will use, will move to feature down the list.
5. It is seems really cool, or interesting, or a challenge to me then it gets moved up the list.
6. The decisions of the judges (who all happen to be me) are final.
7. Begging, pleading, whining, threats of violence, or the offer of large financal rewards will affect the judging.
8. Offers of large financal rewards are encouraged. I can be bought, don't be shy.
So what do you want? Vote early, vote often.
Dale
some stores don't like a lot of money in there till. so how about a "Pickup" feature. A manager can define the amount of cash the drawer can have, when that quote is reached, display a warning each time a sale is rung. the manager then defines the cut-off $ amount point in which he is to put in a password for each sale.until the pickup is put in the computer. you can also add in a "loans" feature. In case a cashier needs change, but no money to give for the change. You can keep track of what's going in/out of the till... I discussed this with Dale in chat, and he mentioned it was one of the uses of the Payout feature, but does not tell you that you have too much in the drawer.... Any suggestions for features?
Like the Idea
I like that Idea, but how it would it work??
An Idea is to have some sort of Accounting Menu within the Maintenance Menu. Maybe Like so...
Accounting Menu................
1. Loans
2. Pickups
3. Reports
if you choose Loan\Pickup a screen would pop up with an associate list and you can loan\pickup $$ to their till.
To manage Pickup options maybe something could be added into the Posconfig Menu to define pickup options. Alert & lockup amounts would have to be set. Say Alert Amount is set to 500.00, once 500.00 worth of cash sales has been collected in the till a popup message (PICKUP NEEDED SOON) would occur after the sale is completed.. This would keep doing this until A- A manager has collected $$ and picked it up, or B- Once the amount in the till reaches the Lockup Amount a new message would appear (PICKUP REQUIRED NOW). Each time you try to Start a new sale the (PICKUP REQUIRED NOW) message would pop up until $$ has been removed and entered under the Pickup Option Screen.
This sounds very advanced & complicated but it's an idea..
Tina
An Idea is to have some sort of Accounting Menu within the Maintenance Menu. Maybe Like so...
Accounting Menu................
1. Loans
2. Pickups
3. Reports
if you choose Loan\Pickup a screen would pop up with an associate list and you can loan\pickup $$ to their till.
To manage Pickup options maybe something could be added into the Posconfig Menu to define pickup options. Alert & lockup amounts would have to be set. Say Alert Amount is set to 500.00, once 500.00 worth of cash sales has been collected in the till a popup message (PICKUP NEEDED SOON) would occur after the sale is completed.. This would keep doing this until A- A manager has collected $$ and picked it up, or B- Once the amount in the till reaches the Lockup Amount a new message would appear (PICKUP REQUIRED NOW). Each time you try to Start a new sale the (PICKUP REQUIRED NOW) message would pop up until $$ has been removed and entered under the Pickup Option Screen.
This sounds very advanced & complicated but it's an idea..
Tina
Here's the scenario
Under POSCONFG.
Select option "Pickups"
- Select whether or not to use the feature
- Enter warning amount (Once this amount of cash is reached in the till for the register, a warning will say "Please do cash Pickup", then used must press OK or ENTER)
- Enter a compulse amount (Once this amount of cash is reached in the till for the register, a warning will say "Must do cash Pickup")
- Select an option whether a password is required for each following transaction after the compulse/lockout amount has been reached
- Enter a password to override the lockout of each transaction until the pickup has been put in (let's say in a menu option of the main menu of POS.EXE which is also security protected with the same password)
This would help prevent too much $$$ being in the register.
Pickups should also be able to be entered at the server/global folder so you can manage the money at multiple registers.
As for the loans, that's like putting money in the register when a cashier doesn't have any change, etc. When using the loan option, it adds money to your starting cash amount. So on the report, maybe it could look like something like this
....
STARTING CASH: $100.00
+ LOANS: $55.00
------------------------------
TOTAL STARTING CASH: $155.00
....
If you want to get really advanced maybe a feature that would allow a manager use the global folder to check the status of each register.
but this is entirely up to Dale to decide. I just thought it would be a good feature.
Under POSCONFG.
Select option "Pickups"
- Select whether or not to use the feature
- Enter warning amount (Once this amount of cash is reached in the till for the register, a warning will say "Please do cash Pickup", then used must press OK or ENTER)
- Enter a compulse amount (Once this amount of cash is reached in the till for the register, a warning will say "Must do cash Pickup")
- Select an option whether a password is required for each following transaction after the compulse/lockout amount has been reached
- Enter a password to override the lockout of each transaction until the pickup has been put in (let's say in a menu option of the main menu of POS.EXE which is also security protected with the same password)
This would help prevent too much $$$ being in the register.
Pickups should also be able to be entered at the server/global folder so you can manage the money at multiple registers.
As for the loans, that's like putting money in the register when a cashier doesn't have any change, etc. When using the loan option, it adds money to your starting cash amount. So on the report, maybe it could look like something like this
....
STARTING CASH: $100.00
+ LOANS: $55.00
------------------------------
TOTAL STARTING CASH: $155.00
....
If you want to get really advanced maybe a feature that would allow a manager use the global folder to check the status of each register.
but this is entirely up to Dale to decide. I just thought it would be a good feature.
R.J.
Website coming soon...
Website coming soon...
The pickup idea...
I really like this one, most POS systems have some form of system to account for this....but here's my 2¢ worth.
As far as a message of pickups needed/required...it's never a good idea to advertise that you've got alot of cash in the drawer. Most companies I've been involved with a till that has a high amount of cash is either flagged in the cash office, on that clerk's terminal, far away from the wandering eyes of the public, appears in code on the casher's screen, or just simply a random star will appear in one corner of the screen. The last two get's the clerks attention, yet avoiding the flasing "I've got a ton of money on hand", just incase you've got a less-than-best customer lurking around. As much as we may hate to admit it, times have changed, and you need to be cautious about letting too many people know how much cash is on hand....that just invites trouble.
First, is it even possible to get a till balance for just one terminal when running in network mode? If yes, then once the money is removed form that lane's accountablity, where then does that balance go? Another terminal, should we be able to say what terminal it goes to? Should it go to the "global" terminal? Does it just go into that magical accounting grey area of unsure till counts, and the closing manager then get stuck with locating any or all missing pickups later that day....or worse yet, the next day?
Second, if we're gonna do pickups, then why not be able to key loans in as well, same argument, where does this money come from? Does it get transfered from the global terminal to the one you're keying it into? Well if we're gonna have pickups and loans, why not be able to transfer it from one terminal to the next? Sure you could pick it up from one terminal, then loan it to the next....but why not just save a step?
We can argue that IBM and NCR both have this fully intergrated into their POS software, but we have to keep in mind their base programming is over 25 years old, they have an army of programmers, and that's what they do for a living. I'm not trying to downplay Dale's software, I think it's top notch, and well put together. Yet I think some of us have lost touch and have forgotten that Dale does have a full time job, a family, and a life away from writing software, and putting in every last qwim and quirk that someone wants.
If pickups get added in great...but that should really become a second, or third application, with the ability to fully account for money in/out and all around your place of buisness. POS afterall is short for Point Of Sale, not Point Of Everything. The POS software should be focused on ringing up, and recording your transactions, maybe someone else can create a Accounting program, to work directly with Dale's POS system. That way you can have cash counts broken down by terminal, account for pickups, loans made to the registers, the cash you have in your office, what you deposit out, what you bring in as a change draft, record non-sales transactions such as depoists/returns on deposits, money orders, money wire, postage stamps, notary fees, returned check fees, and the list goes on.
Here's a thought that we've used many a time when the POS system we used to use would go "offline" <where the terminals stopped talking to the controler>. Stop by your local office supply store, and pickup a "guest check" book. You know, those funny things that the server jots down your order on when you dine out? Well you can get ones that have carbon copies, have lines, areas for descriptions, price, etc.... Just write on the first line "cash" then how much is involved in the transaction, "checks/cheques" and how much in involved, etc...etc.... Down at the bottom write the total, and then write PICKUP or LOAN across the bottom, circle it if the mood strikes you. You sign it, the cashier signs it. Give him/her a copy, you take the other one back to the office. When you go to count that till, you'll have those showing what you should have above/below the total that POS gives you. And later you can match them up, with what you have in the office to double check them. They've even got serial numbers, just to make certain you've got exactly the same copy of the orig.
In closing, adding pickups would just open another can of worms in the "request" department. Pickups really should be left to accounting, not POS, and if someone feels so brave...maybe we can see a Cash Office compainion for DHPOS flicker into existance. In all of it's simplicity, accounting can get very complicated, very quickly.
Oh yeah, and happy 2005 to everyone! ...and Dale, fantastic job you've done, I hope this year is great to you. I'm sure we'll see many wonderous and helpfull advancements to DHPOS, and maybe you'll finally be able to take a vacation without us. =o)
As far as a message of pickups needed/required...it's never a good idea to advertise that you've got alot of cash in the drawer. Most companies I've been involved with a till that has a high amount of cash is either flagged in the cash office, on that clerk's terminal, far away from the wandering eyes of the public, appears in code on the casher's screen, or just simply a random star will appear in one corner of the screen. The last two get's the clerks attention, yet avoiding the flasing "I've got a ton of money on hand", just incase you've got a less-than-best customer lurking around. As much as we may hate to admit it, times have changed, and you need to be cautious about letting too many people know how much cash is on hand....that just invites trouble.
First, is it even possible to get a till balance for just one terminal when running in network mode? If yes, then once the money is removed form that lane's accountablity, where then does that balance go? Another terminal, should we be able to say what terminal it goes to? Should it go to the "global" terminal? Does it just go into that magical accounting grey area of unsure till counts, and the closing manager then get stuck with locating any or all missing pickups later that day....or worse yet, the next day?
Second, if we're gonna do pickups, then why not be able to key loans in as well, same argument, where does this money come from? Does it get transfered from the global terminal to the one you're keying it into? Well if we're gonna have pickups and loans, why not be able to transfer it from one terminal to the next? Sure you could pick it up from one terminal, then loan it to the next....but why not just save a step?
We can argue that IBM and NCR both have this fully intergrated into their POS software, but we have to keep in mind their base programming is over 25 years old, they have an army of programmers, and that's what they do for a living. I'm not trying to downplay Dale's software, I think it's top notch, and well put together. Yet I think some of us have lost touch and have forgotten that Dale does have a full time job, a family, and a life away from writing software, and putting in every last qwim and quirk that someone wants.
If pickups get added in great...but that should really become a second, or third application, with the ability to fully account for money in/out and all around your place of buisness. POS afterall is short for Point Of Sale, not Point Of Everything. The POS software should be focused on ringing up, and recording your transactions, maybe someone else can create a Accounting program, to work directly with Dale's POS system. That way you can have cash counts broken down by terminal, account for pickups, loans made to the registers, the cash you have in your office, what you deposit out, what you bring in as a change draft, record non-sales transactions such as depoists/returns on deposits, money orders, money wire, postage stamps, notary fees, returned check fees, and the list goes on.
Here's a thought that we've used many a time when the POS system we used to use would go "offline" <where the terminals stopped talking to the controler>. Stop by your local office supply store, and pickup a "guest check" book. You know, those funny things that the server jots down your order on when you dine out? Well you can get ones that have carbon copies, have lines, areas for descriptions, price, etc.... Just write on the first line "cash" then how much is involved in the transaction, "checks/cheques" and how much in involved, etc...etc.... Down at the bottom write the total, and then write PICKUP or LOAN across the bottom, circle it if the mood strikes you. You sign it, the cashier signs it. Give him/her a copy, you take the other one back to the office. When you go to count that till, you'll have those showing what you should have above/below the total that POS gives you. And later you can match them up, with what you have in the office to double check them. They've even got serial numbers, just to make certain you've got exactly the same copy of the orig.
In closing, adding pickups would just open another can of worms in the "request" department. Pickups really should be left to accounting, not POS, and if someone feels so brave...maybe we can see a Cash Office compainion for DHPOS flicker into existance. In all of it's simplicity, accounting can get very complicated, very quickly.
Oh yeah, and happy 2005 to everyone! ...and Dale, fantastic job you've done, I hope this year is great to you. I'm sure we'll see many wonderous and helpfull advancements to DHPOS, and maybe you'll finally be able to take a vacation without us. =o)
- Dale Harris
- Forum Owner
- Posts:1171
- Joined:Sun Dec 28, 2003 10:19 pm
- Location:Chicago
- Contact:
Stuff
The method I use to tell when there is too much money in the cash drawer is to notice when I can not get it to close any more because of all the money stuffed into it. Actually this is not usually a problem because I sell keys for a living and rarely have more than $400 in sales on any day.
On the other hand I can tell when it is about time for a cash drop just by looking into the drawer. My employees also have this ability because I try to hire people above the level of trained monkeys. It is not that hard, really.
The POS program already has a method of accounting for cash drops. Use the "Payout" feature to make a payout to the cash room. Put the payout receipt into the cash drawer to turn in at the end of the day and write the transaction number on the cash drop envelope so the cash room can match up the payout receipts with the envelopes at then end of the day.
Even when used on a network the "Cash in reg." value only applies to the local register/cash drawer. Payouts are not included in the "Cash in reg." amount and the total for payouts is listed on the closing receipt. So payouts should work extremely well for cash drops.
The program does not account for "loans" frankly because during the 35 years I have been running a register I have never needed to get a loan and never thought of it. Maybe I will add it sometime in the future. But until then you can just add any "loans" to the amount of the "Opening cash fund" (which can be accessed from the "close" screen then press [ESC] to go back) and this will keep the "Cash in reg." amount correct to balance the drawer at the end of the day.
If the network goes down remember that the computer that has the global folder on its hard drive will still be able to ring sales. That is why it is important to have the global computer also set up and used as a register. If the network goes down you will still have one functional register until you get the network back up. Of course if a psycotic customer attacks the register with the global folder with a baseball bat then that could lead to real problems.
While it is true that I do have a full-time job and family (also full time) the theory that I have an actually real life beyond that and POS is questionable. At least I have not seen any evidence of a real life lately.
Vacation usually means lots of time to work on POS. There is an alternative?
On the other hand I can tell when it is about time for a cash drop just by looking into the drawer. My employees also have this ability because I try to hire people above the level of trained monkeys. It is not that hard, really.
The POS program already has a method of accounting for cash drops. Use the "Payout" feature to make a payout to the cash room. Put the payout receipt into the cash drawer to turn in at the end of the day and write the transaction number on the cash drop envelope so the cash room can match up the payout receipts with the envelopes at then end of the day.
Even when used on a network the "Cash in reg." value only applies to the local register/cash drawer. Payouts are not included in the "Cash in reg." amount and the total for payouts is listed on the closing receipt. So payouts should work extremely well for cash drops.
The program does not account for "loans" frankly because during the 35 years I have been running a register I have never needed to get a loan and never thought of it. Maybe I will add it sometime in the future. But until then you can just add any "loans" to the amount of the "Opening cash fund" (which can be accessed from the "close" screen then press [ESC] to go back) and this will keep the "Cash in reg." amount correct to balance the drawer at the end of the day.
If the network goes down remember that the computer that has the global folder on its hard drive will still be able to ring sales. That is why it is important to have the global computer also set up and used as a register. If the network goes down you will still have one functional register until you get the network back up. Of course if a psycotic customer attacks the register with the global folder with a baseball bat then that could lead to real problems.
While it is true that I do have a full-time job and family (also full time) the theory that I have an actually real life beyond that and POS is questionable. At least I have not seen any evidence of a real life lately.
Vacation usually means lots of time to work on POS. There is an alternative?
Dale
Print Report for Specific Stock Number
How about adding the feature to print report for spesific stock number.
For example :
I want to print the sale report for Key chains that have the stock number
from 101001 to 101015
- Or -
I want to print the sale report for the items that have stock number
from 101001 to 204020
-Kian-
For example :
I want to print the sale report for Key chains that have the stock number
from 101001 to 101015
- Or -
I want to print the sale report for the items that have stock number
from 101001 to 204020
-Kian-
- ChrisKraus
- Forum Regular
- Posts:351
- Joined:Wed Dec 31, 2003 11:10 am
- Location:Dedham, MA - U.S.A.
Re: Stuff
<HR>Dale Harris wrote:The method I use to tell when there is too much money in the cash drawer is to notice when I can not get it to close any more because of all the money stuffed into it. Actually this is not usually a problem because I sell keys for a living and rarely have more than $400 in sales on any day.
On the other hand I can tell when it is about time for a cash drop just by looking into the drawer. My employees also have this ability because I try to hire people above the level of trained monkeys. It is not that hard, really.
Thats Not A Bad Idea.
Chris
- Chris
Christopher Kraus
Christopher Kraus
Something I would find useful is to do a return on the same screen as a sale.
Often, I have a customer that wants to exchange something. At the moment I have to do a return and then a sale. If they want to change for something more expensive I have to fudge it a bit.
If I could put a quantity of -1 in the screen it would be very helpful.
Tamsyn
Often, I have a customer that wants to exchange something. At the moment I have to do a return and then a sale. If they want to change for something more expensive I have to fudge it a bit.
If I could put a quantity of -1 in the screen it would be very helpful.
Tamsyn
Something people might find useful is to have "index" numbers that refer to multiple stock numbers.
For example:
In a hamburger restaurant, menu X might be: 1 soft-drink (stock number a) + 1 chicken burger (stock.no. b) + 2 i-dont-know-whats (stock no c)
If you could combine these items in one "index" number, you could just key in (for example) /15 (index number 15, where the / tells POS that the number that follows is not a stock number but index number, just as * does for vendor SN, and 15 is the index ID in this example, just as a stock number is an ID for a stock table item).
That way you can easily sell 'common combinations' of articles while still able to track the inventory of seperate items correctly.
An index would contain an index ID and several stock item lines, and each stock item line could contain: stock number (of course), quantity and price (this way you can use a different price for the article if it is bought as a part of a set (example 1: normal price for a phone headset is $25, but if bought in combination with the telephone, you get the headset for $15 (where phone+headset would be an index item containing 1xPhone à normal price and 1xHeadset à special price:$15); example 2: you can buy a pen for $.50; but if you buy a box of 20 pieces, you pay only $8 (index containing: 20xpen à special price of $.4)). The option to use the normal stock table price should also be present (for example by setting the price in the index to zero).
I know it sounds difficult, but I hope you understand what I mean.
Just a suggestion.
J Mous
For example:
In a hamburger restaurant, menu X might be: 1 soft-drink (stock number a) + 1 chicken burger (stock.no. b) + 2 i-dont-know-whats (stock no c)
If you could combine these items in one "index" number, you could just key in (for example) /15 (index number 15, where the / tells POS that the number that follows is not a stock number but index number, just as * does for vendor SN, and 15 is the index ID in this example, just as a stock number is an ID for a stock table item).
That way you can easily sell 'common combinations' of articles while still able to track the inventory of seperate items correctly.
An index would contain an index ID and several stock item lines, and each stock item line could contain: stock number (of course), quantity and price (this way you can use a different price for the article if it is bought as a part of a set (example 1: normal price for a phone headset is $25, but if bought in combination with the telephone, you get the headset for $15 (where phone+headset would be an index item containing 1xPhone à normal price and 1xHeadset à special price:$15); example 2: you can buy a pen for $.50; but if you buy a box of 20 pieces, you pay only $8 (index containing: 20xpen à special price of $.4)). The option to use the normal stock table price should also be present (for example by setting the price in the index to zero).
I know it sounds difficult, but I hope you understand what I mean.
Just a suggestion.
J Mous
New POS idea for 2005
Dale,
I would like to see a gift receipt. The receipt wouldn't really have to show everything that was purchased, as long as the receipt number was shown, allowing you to go back through the receipts to verify what the product is.
or
If someone asked for a gift receipt and all I had to do was go in and reprint the receipt, but, press a certain button and the totals would be shaded or deleted from being printed.
I would like to see a gift receipt. The receipt wouldn't really have to show everything that was purchased, as long as the receipt number was shown, allowing you to go back through the receipts to verify what the product is.
or
If someone asked for a gift receipt and all I had to do was go in and reprint the receipt, but, press a certain button and the totals would be shaded or deleted from being printed.
qty pricing
i know qty pricing is at the bottom of the list , but if u could just add qty pricing for just 3 & 6 items, not buy 1 get 2 free , buy 2 free get 1 other , or all that complicated stuff , i know i would (and many others would really appreciate it )
idea for journal
I think it would be nice to have the program keep track, in the journal, of who enters the reports menu and what they print inside it as well as who closes or views the closing screen. This way I can keep track of if people are getting too cerious.
-Nick
-Nick
I think this is an excellent idea. you could do it and then change the price to a lower price. and have packaged prices for a lot parts.... ex.. a computer system. that would usually ring up more expensive if each part is rang up, instead of a package price. and keep inventory correct. I love the idea. come on Dale. You need to intergrade this one.JF Mous wrote:Something people might find useful is to have "index" numbers that refer to multiple stock numbers.
For example:
In a hamburger restaurant, menu X might be: 1 soft-drink (stock number a) + 1 chicken burger (stock.no. b) + 2 i-dont-know-whats (stock no c)
If you could combine these items in one "index" number, you could just key in (for example) /15 (index number 15, where the / tells POS that the number that follows is not a stock number but index number, just as * does for vendor SN, and 15 is the index ID in this example, just as a stock number is an ID for a stock table item).
That way you can easily sell 'common combinations' of articles while still able to track the inventory of seperate items correctly.
An index would contain an index ID and several stock item lines, and each stock item line could contain: stock number (of course), quantity and price (this way you can use a different price for the article if it is bought as a part of a set (example 1: normal price for a phone headset is $25, but if bought in combination with the telephone, you get the headset for $15 (where phone+headset would be an index item containing 1xPhone à normal price and 1xHeadset à special price:$15); example 2: you can buy a pen for $.50; but if you buy a box of 20 pieces, you pay only $8 (index containing: 20xpen à special price of $.4)). The option to use the normal stock table price should also be present (for example by setting the price in the index to zero).
I know it sounds difficult, but I hope you understand what I mean.
Just a suggestion.
J Mous
What about a feature on a network so you could have an administrator terminal that would be used to see who was on what terminal when and what for. And the system would allow the administrator to check who was doing what and see if there were any inconsistences on the list - e.g. someone logged onto two different terminals at the same time or someone running fake transactions and taking all the money out of the cash register...
From your "subs.bas" program it looks like this would be quite complicated but, I don't really know because I use visual basic and don't really know QuickBasic.
From your "subs.bas" program it looks like this would be quite complicated but, I don't really know because I use visual basic and don't really know QuickBasic.
Who is online
Users browsing this forum: No registered users and 13 guests