First comment - you'll probably want a separate ORDER and ORDER_LINE table. If someone buys multiple items, you don't want to have to insert several rows in the ORDER table.
Whether to split the PRODUCT table in 2 or 3 depends on how many fields they share and how you want to use your constraints. For instance, if a service has a bunch of fields that don't apply to inventory products, you're going to have NULLs for 99% of your rows. I find that ugly.
What I typically do is put the common fields into a PRODUCT table, and then have separate tables that share the same key with a 1-to-1 relationship. ie. INVENTORY and SERVICE tables defining those "types" of products.
But it really depends on how complex you want your model to get, if it's just a very simple app for a very simple store, that can often be overkill.