You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Proposal: forecast-based reorder points and shortage allocation ("Replenishment Planner") #5728
Hi, I'm Arnav, a developer interested in Ruby for Good's mission. I've built a prototype feature on a fork and would love feedback on whether it's something Human Essentials would want, and how you'd like it broken into PRs.
Problem
Today banks set on_hand_minimum_quantity by hand and LowInventoryQuery flags items below it. That number doesn't update as demand changes, so slow items can have high minimums (cash and shelf space tied up) while fast movers have none (surprise stockouts). There's also no help deciding how to split an item across partners when requests exceed what's on hand.
What the prototype does
Demand forecast per item: builds a monthly series from the last 24 complete months of distributions (or partner requests). It tries a few simple models (moving average, exponential smoothing, damped-trend Holt, seasonal naive) and picks the one with the lowest out-of-sample error on a rolling backtest.
Reorder point + suggested order: a standard periodic-review inventory policy. Safety stock scales with forecast error, lead time and a chosen service level (e.g. 95%). Items are flagged "Order now / Reorder / OK", shown next to the bank's existing manual minimum for comparison.
Shortage allocation: on an item page, if open requests exceed stock, it shows two suggested splits (proportional vs. max-min fair) with fill rates. It's advisory only and never changes requests or distributions.
It's read-only: no migrations, no changes to existing models or inventory events. New code lives in app/services/replenishment/, plus one controller, two views, a sidebar link, and specs.
@ruestitch@awwaiid@janeewheatley is this something the banks have expressed frustration / concern with? I'd rather not add a beefy feature into the app if there's no product demand for it, especially for something like this where the predictions could be dicey and might not give the user the right answer.
If there's a problem the banks have shown interest in solving, we should try to brainstorm possible solutions (of which this could be one).
Thanks to Sean for pointing out that I jumped to a PR before making the case. I've converted #5729 to a draft. Here is the case properly, including what I don't know yet.
What exists today
Each item can have an on-hand minimum quantity and an on-hand recommended quantity. Staff type both in by hand. They drive:
the low inventory list on the dashboard (red below the minimum),
warnings when a distribution drops an item below either level,
highlighting on the Items tabs and itemized reports.
The Requests - Itemized report also shows requested quantity next to on-hand stock.
The problem I think exists (not yet validated)
Those two levels are fixed numbers. If an item starts moving faster (a new partner, a seasonal spike), or restocking takes longer than usual, the warning can come too late to reorder or run a drive in time. The warning doesn't use how fast the item is actually going out.
A second, related problem: when partner requests for an item add up to more than the bank has, staff split the stock by hand.
How this could be validated
I haven't validated either problem with a bank yet. What would tell us whether they're real:
Ask a few banks how they choose their minimum and recommended levels, how often they update them, and how often they run out of an item before restocking.
Aggregate data, if a maintainer is willing to check (for example in Metabase): the share of items that have a minimum or recommended level set, and how often items hit zero on hand. If most banks never set them, a better formula won't help. Better defaults or guidance might.
Alternatives, smallest first
Documentation only: guidance in the user guide on choosing levels (for example, average monthly distributions times months to restock, plus a buffer).
Suggested levels on the item page: show a suggested minimum and recommended quantity computed from the last 12 months of distributions next to the fields staff already fill in. Staff choose whether to use them. It's small and fits the existing workflow.
"Months of supply" on the low inventory list: one extra column, computed from recent distributions.
Outside the app: a standalone script that turns a bank's export into a stockout report, with no change to Human Essentials.
My current view is that option 2 is probably the right starting point if validation shows a real need, and #5729 should stay a draft or be closed unless banks ask for more.
What I'm asking
Is this worth validating?
Is there a bank or stakeholder I could talk to?
Would anyone be able to check the aggregate numbers above?
Yes -- I've certainly heard banks (I think Judy) making offhand remarks about forecasting being cool, but the tone was always "someday". I like proposals that come with working code. We have the next stakeholder meeting on Oct 7 and we could do a demo/exploration of this at that meeting.
Put this into the "reports" section instead of as its own toplevel tab
I like how isolated this is in general; in addition to the feature-flag, could you make this a feature toggle that each bank can change?
We were recently talking about (or have PRs for, I can't remember) introducing per-item low-inventory per-location (warehouse). Can you incorporate that concept in?
While we very much appreciate the work and proposal, the more hand-written you can make the content that you share with us the better. Machine generated machine code = good; machine generated human communication = .... less good.
We meet together on Sunday mornings (10am US-ET) and we meet with stakeholders once a month. We want to make sure we ground all changes in actual needs as much as we can, though of course sometimes the banks don't know what is possible -- so this sort of new functionality is cool but as sean maybe told you we have to all be brought along the journey together! So feel free to come talk to us in real time.
In any case we'll bring this up with the stakeholders on Oct 7 and go from there.
Activity
dorner commentedon Sep 25, 2026
@ruestitch @awwaiid @janeewheatley is this something the banks have expressed frustration / concern with? I'd rather not add a beefy feature into the app if there's no product demand for it, especially for something like this where the predictions could be dicey and might not give the user the right answer.
If there's a problem the banks have shown interest in solving, we should try to brainstorm possible solutions (of which this could be one).
arnavt687 commentedon Sep 25, 2026
Revised proposal (after feedback)
Thanks to Sean for pointing out that I jumped to a PR before making the case. I've converted #5729 to a draft. Here is the case properly, including what I don't know yet.
What exists today
Each item can have an on-hand minimum quantity and an on-hand recommended quantity. Staff type both in by hand. They drive:
The Requests - Itemized report also shows requested quantity next to on-hand stock.
The problem I think exists (not yet validated)
Those two levels are fixed numbers. If an item starts moving faster (a new partner, a seasonal spike), or restocking takes longer than usual, the warning can come too late to reorder or run a drive in time. The warning doesn't use how fast the item is actually going out.
A second, related problem: when partner requests for an item add up to more than the bank has, staff split the stock by hand.
How this could be validated
I haven't validated either problem with a bank yet. What would tell us whether they're real:
Alternatives, smallest first
My current view is that option 2 is probably the right starting point if validation shows a real need, and #5729 should stay a draft or be closed unless banks ask for more.
What I'm asking
I'm happy to follow whatever process you prefer.
awwaiid commentedon Sep 27, 2026
Yes -- I've certainly heard banks (I think Judy) making offhand remarks about forecasting being cool, but the tone was always "someday". I like proposals that come with working code. We have the next stakeholder meeting on Oct 7 and we could do a demo/exploration of this at that meeting.
@arnavt687 a few notes/requests:
We meet together on Sunday mornings (10am US-ET) and we meet with stakeholders once a month. We want to make sure we ground all changes in actual needs as much as we can, though of course sometimes the banks don't know what is possible -- so this sort of new functionality is cool but as sean maybe told you we have to all be brought along the journey together! So feel free to come talk to us in real time.
In any case we'll bring this up with the stakeholders on Oct 7 and go from there.