Northbeam Precision / Daily Inventory Sync

What it replaces. A person, every morning: open the accounting system on the machine that hosts the company file, run a stock status report, export it to CSV, upload it into the workbook, then walk about a thousand rows setting today's date on everything that needs making and clearing it on everything that does not. Mechanical work, done once a day if it got done at all, and the whole production plan was only as fresh as the last time somebody did it.

What it does. One workflow on three cron triggers plus an on demand webhook. It pulls live stock through a bridge to a desktop accounting product, writes the inventory tab, and applies two rules to the reorder list: set the date and tick the box when the make quantity goes positive, clear both when it goes back to zero. The columns are addressed by position rather than by header name, deliberately, because headers get renamed by people and positions do not.

The rule that had to be deleted. The original workflow had a third rule that wrote the vendor name into the assignment column whenever the displayed assignment differed from the vendor. Read that condition again: the only time it is ever true is when a human has deliberately reassigned the part. So the rule's entire real world effect was to erase human intent and freeze the formula cell into static text, after which every future reassignment of that part silently did nothing. An estimated 212 rows were affected, 38 were restored by hand, and the failure presented as "the form is broken". Turn it on above and watch it happen to your own reassignment.

Why the fix was delicate. Restoring the formulas while the old version could still fire, on cron, on the webhook, or on a manual editor run that ignores the active toggle, would have re-frozen the cells within hours. The order was: deactivate old, activate new, then and only then repair the data. And the repair was itself a mass reassignment, because restoring a formula to a frozen cell silently moves that part to whatever its newest form submission says, which may be a terminal state. It was diffed old against new and signed off before it was applied, with before and after snapshots taken. One more trap: deleting the dead rule's body while leaving its counter variable referenced in the output would have thrown and killed the entire reorder half. Minimal edits still have to be complete edits.

The silent empty. The accounting call was configured never to throw. On any failure it passed its own error downstream as data. The parser took an early return path that produced an object with no rows field. The writer serialized that object, the missing field was dropped entirely by serialization, and the write went out with no values at all. The spreadsheet API returned success on a no-op write against a tab that had just been cleared. Result: an empty inventory tab, a run marked complete, and no error anywhere. The run log could not even reveal it, because the summary node read two field names the parser never emitted, so those columns were always null. Flip both switches above and watch a green run produce nothing.

Assignment is owned by people, and the chain is all formulas. A human submits a small form, responses land newest first, the assignment column looks up the newest one and falls back to the vendor, and the station tabs are pivots over that column. There is no script in the chain at all, which means a reassignment is one appended row and is trivially reversible by appending a newer one. It also means the station tabs keep no history, so any number read off one is live state and never a trend.

Measured. Roughly 1,030 reorder rows processed per run against a catalog of about 3,400 accounting items, of which about 1,300 are inactive and excluded from analytics by default. Three runs a day plus on demand. After the fix, a dry run produced zero writes to the assignment column and no errors, and the restored cells were verified one by one against the pre-change snapshot.