How and where is information stored?

Before diving in and creating large numbers of ingredients and recipes, it's worth taking time to think about how you intend structuring your recipe data.

Like most chefs, you probably have a large repertoire of recipes that you use on an almost daily basis. These recipes can range in complexity from the most basic preparations to quite difficult and complex recipes. When planning a database for recipes, think small. Try to break large complex recipes into smaller units. This not only makes each recipe easier to understand in isolation, but you gain the advantage of being able to use these sub-recipes in more than one place in your database.

For example, you might have several sauces that are based on a white stock. Don't create a recipe for each sauce including the ingredients for the white stock in each of the sauce recipes. Instead, create a recipe for the basic stock and then use that recipe as a component ingredient of each of the sauce recipes. You gain the advantage of only entering the ingredient for the stock once, and should you decide to use a different recipe for white stock in the future, just modify the one recipe and all recipes referencing the white stock will automatically reflect those changes.

HINT: If you are constructing a new database, you are probably planning on entering several hundred recipes. Initially you needn't enter the full details for each recipe. Just create basic 'empty' recipes entering each recipe's name and production quantity/unit. It is possible to mark the newly created recipe as incomplete and you can fill in the ingredient lists at a later time. This lets you build up a large list of recipes in a fairly short time and saves you from 'back-tracking'. There's nothing more annoying than having to leave one recipe partially complete because you have not entered another recipe required to produce the first recipe.

Make sure you include in the recipe database, everything that you use to prepare a recipe in the kitchen. It's easy to just add a little seasoning while cooking a recipe, but your computer doesn't know this, so be sure to add entries for seemingly incidental ingredients in recipes where they are used. You might consider creating a special recipe called 'Season to taste' which consists of some salt and/or pepper, etc. Include this recipe in other recipes and you'll be sure to have everything included in your ingredient lists. This also makes your intentions obvious to anybody else working from a print of one of your recipes.

If you plan to use Resort Restaurant's menu engineering features, pay close attention to the way you set up your retail recipes for sale. Resort Restaurant only lets you use recipes (or ingredients) that are marked as 'retail' products in menus. When you set up these retail products they should represent a dish just as you 'plate it up' for serving, or package it for sale. Take special care when preparing retail recipes to use production units like 'Serve', 'Portion', etc. The menu engineering functions 'expect' recipes to be portioned in 'Serve' like units. If a recipe is portioned in say, 'Pounds', then the program will attempt to perform menu engineering calculation on a single 'pound' of the recipe, which from a menu engineering perspective, makes no sense at all.

Whatever you enter in your database, the onus is on you to think about what you are doing. If you start with a plan in mind and an overall idea of what you want to achieve and enter your data accordingly, you will have few problems.

The main points to remember are:-

•Work from the bottom up. When entering recipes, start from the bottom with all of the basic preparations that you use (i.e. stocks, roux, etc.). Then use those basic preparations to produce your middle level recipes, like sauces. Finally use all of these recipes to produce recipes for the finished product for sale.

•Keep your recipes small. Lots of small recipes are much better than a few large recipes. Try to break large recipes into smaller re-usable units. For example, if you have several recipes each initially based on a roux, then don't add the ingredients for the roux to each recipe. Instead, create a recipe for the roux and use that as a component ingredient in the other recipes. This saves you work, as you're not 're-inventing the wheel' for each recipe, and should you ever wish to change the way you prepare a roux, you only need change the roux recipe and all other recipes referencing the roux will automatically be updated.

•Cost everything. Don't leave seemingly trivial items out of a recipe just because they don't cost much. You should be conservative with your costings and that means including every ingredient used in a recipe. You will also end up with incomplete recipes that you can't pass on to someone else to prepare.

•Retail recipes. When creating retail recipes for sale, make sure you use production units like 'Serve', 'Portion', 'Cover' or similar. This will make these recipes ideal candidates for menu engineering.