Splitting a Reorder Across Suppliers, Without the Mess

One reorder run is never one order

Sit down to plan a week of replenishment and you are doing a single job: deciding what to buy and how much of it. What comes out the other end is not a single job. It is one order per vendor, each with its own terms, its own currency, its own contact, and its own arrival date.

That fan-out is not an accident of your catalogue — it is what a supply base is. Minimum order quantities exist because setup and material costs make small batches uneconomic to produce, so the vendor who wants a full case of one SKU is rarely the vendor who will happily ship six units of another. Lead time is a chain — order processing, raw-material procurement, production, quality control, transit — and every vendor's chain is a different length, so the item you need in three weeks and the item you need in ten belong on different documents almost by definition. And plenty of ranges are dual-sourced deliberately: two vendors for the same category spread supply risk and keep pricing competitive.

So the decision is one job and the paperwork is N jobs. The only real question is where in your process the one turns into the N.

Where the thread gets lost

The usual answer is: at the very end, by hand. Quantities get worked out in one place — a report, a spreadsheet, a stock list — and then someone re-sorts those rows by vendor and retypes them into a second tool as separate orders.

Everything that goes wrong goes wrong in that retyping. Totals drift, because the number in the plan and the number in the order were entered by two different keystrokes. Tax and currency get applied from the wrong vendor's profile, because the person splitting is working from a merged list where that context has already been flattened away. An item lands on two purchase orders because it appeared twice in the sort, or on none because it fell into the gap between two vendor groups. And the moment quantities change — a budget cap, a late supplier, a second thought — the split has to be redone from scratch, because the grouping was a manual artefact, not a derivation.

The deeper problem is sequencing. Hand-splitting forces you to make the grouping decision while you are still making the buying decision, so the plan is never finished in one piece. You are managing half-orders instead of one whole plan.

Decide once, then group by supplier

The fix is to put the two steps in the right order: finish the buy plan completely, then let the split fall out of the finished selection.

In Assisty, that is what the Purchase List is for. As you work through the Smart Buying Table — where every SKU carries an AI-suggested quantity computed from sales velocity, lead times and incoming stock, rounded to your case sizes and capped at your maximum stock levels — you add items to the list as you settle them. The list holds them, priced with each supplier's tax and currency, until you have finished reviewing and are ready to order. Nothing is committed until the order is created, and every adjustment along the way shows a was→now chip with per-row undo, so a change of mind costs one undo rather than a re-split.

Then the grouping happens in one move. When you create orders, Atlas splits your selection by supplier — exact item counts, exact order values — and asks which location receives the stock. One review becomes one purchase order per supplier, not a pile of manual splitting. Grouping replenishment lines by vendor so each vendor receives exactly one document is the standard purchasing pattern; the point is that it should be a consequence of your plan, not a second round of work on top of it.

If you would rather come at it from the other end, you can: create and edit suppliers, assign their products, set their lead times, and start a purchase order for a supplier directly, by chat or in the UI.

What has to survive the split

Grouping rows is easy. Grouping them without dropping anything is the part that matters — and it is the part hand-splitting reliably fails.

Three things have to come through intact. Per-supplier tax and currency, because a vendor's pricing context is the reason the split exists in the first place. Exact item counts and order values, so the sum of the resulting purchase orders is the plan you approved and not an approximation of it. And the receiving location, which is a property of this particular buy, not a default you can quietly inherit.

Then comes the part that is easy to forget: creating the orders is the start of the purchase order lifecycle, not the end of it. A purchase order isn't done when it's drafted. You review line items, email the PO to your supplier, and receive against it when stock arrives — with tax types, landed-cost allocation, and your own custom columns carried through every step. A split that loses fidelity at creation loses it again at every one of those stages.

Decide once, in one place, with the whole picture in front of you. Let the fan-out to N vendors be arithmetic on a selection you already trust.