Date & Time Activated Discounts For Selected Items

[Eli]

DHPOS could really be a truly fantastic POS application if Inventory items could somehow be marked for discounting during certain days/times of the week after which prices can be reverted back to their former levels. Too, would it be asking too much if barcode printing were incorporated in its operation? LOL! As it is, DHPOS is some application! Integrating the features in my wish list could put a lot of commercial POS applications out of business. Perhaps, it is the friendliest application this side of DOS. In fact, it is friendlier than most Windows apps I've evaluated.

[Andrew]

What do you mean? DHPOS is already the best (perhaps only) truly FREE Point of Sale application.

Date/Time Dependant Discounts
The first feature you suggest, date/time dependant discounts is a great idea, however would take massive amounts of time and program space to implement. It is likely that this would require a re-write of the stock table (not a nice task) and the STOCK program written by Jonathan Simpson took care of this sort of thing.

STOCK didn't automatically apply discounts, but from memory it did allow you to reduce items and increase them easily and quickly. I am sure Jon will post more info here, but I think the program is still available at http://return.no-ip.org/downloads .

Barcode Printing
Go to http://crnc.notlong.com and read the latest article, that site is one of the best ways to keep up with the latest buzz. In short - APRINT may be able to help in this respect, but it will require graphics capable printers.

In the meantime, it is just as easy (IMHO) to install a free barcode font, open word and make your labels there.

DOS is still the king of POS applications.
I work at a national supermarket chain and the entire system is DOS based, although the tills are actually Windows 98SE systems - we never see Windows. The POS system itself is very indepth, supporting numerous tenders, customer accounts, stored sales, power failure recovery, coupon cards (one scan, certain products instantly discounted), supervisor keys, credit card authentication and more.

However, it pays to remember the humble language Dale's software is written in, good old QBASIC. This does impose some limitations on what features can make it in - but Dale chooses the best from his Think About it Pile.

I for one would much rather have a free POS system with numerous important features, than hundreds of small features I would hardly use.

[Eli]

No question that DHPOS is a very competent application as far as most POS systems go. However some businesses require certain unique features that are not needed by other businesses (hundreds of useless features as you put it). My 30 year experience in the retail industry starting with NCR in the 70's has taught me that these so called "useless features" are sometimes crucial for some retailers. I know of some retailers who go on sale at certain times of the day (i.e. 10-11 a.m. on Mondays just to drum up sales for their "slow" hours).
My point is, DHPOS is arguably the best free POS system you can find but it can even be better if other generic features that it clearly lacks were somehow added. For example, for it to be a truly heavyweight application, it needs fast scan options instead of having to confirm quantities after each scan. The split second it takes for the extra keystroke is a big deal to some heavy traffic retailers. I have seen this app evolve into what it is now and I've never evaluated it in terms of it being freeware but rather on how well it can stand up to other applications, freeware, shareware or otherwise!

[Guest]

DHPOS is a great application that can stand up against most commercial POS systems in the market and the fact that it is free should only make it more amazing! So stop apologizing for its limitations by saying that it is after all just freeware and therefore expected to have severe limitations. Allow the software to evolve. And the best way for it to evolve is to take into consideration constructive comments on what could make it a better application.

[Eli]

Right! I do not evaluate applications on the basis of their being free or not but rather on whether the application meets certain pre-requisites as determined by my clients' needs. Then and only then will price considerations be a factor. Wouldn't it be a pleasant surprise for my client to find out that the application determined to meet his needs is freeware. I know that the features I hope to see in DHPOS are remote possibilities at this point in time. But who can really say what features this app will have by the time version 8.x comes out?

[Andrew]

a)

so called "useless features" are sometimes crucial for some retailers

I emphasise "some retailers", if a feature is suggested and supported by numerous people, then it may make it into the program. However, if it only affects a small portion of the user base, then it is less likely to be written in.

Remember - this is not a sign of ignorance or pig-headedness, we want DHPOS to be the best software on the market, but are limited in how much memory we can access, what printers we can use etc because it is DOS based and coded in an older language.


b)

it needs fast scan options instead of having to confirm quantities after each scan

So you haven't used the "Scanner" option in POSCONFG to tell DHPOS if numbers are scanned, typed or to allow the program to decide?

With keyboard wedge scanners - there is no true way to determine if a number was scanned or typed - DHPOS uses a calculation based on how fast the characters were entered and how many numbers were entered.

Keyboard wedge scanners simulate typing on a keyboard, so unless you use the options available under "Scanner" in POSCONFG, DHPOS will just try and guess what entry method was used.

[Dale Harris]

Eli,

First the scanner thing. The reason that you have to press [ENTER] after scanning an item is that the scanner has not been programmed to use <RETURN> as its termination character. When properly programmed a scanner willl not only send the number that it reads from the barcode but also one additional character. The character that POS is looking for is ASCII-13 also known as [ENTER], <RETURN>, LF, or LF-CR. You must program your scanner to send this character by either using the software that came with the scanner or by scanning a special barcode that is in the scanner's manual.

I am going to add a feature to the program after I finish the network version that will allow you to put price changes on the hard disk or on a floppy disk. Then when you want to impliment the price changes all you have to do is to load the file, no other changes will be made to the stock table. The program will also save the current prices as a file. So save the prices, load the sale prices, then when the sale is over load the original prices. You can also use this for permanent price changes.

Dale

[Andrew]

Dale

Sounds cool, maybe someone else could write an app to load/unload these changes at specific times.

[Eli]

Dale,

What you intend to do will indeed help a lot. However I was thinking along more automated processes wherein these files you are referring to are loaded into the system based on time/date flags as configured by the sys ad.

I realize of course the limitations set by DOS but what the heck! You have here a really good application. Note that the word "free" is not even a factor in my giving it a high rating. But even the best can get better!

Besides, I don't believe you entered into this with "limitations" in mind or even thought of coming up with a winner...

Now that you have a winner, why not include data base migration capabilities as well. Who knows? You just might do all these in version 8.x. And all because it is there just waiting to be done.... LOL!

Eli

[Jonathan Simpson]

Andrew, I think it would be trivial to pull the code from Stock and make it able to automatically change prices, as Dale said. Doing it a specific time, however, would have to be done by POS, at least until POS-NET is released. At that point, a TSR or windows program would be able to make "live" changes at a specific time, although the results might be intersting if this happened during a sale.

I'll have to think about that...

As far as adding more advanced features, I have done literally dozens of hours of research into different ways to make more memory available for POS, increase the size of the stock table, and do numerous other things. At this time, I am working hard on a new version of aprint which may very well support barcode printing and perhaps even logos. However, some changes have to be made to POS itself, and there is a hard limit on how much room POS has. Dale can't fix that, and neither can I. At best, we find ways to make more stuff fit in less space.

Hopefully, this clears some things up.
Jonathan Simpson

[Dale Harris]

Eli,

Since I write in QuickBASIC every program that I write will eventually come up against limitations. You can only do so much in 640k.

While it would be very nice to have everything in the program to be automatic and self loading that would mean that not only would the POS program have to be able to load the file but it would also have to have the code written into it to constanly check to see if there was a file that needs to be loaded at this time.

Unfortunatly we have reached the point where I have to be very careful what I add to POS because there is VERY limited free space left in it. For example you would not want me to impliment automatic price file loading and then not have room to add "customer accounts"?

So I will make a deal with all the users out there. If you find it impossible to remember when to load price files into your register let me know and I will send you any Post-it notes that I have on my desk to help you remember.

[Eli]

Dale,

What I meant by fast scan option is exactly that! An option for fast scanning or an option to scan and enter quantities. This allows for more flexibility at the work station level. Please remember that the networked version could be subjected to multi-department or even multi-store configurations with varying scanning requirements. This simply means that scanning capability options have to remain at the workstation's discretion. In some cases, this capability even varies depending on the time of day for a given department. It would thus be impractical to solve a software consideration through the hardware. Just a thought...

Eli

[peewee3ie]

I think you have good ideas and stop asking Dale for features that you think that should be included. memory in dos is a big problem. I wrote programs and game for old commodore computers and then you were Limited to 64kb or 128kb. I do not meen to be rude as had and know Dale is fealing the strain from us.

[eli]

Tony,

I believe you don't know the man who started DHPOS... I don't know him either but I can understand the motivation in coming up with a competent application and offering it to the world for free. I do know that discussions such as this is enough motivation for him to keep improving his software. I believe he didn't write POS to avoid the "strain" as you put it. You are all putting limitations to this beautiful application.

From the very start, I've always agreed with DOS as the appropriate language for DHPOS. But if DOS is what prevents it from evolving into one of the better POS systems in the market, then perhaps I should change my opinion and go for a more powerful language. (Please note that I do not agree with nor endorse QBasic... I like DOS, not QBasic).

Lets get things straight! I like DHPOS for the simple reason that it offers at least 80% core functionality to the average POS user and the hardware requirements can be found in most storage cabinets. As Dale would probably put it, if you need more features & capability, don't look for it in a free application! But that was years ago when no one knew DHPOS could have the makings of a winner.

If you guys really feel that DHPOS is good enough and can live with its limitations, then I should just be thankful you had nothing to do with Linux!

Eli

[Andrew]

Eli,

Plain and simple, Dale already told you the limitations are not imposed by himself or any of us. They are imposed by the programming language and DOS. We can work around some of these limitations by creating addon applications (ie APRINT, Payroll, STOCK), but the fact is - suggestions need to prioritised.

While Dale would love to add everything we suggest, sometimes it's just not possible to fit it all in. I repeat, this is a language/DOS limitation!

As Dale mentioned, if he implemented auto price discounts and had to leave out the much looked forward to Customer Accounts feature, there would be a lot of people who would think that (a) should have been implemented, and lots of people who think (b) should have been implemented.

The tough job Dale has, is figuring out which feature will add the most value to the program and improve the use of the program for the most retailers.

e.g. if a poll is taken and 10% want feature (a) and 90% want feature (b), which is Dale to choose?

Forgive those who seem a bit guarded in approving of new features, but we have been here a while, talked to Dale (i.e. chatroom) and know he does his best to please everyone, but you must understand that wheter we like it or not, there are limitations to how much more can fit into DHPOS.

Unfortunatly we have reached the point where I have to be very careful what I add to POS because there is VERY limited free space left in it.