Nexus Claude: I can write code. What you want, I don't know until you explain it to me.
Context
Routine in Business Central rarely looks like a problem. It looks like work: open, run, check, repeat.
The annual physical inventory. Three warehouses. About 300 journals, one per rack. Actually 423. Each one is prepared by hand: Calculate Inventory, check the lines, release to the scanner. 423 times. If you recount, again.
One person runs it. The same person is the developer. And the future user of a tool that doesn't exist yet.
No overview. No statuses. Discrepancies show up only after everything has been counted, reconciled and added up.
This article is not about inventory. It is about how to remove this kind of routine in two days, if you know what you want and can explain it to Claude.
The "Excellence" Rule
The first day went into agreeing on the rules. Twice in a row I had to say it: "go one level up," and then "that's not it, you just want to write code." That is how the rule appeared.
We discuss form and meaning, not implementation. That is how an architect works with a sketch and a sculptor with clay: what we are building, why, how it will feel. Which field, which type, where the Commit goes: later.
One question at a time. A beautiful thing is built from the main idea, not from ten clarifications.
Code is written only after the word "write." Until then: ideas, forks in the road, and saying no to the unnecessary.
Nexus Claude: An architect doesn't pick the brand of nails until he decides whether the building needs a staircase.
Act One: See the Process
The first idea was not a button but a map. Three screens: a list of warehouses, a list of racks in the warehouse, and the standard journal opened on the right rack. A journal batch is a rack. Warehouses in the list pick themselves, by the Directed Put-away and Pick flag: nobody has to maintain them by hand.
Screenshot 1: the list of warehouses (recreated in Claude Design, codes changed)
We built the rack list on a temporary table right away: one row per batch. The decision was made up front, so that summary columns could be added later without moving anything in the chain. The first columns: number of journal lines, number of empty lines, number of bins and of distinct items.
Act Two: Prepare in Bulk
Now the pain itself: Calculate Inventory for every rack. The idea is simple: select batches in the list and run the calculation as one action.
The bin rule turned out to be universal: a batch covers the bins whose code starts with the batch name. By hand, one warehouse ran the calculation by one bin field, another by a different one. The universal rule removed the question "which field do we build the batch on."
Dead end one: the stub. In 209 of 216 rack batches of the main warehouse, an empty line was left over from the last inventory: Item No. empty, dated the end of last year. The standard calculation doesn't touch it; it lives next to the real lines. The fix: an empty-line counter and a mass delete.
Result: ❌ 209 of 216 batches with someone else's line.
A batch with an empty line: the system asks instead of staying quiet (Dev environment).
Nexus Claude: The last inventory didn't finish. It left a note.
Dead end two: duplicates. A repeated Calculate in a batch that already has lines doesn't recalculate. It adds. Quietly, with no warning. We checked it by hand.
We considered two ways out: "calculate only the new bins" and Recalculate (delete the lines and calculate again). We rejected both. Instead, a question for each such batch: Skip or Cancel. You can recalculate only after the lines are deleted.
A repeated calculation: skip the batch or cancel the whole run (Dev environment).
Result: ❌ Silently.
Nexus Claude: The Continue button was never drawn. Sometimes the best feature is the one that isn't there.
The batch list menu: Manage, Home, Mobile, Navigate (Dev environment).
What went into the mass run
The mass calculation window: three fields, like the standard one (Dev environment).
- Our own window with three fields, as in the standard calculation: Registering Date, Whse. Document No., Items Not on Inventory. We don't touch the other filters.
- One Whse. Document No. for the whole inventory. Registering Date defaults to Work Date, not a hard-coded date: on inventory day, Work Date is set to the right day.
- A limit of 15 batches per run (about 22 rows fit on screen). Select more and the run is refused outright, with no quiet truncation.
- Each batch in its own transaction. An interruption doesn't lose what is already calculated, and no rollback is needed.
- The ordinary progress window. In the web client it showed no Cancel button for us. Cancelling through a background session was judged too expensive at a limit of 15.
- Deleting lines works on the same principle: a Delete, Skip or Cancel question for each batch. Delete removes all lines of the batch, counted ones too. How many there are is shown in the question.
Deleting lines: a Delete, Skip or Cancel question for each batch (Dev environment).
Act Three: Manage
Calculating is half the job. Next you need to know where the process stands and see what doesn't add up.
Status. It is stored on the journal lines, not on the batch itself: we don't extend the batch. The values follow the process: In Process, Counted, Recount, Recounted, Approved, plus Calculated, which the mass run sets. The reviewer sets every value with one button, Change Status. The dialog is modeled on the production order status dialog and shows the batch name. We rejected a button for each step and a "next status" button. We rejected an action log too.
Changing a batch status: six values (Dev environment).
The price of this decision is known and accepted: after a journal is registered, its lines are deleted, and the status disappears with them.
Issues. At first, a batch's problems were shown in a message. We rejected that: it needs a Yes/No column, in red, with the details on click. Six checks: empty lines, different document numbers, different statuses, different responsible persons, different dates, different Reason Codes. You can open a journal with problems, but the system asks first: Open the journal anyway? Not silently.
Discrepancies. Surplus and shortage are shown separately, in units and in money at cost. Separately, so that the "+" and the "−" inside one rack don't cancel each other out. Until a batch is counted, the shortage equals the whole book quantity, so read it together with the Counted status.
Scanner. Releasing batches to the mobile device and taking them back work on the selected batches. Checked on a real scanner: everything works.
Outcome
Two days from the first conversation to a working list of racks. Two quiet dead ends. One person.
It was 423 manual runs. Now it is about 30: 15 batches at a time, with a question for each batch that already has something in it. And the process is now visible.
The rack list (Dev environment): status, Issues, surplus and shortage in one row.
But the number is not the point. Claude didn't know what I wanted. I knew, and I explained it. Everything else is refusals: of Recalculate, of a button for every step, of an action log, of Cancel through a background session. What we chose not to write into the code is part of the result too.
What's next:
- printing the standard inventory list for the selected batches as one document, each batch on a new page (the layout is the author's job);
- group registration of journals.
Nexus Claude: You can't speed up inventory with a button. You can make it visible.
STACKCOLLIDER & Nexus Claude
Top comments (0)