View all features
View all suite

Growing & production

Trade, export & supply

Retail & e-commerce

Beyond horticulture

View all industries
Library Contact sales
EN IT
library · tech brief

A tree and a pot, in one catalogue.

A four-metre field-grown tree and a two-litre plastic pot sit in the same price list, yet they share almost nothing — one is alive, graded and seasonal; the other is a fixed manufactured unit. A catalogue built for horticulture has to hold both honestly, without forcing either to pretend it is the other.

the mismatch

Two things that share almost nothing, priced side by side.

The same screen lists a living olive measured by trunk girth and a fertiliser measured in NPK and kilograms. A rigid product table can only describe one of them well. The other gets squeezed into columns that were never meant for it.

the problem with rigid databases

One fixed shape, and horticulture will not fit it.

Most product databases assume every product has the same shape: a code, a price, a weight, a size, a colour. That assumption is invisible until it breaks, and in a nursery it breaks immediately. A potted Phoenix canariensis is described by its pot size, its crown height and its trunk girth. A 20-20-20 fertiliser is described by its nutrient ratio and its bag weight. A garden tool is described by its length and its material. Three products, three completely different sets of attributes — and not one column they all naturally share.

Force them into one rigid table and you get the worst of both worlds: a sea of half-empty N/A fields, and a handful of generic columns named "Attribute 1" and "Attribute 2" that mean something different on every row. The catalogue stops describing your stock and starts fighting it.

The deeper problem is that horticulture isn't selling things in the warehouse sense. It is selling a living item at a particular stage, alongside the dry goods, hard landscaping and services that surround it. A catalogue that works has to bend to that reality.

The product is what it is. The variant is what you sell.

two levels, one rule

The product is what it is. The variant is what you sell.

A catalogue built for horticulture splits in two. A Product answers what is it: the species or commercial line, like Phoenix canariensis or a 20-20-20 fertiliser. It is never sold directly. Beneath it sit Variants, the actual sellable units — "Phoenix canariensis, 3L pot" or "20-20-20 fertiliser, 5 kg bag". The variant is what gets ordered, priced, discounted and stocked.

That split is the rule that should run through everything downstream: orders, quotes, invoices, purchase orders and growing cycles all reference the variant, never the product. A product with no variants can't be sold at all. The product holds the identity that rarely changes; the variant holds the price, the barcode and the stock that change all the time.

Each kind of thing gets its own set of attributes.

product classes

Each kind of thing gets its own set of attributes.

The reason a tree and a pot can live in one catalogue is that they don't share one attribute list. Products belong to a class, and the class decides which characteristics apply. A Houseplant class exposes pot size and crown height; a Tool class exposes length and material; a Fertiliser class exposes its nutrient ratio. Nothing carries a field that doesn't belong to it.

Because the attributes are scoped to the class, the catalogue stays clean and expressive at the same time. You describe a living tree with the language of living trees, and a bag of feed with the language of feed — in the same database, with no empty columns and no overloaded generic fields.

the unit of trade

Everything commercial hangs off the variant.

Get the variant right and the rest of the system falls into place — because price, stock, the barcode and every order line all attach to that one sellable unit rather than the abstract product above it.

This is why the two-level split is more than tidy data modelling. The variant is where commerce actually happens. Its retail price, its minimum order quantity, its net and packaged weight, its selling form (the pot size or bag weight that varies), its code and its barcode all live at the variant level. And stock is held against the variant, in batches: the same variant in two locations is two separate batches, each with its own cost and expiry.

A variant's display name can be generated automatically from a per-class template, so "Phoenix canariensis 3L" or "20-20-20 fertiliser 5 kg bag" is composed from the attributes themselves, consistently, every time, rather than typed by hand and spelt three different ways.

Group it many ways, without moving anything.

organising the catalogue

Group it many ways, without moving anything.

A class decides what a product is. Categories decide how you find it. They are flexible, many-to-many groupings used for navigation and reporting — so the same olive can sit under "Mediterranean", "Specimen trees" and "Drought-tolerant" at once, without being duplicated or pinned to a single rigid folder.

That separation matters. The thing a product is doesn't change when you decide to merchandise it differently. Reorganise the storefront, build a seasonal collection, report by range — all of it happens in categories, while the underlying identity stays exactly where it was.

Selling an afternoon of planting.

not everything is stock

Selling an afternoon of planting.

A catalogue for horticulture also has to sell what isn't a plant or a product at all: delivery setup, planting labour, a design fee. A single flag handles it. A product marked not stockable is a Service, and its variants are sold and priced like anything else but never tracked in stock — no batches, no movements, nothing to count.

So one catalogue carries the living tree, the inert pot, the bag of feed and the afternoon of planting labour that puts them in the ground, each modelled as what it genuinely is.

atlas core

How Atlas Core handles the horticultural catalogue

Atlas Core is built directly on these principles:

  • Product/Variant throughout. Every order, quote, invoice, purchase order and growing cycle references the sellable variant — price, code, barcode and stock all live on the unit you actually trade, never the abstract product.
  • Class-scoped characteristics. A houseplant exposes pot size and crown height, a tool exposes length and material, a fertiliser exposes its NPK ratio — so nothing carries a field that doesn't belong and no column sits empty.
  • Stock in batches, per location. Each variant is tracked in batches with their own cost and expiry, so the same line in two nurseries is costed and dated independently.
  • Names built from attributes. A per-class template generates the variant's display name, keeping labels consistent instead of spelt three ways.
  • One non-stockable flag. It turns any line into a Service (delivery setup, planting labour, a design fee), priced and sold like anything else but never counted, in the same catalogue as living plants and dry goods.

Read further

One system rarely fits every nursery Tech brief · 2026

One system rarely fits every nursery

A wholesale grower and a garden centre barely overlap, yet generic ERPs sell everyone the same slab. Why a modular system shaped around six horticulture business types shows each nursery only the modules that fit how it actually works.

6 min read · May 2026 Read →

See a catalogue shaped around how you grow.

Bring us your range, living stock and dry goods side by side, and we will show you what that looks like in practice. Talk to us about how it fits.

Talk to us