Product
One Automation Rule Per Supplier, Not One for the Whole Catalog
A shared reorder schedule is an inventory policy in disguise: it hands every supplier the same review period, however far apart their lead times sit.
A store-wide schedule is one review period for everyone
"Reorder every Monday" reads like a habit, but it is a policy. Fixing one day for the whole catalog fixes the review period — the gap between the moments you look at stock and decide — at one week for every supplier you buy from, whether their goods take three days to arrive or six weeks.
That matters because of what a run has to buy. An order placed at a review has to last until the next order arrives, not until this one does: the review period plus that supplier's lead time.
cover a run must buy = review period + supplier lead time
Read that back against one shared review period and the waste is uniform, just in two different shapes. The fast supplier carries a full week of review-period cover it could shed by looking more often — that excess comes from the schedule, not from any wait it has. The slow supplier gets reviewed many times inside a single lead time, so most of its runs re-decide demand that goods already in transit will answer.
| One shared reorder day for the whole catalog | One rule per supplier | |
|---|---|---|
| What sets the cadence | Your calendar — one day for everyone | The supplier's own order cycle and lead time |
| Cover each run must buy | The shared review period + each supplier's different lead time | That supplier's review period + its own lead time |
| Effect on a slow supplier | Repeated runs inside one lead time — re-deciding demand that goods already in transit will answer | Wakes on its own cycle, once per real decision |
| Effect on a fast supplier | Carries a full review period of cover it could shed by looking more often | Reviewed often, so the review-period share of cover stays small |
| Order minimums & case packs | You sort the run into per-supplier orders by hand before anyone's minimum can even be checked | Each run accumulates against one supplier's minimums from the start |
| Changing one supplier's cycle | Re-tunes the day everyone shares | Edits exactly one rule |
The cadence belongs to the supplier, not to your calendar
The useful cadence for a rule is not the day that suits your week. It is the cycle the supplier accepts and rewards — its own reorder cycle, its lead time, its minimum order value, the economics of how it ships. Those are supplier-level facts, and in Assisty they live on the supplier record: Lead Time, Reorder Cycle, Min Stock Cover Days, and order minimums and maximums, set once so the buying table's suggested quantities use them automatically.
An automation rule is made of three parts — a supplier, a scope, and a cadence — and Assisty generates the purchase orders on time from them. You pick the cadence, and the honest place to read it off is the same supplier record the quantities come from. A nearby supplier with a short lead can be reviewed often at little cost. An importer reviewed weekly mostly produces runs with nothing yet worth ordering. Where each supplier's frequency should land is its own argument; the point here is that the answer belongs to the supplier, not to your calendar.
Scope is the other half of the rule, and it's supplier-shaped too
Cadence answers when. Scope answers what, and it is supplier-shaped for the same structural reason: an order is placed with one supplier. Minimum order quantities, minimum order values, case quantities, and freight consolidation all apply per supplier, and items ordered together from one supplier share a single fixed ordering cost per order.
Sorting one catalog-wide run into per-supplier orders is work somebody does by hand before anything can be sent, so scoping the rule to one supplier's items up front simply performs that division earlier — and every run then accumulates the full demand that has to clear that supplier's minimum, instead of a slice of it. Assisty keeps the scope true as the catalog grows: products auto-assign by vendor name, or saved rule conditions let future products link themselves. Where one product's terms differ, per-variant overrides carry its supplier SKU, cost, minimum order quantity, and case quantity.
| Part of the rule | What it is, and where it comes from |
|---|---|
| Supplier | The supplier the rule orders from — carrying the lead times, order cycles, and minimums that decide when you reorder and how much |
| Scope | Which of that supplier's items a run picks up — for example, items below reorder point; products link in by vendor name or by saved rule conditions |
| Cadence | How often the rule runs — you choose it, and set it against that supplier's Lead Time, Reorder Cycle, Min Stock Cover Days, and order minimums |
| Quantities | Seeded with the same suggested quantities you'd get in the Buying Table, which already use the supplier's parameters |
| Result | A draft PO for review — an ordinary purchase order with the same per-supplier grouping, tax types, landed cost, and lifecycle |
What changes operationally when every supplier has its own rule
Move from one schedule to several and the texture of the work changes more than the volume of it. Drafts arrive when a decision is actually live for that supplier, rather than in one Monday pile you triage by guessing which rows are urgent. Each rule's output is one complete, sendable purchase order for a single supplier, still gated on your approval.
The slow supplier stops generating noise, because its rule only wakes when its cycle says something might be worth ordering. And the rules become editable one at a time: renegotiate a lead time or shift one supplier to a longer cycle and you change exactly one rule, not a shared day that quietly re-tunes everyone else's cover. You can also ask for a preview of what the next run would include before you trust a new cadence — a cheap check that it is scoped and timed the way you meant.
Where to start, and what per-supplier rules cost you
Start where the gap is widest. Sort suppliers by lead time and take the two or three furthest from whatever your default schedule assumes — usually the long-lead importer and the local supplier you could reorder from far more often. Give each a rule on its own cycle, preview a run, then leave the rest on the default until they earn their own.
The cost of granularity is honest: more rules, and more places for a stale fact to hide. What keeps them true is that the facts do not live in the rules. They live on the supplier record, feeding both the suggested quantities and your choice of cadence — and they can be changed conversationally, flowing into the next day's suggestions. Rules themselves can be created and managed in the UI or just described to the assistant. The rule stays a thin wrapper around a supplier's real terms, which is the only form of it worth maintaining.