docs + locations

docs/Item.md

@@ -1,3 +1,67 @@
 # Item
-An item is the base concept for CDB. Everything is an Item. An Item describes a general product or object. An item can have multiple variants, beeing the concrete instances of the Item like brand products or different flavors, etc.
+An item is the base concept for CDB. Everything is an Item. An Item describes a general product or object.
+
+## Defining an Item
+An Item is defined within a markdown file with frontmatter. Items are the root dataset of CDB. One can use [this](https://git.hydrar.de/red/itemdb) as a starting point or create their own items.
+
+For example, we define a "Water" Item:
+```markdown
+---
+name: "Water"
+variants:
+  common:
+    name: "Common Water"
+---
+
+# Water
+This is a Water Item
+```
+
+The file consist of the frontmatter, containing values for the item, and the rest of the markdown file containing a description.
+
+## Variants
+Variants are different version of the same item. Each variant can have their own values. Each item needs at least one variant.
+
+For our water example:
+```yml
+name: "Water"
+variant:
+  regular:
+    name: "Regular Water"
+  sparkling:
+    name: "Sparkling Water"
+  destilled:
+    name: "Destilled Water"
+```
+
+Here we have defined three "Water" item variants.
+
+## Inventory
+With the items defined, you can start tracking their inventory. See [Transaction](Transaction.md).
+
+### Min
+You can set a minimum required inventory for an item variant. This will trigger events when an item reaches a low inventory threshold.
+
+```yml
+name: "Water"
+variants:
+  regular:
+    name: "Regular Water"
+    min: 2
+```
+
+This will ensure that at least two units of the "Regular Water" item variant are in inventory.
+
+### Expiry
+You can set a default expiry time for an Item Variant. This value is defined as days until expiry.
+
+```yml
+name: "Water"
+variants:
+  regular:
+    name: "Regular Water"
+    expiry: 30
+```
+
+This will mark any item variant as expired if it's older than 30 days.
 

docs/Location.md

@@ -0,0 +1,56 @@
+# Location
+A Location represents a physical location where items can be stored.
+
+## Defining locations
+A Location is defined within a JSON file. What a Location represents is up to you. One location can be as specific as individual storage boxes or as general as a whole room. You can even define a hierarchy and additional properties.
+
+Basic Example: Storage Box
+```json
+{
+    "name": "Storage Box"
+}
+```
+
+### Hierarchy
+You can add a hierarchy to your locations. Let's say for example we have one building we use for storage.
+
+So we create `storage_building1.json`:
+```json
+{
+    "name": "Storage Building"
+}
+```
+
+Then define a room for storage in `storage_room1.json`:
+```json
+{
+    "name": "First storage room",
+    "parent": "storage_building1"
+}
+```
+
+The `parent` field here defines that this location is inside another location, therefor setting up a hierarchy from larger scope locations to smaller scope. The `parent` field expects a location ID, which is typically the filename of the JSON without the extension.
+
+With this we can go even more detailed:
+```json
+{
+    "name": "Black Storage Box",
+    "parent": "storage_room1"
+}
+```
+
+### Properties
+You can define various properties for a location. This allows for checking the best location for an item based on it's requirements. If locations are in a hierarchy they will inherit the properties of their parents by default.
+
+#### Conditions
+Some items might be better stored under certain conditions. You can set the conditions of a location like temperature.
+
+Example: Freezer
+```json
+{
+    "name": "Freezer",
+    "conditions": {
+        "temperature": -10
+    }
+}
+```

docs/README.md

@@ -0,0 +1,7 @@
+# CDB Documentation
+
+- Item
+- Location
+- Statistics
+- Transaction
+- Webhooks

docs/Statistics.md

@@ -1,2 +1,3 @@
 # Statistics
-CDB can create various informational stats based on your dataset.
+CDB can create various informational stats based on your dataset.
+#todo

docs/Transaction.md

@@ -1,3 +1,17 @@
 # Transaction
-A Transaction represents an actual instance of an Item. This is a one to one mapping to a physical Variant of an Item. It can be consumed either manually or by a Process.
-This makes individual physical goods traceable.
+A Transaction represents an actual instance of an Item Variant.
+
+## Supply
+When you obtain an item and add it to your inventory a Transaction gets created. This is one unit of the item.
+
+Transactions can carry some information:
+- Price - The price this item was acquired at
+- Origin - Where this item is from
+- Location - The [Location](Location.md) of the item
+
+## Consume
+If an item gets used or is removed from the inventory, you consume the transaction.
+
+This adds some additional information to it:
+- Price - The price of the item at removal. e.g the selling price, or if negative cost of removal
+- Destination - Where this item went, e.g a person who requested this item

docs/Webhooks.md

@@ -1,2 +1,3 @@
 # Webhooks
-Certain events can trigger webhooks. This allows you to independently build your automation pipeline.
+Certain events can trigger webhooks. This allows you to independently build your automation pipeline.
+#todo