>>>>>Hi,
>>>>>
>>>>>although this is a VFP application, the problem is not really VFP related. Currently I have items that can be sold and multiple of those items can be added to an invoice (invoice line items). I want to allow the user to combine multiple of those items into one item that can then be sold with its own unique price (which is not necessarily a sum of all the prices of the individual components). What terminology is used to describe this? I'm thinking Bill Of Materials, but that doesn't "feel" quite right.
>>>>>
>>>>>I am guessing that the data structure I need to implement is like this:
>>>>>
>>>>>Items
>>>>>ItemId
>>>>>ItemDescription
>>>>>ItemPrice
>>>>>
>>>>>ItemsSub
>>>>>ItemsSubId
>>>>>ItemId
>>>>>ItemQty
>>>>>
>>>>>Does that make sense?
>>>>
>>>>Bot sure about your data structure but I think I'd describe it as a package as your pricing is a repackaging of an existing tariff.
>>>
>>>Thanks, package may not work in this case (Optical Labs), I wonder if something like "Combined Items" might :)
>>
>>Also bundle is often referred to a bunch of linked items in a promotion
>
>Ah, that might be a good term to use!
>
>Now who wants to comment on the data design?

The only time I've done something like this there was a requirement to allow a 'bundle' to be made up not only of items but also to contain other 'bundles'. The data structure was something like (using your Items table as is):

Bundles
Id (PK)
Name
Price ?
etc....

BundleList
Id (PK)
BundleId -> Bundles.Id
Quan
ComponentId
IsBundle

If IsBundle is false then ComponentId points to Items.Id
If IsBundle is true then ComponentId points to Bundles.Id and can be processed recursively to also expand that bundle if required. End result is that even deeply nested collections of bundles can be unwound to a full list of items.....