Sales, promotions, and Deals

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

Post Reply
User avatar
Andrew
Site Administrator
Posts:822
Joined:Sun Dec 28, 2003 3:40 pm
Location:New Zealand

Post by Andrew » Mon Mar 01, 2004 12:29 am

smckane

Jon also looked into the discount option - all the possible combinations nearly fried his brain and it would have taken ages to program.

Even if one or two kinds of discounts were programmed - people woudl complain that their specific discount type wasn't supported.
Image
DHPOS Veteran (from v3.46, July 2002)

smckane
Forum Regular
Posts:20
Joined:Sun Feb 01, 2004 7:17 pm

Post by smckane » Mon Mar 01, 2004 7:27 am

People always complain :D

I'm happy the way things are, but, like Oliver...
"Please sir, I'd like some more."

:lol:

The way the tills at my old work did multibuy discounts was to have a 'flag' set in the product listing - a unique 4 digit number for each till. If the till came across the saem flag again it looked at what the deal was in a master list and then applied that deal if there were enough flags. When I dablled in QBasic I struggled to get it to print in the right colour on screen. I have no illusions that making a working POS program was anything but taxing. As I said earlier, this 'feature' can just go on Dale's very long suggestions list. There's more than enough value for money in the existing program!

User avatar
Andrew
Site Administrator
Posts:822
Joined:Sun Dec 28, 2003 3:40 pm
Location:New Zealand

Post by Andrew » Tue Mar 02, 2004 12:28 am

The problem isn't the finding of items which are on special, it's the logic behind some of the specials that are offered, e.g. buy 1 get one free, buy one get x discount of next, buy this + this + this and get = that etc etc...

The list goes on and on...
Image
DHPOS Veteran (from v3.46, July 2002)

Jonathan

Post by Jonathan » Tue Mar 02, 2004 1:57 pm

I like where that is going ...

Andrew, I don't think the different types would be so hard. On further analysis, I think perhaps 3 or 4 different primary types of "deals" could be sufficent. Lets look at a few cases, taking into account the "deal" code suggested previsously.

Buy X get Y @ Z
in this case, if you buy X items under a specific deal code, you get Y items at a specific deal code for the price of Z (which presumably is stored in a file somewhere). Z could probably be either a value or a percentage of normal price, so this would cover "buy one get one free" and "buy two get one 1/2 off", as well as similar cases. Actually, that probably covers almost half of all sales that I have dealt with :)

Then you have the other primary case, which is simply
Get X @ Z
Where Z is a percentage or dollar value.
This would be used for simpler sales, like 50% or $1.00 off, with no conditions.

The "deal code" may very well be the thing that makes this possible, although Dale would either have to make a space in the stock table for it, or use a parrallel "sales" file. I like option 2, because it is easier to copy a new sales file over, which would not directly impact the stock table, and would proably be easier to implement as far as transmitting from the office to the store.

Comments, anyone?

Jonathan Simpson

User avatar
peewee3ie
Forum Regular
Posts:225
Joined:Tue Jan 27, 2004 7:46 am
Location:Ireland
Contact:

Post by peewee3ie » Tue Mar 02, 2004 5:26 pm

Jonathan

that sounds like a good idea but will qbasic cope with it
Tony McGuire
Ireland Support

smckane
Forum Regular
Posts:20
Joined:Sun Feb 01, 2004 7:17 pm

Post by smckane » Tue Mar 02, 2004 8:54 pm

At work the data is in a pricing file as the stock data is held on an entirely seperate system (nice one IBM, why bother to make my life easy when you can flog two systems to every store! :lol: ) and I have to say that having a seperate file for deals would have disadvantages as well as advantages.

For starters, you have a bit more coding opening and closing files that will slow things down, but you have the safety that you won't corrupt your stock file data by accident when you impliment a new deal. Yet, with all the data in one file it's one less thing to alter and possibly less code to squeeze into the program (please correct me if I'm wrong here, long time since I had to do stuff liek that!). Equally having a seperate file means that you can alter all the deals at once and simply send them down from the office to all your sites.

The best solution is probably the one that is easiest to code!

But I'm willing to wait until Dale, Andrew and Jon all win the Lottery so they can live to code for us for free :lol:

Post Reply

Who is online

Users browsing this forum: No registered users and 181 guests