Because with the bigger item discription and price shown on the screen when every item is scanned it will be easy for a customer to see that price is same as stated on the item with the price on database.cwathen wrote:Umm, why exactly?
Customer Accounts Ver. 7.04x
Moderators:daleadmin, Dale Harris, Alan, Andrew
dwfwfgfwf
Re: Test version 7.04x
It would be insanely difficult to make two lots of text different sizes on the same screen in QBASIC/DOS, and hardly worth the effort. It's only possible to show the large total that appears at the end of a sale because Dale spent a lot of time writing code to draw those numbers manually, he'd have to repeat that work for every letter in the alphabet, and write code to position each letter appropriately etc.
Re: Test version 7.04x
It is just not possible. The big numbers are made on a 5 X 5 grid which is not good enough for all the letters so they would have to be even larger and you could not get 24 characters on one line of the screen. Plus you would have to remove a lot of the information currently on the screen to make room for it.
Much better solutions to allowing the customer to see the data is to more the screen closer to the customer, use a pole display like the Pertilian X2040 which costs less than $50, or the Big Pole program. Or one of those humongous monitors.
Dale
Much better solutions to allowing the customer to see the data is to more the screen closer to the customer, use a pole display like the Pertilian X2040 which costs less than $50, or the Big Pole program. Or one of those humongous monitors.
Dale
Re: Test version 7.04x
No news, still doing inventory.
Although I did take 5 minutes to fix a problem where at the end of the sale you pick a payment method and the program displays the amount due where you type in the amount the customer is paying. The problem only occurs if you are using multiple payment methods. This fix will be in the next release.
Dale
Although I did take 5 minutes to fix a problem where at the end of the sale you pick a payment method and the program displays the amount due where you type in the amount the customer is paying. The problem only occurs if you are using multiple payment methods. This fix will be in the next release.
Dale
Re: Test version 7.04x
Dear Dale,
I have been using the test version for about 3 weeks now, and everything seems to work fine. Only once the prog terminated in the middle of work, but I could not replicate the issue, so it seems to have been a glitch. Thanks for adjusting the program to store custom descriptions, I think this is a MAJOR improvement. Also the squished bug concerning the customer info in the void table is a great improvement.
Best regards from Austria,
I have been using the test version for about 3 weeks now, and everything seems to work fine. Only once the prog terminated in the middle of work, but I could not replicate the issue, so it seems to have been a glitch. Thanks for adjusting the program to store custom descriptions, I think this is a MAJOR improvement. Also the squished bug concerning the customer info in the void table is a great improvement.
Best regards from Austria,
- AussieAussie
- Forum Regular
- Posts:34
- Joined:Mon Apr 20, 2009 10:39 pm
- Location:Victoria, Australia
- Contact:
Re: Test version 7.04x
Working great here. Only problem I've had recently was my own fault, but it did however raise a question in my mind.
Is it possible to be able to add a feature whereby if you scan an item that is not in the stock table for some reason, it can be added there mid sale?
I know I can park the current sale and add it to the table then go back to the sale, but just thought it might be possible.....but then it might not.
Is it possible to be able to add a feature whereby if you scan an item that is not in the stock table for some reason, it can be added there mid sale?
I know I can park the current sale and add it to the table then go back to the sale, but just thought it might be possible.....but then it might not.
"...In Switzerland they had brotherly love - they had 500 years of democracy and peace, and what did that produce? The cuckoo clock."
Re: Test version 7.04x
AussieAussie,
Nope. The reason is that I want the store management to have a real incentive to add new merchandise to the stock table. This will prevent a clerk from adding the new item and giving it any price she wants. It will also allow the management to properly enter the other parameters for the item like tax rates, cost, model, etc.
Others disagree about this policy but I write the program so I win.![Smile :)](./images/smilies/icon_smile.gif)
Dale
Nope. The reason is that I want the store management to have a real incentive to add new merchandise to the stock table. This will prevent a clerk from adding the new item and giving it any price she wants. It will also allow the management to properly enter the other parameters for the item like tax rates, cost, model, etc.
Others disagree about this policy but I write the program so I win.
![Smile :)](./images/smilies/icon_smile.gif)
Dale
Re: Test version 7.04x
Well inventory is tomorrow so I will get back to working on the POS program on Thursday.
In chat tonight Jon and I picked up a little feature that we will be working on for a user. This will require that I do about 2% of it and Jon will have to do 98% of it so it will not delay my getting back to the Customer Accounts feature by more than an hour.
Actual CA progress updates will resume on Thursday.
Dale
In chat tonight Jon and I picked up a little feature that we will be working on for a user. This will require that I do about 2% of it and Jon will have to do 98% of it so it will not delay my getting back to the Customer Accounts feature by more than an hour.
Actual CA progress updates will resume on Thursday.
Dale
Re: Test version 7.04x
Dale,
Reading this topic makes me realize just how much work and planning goes into a new feature like this.
I for one, appreciates everything you do. A VERY BIG THANK YOU DALE!!
I am following the progress with much appreciation.
Some thoughts on the customer accounts feature:-
1. Agrees that the price and tax rates in effect at the time that the customer actually receives(buys) the merchandise should be what he pays in the end.
Maybe the legal interpretation of when goods are actually purchased differs internationally.
2. What about limiting the total amount and period for each customer or at least an option(for management) to block/stop an account?
Regards
ToPS
Reading this topic makes me realize just how much work and planning goes into a new feature like this.
I for one, appreciates everything you do. A VERY BIG THANK YOU DALE!!
I am following the progress with much appreciation.
Some thoughts on the customer accounts feature:-
1. Agrees that the price and tax rates in effect at the time that the customer actually receives(buys) the merchandise should be what he pays in the end.
Maybe the legal interpretation of when goods are actually purchased differs internationally.
2. What about limiting the total amount and period for each customer or at least an option(for management) to block/stop an account?
Regards
ToPS
Re: Test version 7.04x
Wow Dale. Seeing what you go through to add a new feature is amazing. Think its good for us to see how hard you work. Maybe will humble some of the more outrageous feature requests. lol Thanks for all your hard work!Looking forward to reading more updates.
-Wes :O)
- Dale Harris
- Forum Owner
- Posts:1171
- Joined:Sun Dec 28, 2003 10:19 pm
- Location:Chicago
- Contact:
Re: Test version 7.04x
You have probably been wondering where I have been with this customer accounts stuff.
I’ve been busy.
I had a week of vacation where I have done my best to kill myself by turning my garage into a workshop. I am nowhere near finished with this (I am still alive) and I will take another week’s vacation later to try to finish myself off (or finish the workshop, both options are good.) But since vacation is on “pause” I have worked on the manual for the customer accounts feature which is posted here http://www.dhpos.com/customer.pdf
This is a good thing because it nails down what the feature is going to do, how it will look to the user and how much I have screwed myself by taking on this project. Death by garage is looking better and better as an option.
I am posting the manual for customer accounts so that you can read it because you may have a different opinion on what this feature is supposed to do. Not that it will matter because I have all the votes on the subject. However I have occasionally been known to listen to the psychotic ramblings of users who disagree with me on the functions of this program. Who knows, you may convince me to do it your way although offers of large cash donations, can goods, or threats of violence on my person may help to make your suggestions, pleadings, or demands win the day.
Therefore the posted CA manual will probably change as either I change my mind or I bow to the will of others to be named later.
But bitch now. Once I have written the actual code to implement parts of this feature I am unlikely to dump that code just to make you happy.
Post your suggestions here so that they can be ridiculed by everyone else. That is what happens to me, join the fun.
I’ve been busy.
I had a week of vacation where I have done my best to kill myself by turning my garage into a workshop. I am nowhere near finished with this (I am still alive) and I will take another week’s vacation later to try to finish myself off (or finish the workshop, both options are good.) But since vacation is on “pause” I have worked on the manual for the customer accounts feature which is posted here http://www.dhpos.com/customer.pdf
This is a good thing because it nails down what the feature is going to do, how it will look to the user and how much I have screwed myself by taking on this project. Death by garage is looking better and better as an option.
I am posting the manual for customer accounts so that you can read it because you may have a different opinion on what this feature is supposed to do. Not that it will matter because I have all the votes on the subject. However I have occasionally been known to listen to the psychotic ramblings of users who disagree with me on the functions of this program. Who knows, you may convince me to do it your way although offers of large cash donations, can goods, or threats of violence on my person may help to make your suggestions, pleadings, or demands win the day.
Therefore the posted CA manual will probably change as either I change my mind or I bow to the will of others to be named later.
But bitch now. Once I have written the actual code to implement parts of this feature I am unlikely to dump that code just to make you happy.
Post your suggestions here so that they can be ridiculed by everyone else. That is what happens to me, join the fun.
Dale
- Dale Harris
- Forum Owner
- Posts:1171
- Joined:Sun Dec 28, 2003 10:19 pm
- Location:Chicago
- Contact:
Re: Test version 7.04x
Bummer.
After reading over the customer accounts instruction is has become apparent that there are enough differences between ringing up a regular sale and ringing up an account payment that I will not be able to use the POS.EXE program to ring up payments. There is not enough free code space in the POS.EXE program to be able to add the code to allow payments to be made in that program.
This means that I will have to add the “Purchase” code to the ACCOUNTS.EXE program with enough changes to the code to allow it to take payments only. Fortunately I will be able to copy most of the code for this from the POS.EXE program. In addition to making the payment sale the program will also have to be able to save the transaction into the .REC file and modify the invoices with the payment information.
However you folks will not see any of this. When you press the hot key from the regular purchase screen the ACCOUNTS.EXE program will load with a screen that will look exactly like the regular purchase screen only it will be loaded with a sale comprised of all that customer’s unpaid invoices (up to 60). Then when you complete the payment transaction, or void it out, you will be returned to the POS.EXE program either to the main menu or the next sale. You will not know that you have gone for a little trip to another program file.
You will also load the ACCOUNTS.EXE program from the “Customer info” feature of the POSCONFG.EXE program. But this time when it begins you will not be in a “payment” transaction but the program will open with the “1. Enter customer data”. 2. Manage accounts” menu.
So depending on if the POS.EXE program or the POSCONFG.EXE program calls the ACCOUNTS.EXE program the called program will act like two different programs. When you exit the ACCOUNTS.EXE program it will know which parent program opened it and return you to the correct parent.
Now it is time to write some actual code. First up will be work on the ACCOUNTS.EXE program so that it can modify the POS.EXE program to allow the “Account” payment method.
Next work on the POS.EXE program to actually make sales that accept the “Account” payment method. This also means that POS.EXE will save invoices to the invoice files.
After that work on the ACCOUNTS.EXE program to make payments.
This should keep me busy for a month to 6 weeks.
After reading over the customer accounts instruction is has become apparent that there are enough differences between ringing up a regular sale and ringing up an account payment that I will not be able to use the POS.EXE program to ring up payments. There is not enough free code space in the POS.EXE program to be able to add the code to allow payments to be made in that program.
This means that I will have to add the “Purchase” code to the ACCOUNTS.EXE program with enough changes to the code to allow it to take payments only. Fortunately I will be able to copy most of the code for this from the POS.EXE program. In addition to making the payment sale the program will also have to be able to save the transaction into the .REC file and modify the invoices with the payment information.
However you folks will not see any of this. When you press the hot key from the regular purchase screen the ACCOUNTS.EXE program will load with a screen that will look exactly like the regular purchase screen only it will be loaded with a sale comprised of all that customer’s unpaid invoices (up to 60). Then when you complete the payment transaction, or void it out, you will be returned to the POS.EXE program either to the main menu or the next sale. You will not know that you have gone for a little trip to another program file.
You will also load the ACCOUNTS.EXE program from the “Customer info” feature of the POSCONFG.EXE program. But this time when it begins you will not be in a “payment” transaction but the program will open with the “1. Enter customer data”. 2. Manage accounts” menu.
So depending on if the POS.EXE program or the POSCONFG.EXE program calls the ACCOUNTS.EXE program the called program will act like two different programs. When you exit the ACCOUNTS.EXE program it will know which parent program opened it and return you to the correct parent.
Now it is time to write some actual code. First up will be work on the ACCOUNTS.EXE program so that it can modify the POS.EXE program to allow the “Account” payment method.
Next work on the POS.EXE program to actually make sales that accept the “Account” payment method. This also means that POS.EXE will save invoices to the invoice files.
After that work on the ACCOUNTS.EXE program to make payments.
This should keep me busy for a month to 6 weeks.
Dale
Re: Test version 7.04x
Hi
dale
i think it's time for you to create new pos main screen becouse now dhpos have a lot of feature,
my suggestion is new dhpos main screen will look something like this ....
thank you
dale
i think it's time for you to create new pos main screen becouse now dhpos have a lot of feature,
my suggestion is new dhpos main screen will look something like this ....
thank you
- Attachments
-
- untitled.JPG (40.99 KiB) Viewed 109987 times
dwfwfgfwf
Re: Test version 7.04x
I would like to see a note feature for the customer invoice. Working in a college bookstore, the only people we let buy on accounts are faculty buying for departments. They always have a purchase authorization that must be on invoice for us to be paid. It is a different number each time they make a purchase so I could not store it any any current field. Also financial aid will let certain students get books free and must have their pa and student account and id on invoice to get paid.
Hope this would be one of the easier requests. Can always write it on there, but much easier to have stored for reprints, etc.
Thanks Dale! Looking forward to testing this for you.
Hope this would be one of the easier requests. Can always write it on there, but much easier to have stored for reprints, etc.
Thanks Dale! Looking forward to testing this for you.
-Wes :O)
- Dale Harris
- Forum Owner
- Posts:1171
- Joined:Sun Dec 28, 2003 10:19 pm
- Location:Chicago
- Contact:
Re: Test version 7.04x
Wes,
You can have a line in the stock table for authorizations..
Now the first thing you ring in the sale is stock number 999. Change the description to the authorization number and it will print in the receipt. I just hope your authorization numbers are 24 characters or less.
You can have a line in the stock table for authorizations..
Code: Select all
STOCK NUMBER DESCRIPTION PRICE
999 TYPE AUTH # HERE 0.00
Dale
Who is online
Users browsing this forum: No registered users and 269 guests