Ok, I'm creating a interface for a waiter to enter orders into and I've come across a stumbling block.
I'm showing the waiter which menu items are available to be added to the order based on if there are enough ingredients left in stock to construct each menu item. That's fine, but the waiter can still submit orders which can cumulatively use more ingredients than are in stock.
For example, an omelette (let's say 3 egg) is allowed to be added to the order because theres 4 eggs left, so what happens when 2 omelettes are added to the order? To make things more difficult, what about if someone wants one omelette and a pancake (2 eggs)?
How should I alert the waiter that there's going to be a problem with the order?
A couple of options I have thought about so far:
1) Allow the waiter to submit the order, then show an error and explain why it has happened. Downside being the customer will consider the order final, and won't be happy about re-do'ing it all.
2) Each time a menu item is added to the order and each time a menu item quantity is changed, re-assess the ingredients and work out if it is possible to construct the order. Downside being it will be complex to program and could potentially flood the database with queries if not programmed carefully. Also, how would the waiter be alerted? In some cases there will be multiple solutions (and causes) to an ingredient overflow, so it would be a bad idea to flag one certain menu item up as the error causer, when it could be one of many.
3) Alongside each menu item which can be added to the order, also show the total amount of that menu item which could be added before stock runs out. This number could be updated dynamically as things change, and then when any of the menu items go below the current quantity required, flag them up as error causers. This is quite a similar option to #2.
When it comes to programming #2/#3 it would pretty obviously be more sensible to grab the total stock of each ingredient and how much of each ingredient each menu item will consume and put the data into local data structured to prevent heavy database usage.
Another thing that comes into contention is that it may not be worth the hassle programming something so complex for this scenario, because any decent restaurant will have enough ingredients in stock to cope with pretty much any size order.
Are there any better options to what I have thought of? What would you do?
Thanks for any input.
Dynamic data validation
Moderator: General Moderators
- jayshields
- DevNet Resident
- Posts: 1912
- Joined: Mon Aug 22, 2005 12:11 pm
- Location: Leeds/Manchester, England
Re: Dynamic data validation
Being somewhat familiar with how restaurants work, I'd say this is the most sensible assumption.Another thing that comes into contention is that it may not be worth the hassle programming something so complex for this scenario, because any decent restaurant will have enough ingredients in stock to cope with pretty much any size order.
Otherwise, I'd load up the ingridients stock on the client side (using JSON) and also the quantities that each item composes. Sounds like a lot hassle for something that is rather useless though
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
Re: Dynamic data validation
Perhaps pytrin has already answered your question. If you're going to agile about it, implement the system without the stock checking features and see how it goes without it. Perhaps allow chefs to mark menu choices as unavailable as a simpler alternative.
Out of interest, how is this the case?In some cases there will be multiple solutions (and causes) to an ingredient overflow