Changed because somebody said so

We took his advice and then got the last word of it wrong.

Denyslg · said September 4, 2026 · live 11 days · builds a competing app

Missing from the formulas above: where the lead time number comes from. Most people type in what the supplier told them, and suppliers quote their best case. Your own receiving history knows better, because it holds the real number of days between raising each order and the stock actually landing on the shelf.

We took his advice and then got the last word of it wrong. The app measured from its own receiving history, as he said it should, but read the day the merchant closed the purchase order rather than the day the delivery was booked in. Closing an order is paperwork and it always happens after the lorry, so the error could only ever run one way: a supplier who delivers in thirty days, on an order tidied up three weeks later, was recorded at fifty. Every reorder point for them was then sized for fifty days - two thirds more stock than the shelf needs, held permanently, and ordering started three weeks early. It now measures to the first delivery recorded against the order. Eleven days, because nobody went back and checked which date “actually landing on the shelf” meant.

He was describing his own app.

nandor_nasolv · said September 14, 2026 · live next day · builds a competing app

I fixed the denominator first, the obvious one, dividing by days in stock instead of calendar days. Then a steady seller that had run out started coming back as “erratic”, and it took me a while to see why: the empty weeks are still sitting in the variance. So the fix for the average made the spread worse, and the product I should have been most confident about was the one getting hedged.

He was describing his own app. It was true of this one, and I had posted the same diagnosis to that thread a fortnight earlier without ever looking for it here. Dividing units by days in stock repaired the average; the variance was still handed the calendar, so every day a product could not be bought counted as a day of zero demand. A line selling three every single day that then spent three weeks out of stock came back with a standard deviation of 1.4 instead of 0, and was given a nineteen-unit buffer it has never needed. The direction is what made it expensive: the better the seller the more likely it ran out, so the hedging landed hardest on the products with the best claim to that cash. The spread now divides by the days on sale.

His complaint was about Shopify Inbox, and the same two states were collapsed inside our own arithmetic.

robinthebest · said September 14, 2026 · live same day

We run a wine store where backorder inventory is a core part of our catalogue. Since enabling the Shopify Inbox agent, we've noticed it consistently excludes products with zero stock from search results and recommendations - even when those products are published and available to order as backorders.

His complaint was about Shopify Inbox, and the same two states were collapsed inside our own arithmetic. We discount the days a product sat empty so a best seller is not under-ordered for having run out. For a shop selling on backorder those are selling days, and they are most of them, because the allocation goes first and the demand carries on. We were deleting exactly the days the demand happened on and under-ordering the lines that sell hardest. The test is now whether the variant could be bought, not whether the shelf was empty.

He tested the claim in our own post rather than taking it, and the fields we had fixed turned out to be the wrong half.

lumine · said September 14, 2026 · live same day

Swapping parseInt for Number looks like it closes it. Number("1,200") is NaN, so you catch it. But that NaN almost always lands next to a || 0 somewhere downstream, and then the number that gets written is 0, not 1. [...] The one that actually got me is the European format. Number("1.200") is 1.2. Not NaN. It passes every guard you just wrote.

He tested the claim in our own post rather than taking it, and the fields we had fixed turned out to be the wrong half. The money boxes were still reading with parseFloat, including the one that sets the retail price on Shopify: 1,200 typed with its separator read as 1, passed a finite-and-positive guard, and would have put a twelve hundred item on sale for one. The purchase order line cost carried the exact trap he names, parseFloat(raw) || 0, where an unreadable cost became free and quietly flattered the margin. Money is now read by shape and anything with two readings is refused rather than guessed, and unreadable leaves the stored figure alone instead of collapsing to zero. His test also found a smaller version of it in the quantity parser we thought was finished: every comma was stripped, so 1,2 read as 12.

Repeat shortages were grouped by product alone, and the location was recorded on every count and then thrown away by the analysis.

SealSubs-Roan · said September 13, 2026 · live next day

The trick is to be able to identify repeat variances by SKU, location, or over time. The history of the same SKU being repeatedly short becomes far more valuable than one single stocktake.

Repeat shortages were grouped by product alone, and the location was recorded on every count and then thrown away by the analysis. A product short three times in one stockroom is a cause with an address; the same total spread across four is a supply or counting problem, and merging them lost the only part that says where to walk. The report now names the place when the counts agree on one, and says how many places when they do not.

A gap now records what was done as well as what caused it, and where the answer leaves it open it asks who is chasing it and by when.

clickfromai · said September 12, 2026 · live same day · builds a competing app

Keep the cause separate from the fix. Cause might be transfer not received, damage, picking error, or unknown. Fix might be inventory adjusted, transfer corrected, or recount needed. For unknown, add a person and review date. Otherwise unknown becomes a dead end.

A gap now records what was done as well as what caused it, and where the answer leaves it open it asks who is chasing it and by when. One of his examples is deliberately missing: this app performs the inventory adjustment itself, so a box asking somebody to type it would only repeat what it already knows. The fields are not the cure for a dead end — a name typed once and never read again is the same dead end with more typing — so the shrinkage screen leads with what is still open, what is past its date, and what has nobody's name on it at all. Picking error is now one of the causes, which it was not.

This corrected a feature built two days earlier from his own earlier sentence.

gotinker · said September 11, 2026 · live next day

Most of the blank ones for us are the first kind. Someone counts, sees it is off by one or two, and the shelf is already corrected before anyone wants to invent a sentence. The puzzling ones almost always get something. So when the same SKU is blank three counts in a row I treat that as we keep not bothering to stop, not mystery.

This corrected a feature built two days earlier from his own earlier sentence. A run of blank reasons was being marked as a mystery to investigate; he pointed out that the puzzling shortages get a note at the time and the blank ones are the ones too small to stop for. It now reads as a small leak nobody stops for, and reports what it has cost rather than inviting an investigation into a puzzle that is not there.

A stocktake line no longer asks why unless it is out by more than two units, worth more than a figure you set, or the same product was short in an earlier count.

clickfromai · said September 12, 2026 · live same day · builds a competing app

What has worked for us is not forcing a reason on every variance. That just creates junk notes. Require a note when the variance is over 2 units, over a set dollar value, or the SKU was also off on the previous count. Small one-off misses get corrected and ignored.

A stocktake line no longer asks why unless it is out by more than two units, worth more than a figure you set, or the same product was short in an earlier count. Asking on every line never produced more answers — it produced the same answers plus a screenful of blanks, and it taught people to skip the field on the lines that mattered. The value figure has no default: twenty of anything means something different in yen, so until you set one, gaps are judged on size alone and the screen says so.

A purchase order now says so before it is sent, compared against what deliveries actually cost rather than what older orders said.

Denyslg · said September 11, 2026 · live same day · builds a competing app

Worth flagging automatically: a new order priced above the last receipt for the same SKU, or an invoice that comes in above the order. Both fall straight out of the receipt rows, and both are how margin leaks without anyone deciding anything.

A purchase order now says so before it is sent, compared against what deliveries actually cost rather than what older orders said. Reading his post also turned up a bug of ours: the cost written back to Shopify was weighted against available stock rather than what is in the building, which drags the average toward the new price hardest in the busiest week.

The computed reorder point was worked out and thrown away whenever you typed your own.

gotinker · said September 10, 2026 · live same day

Suggested mins I would ignore unless they are clearly wrong on a SKU I already care about.

The computed reorder point was worked out and thrown away whenever you typed your own. It now appears in one place only: where your number cannot cover your lead time. Your number is still the one used — the line says what it costs, not that you were wrong.

The screen built for his point above was ignoring products you had already silenced, which would have been exactly the trap he described.

getnetnet · said September 10, 2026 · live same day

Discontinued and end-of-season products will keep firing forever if the floor is driven by history and nobody can push it down. If there is no “not reordering this” state, that noise is what teaches people to filter the whole alert channel.

The screen built for his point above was ignoring products you had already silenced, which would have been exactly the trap he described. It respects the setting now, and says how many it is holding back rather than quietly shortening the list.

The lead time now shows on every row beside the days remaining.

getnetnet · said September 10, 2026 · live same day

“11 days of stock left, replacement takes 40” is something a merchant can sanity-check. “40 units” is not.

The lead time now shows on every row beside the days remaining. It used to appear only once a supplier had been entered, which took the check away from exactly the shop that needs it most — a new one.

A new screen for stock that stopped moving, which no low-stock alert can find because nothing is low.

getnetnet · said September 10, 2026 · live same day

A product that quietly stopped selling never approaches any threshold, high or low, so no amount of tuning surfaces it. That one needs its own signal: in stock, was selling, zero sales in N days.

A new screen for stock that stopped moving, which no low-stock alert can find because nothing is low. It says what the stock is worth and never calls it dead — a seasonal line out of season looks identical and only you can tell them apart.

A refund only counts as demand if the unit actually shipped.

Kalvin_Mizzi · said September 9, 2026 · live next day

The restocked flag is being asked to answer two questions with one bit. NO_RESTOCK is not one thing. A customer sent it back and it could not be resold... Or the line was refunded before anything was restocked and nobody ever returned anything. Nothing was consumed, and your rule counts it.

A refund only counts as demand if the unit actually shipped. He proposed checking for a Return; that misses the case he named himself, telling a customer to keep a faulty item, which creates no Return at all. The fulfilments settle it instead.

The app says this before you press the button rather than after, so the day is yours to pick.

Kalvin_Mizzi · said September 9, 2026 · live next day

Cost per item is read live by your inventory valuation. Type a new number in and every unit you are holding revalues, including the ones you bought at the old price. If that lands inside a period your accountant is closing, it is a real number on a real report.

The app says this before you press the button rather than after, so the day is yours to pick. There was no code to fix — Shopify holds one cost per item and that is that. What was missing was saying so.

The cost trail now shows both figures and says which describes what.

Kalvin_Mizzi · said September 9, 2026 · live next day

(40 x 10 + 60 x 12) / 100 = 11.20 weights the average by what you bought. What you own is a different set. If thirty of those March units sold before May turned up, the stock on your shelf is ten at $10 and sixty at $12, which is $11.71.

The cost trail now shows both figures and says which describes what. Cheap units sell first, so an average weighted by what arrived keeps counting units that are already gone — understated cost, overstated margin, widening while prices rise.

The note on a stocktake line no longer hides behind the reason dropdown — you can type what happened and pick nothing at all, which is how he actually works.

gotinker · said September 9, 2026 · live same day

We keep a notes column on the same sheet as the count, next to the SKU. Nothing fancy. Most notes never get reread until the second hit. The SKUs that never get a note are usually the ones that keep coming back.

The note on a stocktake line no longer hides behind the reason dropdown — you can type what happened and pick nothing at all, which is how he actually works. Products short in more than one count are named on their own. What a run of blanks means took another two days and another correction from him; see below.

What this list is not

It is not everything that changed — most of the work here came from nobody in particular. It is not a promise about how fast the next one will be; the dates above are what actually happened, including the slow one. And it is not a claim that the app is finished. The reason this page can exist at all is that people keep finding things wrong with it.

If you have one, the threads above are open, or the app’s support address is on its App Store listing. Being told the arithmetic is wrong has been the most useful thing that has happened to this app so far.