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
- 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.