An internal SCM & purchasing system that connects order, inventory, incoming shipment, and forecasting data, previously scattered across separate spreadsheets, into one workflow that nothing slips through.
In day-to-day purchasing operations, the question is always the same: what do we order, how much, and when does it need to move? The answer lived across a dozen files. One for open orders, another for warehouse inventory, another for incoming vessels, another for sales history and projections.
Reaching a single purchase decision meant opening all of them side by side, cross-checking by eye, and hoping nothing had changed since the last export. At real volume, that comparison step is exactly where things quietly get missed.
This project didn't start as a request from anyone. It started as a decision to stop re-comparing the same spreadsheets every day, and build the connective layer that was missing between them instead.
Before writing a single screen, the recurring failure points in the manual process had to be logged clearly, like any incident report.
Every ordering decision required manually cross-referencing four or five separate exports before a single number could be trusted, repeated daily for every SKU.
"What's in the warehouse" and "what's actually free to sell or ship" were easy to conflate, risking over- or under-ordering whenever the two got mixed up.
Once a planned order moved toward approval and shipment, there was no single place to confirm a step hadn't quietly been skipped along the way.
Every module reads from and writes to the same underlying dataset. Nothing is re-entered, re-uploaded, or recalculated twice. That's the system's one non-negotiable rule.
Note: this was built to solve a real, day-to-day problem, not as a showcase, so the walkthrough below is simplified and doesn't include company-specific data or screens.
Forecasting and reporting quietly worked from different snapshots of the same spreadsheet, so numbers never quite matched.
One upload point with version history. Every module reads the same active dataset, and superseded files are archived, not deleted.
Order quantity, remaining quantity, and delivery date lived in separate tabs, so answering what's still owed took several lookups.
Each order expands inline to show allocated and remaining quantity directly beneath it, with no side panel to reconcile.
Warehouse inventory was often shown already net of open orders, hiding the real physical count.
Current inventory, open orders, and available inventory sit side by side on one screen, kept as three distinct figures instead of one merged number to look up separately.
Deciding how much to order meant manually weighing stock, incoming vessels, and sales trends from scratch, every time.
Available inventory, incoming quantity, sales, and projections sit in one row per SKU on a shared, adjustable time window.
A recommended quantity is a starting point, not an answer, and there was no clean path to a final human decision.
Recommended quantities move to review with supporting data attached, and a final quantity is accepted or adjusted and logged in one line.
Framed the way any purchasing decision gets framed, before touching a single screen.
Remove repetitive manual comparison across siloed spreadsheets, and make sure no step between "we should order" and "it shipped" gets skipped.
A connected workflow of upload, order management, inventory & incoming, forecasting, and PO review, all reading from one shared dataset.
Built for the day-to-day purchasing decision-maker first, with a lightweight review layer for final sign-off on order quantities.
An internal tool that sits alongside the supplier and inventory exports the team already relies on, as a layer on top rather than a replacement.
Designed and refined continuously alongside live purchasing work, with every screen tested against a real week's decisions.
Every new Excel upload becomes the active version automatically, while every prior version stays logged in history, so the data can always move forward without ever losing a record of what changed.
Detail expands beneath the row it belongs to, never a side panel that breaks context.
An upload failure names the row, column, and value at fault, never just "upload failed."
The system recommends a quantity, and a person still confirms or changes it before it's real.
Past order plans are archived, not edited over. Each new decision starts a new, traceable plan.
This isn't a finished product. It's a working tool, shaped by whatever the previous week's purchasing cycle exposed as still fragile. The forecasting logic behind the recommended order quantity is deliberately being finalized last: the data connections had to be trustworthy before any calculation was allowed to run on top of them.
What it's already changed is smaller and more concrete than a dashboard: the daily habit of opening five files to answer one question has become the habit of opening one screen, and trusting that if a step had been missed, the system, not memory, would be the one to catch it.