It won't be as easy as it should be. Those starter solutions have a nearly complete lack of supplied documentation which makes it more difficult than it should be when trying to figure out the design in order to make changes.
A few general comments that may help.
- What you describe will require adding fields to the Invoice data field. Those additional fields should then be added to the layouts where a user enters the "line items" listed on a given invoice. There are layouts for both desktop and iOS systems so if you use both, you have multiple layouts to modify. Adding those extra fields will require a redesign of these layouts to "make room" for the added fields.
- For pricing, the current system looks up (copies) the price into the Invoice Data record. You can leave this price empty in the products field and manually edit on the invoice layouts or you can leave the "base" price in products and manually modify the price when needed on the invoice layouts.
Well I am not certain I am going to use the starter. There is a lot of it I don't understand, not only in how it works but in what information it is providing - which, ironically, is also part of reason for thinking I will use it. I am thinking once I actually have it populated with itms pricing and sales I am going to find it is giving me information I would not have thought to ask for. Which could be very useful, or it may just be a distraction.
On pricing, what I really need for it to do is have a base price AND calculate in the adjustments for upgrades. Otherwise I will have to have over 100 different entries just for the possible variations of photo albums alone. On top of that, if the database does not calculate the adjustments then I or whomever is doing a sales session with a client would have to memorize or look those cost differences. Thats what we already do, the idea of putting it in the database is to save us that work and eliminate human error.
In short, I am really open to suggestion on the best way to approach this.
Then you really should use a different product record for each pricing item. This what I would do if creating my own invoicing solutions or modifying the starter solution. But I'd modify the means used to select a product category and then select a specific item just from those that make up a specific category.
I'd also probably build in support for "packages" where selecting the package from list of products actually selects a group of products and adds them to the invoice.
"Then you really should use a different product record for each pricing item" I am a little confused here as I was expecting to do this anyway, So I am not sure what the alternative would have been?
"But I'd modify the means used to select a product category and then select a specific item just from those that make up a specific category." This I am not sure what you mean. The way i picture this working is if someone wants an album then we would start typing in alb... select the album and then be able to modify it with whichever add-ons they choose, like a larger size or a leather cover and added photo spreads... And really it is how to create the modifiers which boggles me, especially since not all items use the same modifiers.
"I'd also probably build in support for "packages" where selecting the package from list of products actually selects a group of products and adds them to the invoice." This idea I really like as we sell canvas clusters which are 10% off of the individual costs of the canvases, so a cluster of Four where there of them are sized 11x14 and $100 and one of them sized 16x20 for $200 then they only pay $450 and not $500... I am guessing this would be relying on some kind of look up table so when the 11x14 canvas base cost changes I would only need to change it in one spot and it would not retroactively effect any of the previous records...
Look at your own second paragraph:
"select the album and then be able to modify it with whichever add-ons they choose,"
Either each "add-on" is a separate product or each album option is a separate product to be priced differently. I was telling you that you really do need to do what you don't want to do.
And you can have a product category called "album". You select "album" and then your list of products narrows to just those items in the "album" category, thus providing the user with a shorter list of products from which to choose from.
As I have school age kids, I'm well aware of Photo packages from businesses like yours. At times, I wish I didn't when it comes to reigning in my wife's spending on the same.
You already have a look up table of products. A "package deal" or a "kit" is just another item in the products list. But, if needed, you can use a script performed when the package is selected to add all of the package's individual items to the list of purchased items on the list or you can just log the purchase of the package and its cost. Which approach to use depends one whether you need to track individual items from the package that might also be sold separate from the package. (How many 8x10's did we sell last month, for example). It also may be helpful for communication to the customer and for order fulfillment purposes to list the individual items.
To list the items that make up a package, both to compute a package price and to be able to list the individual items in the package when needed, you add a "self join" that links Products to another occurrence of products.
Products::Product ID Match Field = Products|Package::Product Package Match Field