order_schema

```
Order schema
- has_many order_items
- has_many taxes
- has_many fees
- has_many discounts
- id
- timestamps
- print_count (for storing number of times order was printed)
- note - string
- subtotal - price of all selected items without fees and taxes applied
- total_price - price of all selected items with fees and taxes applied
- completed - timestamp. to keep track of how long before an order is fulfilled
- snapshot - json field - stores all relevant data at the time of order

Tax schema
- value - decimal
- percentage - boolean
- name

Fee schema
- value - decimal
- name

Discount schema
- value - decimal
- percentage - boolean
- name

OrderItem schema
- has_one selected_item
- has_many selected_modifiers - must be selected from modifiers of the selected_item
- has_many taxes
- price - store price of selected item with modifiers selected
- note

SelectedItem
- belongs_to item - must be a combo_option or an item_option
- price

SelectedModifier
- belongs_to modifier
- price

Refund schema - should have at least one association. associations here represent the refunded item
- timestamps
- has_many order_items
- has_many selected_items
- has_many selected_modifiers
- has_one order
- reason

Comp - should have at least one comp. comps here represent the comped item
- timestamps
- has_many order_items
- has_many selected_items
- has_many selected_modifiers
- has_one order
- reason
```

Order schema
- has_many order_items
- has_many taxes
- has_many fees
- has_many discounts
- id
- timestamps
- print_count (for storing number of times order was printed)
- note - string
- subtotal - price of all selected items without fees and taxes applied
- total_price - price of all selected items with fees and taxes applied
- completed - timestamp. to keep track of how long before an order is fulfilled

Tax schema
- value - decimal
- percentage - boolean

Fee schema
- value - decimal
- name

Discount schema
- value - decimal
- percentage - boolean

OrderItem schema
- has_one selected_item
- has_many selected_modifiers - must be selected from modifiers of the selected_item
- price - store price of selected item with modifiers selected
- note

SelectedItem
- belongs_to item - must be a combo_option or an item_option
- price

SelectedModifier
- belongs_to modifier
- price

Also note that order items may themselves have notes.

Ok - just want to make sure we're accounting for the fact that a combo may have multiple items chosen from multiple item groups, and these selections will render within a single order tab 'section' (see hi-fi Menu Screen wireframes for reference).

• A reference to combo option will mean we can get all its associated references (combo, item groups, items, etc...). Same with selectedModifiers. In the graphql_schema, we can make SelectedItem return the ff field:
  • Item name > which will either be combo name or item name (depending on which one is selected)

Wondering if this schema can/needs to support voids, refunds, and partial refunds (or combinations thereof) after the order has already been 'placed'.

OrderItems can also be comp'd/discounted individually.

The price of each item is going to fluctuate in the DB, so we will want total_price to be non virtual and captured @ time of sale.

• Is the tax on individual items/combos or on the total order? Are individual items likely to attract different tax rates? Depending on the answers, the order item might need to have these inline

• Should orders have versions? For example, to allow modification after it has been entered. If this is likely to be a use case in a later version, the DB schema should take this into account even if currently we only use one version. Edit: Similar to Ian's comment above

• Should 'discounts' be replaced with something generic like offers (discounts, buy something and get something free, etc)? If this is likely to be needed in future, discounts should be structured as an offer for V1

• We should basically be able to reprint the original order exactly as it is (names, composition, tax names, tax values, prices, all other details) at any later date. This should be kept in mind when deciding what parts of the orders should be snapshotted. Edit: One way would be to take the entire Order (containing values, not references) that qtclient has generated and store it as a JSON field as is. The rest of the normalized schema can then remain (still useful for other reporting/analytics purposes)

• minor nit - tax should have a name

A single coupon can also fluctuate in some restaurants over time (same coupon is tweaked and redeployed...); We will want to capture current state information of the coupon. Final cost of each item (after all additions and discounts) should also be recorded with each item so it can be displayed back on the Order History screen in the UI.

I realize this is a lot of data, however we can't allow changing of an items pricing or coupon discount changes to effect historical data.

Re: Justin's comments: fortunately for v1, I we're not going to need to handle coupons, so hopefully adding that later won't be too bad.

Re: Kul's comments:
Is the tax on individual items/combos or on the total order? Are individual items likely to attract different tax rates? Depending on the answers, the order item might need to have these inline
Taxes on individual items are a v2 feature and will not be included in v1 - we need to account for adding that feature, which we 100% will have to, but for now, we don't need to worry about that.
Should orders have versions?
Curious how you would envision the implementation of this, but not a bad idea, overall. +1 on including this as a feature in v1.
Should 'discounts' be replaced with something generic like offers (discounts, buy something and get something free, etc)? If this is likely to be needed in future, discounts should be structured as an offer for V1
There aren't really 'discounts' per se in v1 (this will be v2+ along with coupons, etc.), only 'comps' for items and orders (and partial comps for orders).
We should basically be able to reprint the original order exactly as it is (names, composition, tax names, tax values, prices, all other details) at any later date.
We will 100% need to be able to do this.

Order schema
- has_many order_items
- has_many taxes
- has_many fees
- has_many discounts
- id
- timestamps
- print_count (for storing number of times order was printed)
- note - string
- subtotal - price of all selected items without fees and taxes applied
- total_price - price of all selected items with fees and taxes applied
- completed - timestamp. to keep track of how long before an order is fulfilled
- snapshots - json field - stores all relevant data at the time of order. the names of the order items, fees, taxes, discounts and their corresponding values. key will be timestamps since we will have multiple snapshots. latest snapshot will have time equal to that of the updated_at field. 

Tax schema
- value - decimal
- percentage - boolean
- name

Fee schema
- value - decimal
- name

Discount schema
- value - decimal
- percentage - boolean
- name

OrderItem schema
- has_one selected_item
- has_many selected_modifiers - must be selected from modifiers of the selected_item
- has_many taxes
- price - store price of selected item with modifiers selected
- note

SelectedItem
- belongs_to item - must be a combo_option or an item_option
- price

SelectedModifier
- belongs_to modifier
- price

Changes to above updated schema:

• added snapshot json field.
• add has_many taxes to OrderItem schema

Questions:

• Should 'discounts' be replaced with something generic like offers (discounts, buy something and get something free, etc)? If this is likely to be needed in future, discounts should be structured as an offer for V1

• If we add offers (different from discounts) later on, it looks like it will have different fields from discounts so it will be a separate schema

• Should orders have versions?

• @Khul what did you have in mind for versions? Do you mean that every update to an order would create a new order?

Instead of adding timestamps fields for comps/refunds (since those will be null for most orders), adding schemas for those instead. The schemas look like:

Refund schema - should have at least one association. associations here represent the refunded item
- timestamps
- has_many order_items
- has_many selected_items
- has_many selected_modifiers
- has_one order
- reason

Comp - should have at least one comp. comps here represent the refunded item
- timestamps
- has_many order_items
- has_many selected_items
- has_many selected_modifiers
- has_one order
- reason

A little confused on the Refund and Comp schemas:

- has_many order_items
- has_many selected_items
- has_many selected_modifiers

Unsure what these mean exactly...
An order may have multiple partial refunds and/or comps, up to the total amount.
An orderitem may only have a single refund or comp, of the total amount of that orderitem.

If a Refund has_one order, then the whole order is refunded. If a refund has one selected_item, then only that one selected item is refunded. Did it this way instead to avoid columns that would usually be null anyway.

@gjaldon this accounts for multiple partial refunds on a single order too though, right?

@ian-bateman yes, it does. If a Refund has no order association but has at least one selected or order_item or selected_modifier, this will mean partial refund of the order.