Parkcore Blogging Site

The Supplier Database Most Park Software Forgets to Build

The Supplier Database Most Park Software Forgets to Build

Status: Available now.

Quick answer:

 There's a familiar pattern in software built by people who've never actually run the business it's meant to serve: it solves the obvious, visible problem and quietly ignores the one sitting right next to it. Stock tracking is the obvious problem — everyone agrees a shop needs to know what it has. Supplier management is the one that gets skipped, because it doesn't show up on a features list the way "track your stock" does, even though anyone who's actually run a park shop knows the supplier phone number scrawled on a Post-it note is just as critical as the stock count itself.

 

The gap, in practice

 

Walk into most holiday park shops or bars and ask where the supplier contact details live, and the honest answer is rarely "in our park software." It's a phone kept by whoever usually does the ordering, a folder of invoices with a logo and a phone number printed somewhere on each one, or a handful of favourited numbers in a personal mobile — tied to one person's knowledge rather than the business's own records. When that person is on holiday, off sick, or has simply moved on, reordering from the usual supplier stops being routine and starts being a small investigation.

 

This isn't a criticism of any particular park — it's just where supplier information naturally ends up when the software a business uses never gave it anywhere better to live.

What's actually built

Parkcore's Stock & Suppliers area treats suppliers as a proper, structured part of the system, not an afterthought bolted onto a stock list. Each supplier record holds company name, a named contact, email, phone and mobile numbers, website, full address, the park's own account number with that supplier, payment terms, and free-text notes — everything genuinely needed to place an order or chase a delivery, in one place rather than scattered across invoices and personal phones.

 

Every stock item can be linked to the supplier it comes from, so looking at any item on the shelf answers "who do we order this from?" instantly, and looking at a supplier's own record shows every item they provide — genuinely useful when deciding who to call for a reorder, or when comparing where else an item might be sourced. Suppliers search by name, and the list can be filtered to show active suppliers, retired ones, or both. A supplier that's no longer used isn't deleted — it's retired, keeping historical stock and ordering records intact rather than leaving orphaned references once a relationship ends. Everything exports to CSV and prints cleanly, for anything from a quick desk reference to handing a supplier list to a new team member.

Stockeand Suppliers

Why this matters more than it first appears

A supplier database sounds like a convenience. In practice, it's closer to institutional memory that doesn't depend on any one person's head. The real test of whether supplier information is properly managed isn't whether reordering goes smoothly on a normal Tuesday — it's what happens on the day the person who usually handles it isn't there, and someone else needs to place an order by lunchtime. A searchable record with a contact name, a phone number, and an account number answers that in seconds. A gap where that record should be turns a routine reorder into a delay that a busy shop or bar genuinely can't afford.

How this compares to most park software

Most booking and park management platforms treat the shop or bar, if they touch it at all, as a simple point-of-sale add-on — track what's sold, maybe track a basic stock count, and stop there. Supplier relationships, payment terms, and the link between a specific item and where it's actually sourced from are left entirely outside the system, on the assumption that's "just admin" a park will handle some other way. That assumption is usually correct, in the sense that parks do handle it some other way — just rarely a way that's searchable, exportable, or visible to anyone besides whoever built the informal system in the first place.

 

Parkcore's position is that supplier management isn't a separate concern from stock management — it's the other half of the same question. Knowing what's running low is only useful if reordering it is just as fast and reliable, and that depends entirely on supplier information being real, structured data inside the same system, not a personal habit that happens to work until it doesn't.

What this connects to

A  supplier record isn't an island. It's the starting point for Parkcore's purchasing tools — covered in their own piece — where reorder suggestions are grouped by supplier automatically, and a purchase order pulls a supplier's contact and address details straight from their record rather than requiring them to be typed out again. It also means a stock item's cost price, margin, and ordering history all trace back to a real supplier relationship a park can actually see and manage, rather than numbers floating free of where they actually came from.

 

What's deliberately not built yet

This is supplier record-keeping and linking, not supplier communication — Parkcore doesn't currently email a purchase order to a supplier automatically; today, a completed order is printed or sent manually by whoever's placing it. Pack sizes and case quantities specific to a supplier (ordering in boxes of 24 rather than individual units, for instance) aren't captured yet either. Both are natural extensions once the core supplier database has been lived with for a season, flagged here honestly rather than implied as already covered.

A small feature that changes a specific, recurring moment

It's worth picturing the exact moment this is built for, because it's easy to undersell a feature like this in the abstract. The till shows three bags of a popular crisp flavour left on a Friday afternoon before a bank holiday weekend. In a park without a proper supplier record, that's a problem for whoever remembers the supplier's number, assuming they're working that day. In a park with one, it's a two-minute task for anyone on shift: open the item, see the linked supplier, see their phone number and account reference right there, and place the order — no dependency on any one person's memory, no delay waiting for the usual person to be back in. That's the entire value of treating supplier information as real data rather than tribal knowledge — not a dramatic transformation, just one less way a busy weekend can go wrong.

Key takeaways

- Parkcore holds full supplier records — contact details, account number, payment terms, and linked stock items — not just a basic stock list.

- Every stock item links to its supplier, so both "who supplies this?" and "what does this supplier provide?" are answered instantly.

- Suppliers are retired, not deleted, keeping historical ordering and stock records intact.

- Most park software skips supplier management entirely, leaving it as informal, person-dependent knowledge outside the system.

- Supplier records feed directly into Parkcore's purchasing tools, covered in a companion piece.

Frequently asked questions

Yes — every stock item can be linked to its supplier, and a supplier's own record lists every item they provide.

Suppliers are retired rather than deleted, keeping historical stock and ordering records intact while keeping the active supplier list clean.

Not yet — orders are currently printed or sent manually. Automatic emailing to suppliers is a natural next step, not yet built.

Knowing what's low is only half the problem — reordering it quickly depends on having real, searchable supplier contact details and account information in the same place, not scattered across invoices or one person's phone.

Parks wanting their supplier relationships properly recorded alongside their stock can find Stock & Suppliers in Parkcore today.

Steve Richards headshot

Bio for Stephen Richards: Born in Colwyn Bay North Wales, Steve's introduction it Computers was at secondary school in 1974. That first year, Machine Code was hand written onto gridded paper and sent to Connah's Quay Technical College where is was copied to punch card and then entered into a mainframe computer. The results printed out were sent back for the following week!

Steve left School in 1976 joining the Royal Air Force to work on RADAR and communications equipment. His last 5 years involved working in an Automatic Test Equipment (ATE) department on the System Management Team and also writing models for Microchips. It was a good job that he had kept up with computers which had become rather a passion by the time he started in ATE.

During that time the main Mainframe we replaced in a £3.9 million upgrade reducing the run time of the biggest ATE program from just under 2 weeks to the time it took for a finger to come off a depressed return key!

Leaving the RAF after 18 years service Steve worked for a Charity (Apex Leicester Project) before returning to electronics at Sonatest in Milton Keynes which after 3 or 4 years led to a Job at Telematica the then development arm of Trafficmaster PLC (Tm). Eventually brought in-house at Tm he worked moved into the IT Support Team with his last project moving email from a Linux Box to Microsoft Echange for the 300 users in the company each of whom typically had 5 email addresses.

In 2006 Steve left to start his own company back in North Wales, Computer Technical Solutions was an MSP and moved to become an MSSP following another of Steve's passions Cybersecurity. Officially retiring in 2025, by May 2026 that overactive mind started thinking about all of the software he had seen not just for MSSPs but also for his clients that was either extremely expensive or that didn't exist with a complete answer to the needs of the SME.

By August 2026 two significant pieces of software have been created. Netmon the Network Monitoring Software and the second release Parkcore aimed at Caravan/Lodge Holiday Parks..... And so it begins!