Order entry is one of those application types that is pretty well defined but with some variations. One thing is that you either store the item prices by date or you copy the price onto the orderdetail record. I prefer copying the price but I still keep price by date because if I know the price is going up on Tuesday, I'd like to enter the new price today with an effective date of Tuesday. That process adds an end date of Monday to the current price record to close it out so it won't be used after Monday. If I keep only a single price, I have to shut down the app and update the product table at midnight on Monday to get the new price in place.
Tax is a little different. the rates don't change often but they do. There can also be multiple tax jurisdictions involved, at least in the US. So, each item might have city tax, county tax, state tax, and federal tax so there are classes or no tax at all. Customers may be subject to tax or exempt. Tax is so complicated in the US that it is frequently calculated with purchased software. So the tax rate is usually stored in the order.
The order itself has several status values. It starts with incomplete, which is why we create orders in the production table rather than create them with unbound forms or shadow tables. When the order entry is complete, the user marks it complete and sometimes validation is done to ensure nothing is missing. Then the order goes to picking, then to shipping, and finally to billing. Your schema considers none of this at the moment.
Another variation is do you encumber inventory as the item is entered? The answer is - it depends. If you are taking an order on the phone or on line, the answer is yes. This is the only way to prevent selling items you don't have in stock. If you don't reserve the inventory when the order is entered, you have to deal with out of stock in the picking process and make rules regarding whether you ship incomplete orders or wait until they can be completely filled.
