Properties

Properties are freely created attributes that you define yourself in TRADElube and that are transferred just like a built-in field. They exist not only on the product but on all six main objects, so on manufacturers, categories, media, orders and customers as well.

The reason for them is straightforward. Every product has an article number, a name and a price, and those are fields: built in, present on every product, and no configuration makes them go away. What defines a product beyond that, however, differs from trade to trade. A paint dealer records coverage and drying time, a tool dealer voltage and battery type. Building another field into the software for every one of those would be neither feasible nor sensible. So you create these attributes yourself, with no waiting and with no change to TRADElube.

You create a property once under Settings, via the button Properties. After that it appears on every record of its object type, filled or empty, on the same detail page as the built-in fields, just further down. For a transfer its origin makes no difference: in the transfer plan a property appears as a target field alongside the built-in ones, and in the connected system it ends up wherever that system holds attributes. An online shop such as Shopware uses the word property for the same thing and collects them into property groups.

First check whether the field already exists

Before creating a property, it pays to look at the built-in fields. Several things people reach for as a property have long been present on the product: Width, Height, Length, Weight, EAN, Manufacturer Product Number, Release Date, Base Unit Size and Delivery Time.

The difference is not cosmetic. A built-in field has its fixed counterpart in the target system, so the weight ends up in the shop's weight field, where it can feed into the shipping cost calculation for instance. The same value as a property ends up among the attributes instead, where at best it is displayed. If both end up filled, you also get double maintenance and the question which of the two values is the valid one.

A property is therefore meant for what the record does not already have. Which fields each object brings with it is listed under Products.

Where properties are held

TRADElube holds properties for six objects, and the settings have one tab per object: Products, Manufacturers, Categories, Media, Orders and Customers.

That is more than a completeness statement. A requirement rarely stops at the product: an attribute on the order by which orders can later be split, a marker on the customer, a value on the medium for the media library. Each of them you create exactly as you would a product attribute and assign exactly as you would in the transfer plan, with no detour and without anything in TRADElube having to change.

This is where the path begins on which TRADElube adapts to the way you work rather than the other way round. It runs through the transfer plan, where it is decided where such an attribute goes in the connected system, and only ends at the scripts with which its value can be calculated.

Each object type has its own set. There are no properties shared across several. A property "Color" on the product and one of the same name on the manufacturer are two different things, with their own list of values and their own assignment in the transfer plan.

Whether a property arrives in the connected system is decided by that system: an online shop knows attributes on a product, but not necessarily on a customer. What each system accepts is listed under Channels and tasks.

The seven property types

The type is chosen when the property is created and decides what can be entered and how the value is transferred. It cannot be changed later.

Type	What for	Example
Text	Free text, single line, multi-line or formatted	Care instruction
Boolean	Yes or no, a checkbox	Top article
Integer	Number without decimal places	Number of parts
Float	Number with a configurable number of decimal places	Coverage in m² per litre
Date	A date	Best-before date
Date Time	Date with a time	Start of a campaign
Option	One value from a fixed list	Color, finish

The choice reaches further than it looks, which is why it is worth a minute's thought. The type also decides what the transfer plan offers as a source, because the pick lists there are filtered by data type: a number field will not accept a text column. The reason is the transfer itself. A target system rejects a text where it expects a number, and that error should show up during configuration rather than weeks later in the middle of a nightly execution. Create a number as text and you therefore only notice in the transfer plan, by which time the type can no longer be changed. A value such as "0.75 l" is, incidentally, Text and not a float, because the unit belongs to the value.

Option lists: why not simply make everything text?

A property of type Option brings its own list of values. On the record there is then no input line but a pick list. Setting that up costs a little more effort than a text field, and it is fair to ask why the effort is worth it.

Free text means that "Light ivory", "light ivory" and "Light-Ivory" are three different values. In the target system they become three different attributes a customer would have to filter by separately. With an option the value exists exactly once. For online shops that is the difference between a usable filter and an unusable list, and with variants it decides whether the customer can select anything in the shop at all.

Hence the rule of thumb: as soon as a value repeats, it belongs in an option list.

You can spare yourself most of that effort. The option Auto Fill is set from the outset on a new option property. The list of values then fills itself from the transferred data, instead of you creating it by hand up front. Added to that are Ignore Case Sensitive and Ignore Whitespace: with them "Light ivory" and "light ivory" become one entry while filling, not two. That is precisely the case in which an automatically filled list would otherwise end up as untidy as free text again.

Groups

A range quickly reaches twenty or thirty properties, and nobody reads a detail page with thirty fields in a row. Properties can therefore be collected into groups you name freely, for instance appearance, application and technical data.

In the settings each group has a tab, and you determine the order of the tabs as well as the order of the properties within them. Both directly affect how the detail page looks.

Property settings with the tabs for object types and for groups

A group is not compulsory. Properties without one sit under the first tab, Default, and on the record they appear before all groups, as ordinary fields. The groups themselves are collapsible sections there. That is the practical split: what is nearly always filled stays out of a group and therefore visible, and what is rarely needed moves into a group and sits collapsed.

Properties section of a product with two ungrouped fields above three collapsed groups

From creating it to the filter in the shop

Suppose you sell wall paints and want your customers to be able to filter by gloss level in the shop. The route there has four steps, and in none of them do you type the list of values:

Under Settings, button Properties, in the Products tab you create Gloss level as a property of type Option. Auto Fill is already set.
In the import's transfer plan you assign the supplier file's column to it. The next execution enters the values as the file delivers them: matt, satin, gloss.
In the upload's transfer plan you add an assignment so the property goes into the shop.
In the shop it sits among the attributes, and the filter shows three values.

Step three is the one that gets forgotten. A property without an assignment in the upload is filled in TRADElube and absent from the shop, and no execution fails over it, because from the transfer's point of view nothing is wrong. Without that row you look for the fault in the shop, where it is not.

With two suppliers the second usual stumbling block shows up. If one delivers "satin" and the other "Satin", then without Ignore Case Sensitive there are four values in the filter, two of which mean the same thing. With the option there is one, and the filter list in the shop stays the one a customer expects.

Not every property has to travel that route. You simply leave a marker that only serves your own sorting out of the upload's transfer plan. The property then stays in TRADElube, and that is perfectly fine.

How it fits together

You set properties up under Settings and fill them on the individual record. The first happens once, the second continually.
In the transfer plan each property has an assignment of its own, in every plan that is to carry it.
The channel, through its mappings, determines which attribute of the target system a property meets.
With variants, properties of type Option carry the distinction: they are what becomes the selectable version in the shop.