Claudio Lassala's Blog

In my previous post, I wrote about why starting a software project with CRUD features rarely pays off as people expect. One of the points I touched on is that the data feeding those tables might be owned by more than one part of the business. I want to make that concrete with an example.

The Inventory Adjustment Scenario

Picture a business with a warehouse and a back-office accounting team. Both departments care about inventory, but they care about different things.

The warehouse cares about physical inventory: quantities, locations, what’s on the shelf. When someone on the receiving dock finds that a forklift has backed into a pallet and damaged three cases of a product, they need to record that. Lot XYZ. Three cases removed. Reason: product damaged.

Accounting cares about the value of that inventory. When three cases are adjusted down that same lot, a transaction needs to be written to the general ledger. To do that correctly, there has to be a link between the adjustment reason and a posting account in the chart of accounts. That’s how the system knows where to record the loss.

The Table That Looks Simple

When you look at what this requires in a database, the structure seems obvious. An inventory adjustment reasons table. An ID. A user-facing code. A description. A posting account ID. Four fields.

How most developers see a “broken case”…

That’s an easy table to build. And the temptation is to say: someone needs to fill this out before the warehouse can start using the system.

But step back and look at who actually owns the pieces of that table.

The warehouse owns the codes and descriptions. They know what kinds of adjustments happen: product damaged, spoiled product, quantity correction, cycle count variance. That’s their domain. They know those reasons as well as they know their forklifts.

Accounting owns the posting account associations. They’re the ones who know which account in the general ledger should receive a write-off for damaged product versus spoiled product. That’s their domain. The warehouse shouldn’t assign ledger accounts, and accounting shouldn’t be defining the physical reasons for inventory movement.

How the warehouse and accounting see a “broken case”:

Two Departments, Different Timing

There’s another dimension here: when each department needs the data.

The warehouse needs a reason when they need to adjust inventory for a lot. If a pallet is damaged on a Tuesday morning, they can’t wait for accounting to finish associating posting accounts before they record it.

Accounting, on the other hand, may not need the posting account association until they’re closing the books at the end of the month or running an inventory valuation at the end of a specific period. Their window is different.

If the system is designed as though one team has to complete their part before the other can work, you’ve created a bottleneck. Accounting becomes a gatekeeper for warehouse operations. That’s not how the business actually functions.

A Better Model

What if we split those responsibilities the way the business actually works?

Inventory control enters adjustment reasons as needed. They own the codes and descriptions. When a new reason is added, accounting is notified: a new adjustment reason has been created. Please assign the appropriate posting account.

If inventory gets adjusted using a reason that doesn’t yet have a posting account associated, accounting gets an alert: an adjustment was recorded without a posting account. Please assign one before the next inventory valuation.

The deadline isn’t arbitrary. It’s tied to when the business actually needs the financial data to be accurate.

Now both departments can do their work when the work needs to be done. Neither is waiting on the other. The system reflects how the business actually operates.

What This Has to Do With CRUD

This is exactly the kind of thing that gets missed when a team starts with lookup tables. Four fields. Easy to build. Move fast, get it done, unblock the rest.

Except the table isn’t really a table. It’s a workflow. It has two owners with different knowledge, different responsibilities, and different timing requirements. Build it as a single admin screen with a single owner, and you’ve encoded an organizational bottleneck into the software.

Build it after you’ve understood the workflow, and you’ll know how to split ownership, build the notifications, and tie the deadlines to actual business events.

What I keep noticing is that the complexity isn’t in the data structure. Four fields are four fields. The complexity is in who enters which field and when, or more specifically, who needs what and when. And that only becomes visible when you follow the workflow before you design the table.