Why not add a Kit Feature?

[janvier]

Hi,

My name is Jacques.

In South Africa it is customary to sell beer in a liquor store in the following manner.

Case price 24 items Cost plus +-5% profit
Dozen price (half a case) compound add another +-5%
Sixpack price (quarter case) compound add another +-5%
single beer (single unit) - SKU or single known unit -compound add another +-5%

This is to entice customers to rather buy in bulk and save - the program however does not permit a category of kits - A kit entry screen with its own product code referring to the sku (single known unit) in the stock table would allow for capturing set prices for sales based on quantity of item and make the inventory feature deduct 6 beers for instance at a set price wheras one beer costs $1 but a sixpack is charged at $5. This would make your program usefull in any retail environment in South Africa or for that matter around the world.

Just a thought
Regards
Jacques

[ibmsystems]

Hi,

My name is Jacques.

In South Africa it is customary to sell beer in a liquor store in the following manner.

Case price 24 items Cost plus +-5% profit
Dozen price (half a case) compound add another +-5%
Sixpack price (quarter case) compound add another +-5%
single beer (single unit) - SKU or single known unit -compound add another +-5%

This is to entice customers to rather buy in bulk and save - the program however does not permit a category of kits - A kit entry screen with its own product code referring to the sku (single known unit) in the stock table would allow for capturing set prices for sales based on quantity of item and make the inventory feature deduct 6 beers for instance at a set price wheras one beer costs $1 but a sixpack is charged at $5. This would make your program usefull in any retail environment in South Africa or for that matter around the world.

Just a thought
Regards
Jacques

Welcome!
anyway i do reccomend you come to dhpos chat sometime today as for today i mean feb 17 as for i'm in phx and it turned friday 30mins ago

----> Tip: Never ask me what day it is after 12:00 clock

anyway like i said dhpos chat would be a great place to discuss this beacuse dale could help you as for i do not fully understand (Dont worry its just me ) you can find chat at http://www.dhpos.com/chat

[Andrew]

A kit feature has been suggested many times before, and hasn't succeeded in convincing Dale it's worthy of hogging some of the teeny free space available for new features.

[ToPS]

Hi Jaques

Welcome to this forum.
Please see my post(poll) on Linked stock table (inventry) items.
What you are suggesting is what I also need and suggested.

I'm just wondering why, if this has been suggested so many times, this feature can not be added.

The DHPOS program is actually quite smal compared to other similar programs.

We must accept that computers are developing very fast and that the days of 3Gb hard drives and 1.44mb stiffy drives are history.
PC's don't last forever and before long we will not be able to keep this old machines in a working condition and they will only be a memory.

Please Dale, can you look at this?

A commercial program available in South Africa that has this feature is IQ2000 but it is quite expensive.


Regards
ToPS

[Dale Harris]

Well let me address this issue yet again.

But first the memory thing. While computers now come with a huge amount of RAM memory unfortunatly that will not help DHPOS at all. Since DHPOS is written in DOS it is limited to only using 640k of memory for both the program itself and any data that is held in memory. This requires that I split up the program into several modules to handle different functions and the program switches code in and out to accomodate each function. But each set of code must completely handle 1 function. It would be a nightmare to split one function among several modules.

The function that requires the largest amount of code is a sale, which includes loading all of the parameters set in the POSCONFG.EXE program to format a sale, entering the items into a sale, processing payment methods, calculating the totals, printing receipts, parking, saving sales data, etc., etc. This is basically all that the POS.EXE program does and it is the largest module. Once it reaches the memory maximum I am done adding new features to DHPOS unless the new feature is not part of a sale.

So lets get to "kits" or as I refer to it "deals."

The setup of deals would go into the POSCONFG.EXE program so that would not be a memory problem. However calculating each deal into a sale would of course have to go into the POS.EXE program. Can you see what is coming?

Janvier wants different unit pricing depending on if you purchase 1, 6, 12, or 24 of a particular item. And of course he would want that even if the items were not all rung up in the sale at the same time. For example if you rang up 4 of them at the beginning of the sale and then 6 later and then 14 near the end of the sale the program would find them all and charge the 24 count price for each one, less discounts and reductions of course. This means that every time you ring up a new item that the program would have to check back over the entire sale for like items and keep track of the totals of each.

In addition, while some items would have the 1/6/12/24 deal other items in the stock table would not have a deal, or would have other deals. Such as....

Buy ? of this and get one (or ?) free.
Buy ? of this and get another one at ??% off.
Buy ? of this and get another one at $?.?? off.
Buy ? of this and get one (or ?) of this other thing free.
Buy ? of this and get one of this other thing at ??% off.
Buy ? of this and get one of this other thing at $?.?? off.
Buy this and this and get this other thing for free.
Buy this and this and get this other thing for ??% off.
Buy this and this and get this other thing for $?.??% off.
Buy ? this and get ? of this, or this, or this, or this, or this free.
Buy ? this and get ? of this, or this, or this, or this, or this at ??% off.
Buy ? this and get ? of this, or this, or this, or this, or this at $?.?? off.
Buy ? this and get ? of this, or ?? of this, or ??? of this at $?.?? off.

and it goes on and on, endless possible deals.

And I must say that the "cost plus" pricing scheme is something that has never been suggested in all the previous times this subject has been brought up. It adds a whole new dimension of possible deals.

For each possible deal you would have to tell the program which items belong to which deals and fill in the question marks with numbers for each deal.

So with 13,000 different items how many possible, conceivable deals could there be? 25,000? 50,000? 100,000? More?

Assuming a minimum of 5,000 possible deals to support, with a wholy inadequate 100 bytes of code to impliment each deal, that would only add 500,000 bytes of code to the POS.EXE program that has a maximum 500,000 byte file size and already is 450,000 bytes.

To give you an example of how tight space in the POS.EXE file already is, I am trying to impliment the "gift card" feature with only adding 500 - 1000 bytes of code.

I could go on with how complicated formatting the program would become for users with just 5000 possible deals to choose from and program, and the fact that the stock table file would have to be reformatted to impliment the deals which would require that I change large parts of the program, and that not only would the new code for the deals have to be added to the program but also the data on each deal would have to be held in memory, but why shoot a dead horse?

Rather than try to add a new feature that (considering the limitations of DOS) may be impossible and would take just about forever to impliment I am going to continue to add features that I think are more useful like gift cards, X-Charge, and customer accounts.

[Andrew]

Thanks for the full reply Dale, I did try to warn them - but you know the full details of what can and can't fit into the remainder of DHPOS.

[ToPS]

Yes thak you Dale, it does make things a lot clearer to understand.

Wouldn't it be easier for you to point/guide us to your previous replies to matters that were answered before?

I feel that the discount feature can be used to handle most sorts of deals that may be done.
What we can do is calculate price structures based on different percentages of discount and then ring up the single units and discount them.
In other words - work from the highest price down rather than from the lowest up.
6 to 12 units = less 2%
13 to 18 units = less 4%
etc.

Still happily POSsing

ToPS
ensovoorts

[Andrew]

ToPS,

Most won't bother to click a link and read a previous post on the topic, such as these two on this exact topic, which I just found via search...

http://www.dhpos.com/discuss/phpBB2/vie ... t+features
http://www.dhpos.com/discuss/phpBB2/vie ... limitation

In respect to the discounts/kit features - the problem lies not in that although the concept is relatively simple and would be excellent, there are many kinds of different discount setups people would want - such as those Dale mentioned above.

DHPOS would have to have code to process and validate each of these varied discounts, deal with conflicts where two or more discount schemes appear in the same sale etc...

Could you imagine the loops it might get in with a buy X get Y free scheme? What if someone buys X, get's Y free and DHPOS finds a buy Y get Z free discount? A rare occurence I concur, but a very possible situation, DHPOS could end up in a proverbial loop of discounts and freebies. Even if such an occurence is rare, the programmer must think ahead and trap every possible situation, every keystroke and every sequence of events an end-user might throw at the system.

Example was I used to work in a supermarket, the till could easilly be jammed by scanning an item return - and scanning the discount coupon card into the return. The computer would jam with an "Overtender not allowed for tender type Coupon Card", and would need to be rebooted.

The programmers of that system did not have proper error-checking to trap that action and stop the system from locking up, resulting in a long reboot process while the till downloaded the stock table etc all over again.