Module
PO Chaser
Which suppliers to ring this morning, in what order, with the message already written.
What it produces
- Every open order needing a chase, grouped by the conversation it needs
- Judged against the supplier's own confirmed date, not against our request
- The value and quantity still outstanding on each
- A drafted message per order, assembled from that order's own figures
- Orders that could not be judged, named with what is missing
A worked example
PO-4471 — Acme Metals — 10 days past their own date
confirmed 10 Jun, nothing received against it
₹5,00,000 and 1,000 units outstanding
→ “You confirmed delivery for 2026-06-10, which was 10 days ago”
3 orders could not be judged — listed, not hidden
Illustrative figures. On your tenant the same page shows yours.
Why it is hard
The part that is not a report.
Chasing suppliers expands to fill whatever time is given to it, and the order it is done in is usually the order the emails arrived in. What matters is which delay actually threatens something downstream. Given open orders, promised dates and what each one holds up, the list writes itself — and so does most of the message, because the chasing email that works is the one quoting the order, the date that was promised and the consequence of missing it, rather than the one asking politely for an update.
Opened by the procurement lead, the supply chain manager and the planner — what each of them sees first.
Said before you ask
What is not finished.
BETA rather than AVAILABLE: every field it reads is already populated by the purchase-order import, so it runs against live tenant data today, and no customer has yet run it against their own. One limitation matters more than the rest and is stated on the screen as well as here: nothing is emailed to a supplier. Your supplier records carry no contact address anywhere in this schema, so there is nobody to send to, and inventing one would be worse than useless. Each chase is drafted for a person to send and the notification goes to the buyer. That is a smaller claim than automated follow-up and it is the true one — a module that silently failed to reach suppliers would be worse than no module, because a buyer would stop chasing in the belief it was handled. A second, smaller one: the pre-emptive chase reads the need date from a purchase requisition, so on an order raised without one it never fires and the other three reasons still do.
Where this sits
One of 16 modules, on one engine.
PO Chaser reads the same reconciled data as everything else SIAARU runs — connected read-only to your ERP, scored on the way in, measured in SQL. How that engine works is a page of its own. The other 15 modules, each with the state it is really in and the reason where it is not switched on, are on the module list; what this one costs, and what it costs beside the rest, is on the pricing page.