POS beta test version 6.33

[Dale Harris]

Ok POS fans, here is another new beta test version. The concept here is to test out this version and report back. I need to know if it works or if it does not work for you, so report back either way. Test out both the new feature and the program as a whole. Does anything weird happen? remember that this is a BETA version so make backups of the version that you have now.

Here is the download link...
<center> http://keyhut.com/pos633.zip </center>



New features “B” us.

We have a snappy new feature for you. The new feature will add up items being rung up separately, if they are the exact same item, into one line on the sale instead using a different line for each item. For example if someone brings four identical cans of peas to your register and you scan them one at a time they will be rung into the sale on one line as 4 cans of peas instead of being run on four lines as 1 can of peas each. See receipt below…

<pre>OLD WAY
63414641 CAN OF PEAS 10 OZ. 1 .56
63414641 CAN OF PEAS 10 OZ. 1 .56
63414641 CAN OF PEAS 10 OZ. 1 .56
63414641 CAN OF PEAS 10 OZ. 1 .56

NEW WAY
63414641 CAN OF PEAS 10 OZ. 4 2.24</pre>

There are some rules for this to happen. When ringing up a new line, the program will only check the previous line for a match. For example, if you are ringing up an item into line 23 of the sale and the exact same item has already been rung up in line 17 of the sale, the new item will not be added to line 17. For two items to be considered the same, they must have the same stock number, description, price, and tax rate. “Tax rate” means not only the same rate but also the same line in the tax rate chart.

If you wish to sell several of the same item with a reduction on some of them but not on others you either must ring up a different item between the items with a reduction and the same item at the regular price, or you must ring up some of them, then the reduction, then the rest of them.

[bdude]

will this be able to be disabled?

[Dale Harris]

Nope, it is always on. Is there some reason that you think it should be optional?

[ChrisKraus]

Nope, it is always on. Is there some reason that you think it should be optional?

<HR>
Most POS Systems Do This Anyway
For One Item, It Would Look Like This

Code: Select all

123456 ITEM-NAME $2.50

For Multiple Items, It usually uses 2 reciept lines, like below

Code: Select all

123456 ITEM-NAME $7.50
3 @ $2.50 Each

- Chris

[Bobby]

Hello,

Now this seems like it could be a great feature, but the thing I noticed is that it only combines items if they are rung up one after the other. It is not always the case that the items will be rung up one after the other. Just a suggestion would be to wait to combine the items until the "+" is pressed. Then any items with the same sku/upc and price would be combined. That way if you wanted to reduce just one item, you could. I just think that it looks odd to be ringing up items and then on the receipt only some like items are combined.

Just my input,
Bobby

[Andrew]

Hi Bobby,

Dale did say this is how the feature would work - it will only group if they're rung up one after the other.

Your idea of waiting until the end of the sale has merit, but the complication could come in with that reduction on a single item, when DHPOS goes and merges all those similar items together.

[Dale Harris]

Bobby,

One of the reasons it works this way is that it took only 10 lines of code to do it. And code space is at a premium.

The problem with your suggestion is that it reduces the number of lines after everything has been added to the sale. One of the purposes of this feature is to keep the number of lines under the maximum of 60 as the sale is being rung up.

The reason not to combine lines of like items together no matter where they are in the sale, for example entering an item on line 23 that is already on line 11, is that the line (and item) will seem to disappear as soon as you enter it.

[Mike Wazowski]

Dear Sir,

I found small bug in v6.33 of software with new feature.

when combining items to same line, total cost is calculated wrongly after third entry or scan.

only first quanity entry and last entry quantity is used in calculation of total, but screen shows otherwise.

Mike Wazowski

[Dale Harris]

Mike Wazowski,

Actually this is a big honking serious bug. However it has been fixed in version 6.34 which can be downloaded now at http://keyhut.com/pos3.htm

Thanks for reporting this which none of my beta testers did.