99,000 lines in the stock table

Make comments, ask questions, or just complain about the software on this site. Or comment on any educational software.
Please note that by clicking on links that may appear in these posts that you may be leaving the Dale Harris Educational Software website and that the content of those sites is the sole resposibility of the authors of those sites.

Moderators:daleadmin, Dale Harris, Alan, Andrew

User avatar
daleadmin
Forum Owner
Posts:1279
Joined:Tue Dec 30, 2003 9:47 pm
Re: 99,000 lines in the stock table

Post by daleadmin » Wed Apr 20, 2011 7:16 pm

Well it looks like Bruce and I am doing our part, where is everyone else?

I am depending on CB to check out the PURCHASE.EXE program.

Today I worked on the history reports. I have created a filled 26000.HST history file. It is included in both downloads at the end of this post. I have used it to find a few more problems in the Reports program. These I have fixed and the new program file is in the 26000D.EXE file which is a full download of version 7.04d26. I have also added a routine to the program that will expand old history files from 15,000 lines to 30,000 lines without losing the data in the old file. Please download and unzip this file to continue your testing. AND REPORT BACK!!!

Here are the links...

(New file, see below) = Full download

http://keyhut.com/26000s2.exe = Data files only.

Dale

User avatar
brucef2112
Forum Regular
Posts:336
Joined:Mon Mar 06, 2006 11:19 pm
Location:Broward County, Floriduhh
Contact:

Re: Possible False Positive Bugs with 26k Stock Table

Post by brucef2112 » Wed Apr 20, 2011 7:50 pm

Hey Dale,
I DL 26000c.exe 6pm Eastern.

The mock up sales data in the stock data must be missing some supporting info in other data files somewhere.
I ran the A. Total Sales and it only shows;
Cash Sales $134307 in 3 transactions.
and TAX as ZERO

However the E. Total by Stock # shows a big honking number of 1318498821.

I rang up a transaction and it is producing correct cash and tax. (it added my one transaction to the count, added cash, added tax)
If you want to continue providing a base of data, you'll need to fix the data set with transaction counts, tax, other wise we may be chasing a false positive bug later on and not know it to be related to the table mock up. If not, it may be better to just provide the stock table without sales data in it and just let lusers create their own sales as we test.

I also want to give you a performance report on what I'm seeing.
My frame of reference is from 2k item stock table and daily sales transactions in the 40-50 range. So I'm use to reports generating in a flash of a second each.

I know this mock table and sales it huge. But just want to report back on the run time I'm seeing for generating reports. To me they seem slow. I'm running on WIn XPsp3 Celeron 2.40Ghz 1GB RAM.
With the 26K data as provided, when I run either the E. Total by Stock or F.Total by Cat each take about 1minute and 40 seconds to run.
I'll give the report's record counter on top a name of Counter A and the one below it as Counter B.
When running either report, Counter A takes about 1min and 17seconds to count down. Followed by Counter B taking about 20 seconds to count down. If this is typical then an auto reports close-out could be close to 5min for just generating 3 reports as closeout. I guess if I had the daily sales in the mockup I'd be happy to wait! But just wanted to give some feedback on what I'm seeing.

Also I know there are other features on the to do list pre-26K POS. One is something about customer accounts??? This involving major table changes or additions to impliment. This was the reason it wasn't implemented yet.?? If every impplimented, have you given concideration to how the additional data or other features on the waiting list would further bog down the system with 26K POS?

Later,
b
Later,
Bruce

They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Benjamin Franklin - Historical Review of Pennsylvania, 1759

User avatar
brucef2112
Forum Regular
Posts:336
Joined:Mon Mar 06, 2006 11:19 pm
Location:Broward County, Floriduhh
Contact:

Re: BUG or FEATURE in Void function

Post by brucef2112 » Wed Apr 20, 2011 10:24 pm

Dale,
Stumbled on this one while testing 26K POS but it is also in 704p and previous versionss.

If you hit the [F5] key to void an item but accidently hit it two times, it will dump the entire sale.

How I did it:
Added several items to the sales screen.
Accidently hit [F5] two times in a row.
It will dump the entire sale.

How to do it:
1. Add a couple of items to a sale.
2. Hit the [F5] key. ( you are prompted for 1,2,3,4) however....
3. Hit the [F5] key again. (the entire sale is dumped as if number 2 was selected.
Later,
Bruce

They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Benjamin Franklin - Historical Review of Pennsylvania, 1759

User avatar
daleadmin
Forum Owner
Posts:1279
Joined:Tue Dec 30, 2003 9:47 pm

Re: 99,000 lines in the stock table

Post by daleadmin » Wed Apr 20, 2011 10:53 pm

Bruce,

Reports A - D are not affected by by the 26000 lines in the stock table so I have not provided test data for them. Think of it like this. Since all the stuff in the stock table was rung up you have closed out the register resetting the sales data, but you did not reset the merchandise data. Therefore the sales data is zero (except for new sales you have rung) but the merchandise data will still have massive amounts of information.

As far as speed is concerned it does get pretty pokey once you exceed 13,000 lines of data especially the sorting part. However how many stores that carry 26,000 items will sell more than 13,000 of them in one day or even one week. There is a thing called the 80 / 20 rule that states that in a retail setting that 80% of the sales will be generated by only 20% of the merchandise. This means that it will be unusual for a store to sell more than 30% of what they stock (we are talking about 30% of the different items, not 30% of the entire inventory.) So 30% of 26,000 is 7,800 so that will not take too long. (It is an expotential thing. As the list increases size the time needed to sort it increases exponentially.) And the vast majority of users will not even carry more than 10,000 items. So for most users the report times will still be pretty darn quick.

The history report can run for the entire year so it is possible for it to actually exceed 26,000 items. It also counts discontinued items that have been removed from the stock table. The "history" limit is now 30,000 lines. However most folks will not do a full "automatic" history report when they close the register. If they do they should have a snack handy while they are waiting.

BTW: the "A" counter is the sorting counter and the "B" counter counts the lines being added to the report after sorting. If you are doing a history report the "A" counter counts the polling of the database first, then sorting. The purpose of the counters is so that the user knows that the program is actually doing something and that it has not just locked up. Notice that the counters all count down so that the user will have some idea of how much longer they will be counting.

User avatar
daleadmin
Forum Owner
Posts:1279
Joined:Tue Dec 30, 2003 9:47 pm

Re: 99,000 lines in the stock table

Post by daleadmin » Wed Apr 20, 2011 10:56 pm

Bruce,

The hitting [F5] twice to completely void the sale is intentional and is an actual feature (undocumented) of the program. I use it all the time.

Dale

BTW, It has been there since version 1

User avatar
brucef2112
Forum Regular
Posts:336
Joined:Mon Mar 06, 2006 11:19 pm
Location:Broward County, Floriduhh
Contact:

Re: double clutch [F5]           EASTER EGG!!!!

Post by brucef2112 » Thu Apr 21, 2011 12:09 am

WOOOHOOO!!! ♪ ♪ I just *found* an Easter Egg, in D,H,P,O,eSSSS!! ♪ ♪ :mrgreen:
[Bruce bouncing up and down doing a victory jig]

I love it! After already seeking out the [F5] key to void an entire sale I always hated searching the keyboard to find the number 2 key and then back to the [ENTER] key. Although in my store I now have a Cherry programable KB, so I've got my VOID SALE to one key stroke instead of THREE. The double [F5] is much quicker but I still save 1 key stroke with my Cherry! :lol:

later,
Later,
Bruce

They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Benjamin Franklin - Historical Review of Pennsylvania, 1759

User avatar
brucef2112
Forum Regular
Posts:336
Joined:Mon Mar 06, 2006 11:19 pm
Location:Broward County, Floriduhh
Contact:

Re: Observation of difference in CC & Debit finishing sale

Post by brucef2112 » Thu Apr 21, 2011 12:31 am

Dale,
This is just a dumb observation but I notice things like this when Im left alone at the late hours of the night.
With a basic install like 26k POS without a printer setup, the finishing of a Debit sale is 1 less key stroke than with a Credit Card sale.

With a Credit Card payment. if you hit [enter] to accept the default amount the register displays the following about no printer.
┤REGISTER IS NOT PROGRAMMED TO PRINT RECEIPTS.├─
And if you hit the [ENTER] or anykey it goes back to the main menu.
Actually the Cash works the same as the CC but I recall there being a reason for it functioning like that.

With Debit payment. if you hit [enter] to accept the default amount the register displays the message for a few seconds BUT then returns to the main menu on its own without hitting any keys!

I then configured POS to go to the next sale instead of main menu.
The results are the same. In CC you hit [enter] to accept default amount, (it displays printer message), til you hit any key to goto next sale.
In Debit, you hit [enter] to accept default amount, (it displays printer message for a few seconds then goes to next sale by its self)

this is really a non issue for those with a printer configured cause both CC and Debit go to the next without further keystroke.
I'm sleeepyy...... going to bed.....
Later,
Bruce

They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Benjamin Franklin - Historical Review of Pennsylvania, 1759

User avatar
brucef2112
Forum Regular
Posts:336
Joined:Mon Mar 06, 2006 11:19 pm
Location:Broward County, Floriduhh
Contact:

Re: History is fun!

Post by brucef2112 » Thu Apr 21, 2011 11:07 am

Dale said;
I have created a filled 26000.HST history file. It is included in both downloads at the end of this post. I have used it to find a few more problems in the Reports program. These I have fixed and the new program file is in the 26000D.EXE file which is a full download of version 7.04d26. I have also added a routine to the program that will expand old history files from 15,000 lines to 30,000 lines without losing the data in the old file.
Dale can you clarify for me what/how of the history file.
From the reports menu it seems that the history is based on time (1 to 12 months with a roll-over) and not a record count or limit. Was the 15K line limit an undocumented limit? I peeked at the raw data of the *.HST but was not sure of whats going on there. Will the earth wobble @ 30,001? With the new double sized 30K history how long before this would run out for me as a user? Will the earth even be here @ 30,001? Does everyone get a super sized 30K history file regardless of their stock table size? Is this meant to accommodate the 26K possible stock items plus a little buffer room of sorts?

Does this new 26K POS also need more lines in the Sale Recording-VOIDS setting? Or is the existing max of 10,000 Number of sales recorded going to keep us safe and the earth on its axis?

thx
Later,
Bruce

They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Benjamin Franklin - Historical Review of Pennsylvania, 1759

cpb14
Forum Regular
Posts:56
Joined:Fri Oct 22, 2010 10:44 pm

Re: 99,000 lines in the stock table

Post by cpb14 » Thu Apr 21, 2011 6:00 pm

Dale. I am going to play in purchase.exe tonight will report back might also play with inventor and receive

cpb14
Forum Regular
Posts:56
Joined:Fri Oct 22, 2010 10:44 pm

Re: 99,000 lines in the stock table

Post by cpb14 » Thu Apr 21, 2011 6:12 pm

BUG REPORT FOR PURCHASE.EXE

if i try to make a proof sheet or PO program crashes and says subscript out of range this is from most current download aka 26000d.exe so in a sense program no work now i will attempt inventor and receive

User avatar
daleadmin
Forum Owner
Posts:1279
Joined:Tue Dec 30, 2003 9:47 pm

Re: 99,000 lines in the stock table

Post by daleadmin » Thu Apr 21, 2011 6:23 pm

Bruce,

When you sell an item with "History" turned on it is placed in the history (.HST) file. The history file starts out with no stock numbers in it. When an item is sold the program looks through the file to see if the stock number is there. If it is not then the stock number is added is added to the file. This means that the stock numbers in the history file are not in the same order as the stock table.

Once the stock number has been located (or added) in the history file the number and value of the item being sold will be added to that line in the month it has been sold. This means that there is sales data (pieces and value) of the items sold for each month. This allows you (for example) to find the sales for a particular item for the past X number of months.

The history file is updated on the first of each month. If an item has had no sales over the last year it is removed from the file. This means that the file does not have to keep gettting larger and larger. However it is possible that the merchandise in the stock table is turned over in the year, with old items being removed and new items added. But the history file cannot have items removed until a year of no sales, this means that the history file must be larger (more lines) than the stock table. Plus at any time you may decide to increase the size of your stock table. For these reasons the history file is always formatted to hold 30,000 items (up from 15,000) no matter how many lines are formatted in the stock table.

The size of the .REC file is dependent on the number of lines you can ring up in a sale - 60. Since that has not changed there is no reason to change the .REC file, therefore the "5. Voids" feature does not require testing.

As far as I can tell the Earth is safe from DHPOS but in life there are no guarantees, make you have plenty of canned goods stashed away just in case.

Dale

User avatar
daleadmin
Forum Owner
Posts:1279
Joined:Tue Dec 30, 2003 9:47 pm

Re: 99,000 lines in the stock table

Post by daleadmin » Thu Apr 21, 2011 6:28 pm

CB,

Well what do you know, the PURCHASE.EXE program also sorts. This is going to take at least a day to fix.

Dale

cpb14
Forum Regular
Posts:56
Joined:Fri Oct 22, 2010 10:44 pm

Re: 99,000 lines in the stock table

Post by cpb14 » Thu Apr 21, 2011 6:31 pm

Dale

whats your thinking on inventory bit i found it weird just enter a few items in have pos read file then use f8 to look up a number not included in inventory (so it should be zero then) and it says inventory = x (with x being greater than zero

User avatar
daleadmin
Forum Owner
Posts:1279
Joined:Tue Dec 30, 2003 9:47 pm

Re: 99,000 lines in the stock table

Post by daleadmin » Thu Apr 21, 2011 6:55 pm

The "Read inventory" function had a test for the maximum number of lines in the stock table that topped out a 13,000. If it exceeded that it would reduce it to 5,000 which was the max for a much older version of the program. Therefore only the first 5,000 lines in the stock table had the inventory reset to zero before the inventory file was read.

I have now just fixed this.

Dale

cpb14
Forum Regular
Posts:56
Joined:Fri Oct 22, 2010 10:44 pm

Re: 99,000 lines in the stock table

Post by cpb14 » Thu Apr 21, 2011 7:01 pm

well that would explain it

Post Reply

Who is online

Users browsing this forum: No registered users and 37 guests