Reorder software that is not a demand forecast, an auto-purchase-order engine, or a manufacturing system
A reorder rule is a number somebody chose once. It came from a demand assumption and a lead time, and both of those keep moving while the rule stays exactly where it was — so the failure of this category is rarely a wrong number appearing, it is a right number quietly ceasing to be true. Stock movement, purchasing, the warehouse records and the low-stock signal live in Commerce. What NoxOrigin holds is the threshold you wrote, the comparison against what is on hand, and the record of who set it and when. There is no demand forecasting model, no auto-purchase-order engine, and no manufacturing capability set here. That is not a gap in the page: an order placed automatically on a wrong assumption is worse than a manual order, because it spends your money, arrives too late to be useful, and does it again next week without anyone awake to object.
Five products this is not, and the one thing it is
Everything under the reorder-and-low-stock name belongs to one of the five below. None of them is in NoxOrigin, and the sixth item is what you get instead.
The demand forecasting model
There is no demand forecast, no seasonality detection, no trend or moving-average function, no suggested order quantity, no forecast-versus-actual comparison, and no learning from what was ordered against what sold. Nothing in NoxOrigin estimates what will be needed next week. If a threshold needs to be right by itself, this page is not the product, and the right question to ask any vendor is what the error was on their own past periods.
The auto-purchase-order engine
There is no automatic draft order, no scheduled reorder run, no auto-raise on threshold breach, no suggested quantity, no approval workflow for buying, and no supplier lead-time tracking that changes a rule. A purchase order placed on a wrong assumption is money committed to the wrong quantity at the wrong time, and the engine that placed it has no way of knowing it was wrong. That is why the ordering decision here stays with a person.
The manufacturing system
There is no bill of materials, no routings or work centres, no shop-floor or production scheduling, no job or production costing, no capacity planning and no manufacturing capability set of any kind. Bill of materials, shop-floor scheduling and production costing are a different category of software, sold to a different buyer, answering a different question — and if that is your problem, this page should send you elsewhere rather than half-fit you.
The warehouse control layer
There is no bin-level location model, no wave or pick-path planning, no generated replenishment task list, no cycle-count program and no dock or receiving queue. The warehouse records live in Commerce. What is not here is a task-generation layer for a picker, because a generated task inherits every wrong assumption in the rule that produced it and removes the last person who would have noticed.
The stock analytics product
There is no sell-through reporting, no shrinkage tracking, no dead-stock ageing, no days-of-supply view and no inventory-turn benchmark, and this page quotes no turn rate, no shrinkage percentage and no industry average. Those figures are measured outcomes of a stock record set over a named period with a named denominator — and the denominator is chosen after the fact more often than not.
What there is instead: a threshold you wrote, a comparison you can read, and a person who orders
The number, the date it was set, the person who set it, and the review date it should next be checked. The low-stock condition compares it against what is on hand and reports the comparison. It is small, it can be wrong, and every part of it is visible — which is the only property that makes a buying rule worth keeping.
A reorder routine with a person at the end of it
Six steps. The first three are about the number, the last three are about the decision it produces — and the last step is the one no automation on this list would let you keep.
Write the demand assumption down, with the period it came from
Not a number on its own — a number plus where it came from and over what period. Every reorder rule starts here, and the two things that break it are a demand figure nobody can date and a lead time nobody has confirmed with the supplier. When the assumption is written down, it can be wrong in a way that is visible; when it is in somebody’s head, it cannot.
Separate lead-time cover from the buffer you chose
Lead-time cover is arithmetic from your own two figures. The buffer on top of it is a judgement about what happens when those two figures are wrong. Keeping them apart in your head, in the number, and in the review note is what lets you tell later which of them no longer holds, instead of adjusting one until the rule looks reasonable again.
Set the threshold once, and give it an owner and a review date
A reorder point entered with no owner is a number that will still be there in two years, answering a question nobody is asking. The owner is the person who chose the figure; the review date is when they last checked it against actual demand and actual lead time. A rule with a review date is a decision; a rule without one is a fossil.
Let the low-stock condition fire, and read it as information
The condition compares quantity on hand against the threshold and reports the comparison. It is true or false about two records and nothing more — it does not know why a threshold was set, whether a purchase is already in flight, or whether the shelf is full because the units are on another record. Reading it as information rather than as an instruction is the difference between a warning and an accident.
Have a person place the order, and check it against the open one
Nobody is woken up and nothing is submitted. The decision covers quantity, supplier, and whether an order already exists for the same item — the case a stock threshold handles worst, because a duplicate purchase order looks exactly like a good one until the second invoice arrives.
Write the outcome down: what was ordered, and what it turned into
Ordered quantity and date, so the next review compares the rule against what actually happened rather than against what was intended. This is the only part of the cycle NoxOrigin can help you keep, and it is the part that turns a number somebody chose once into something a team can actually argue about.
One item, one rule, and what happens when the assumption moves
Every figure below is constructed for this page so the arithmetic can be checked by hand. It is not a NoxOrigin result, not a customer’s stock record, and not a benchmark — the demand, the lead time and the buffer were chosen to make the arithmetic visible, and NoxOrigin computes none of them. Replace all of it with your own movement history before drawing anything from it.
The rule as it was written
Item X sold 45 units in the last 30 days, so average demand is 45 ÷ 30 = 1.5 units a day. The supplier quotes 9 days of lead time, so lead-time cover is 1.5 × 9 = 13.5, which is 14 units. A buffer of 6 units was chosen on top, so the reorder point is 14 + 6 = 20 units. Three inputs, one addition, and all three are numbers a person picked — NoxOrigin does not calculate any of them and does not maintain them either.
The comparison the low-stock condition makes
Item X has 18 units on hand. 18 is below the reorder point of 20, so the low-stock condition is true. That is the entire output: one record’s quantity compared against one number, reporting true or false. It does not know why 20 was chosen, whether a purchase order is already in flight, whether the supplier is behind, or whether the buffer is still the buffer you would pick today.
What a week of automatic ordering would have cost
20 units at a constructed unit cost of ₹340 is ₹20 × 340 = ₹6,800 per order. If the condition fired once a week for four weeks, that is ₹6,800 × 4 = ₹27,200 committed to a rule nobody has reviewed. Constructed, and the point is not the amount: it is that an automatic order has already been placed by the time anybody sees the condition, so the number of times it can be wrong per year is bounded only by how often it fires.
When demand turns out to be 3 a day instead of 1.5
Lead-time cover becomes 3 × 9 = 27 units, so the reorder point should be 27 + 6 = 33. The rule on the screen says 20, which is 33 − 20 = 13 units short. A manual orderer who knows the item is moving fast will simply order more; an automatic engine would have fired at 20, ordered 20, waited 9 days, and repeated — arriving late every single time, which is the specific failure that makes an auto-reorder worse than a person doing it.
When demand turns out to be half a unit a day
Lead-time cover becomes 0.5 × 9 = 4.5, which is 5 units, so the reorder point should be 5 + 6 = 11. The rule says 20, which is 20 − 11 = 9 units more than the arithmetic needs. Stock that sits, ties up cash, and eventually ages out. Neither error above is visible from inside the number, and neither is the kind an automatic system can detect — a rule that is confidently wrong behaves exactly like a rule that is confidently right until somebody counts.
When the supplier changes the lead time and nobody reopens the rule
The same 1.5 units a day with a new 15-day lead time gives cover of 1.5 × 15 = 22.5, which is 23 units, and a reorder point of 23 + 6 = 29. The rule still says 20, so it is now 29 − 20 = 9 units too low, permanently, and no signal anywhere says so. This is the ordinary way these rules fail: not a dramatic error, but a figure that was correct once and stopped being checked.
The same item on two records
Record A shows 18 units on hand and carries the threshold of 20. Record B shows 25 units of the same item. The condition compares A against 20 and fires, while 18 + 25 = 43 units of the thing exist and the extra 43 − 20 = 23 units are invisible to the comparison. The number is simultaneously correct about A and useless about the shelf. Detection flags A and B as merge candidates and a person reviews them; merging is a setup decision and nothing merges automatically.
The purchase that is not a payment
A supplier invoice of ₹6,800 with ₹0 allocated against it is ₹6,800 outstanding. A payment of ₹6,800 arrives and, until it is allocated, the outstanding is still ₹6,800 — money in the bank that has reduced nothing. Once allocated, it is ₹6,800 − ₹6,800 = ₹0. An invoice and a payment are different records, and paid is a projection of allocations rather than a stored status, which is why a reorder cycle that treats the purchase order, the supplier invoice and the payment as one step is doing three things at once.
The figure this page will not give you
There is no sell-through rate, no shrinkage percentage, no inventory-turn figure, no days-of-supply benchmark and no average lead time anywhere on this page, and we would not print one we cannot derive from your own records. A turn rate is only a number against a stated period and a stated cost basis, and both of those are chosen after the result is known — so the figure on a competitor’s slide and the figure on yours can differ by a factor of two while describing the same shop.
Where this is the wrong tool
Reorder software is judged by what it refuses to decide for you. Almost everything below can be automated into looking helpful while quietly committing money against an assumption that stopped being true months ago.
There is no auto-purchase-order engine, and that is the argument
No automatic order, no draft raised on threshold breach, no scheduled run, no suggested quantity, no buying approval chain. The reason is not caution, it is arithmetic: an automatic order inherits every wrong assumption in the rule that produced it, and applies it repeatedly at a frequency no person can supervise. A manual order is slower, is a decision, and can be checked against the shelf before the money goes out.
No demand forecasting, so the rule is only as good as its inputs
No forecast, no seasonality, no trend, no learning from ordered-versus-sold history. The reorder point is your own arithmetic over your own assumptions, and the platform will not update it, suggest a revision, or tell you that the assumption behind it has stopped matching your movements. That is why the review date and the owner matter more than the number.
This is not a manufacturing or bill-of-materials system
No bill of materials, no shop-floor scheduling, no routing or work centres, no production costing, no capacity plan. Manufacturing capability is a separate category of software with a separate evaluation; if you are comparing it to this page, you are comparing a production system to a buying threshold, and NoxOrigin is plainly the wrong one. Stock movement and purchasing live in Commerce.
Nothing merges automatically
Merge is a setup decision. Detection flags candidate pairs and a person reviews them; there is no automatic merging, so one item or one supplier on two records splits the stock picture and the buying decision exactly as thoroughly as it splits the record.
Paid is a projection, and this is not a tax product
An invoice and a payment are different records; paid is derived from allocations rather than stored, and a payment received without an allocation has reduced nothing. NoxOrigin also does not file GST returns or any other statutory return, and does not determine how a purchase, a credit note or a written-off balance should be treated for tax — that question belongs to your chartered accountant, not to a field here.
No timesheets, no payroll, and reconciliation is a setup conversation
There is no timesheet record and no payroll module, so if the real constraint on a reorder is your own labour rather than your supplier’s lead time, that figure has to come from somewhere you keep it. Expense tracking is Nox-Billings, and purchasing is in Commerce. Shift close and day-end reconciliation are assisted-setup maturity rather than switches you flip in an afternoon — a stock count that has not been reconciled through that conversation is a new number, not a correct one.
Run the stock records on the plan that matches your customer count
Growth is ₹1,600/month or ₹15,000/year, includes a 30-day trial, 10 users, 50 active projects, and 10,000 contacts. Say this plainly rather than let it be assumed: these are NoxOrigin platform plans. NoxCRM, Nox-Billings and Nox-Tickets are scoped custom deployments, quoted and priced separately against your own configuration, and the platform plan price never applies to any of them. Stock movement, purchasing and the low-stock signal sit in Commerce on their own terms, so ask for a configuration quote for a buying cycle rather than assuming a plan list covers one.
Stock reorder and low-stock questions
Will NoxOrigin tell me when to reorder?
It compares what is on hand against a number you wrote. That is the whole of it. A reorder point is a figure somebody chose once, from a demand assumption and a lead time that were both true on the day they chose it, and neither stops being true afterwards. NoxOrigin holds the comparison and the record of who set the number; it does not hold a belief about what will sell next.
Does it forecast demand, so the reorder point is right on its own?
No. There is no demand forecasting model, no seasonality detection, no trend or forecast function, no suggested order quantity, and no learning from what was ordered against what sold. The reorder point is your arithmetic on your own assumptions. If you want the platform to derive it, that is a forecasting product and you should ask to see the error figures on its own past periods, because a forecast with no backtest is a guess with a chart around it.
Will it raise the purchase order for me when stock runs low?
No, and deliberately so. There is no auto-purchase-order engine, no automatic draft order, no approval workflow for buying, and no scheduled reorder run. An order placed on a wrong assumption spends your money on the wrong quantity, in the wrong month, with a supplier who has already invoiced you — and it does so silently, in the middle of the night, at a scale no one is awake to question. A manual order is slower and correctable; an automatic one is fast and already on its way.
Is this inventory or manufacturing software?
It is neither, in the sense those words are usually sold. Stock movement, the purchasing documents, the warehouse records and the low-stock signal live in Commerce. There is no bill of materials, no shop-floor or production scheduling, no routing, no work centre, no production or job costing, and no manufacturing capability set of any kind. Bill of materials, scheduling and production costing are a different category of software with a different buyer, and pretending a reorder threshold is any of those is how a factory ends up running on a purchase list.
Where do stock levels and purchase invoices live?
In Commerce: the stock movement, the purchasing side, the warehouse records and the low-stock signal. This page is about the rule you write against those records. And the usual distinction still holds everywhere in the ledger — an invoice and a payment are different records, and paid is a projection of allocations rather than a stored status, so a supplier invoice is not settled by having been raised and a payment is not money applied until a person allocates it.
A low-stock signal fired but the shelf is full. What happened?
The threshold is on one record and the units are on another. If the same item or the same supplier sits on two records, the condition compares one record’s quantity against a number written against the other, and the number it reports can be right about both and wrong about the shelf. Detection flags candidate pairs and a human reviews them; merging is a setup decision and nothing merges automatically.
The supplier changed the lead time. Does the system notice?
No. Nothing watches a lead time you typed once, and nothing compares it against what the supplier actually did. The condition is a comparison between two numbers, one of which was correct when somebody entered it. This is why the reorder point has an owner and a review date written beside it: the failure mode of this feature is not a wrong number appearing, it is a right number that stopped being true and nobody was looking.
Will it report sell-through, shrinkage or how fast stock turns?
No. There is no sell-through reporting, no shrinkage tracking, no dead-stock ageing and no inventory-turn or days-of-supply benchmark, and this page quotes no turn rate, no shrinkage percentage and no industry average. Those are measured outcomes of a stock record set with a stated period and a stated denominator, and the denominator is the part that gets chosen after the fact. If you want them, derive them from your own movements over a period you name.
Is this included in the platform plan price?
The plan prices on this page are NoxOrigin platform plans. NoxCRM, Nox-Billings and Nox-Tickets are scoped custom deployments, quoted and priced separately against your own configuration, and the platform plan price never applies to any of them. Stock movement and purchasing sit in Commerce on its own terms — ask for a configuration quote rather than assuming a plan list covers a buying cycle.
Bring the reorder rule you stopped believing.
We will walk the arithmetic with you line by line, show which assumption each number is standing on, and put an owner and a review date against it — then be blunt about whether you need a threshold, a demand forecast, or a manufacturing system, because NoxOrigin is the first of those and not the other two.