New feature BETA test.

[Dale Harris]

eureka8888,

I posted this last night and it disappeared.

Earlier this year I changed the format of the stock table to accomodate the field for the "sale prices" and to increase the maximum numbers of lines from 5000 to 13,000.

The STOCK.EXE program was not written by me and the author of that program has not had time to update it. I guess that Andrew should either remove the program from the 3rd party software list or post a note saying that it will only work with versions of the POS program earlier than 6.0

However the POS program itself has many tools to move lines around in the stock table. When in the stock table press [F5] to "Move / Export lines" Then choose to MAKE A BACKUP OF THE STOCK TABLE!!! Now you can select lines and then copy them into the clipboard. Now delete the selected lines.

Move to the part of the stock table where you want the lines to be and paste them there by moving the current lines back. If you are using the POS beta version 6.14 BETA 2 you can now sort the lines you pasted by any field you want in either increasing or decreasing order.

Repeat this process for the other groups. If you somehow screw up your stock table beyond all comprehension you can restore the earlier version of your stock table by loading the backup. YOU DID MAKE THE BACKUP, DIDN'T YOU?

[eureka8888]

thanks a lot dale, i have seen this option but i didn't try it.... stupid me hehe, i thought this is only for backing up. thanks

[Dale Harris]

Well here is a tiny new feature. I got a call from a mall out in Colorado. The want to use the POS program for their leased sales carts. However one of the things they require is that the register can do "Z" readings.

A "Z" reading is a tally of your sales from the first sale ever rung up on the register when it was just taken out of the box and it cannot be reset. However it works like a speedometer. When it reaches its maximum it will "turn over" to zero. For the POS program the maximum is 999999999999.99 and if you add 10¢ to that you will get 000000000000.09. Got the concept? Not that you are going to reach 999999999999.99 in sales too often.

Anyway, the point of this is that the mall can take a "Z" reading from each of the cart registers one a week, or once a month, and subtract the previous "Z" reading and they will then know what the cart sold in the time period without having to worry about how many times the daily sales were reset.

The POS program will now do "Z" readings. The "Z" reading is displayed in the upper left corner of the "Close" screen of the POS.EXE program only if the display of the "Z" reading has been turned on. You turn it on using the "History" feature of the POSCONFG.EXE program. The POS program will keep track of the value of the "Z" reading even if the "Z" reading is not displayed.

Here is the download link to test this puppy. (THIS FEATURE IS NOW IN THE CURRENT VERSON OF POS) It is version 6.14d although only the POS.EXE and POSCONFG.EXE programs have changed from 6.14. I am going to give this a day for all of you to test it because it was a pretty easy new feature to update. If no bugs are found I will upload it as the release version tomorrow night.

[Dale Harris]

I added a little to the "Z" reading feature. If you have enabled "Z" readings then from the "Close" screen you can print the "Z" reading by pressing [F1].

Try it out, version 6.14d (THIS FEATURE IS NOW IN THE CURRENT VERSON OF POS)

[Dale Harris]

Well we had a very interesting discussion on the "Z" reading in chat tonight (you <u>were</u> there, weren't you?)

The problem we came up with was that a user could have two (or more) register files on his computer. They are identical except for the file name. On the first half of the month the user uses one of the files and on the second half of the month the user uses the other file. Since they look and work the same the mall would have no idea that different files were being used at different times of the month. The problem is that when the mall takes the "Z" reading only the sales from that register file would be included, the other register file would have the "Z" sales that were rung on the other register file and would not be included in the "Z" from the first register file. In other words the mall would only be getting half of the sales.

There were two possible solutions. The first solution would be that if "Z" readings were being used then only one register file would be useable on that computer. This was not feasable.

The solution that we implimented is that all register files on the same computer use the same "Z" reading. This means that all register files, in any folder, on any drive, in the same compter will share the same "Z" reading. If you have register files for "JEWELER" and "KEYSHOP" on the same computer then a sale rung using the JEWELER register file will increase the "Z" reading for both the JEWELER and the KEYSHOP registers. So in the example in the second paragraph above, it would make no difference how many register files the user used to ring up sales for the month the "Z" reading would be increased on every sale.

The downside of this is that if you do use the "Z" reading then once a computer becomes an actual register in a real store then you cannot use the other register files to "play" with or for other vendors. However if you do not use the "Z" reading (meaning that you do not keep track of it) then this will not apply.

Also remember that if you turn the display of the "Z" reading off the register file will still update the "Z" reading on every transaction, only the <u>display</u> of the "Z" reading has been turned off.

Version 6.14d (THIS FEATURE IS NOW IN THE CURRENT VERSON OF POS)