Cash Register... Might find this interesting

[nakiboy]

I don't think those guys make our software. I once found a small mention of Foodstuffs (the company) on the same page as POSware but I can't seem to find the link anymore.

[Jonathan Simpson]

Well, other stuff being added right now, apparently, includes the ability to transmit pricing and sales data via TCP/IP or possibly Dial up. The idea is that sales, customer info, and product stock levels could be transmitted to a home office in shops with more than 1 store. Personally, I like the idea of sending sales back to the stores, so they can be started without manually editing the stock table. Another possible new feature is "reciept designer", which would allow users to build an reciept interactively (I'm using VBDOS for this, because of it's drag n drop interface works well.) This would tie in with aprint.

Other ongoing projects include me trying to find a way to decrease the memory required for searching the stock table, by finding a fast and reliable alternative for doing the search. While a few things have surfaced, nothing has really stood out... so if any of you have a brilliant idea for search and sort with a large number of 18 digit numbers, let me know

Jonathan Simpson

[Moneo]

Well, other stuff being added right now, apparently, includes the ability to transmit pricing and sales data via TCP/IP or possibly Dial up. The idea is that sales, customer info, and product stock levels could be transmitted to a home office in shops with more than 1 store. Personally, I like the idea of sending sales back to the stores, so they can be started without manually editing the stock table. Another possible new feature is "reciept designer", which would allow users to build an reciept interactively (I'm using VBDOS for this, because of it's drag n drop interface works well.) This would tie in with aprint.

Other ongoing projects include me trying to find a way to decrease the memory required for searching the stock table, by finding a fast and reliable alternative for doing the search. While a few things have surfaced, nothing has really stood out... so if any of you have a brilliant idea for search and sort with a large number of 18 digit numbers, let me know
Jonathan Simpson

Jonathan,
I don't understand the following: " Personally, I like the idea of sending sales back to the stores, so they can be started without manually editing the stock table. "
Does that mean that you disagree with sending sales to a home office? Also, I'm not sure what you mean by the "stock table". Is this the inventory file? Does it also contain the PLU, the item's selling price?

Later you mention an 18 digit number. Is this the store's own SKU, stock keeping unit? If it's a bar code, then the EAN bar code is only 13 digits. Please explain.

In the phrase "stock table" do you use "table" in the Relational Database sense? In my mind, the search should be done directly using the 18 digit code as a key to the database file.
*****

[Jonathan Simpson]

I don't disagree with sending sales data back to a home office. In fact, I am all for it. Not only that, but I am writing the program (for Dale) that will do the actual sending and recieving. What I meant was that price changes should also be sendable via that program, so that a price update (for a weekly sale or just for general price changes) can be sent to the stores from that main office.

No, no database. By table I mean a random access file, the inventory file as you say, 106 bytes per record, with at present a maximum of 5000 records. 18 bytes are allocated for the stock number, although they are all always numbers. This is partially to allow room to grow, and partially for other reasons. For one thing, the barcode standard is changing in 2005, so it's a good thing Dale allowed the extra space. It also wouldn't surprise me if some day a new feature gets crammed in by changing the string to a currency or something similar.

Jonathan Simpson

[Moneo]

Jonathan,
Ok, I agree with your point about the home ofice. That's the right way to do it.

Question: How come you only have 5000 items? An average supermarket has about 40-50,000.

Also, I still don't understand what you meant by " trying to find a way to decrease the memory required for searching the stock table, by finding a fast and reliable alternative for doing the search". Are you accessing the file directly or are you doing some sort of searching in memory like looking for an index? I can appreciate that this is a critical part of your operation, so please explain a little.
*****

[Jonathan Simpson]

Well, this is kind of a touchy subject, in some ways... I am for having a larger stock table, and it will be increasing to 13,000 in relatively short order. As you say, the average supermarket has much more than 5000 items. The reason for only 5000 items comes down to two things.

1. This program is not meant for the "Wal*Marts" of the world. It is intended to give small shops the edge they need to stay competative, and it does. Dales opinion has always been "If they are that big, they can afford a purchased POS system.

2. Memory requirements: Right now the stock table works via a index file, with a 4 byte string stored for each record. This string is a compressed version of a portion of the stock number. Actually, it looks just like a long integer would in a disk file. This index is loaded into a single large string, and records are found by using INSTR with the input stock numbers compressed form against the string. This takes 4 bytes per record, or 20K of string space. It's going to be reduced to 2 bytes per shortly, and 26K will then allow for 13,000 records.

Now, of course your going to say that there are many other ways to lookup records... and you are right! However, all of these records also need to be sorted by a variety of fields, up to and including a 24 byte description string. I have looked at numerous sorting and searching routines, and doing everything in that amount of space for larger numbers of items quickly and effeciently becomes very complicated.

If you have any suggestions, go for it, I would love to hear them... but keep in mind the quiding principle is that this is not intended as a POS system for the world to use, but rather one for small businesses which cannot afford the often enourmous expense of POS software and hardware. POS runs on very low end machines, all the way down to 8086 hardware with 640K of ram or less. There are actual businesses using POS on hardware with specs not much higher than that, so using XMS or EMS for sorting and searching is not really an option.

For the record, being persistant and annoying, I have been working (with some help) on a sort routine designed for a large number of records, which never uses more than 20K of memory but can sort 100,000 or more records with relatively good speed. It's based on seperating the file to be sorted into a number of smaller files, each of which contains specific ranges of unsorted numbers... this way, once each sub-file is sorted, the entire set is sorted, you just have to put the files back together. I'm going to try using a radix sort in the actual sort code, and if that fails or is too slow I'll fall back to the quicksort.


Thanks for the input

Jonathan Simpson

[Moneo]

Jonathan,

Sorry about questioning the number of items in your stores. I should have figured they were small stores.

About the memory requirements and searching the index string using INSTR, I just have a feeling that INSTR is not the best way. Since your search argument (the 4 byte key) is 4 bytes long, INSTR will compare bytes 1,2,3,4 then 2,3,4,5 then 3,4,5,6 then 4,5,6,7 doing 3 extra compares for each. But worst of all, if your 4 byte keys do not include a delimiter, and therfore you could find an invalid combination. Question: Does the byte location where the INSTR finds the Key mean anything? Does this location translate into some offset into the data file?

Example of finding an invalid combination:
Let's say that the first 2 Keys in your string of Keys are 2705 and 1699, so the string begins with 27051699. Now you are given an invalid Key of 5169, which the INSTR will find starting in position 4 of the string. You could recognize this error by making sure that the position-1 is either 0 or a multiple of 4.

Regarding sorting, the best advice I can give you is to have your program Shell to the best DOS-based sort I have ever seen and have been using since 1985; that is, the OPTTECH sort. See www.opttech.com. It costs $149 and is truly worth it.

Regarding searching and sorting in general, visit www.ethanwiner.com and get a free download of Ethan Winer's famous book on Basic programming. He's a renowned expert on Basic and his book has lot's of good info on the subjects.

By the way, your idea of splitting the data onto several smaller files, is a recognized solution. Back in the late 50's or early 60's, Citibank put together a mainframe system having 128 tape drives. They had several million accounts and needed to access them fast. This baby was called The Citibank Machine.

Regarding Quicksort, one of the things that I don't like about it is that it doesn't respect any original sequence that the input file had.

Regarding your comment: " this is not intended as a POS system for the world to use", I'm sorry for "thinking big". I worked on POS systems for J.C. Penney, a chain of supermarkets in Los Angeles, Woolworth, Kmart, and yes WalMart. Only did some work on a
small POS system for a chain of 3 drugstores in Mexico City. Working on the big chains, you get to appreciate many concepts and many problems.

I'd love to keep in touch with you on this and help out in any way I can. If you want to contact me by email, do so at moneo@prodigy.net.mx which is at my home.
*****

[Jonathan Simpson]

Updates:
POS 5.0 supports multiple registers sharing a single set of files. There are global and local files, with customer, sales, and stock information on the server. Currently in the beta is support for 13,000 stock items (up from 5000), and pole display support. Lots of other cool stuff is in the works as well.

Jonathan Simpson