01 // PLAN
Offline MRP calculator
A native Mac wrapper around a self-contained planning engine. It reads operational spreadsheets, detects planning modes, applies replenishment rules, groups recommendations and exports a reviewable workbook.
01.5 // SUPPLY CHAIN · PRIVATE-IMPLEMENTATION CASE STUDY
REAL WORK,
LOCAL BOUNDARIES.
An offline MRP calculator and a document-driven voyage and invoice review tool. Both begin with ordinary PDFs and spreadsheets, keep processing on the device, produce auditable output and stop before the ERP.
02
LOCAL-FIRST OPERATIONS TOOLS
PDF + XLSX
EXISTING BUSINESS FILES IN
XLSX
REVIEWABLE OUTPUT OUT
00
ERP OR CLOUD DATA WRITES
// why I built it
Constraints do not remove the problem. They change the architecture.
Many companies restrict cloud AI, direct ERP access and automated external actions. The planning work still has to happen, often through the same spreadsheets, PDFs and manual checks.
I built two local-first tools around that reality. One turns planning exports into grouped replenishment recommendations. The other connects shipment documents, warehouse translation, receipt history and invoice review without sending the files to a cloud service.
THE OPERATING RULE
Process locally. Explain the result. Stop before the system of record.
The tools prepare a decision and its evidence. A person reviews the output, resolves exceptions and performs any final ERP or external action.
// the toolkit
Plan upstream. Reconcile downstream.
The two tools sit at different ends of the same operating loop: deciding what to replenish, then proving what arrived and what can be paid.
02 // SETTLE
Voyage & invoice review
A browser-based local tool that reads purchase orders, packing lists, invoices and receipt history, then connects warehouse translation with an auditable payment review.
03 // PDF
Document parsing
PDF rows become structured purchase, shipment and invoice facts. Parsing failures stop the workflow instead of being disguised as confident matches.
04 // EXCEL
Spreadsheet ingestion
Existing planning and receipt exports remain the system boundary. The tools adapt to the files people already use rather than requiring a new database on day one.
05 // CONTROL
FIFO receipt allocation
Receipt quantity is pooled by purchase order, item and time window, then allocated to the oldest invoice first so every payable or hold decision can be traced line by line.
06 // MACOS
Native file hand-off
The Mac shell provides familiar Open and Save panels while the calculation remains local and portable. The human still decides what enters the ERP.
// how I worked inside the constraint
No integration required to prove the workflow.
- 01
Start from the files people already receive
The tools accept the PDFs and spreadsheets already present in planning, warehouse and AP work. No system integration is required to test whether the workflow is useful.
- 02
Translate operating rules into deterministic logic
Planning modes, order multiples, lead-time treatment, item mappings and receipt allocation become inspectable rules rather than instructions hidden in a conversation.
- 03
Keep arithmetic outside the language model
Quantities, matching and allocations are computed deterministically. AI can help shape the interface and workflow, but the result is reproducible from the same files.
- 04
Design for review, not invisible automation
Every recommendation or payment decision carries its inputs, match status and exception reason. The output is built for a person to challenge before acting.
- 05
Respect the company boundary
When cloud AI and ERP automation are restricted, useful software can still operate locally: ingest files, calculate, stage output and stop before the irreversible action.
- 06
Separate the public story from private implementations
This page uses generic process descriptions only. A future downloadable edition would require synthetic master data, fictional transactions and a fresh privacy review.
WHY LOCAL-FIRST MATTERS
Useful AI work can begin before integration approval.
- Files stay on the device; the workflow does not depend on a cloud database.
- Teams can test value inside an existing manual control boundary.
- A reviewer receives calculations and evidence, not an unexplained system action.
- The design creates a safe path from shadow use to a later, governed integration.
THE PUBLIC BOUNDARY
Case study now. Synthetic demo later.
- The current operational implementations are private and are not linked or downloadable here.
- No real master data, product codes, orders, invoices, people or organisations appear on this page.
- The public claim is limited to the workflow and capabilities demonstrated by the local tools.
- Any future demo must be rebuilt around fictional data before release.
THE SIGNAL // OPERATIONS × SOFTWARE × PRAGMATISM
The shortest path to value may be a better local tool, not a larger platform.
This case study shows how I turn manual supply-chain work into deterministic, reviewable software while respecting data, access and approval boundaries. It is practical automation shaped by the environment it has to survive in.