Data model

TRADElube holds a fixed set of objects, and everything else refers to them: a transfer plan assigns fields of these objects, a task transfers one of them, a channel mapping hangs on a single record.

So this page answers a question that comes up sooner or later in every setup: where does this value belong? A value sitting on the wrong object can only be moved later with effort, because transfer plans, mappings and already transferred records hang off it.

The six main objects

Six objects carry the model. Each has its own navigation item, its own list and its own detail page.

Navigation bar with the six object areas between Dashboard and Channels

Object	What it holds
Products	Articles with number, name, description, dimensions, prices and stock
Manufacturers	Who makes the article, with a name and texts of their own
Categories	The tree products are sorted into
Media	Images and files as records in their own right
Orders	What was ordered, with items, addresses and statuses
Customers	Who ordered, with billing and shipping address

How to recognize a main object: only these six carry properties and channel mappings. Everything else in the model either belongs to one of the six, the way an order item belongs to the order, or comes from the Settings and is used by several records, like a store or a tax rate.

You do not have to use all six. Anyone who only sells through a marketplace and keeps no article data there never touches manufacturers and media. Those areas then stay empty and get in nobody's way.

The same six objects are the ones a connected system knows. What each system accepts is listed under Channels and tasks: a marketplace may only take orders, while an online shop takes all six.

Products, variants and single articles

A product can have three roles, and you do not set the role. It follows from the records above and below it:

A single article stands on its own, with no variants and no article above it.
A parent article is a product with variants below it. It is the umbrella over a family, a varnish in four container sizes and six colors for instance.
A variant is a product with a parent article above it. It is a full article with its own article number, its own price and its own stock.

On the product you see both directions in the Common section: a variant shows its parent under Parent Product, a parent article shows its variants under Product Variants, both as links to the respective record.

Common section of the parent article Spray varnish with its four variants

Anyone wanting to subdivide their article families once more runs into a limit. A product with variants below it cannot itself be given a parent article, and TRADElube refuses that when saving. The reason does not lie with us but with the target systems: an online shop presents an article family with selectable versions, and a third level has no counterpart there. A structure that cannot be transferred is not freedom in an integration platform, it is a trap.

What distinguishes variants from one another are properties of type Option, color and finish for instance. That is exactly what becomes the choice the buyer makes in the shop.

This yields a recommendation that saves a lot of rework: the parent article carries what holds for the whole family, the variant only what sets it apart. A parent article carrying the weight of its first variant looks inconspicuous in the list and is still displayed wrongly in the shop.

Sorting a supplier list

That makes the opening question answerable, column by column. Suppose your varnish manufacturer sends their article data as a table and you set the import up once:

Column of the supplier list	Where it belongs
Article number, name, description	Fields on the product, the two texts per language
Brand	Manufacturer, a record of its own, selected on the product
Product group	Category, a record of its own in the tree
Color shade, container size	Properties of type Option, on the variant
Gloss level	Property on the parent article
Purchase price, sales price	Two price groups, one block each on the product
Stock	Stock line on the product, belonging to a store
Tax rate "19 %"	A choice from the Settings, not the number on the product
Image, safety data sheet	One medium each, linked on the product

Three of these rows decide something later on. Color shade and container size sit on the variant because they are exactly what tells the four containers apart. In the shop they become the choice the buyer makes. The gloss level, by contrast, sits on the parent article because it is the same for the whole family: below, it would stand four times and have to be kept right four times. And the tax rate comes from the settings rather than as a number on the article, which pays off the moment the legislator changes it and you touch one entry instead of twelve thousand products.

The safety data sheet shows the same idea once more: it applies to all four containers, exists as one medium and is transferred once. Four identical files would be four records, four transfers and four places where the next version would have to be brought up to date.

Categories and manufacturers

Both say something about where a product belongs, and both work differently.

Categories form a tree. Each category has at most one category above it, and from that comes the structure the customer sees as a menu in the shop. A product is sorted into any number of categories, and the order of those assignments is preserved. The assignment is a record of its own between product and category, which is why it can carry a channel mapping of its own: the connected system knows the link as an object, not as a field on the product.

Category tree with seven roots and the expanded subcategories of Interior paints

A category can also point to other categories, to a related range for instance. Those links stay inside the client and are not transferred. Where they are maintained is described under Categories.

Manufacturers, by contrast, are a flat list. A product has at most one manufacturer, and it need not have one at all: accessories from your own import often carry none. The manufacturer is a record of its own rather than a text field on the product, so that its name is maintained in one place and can be transferred to the shop with properties of its own.

Media

In TRADElube an image is a record of its own and not a file glued to the product. That is the difference that counts in practice: the same image can hang on several products, is transferred once, and keeps its channel mapping in the target system. A data sheet that applies to a whole product family is therefore uploaded once and not twenty-four times.

On the product this becomes an ordered list of references in the Images section, and one of them is marked as the cover: the image the shop shows in its overview.

Prices, stock and the lists from the settings

Prices and stock hang on the product, but not as a single field:

A price always belongs to a price group, purchase price or sales price for instance. The product therefore shows a block of its own per price group, filled or empty, and inside it you can hold tiers by quantity and validity periods. Details are under prices.
A stock figure always belongs to a store. Create a second store and every product gets a stock line for it automatically, without you touching every article one by one. Details are under stock.

Both follow the same construction: the value does not sit on the product but on the link between the product and an entry from the Settings. That is how you get another price group or another store without any change to TRADElube. That construction has its price too: a new store creates a stock line on every product, including the ones you will never keep there.

The remaining lists from the settings work the same way. Tax rate, base unit, pack unit, delivery time and shipping method sit there once and are selected on the product. Order status, payment method and salutation work the same way on the order. They are the reason why the interface offers a pick list in many places where you would expect a text field: a selected entry is unambiguous, a typed text is not, and in the target system that unambiguity is exactly what decides whether the value arrives.

Orders and customers

A customer is a record of their own with a billing and a shipping address. An order points to that record but additionally holds their details as its own copy: address, salutation, billing and shipping address appear once more on the order itself.

At first glance that looks like duplicated data, and it is a deliberate decision. An order is a document about something that happened. If the customer moves, the new address applies to the next order, not retroactively to the last thirty. With a mere reference to the customer record, every change of address would silently rewrite all past documents.

The Positions of an order are not all articles. They come in five kinds: Product, Discount, Voucher, Surcharge and Shipping. The amount of an order is made up of all five, which is why the totals on the order are held separately by those kinds.

Items of an order with three article lines and one line of type Shipping

An article position points to the product but additionally carries the article number and the name as values of its own. That is why an order stays fully readable even when the article left the range long ago: deleting a product costs the positions concerned their reference, not their content.

Conversely, the Orders section of a product shows which orders it appears in.

Translations hang on the record

Descriptive texts exist per language rather than once per record: the name, short description and description of a product are held separately for every localization that is set up, and the same goes for categories and manufacturers. Numbers, prices, stock and dimensions exist only once, because they are the same in every language.

Which languages there are and how a bilingual shop hangs off them is under languages and translations.

How it fits together

Every one of the six main objects carries properties for everything the built-in fields do not cover.
Every one of the six carries channel mappings, one per connected system. They are the reason a second execution updates the same record instead of creating it again.
The transfer plan of a task follows this model: it has one section per area, so one for prices, one for stock, one for media.
A task always transfers one object, not everything at once. That is why tasks are named after the object they move.