DHES

i was wondering if in the future the following things could be added:

1. Discounts - by customer
2. Discounts - based on a price structure, such as COST + 10%
3. a few more customizable? fields to the customer database. Of interest to me is a "family" field so you can group people together.
4. a "last modified" field in the stock table. We could use this to print only certain products' shelf stickers (pull info from table into word sticker template, etc)
5. for our business, an extra column in the stock table that is an integer would be beneficial. It would demarcate "section" within its fine line class (where is it in the store). This would again, allow us to modify or report based on areas of business.
6. whats the chance the inventory stock table number will increase over 13000?

thanks

if there could be more than 3 discounts, that would help too. thanks

VillageApothecary,

I wouldn't hold your breath on the changes to the stock table structure for that last date modified field. Any changes to the structure are particularly complicated and it already consumes a lot of memory.

As for more than 13,000 items - see this FAQ from Dale's site:

http://keyhut.com/faq.htm wrote:13,000 ITEM LIMIT
You may have noticed that it requires almost zero time to find any item in the stock table by the stock number. This is because all of the stock numbers are indexed and held in memory by the program. Unfortunatly there is limited memory in DOS software to do this. The theroretical maximum would be 16,384 items but since some memory must also be used for other purposes the program becomes unstable with more than 13,000 items.

The other consideration is that one of the reasons that this program is free is to help the small to medium business compete with the Wal-Marts of this world. With some exceptions once a retail business grows large enough to carry more than 13,000 different items then it is a Wal-Mart type large business and should be able to afford commercially produced POS software.

As for your other requests - these will need to be addressed by Dale as I do not know the technical implications of implementing them.

i am thinking i'm going to have to make an interface program... we deal with so many products i think that we need some more automation, especially with inventory update.

i'm thinking a upc scanner ability would be most useful, along with a database that can talk with yours. That way we can maintain just one and "sync" the other.

i dont agree with the walmart jive there, pos stuff is like 6k for pharmacy

Neal

VillageApothecary,

I would imagine a pharmacy and a few other businesses would have large stock tables. Regardless of that, unfortunately these limitations are imposed upon DHPOS by Windows not liking DOS programs to have too much access to memory etc.

As Dale mentioned, above 13,000 items - things start getting unstable which is as good a reason as any in my book - to limit the amount.

As for your interface idea - sounds good. File format information is located at http://keyhut.com/fformat.htm (including the stock table) note this code is in QBASIC format only and you would have to perform any conversion to your own programming language of choice.

i see the link to the file formats. how does one access the data inside the TBL file?

i know it has qbasic code at the link there. it seems that will print the contents to screen. what if i want to manipulate the table itself. sorry if i dont understand

That code will give access to the TBL file, printing to the screen can be substituted for outputting to a file etc.

However going back the other way, altering the data is a risky business and I suggest you chat to Dale about that through here - email or maybe via Chat, which he is scheduled to be at shortly http://www.dhpos.com/chat

does the receiving program allow you to scan items in?

I'm not 100% sure, I've not used it much. But I'm sure it probably would.

VillageApothecary,

Some interesting features you have here. Unfortunatly most of them would require a whole lot of time and code space to accomplish. That is not a bad thing if hoards of peasents were storming my humble abode clammoring for them, it is amazing how being at the pointy end of several pitchforks will focus one's attention on the topic at hand. But the difficult part for a person requesting a lot of time, effort, and code space is to come up with a fair sized hoard that also wants it.

The other consideration is that while I would be working on your stuff that I would not be working on other stuff that is "hoard" backed. Stuff like gift cards, X-charge, customer accounts, etc. There is just one of me contrary to popular opinion which I believe now thinks that I am at least a platoon.

So lets go through your features.

F1) Discounts - by customer.
A1) Interesting, I will stick it in the "think about it" pile.

F2) Discounts - based on a price structure, such as COST + 10%
A2) This has been discussed several times before. The problem is that there is no limit to the possible kinds of deals. Buy 2 of this and get a 3rd one half off. But this, get 10% off that. Buy this and this, get 1.00 off of this or that. How could I program every possible deal? How could the store owner sort through hundreds (thousands) of deals to pick the one he wants? and of course different merchandise would have different deals. Of course I could only do the deals that you want, that would not only cut down on the problems but would also lead to riots from the hoards that did not get the deals that they want. Best to do nothing.

F3) A few more customizable? fields to the customer database. Of interest to me is a "family" field so you can group people together.
A3) Not sure what you are looking for here. How would you group people together and why would you want to?

F4) A "last modified" field in the stock table. We could use this to print only certain products' shelf stickers (pull info from table into word sticker template, etc)
F5) For our business, an extra column in the stock table that is an integer would be beneficial. It would demarcate "section" within its fine line class (where is it in the store). This would again, allow us to modify or report based on areas of business.
A5,A6) Modifying the stock table is to be approached with fear and loathing. Since almost every part of every program file has something to do with the stock table making any changes in it would require changing huge parts of the program. This means not only making the changes in the part of the program you want but also all parts of the program that access the stock table that have nothing to do with what you want. You have to first find them all, then make the changes, then test the changes to make sure that the program still works. The last time I changed the stock table format it took two months just to change the format, not including the actual new stuff the program was supposed to do. For this one your hoard would need to be very large indeed.

F6) Whats the chance the inventory stock table number will increase over 13000?
A6) About as close to zero as possible. Or maybe. The program currently stores an index of stock numbers in memory. Finding any particular item by stock number then requires almost zero time. However in DOS you can only store only so much in memory and 13000 seems to be the practical limit.

However. A few months ago I suggested in the chat room to several users that it would be possible to store the index on the hard drive. Unlike the memory index this would require that the index be sorted and every time you made any changes to the items in the stock table it would have to be resorted when you exit the stock table. A resort could take considerable time depending on the size of the stock table and the speed of the computer, anywhere from a few minutes to many hours. Sorting reports would also take far, far longer.

The upside is that the stock table would be limited only to the storage capacity of the hard drive at 210 bytes per item. I gigabyte would hold a stock table of 4,761,904 lines.

Finding any particular item using a sorted index would not take any longer than it does now even with billions of lines. (A binary tree search is an amazing thing.) And since the format of the stock table would not be changed the coding would not be all that hard except for the reports feature which would be pretty nasty.

So I mentioned it in the chat room hoping to spur a discusion of it, especially the time verses size issue. The result was complete apathy. No one even commented on the fact that I had mentioned it even though I mentioned it several times. So screw it, I forgot it.

But I will give it it one more try. Tuesday, 6-20-06, 20:00:00 server time, in the chatroom, be there. http://www.home-nets.biz/chat/ You must bring your hoard.

F7) If there could be more than 3 discounts, that would help too. thanks
A7) Just use the discounts where you can type in the percentage. That will give you 99 possible discounts.

F8) I don't agree with the walmart jive there, pos stuff is like 6k for pharmacy.
A8) I agree with it and that is what counts.

F9) I see the link to the file formats. how does one access the data inside the TBL file? I know it has qbasic code at the link there. it seems that will print the contents to screen. What if i want to manipulate the table itself. sorry if i dont understand
A9) The code is a demo to show you how to write a program in QuickBASIC that will access the stock table. Once you can do that it is up to you to write a program that will do something else with the stock table besides print it.

F10) Does the receiving program allow you to scan items in?
A10) Yep, just remember that the item must be listed in the stock table before you can use the receiving program or inventory program to enter it.

i dont think that the cost + 10% falls in the special deals section as you stated.

Employee discounts would be cost +5% on everything in the store, physician discounts would be cost + 10% on anything they buy. Senior discounts is 10% off retail. It's just moving the equation around a bit, and changing the focus of the discount.

This is not a major POS program, i know. But, even to have limited support for those sale items (not stuff i want, for the record), would make your product even more powerful.

as for the stock table being stored to the hd... isnt that what every other program does? yeah it takes time, but most pc's could crunch thru a good size db rather quickly. if you were using a 486 it might take some time...!


i do believe you should add a feature to make BATCH changes in the stock table. you should be able to either scan a group or search and add a group, then make changes or export this list to another file so you can toy around with it.

thats all for now, have to go to the store

one more thing

i would LOVE an inventory reconciliation module. If i could go through the store, scan and enter inventory quantity and reconcile vs what is in the stock table, that would be GREAT

VillageApothecary,

Q1) I dont think that the cost + 10% falls in the special deals section as you stated. Employee discounts would be cost +5% on everything in the store, physician discounts would be cost + 10% on anything they buy. Senior discounts is 10% off retail. It's just moving the equation around a bit, and changing the focus of the discount.
A1) Sure it is.

Q2) This is not a major POS program, i know. But, even to have limited support for those sale items (not stuff i want, for the record), would make your product even more powerful.
A2) Define "major." It seems to be popular with quite a few people. And part of the pholosophy of the program is for it to do what most people want but not be so feature laden that a user would need a degree in accounting and computer science to figure out. I am trying to strike a balance here. Also I am lazy.

Q3) As for the stock table being stored to the hd... isnt that what every other program does? yeah it takes time, but most pc's could crunch thru a good size db rather quickly. if you were using a 486 it might take some time...!
A3) Of course the stock table is stored on the HD, it is the INDEX of the stock table that is currently stored in memory. In some parts of the program, notably the "Reports" feature, it may be required that the program find hundreds or thousands or stock items all at once. This means that you would want the time required to find each one of them to be as insignificant as possible. Particularly if you are doing this over a network of shared registers.

Q4) I do believe you should add a feature to make BATCH changes in the stock table. you should be able to either scan a group or search and add a group, then make changes or export this list to another file so you can toy around with it.
A4) When in the stock table press [F5], you can do some pretty interesting things there.

Q5) I would LOVE an inventory reconciliation module. If i could go through the store, scan and enter inventory quantity and reconcile vs what is in the stock table, that would be GREAT.
A5) You can use the "search" function in the stock table to look up any item and it's inventory quantity pretty quickly. You can also print out the inventory of all the items in your store which would be much easier to carry around the store than one of your registers.

ok. how should i take the cynicism?

VillageApothecary wrote:ok. how should i take the cynicism?

Any way you please, "the Dale" has spoken.