# Warehouse Management: Stock that has to add up

> An internal tool for a staple-goods warehouse: stock, goods in and out, deliveries, and units that run five levels deep.

- Site: Falah Isnan (https://falah-isnan.com/work/warehouse-management)
- Author: Falah Isnan (https://falah-isnan.com/)
- Published: 2026-09-23
- Updated: 2026-09-23
- Discipline: Internal operations tooling
- Focus: Exact arithmetic under ordinary work
- Year: 2022
- Role: Internal tool — stock, movement, and delivery
- Client: Private company
- Stack: Not published
- Access: Private project

## The problem

One product can carry several units of measure with different rules. The quantity per pack is not consistent, the structure can run five levels deep, and damaged goods still have to be valued down to the smallest unit.

## The approach

Give every product its own unit ladder from a base unit upward, record movement rather than a stored count, and resolve damage down the ladder instead of rounding it to the pack.

An internal application for a staple-goods warehouse: what came in, what went out, what is on its way, and what is actually on the shelf right now.

It is unglamorous software with an exacting core. Stock is only as good as the arithmetic underneath it, and in this warehouse the arithmetic did not want to cooperate.

## What the project is

### Stock is a movement problem, not a number.

Goods received, goods issued, and deliveries are three different events that all resolve to the same figure. Tracking the figure alone tells you what you have and nothing about how you got there.

So the system records the movement and derives the stock, rather than storing a count and hoping the movements agree with it.

### One item, five units, none of them the same.

A single product can carry several units of measure, each with its own rules. The quantity per pack is not consistent between products, and the unit structure can run up to five levels deep.

That means there is no global conversion table. Each product describes its own ladder, and the system has to work in whichever unit the person in the warehouse is actually holding.

### Damage has to resolve to a number.

When goods are damaged, the loss has to be valued down to the smallest unit that exists for that product — not rounded up to the pack it happened to be sitting in.

This is the case that decides the data model. Get the unit ladder right and damage is arithmetic. Get it wrong and every damaged pack becomes a manual judgement call.

## The hard part: Units that do not divide evenly

Five levels of unit, a different count at every level, and a different ladder for every product.

1. **Start from the smallest unit that exists.** For each product, the base is whatever the warehouse can least meaningfully split. Everything above it is defined in terms of that base rather than in terms of each other.
2. **Let every level carry its own count.** A pack is not a fixed number of pieces across products, and a box is not a fixed number of packs. Each step of the ladder holds its own multiplier, per product.
3. **Value damage all the way down.** A damaged item is converted down the ladder to the base unit and valued there, so a loss inside a pack is recorded as what it actually was rather than as a whole pack.

## What you can open

Internal tool. The application, its link, and the client warehouse's name are not published. Everything here describes the problem and the approach, not the screens.