Stock levels that subtract correctly.

Take a file

Take products-100.csv alongside this and inventory value reconciles across the two files, because the unit cost on a snapshot row is the catalog cost for that SKU.

Turn a snapshot into a history

Larger sizes add snapshot dates rather than SKUs, so a hundred thousand rows is roughly 1,600 dates across the same sixty products. That turns a snapshot into a history, which is when the interesting questions start.

Ten columns, and what each one holds

What it models

A stock position: for a given date, warehouse and SKU, how many units are in the building, how many are already promised, how many are actually sellable, and whether that number has fallen below the level that triggers a purchase order. It is the file that sits behind every out-of-stock alert.

Snapshot dates advance in blocks of sixty rows, one per SKU, so the 1,000-row file covers about seventeen dates. Warehouse is drawn per row rather than fixed per block, which is a simplification worth knowing about: this is a sample of positions rather than a complete count of every site on every date.

The arithmetic, and the flag

available is on_hand minus reserved, computed rather than drawn, and a test asserts it on every row. reserved can never exceed on_hand, so available is never negative, which spares you the conversation about whether negative stock is a data error or an oversell.

below_reorder is true exactly when available is under reorder_point. Like every other derived column in this collection, it is computed from the numbers on the same row, so the flag and the quantities cannot drift apart. That makes it a reference answer: write the rule yourself, apply it, and the two columns should match on all 1,000 rows.

days_of_cover is available divided by that SKU's mean daily demand, to one decimal. It is the column that turns a quantity into a decision, and it is also the one most likely to be infinite or undefined in real data when demand is zero. Here demand is always at least three units a day, so the column is always finite, which is a deliberate simplification rather than an accident.

Why it shares keys with the catalog

Every sku is between SKU-1001 and SKU-1060, the same space the orders dataset uses, and unit_cost is the catalog cost for that SKU. So the three files fit together: the catalog says what a thing costs and sells for, inventory says how many you hold, and orders says how many you sold.

That combination lets you build the reconciliation that most sample data cannot support. Inventory value at cost, revenue at price, units sold against units held, all from files whose keys resolve and whose prices agree. It is the difference between a demo that shows a chart and a demo that shows an answer.

It shares keys with the catalog

sku is SKU-1001 to SKU-1060 and unit_cost matches the products catalogue, so inventory value reconciles across the two files.

The pairing to try is inventory against the product catalog on sku. Multiply on_hand by unit_cost and sum by warehouse and you have inventory value by site, which is the number a finance team asks an operations team for and the one that is hardest to produce when the two files disagree about what a SKU costs. Here they cannot disagree.

Open it somewhere useful

Inventory value is a join and a multiply, which makes the merger and the pivot table the two tools that earn their place here.

Questions people ask about this file