Invoicing

Kevin Wow. Invoicing is an incredible resource. <i>Thank You!</i>

(Obviously I need to RTFM w.r.t. the markup syntax used here. Sorry about that!) (laziness - check) (hubris - check)

It's not only a good idea, it's a great idea. Quantity belongs in the OrderDetailsT record. If a customer orders two identical mice, that is normally one line item with Quantity = 2.

The main exception is when you need to track each physical item individually, such as separate serial numbers, asset tags, or barcodes. In that case, the two mice need separate records so each one can have its own identifier and history.

And don't worry about the markup syntax. We all have to RTFM once in a while.

Regarding invoicing, you may need a separate invoice table if invoice detail (item, quantity price) could be different from order detail.  In my old job, that happened quite often.  Sometimes we had partial shipments or split shipments, so the invoice would only had partial detail from the order.  Sometimes we needed to overship or undership a quantity.  Sometimes the invoice price would be different from what was the agreed-upon price on the order.  Sometimes an invoiced item didn't exist at all in the order.

Yes, Kevin is completely right. What I teach in the basic order-entry examples is a simple, typical small-business setup. You create what I call an order, and in my courses there is a checkbox that lets you flag it as a quotation instead of an actual invoice.

You can send the customer the quotation ahead of time with "Quotation" across the top. Once they approve it and say, "Okay, let's do it," you convert it into an invoice, and the system then knows it needs to be paid.

For more complex businesses, you may absolutely need separate OrderT and InvoiceT tables. I've built systems where quotations go through multiple revisions, and you have to retain every version. The final approved quotation becomes an order, but then the order may be invoiced separately. You might invoice certain items to one department and other items to another department. Partial shipments, split shipments, over- or under-shipping, price changes, and invoice-only items all make a separate invoice structure appropriate.

Like Kevin said, it depends on the real-world workflow. The TechHelp examples are intentionally simple. In my developer courses, I get into more complicated scenarios involving multiple packing slips, shipments, and related invoicing. It's as simple or as complex as you need it to be. If you're running a lemonade stand, great. If you're running a multinational corporation with worldwide shipments, Access can handle that too.