Products Import

The task reads your article file and turns it into products: with descriptions per language version, prices, stock, categories, images and properties. It is the channel's largest, and the only one whose transfer plan you build in any case, because only you know how your file is shaped.

What gets transferred

One product per row read, plus everything that hangs off the product. Which sections you fill is decided by what the file brings along: a stock list needs three sections, a complete supplier catalogue all nine.

A parent article with its variants is built not from two files but from two plans over the same file. The usual case is one row per variant and no row of its own for the parent article. Grouping combines the rows of one family and creates the parent article from them, and the second plan attaches the variants to it.

The manufacturer does not go along as a record: the Manufacturer row holds a reference to one that already exists in TRADElube. It is created by Manufacturers Import or by hand.

The task's own configuration

Besides names and endpoints, the Configuration section carries two checkboxes that exist on this task alone.

Caution: Disable Unused Items and Delete Unused Items (only by manually execution!) refer to everything that does not occur in the file just read. An incomplete file therefore acts like a deregistration of half the range. The addition in the second caption is meant seriously: deleting only happens on a manual start, not in a scheduled execution.

Both are unticked out of the box, and that is the right setting as long as the file carries only part of your range, the list of one supplier out of three for instance. Tick them only once this one file holds the full range and an article vanishing from it really has been delisted.

On top of that comes a field in the task's Common section that belongs to tasks with images only: Media Renewal Time. It stands at Never out of the box, so an image TRADElube has already fetched is not loaded again on every execution. Where images change under stable addresses, you switch it over.

How the transfer plan is built

Nine sections, and the tab bar is longer than the screen is wide: the arrows at its ends scroll it along. Above it, as soon as you have created a second plan, sits the tab bar of the plans.

Transfer plan of an import task with the tabs of both plans, the section bar and the record set Article list CSV with its five assignments

Section What sits in it
Layout The record sets: which level of the file is read, what a product is recognized by, which rows are passed over, and how rows become families
Selection Whether anything is created at all, and which further channels the product is marked for straight away
Common The fields on the product itself, Parent Product, Manufacturer, dimensions and weight among them
Descriptions One record set per language version, with name, description and short text
Prices One record set per price group, with either Net Price or Gross Price
Stocks One record set per store, with quantity and the remaining stock fields
Categories The categories the product belongs in
Media One record set per image, with mapping, name, source and Is Cover
Properties One tab per property, with the value the file supplies

Four places decide the outcome more than all the field assignments together.

The Mapping assignment on the record set carries the value the next execution finds the same article by. Never take the product number for it but an identifier the supplier does not change: otherwise, after a renumbering, the next execution creates a second article instead of updating the existing one.

Grouping combines all rows carrying the same value into one group, and the grouped record set yields exactly one product per group, the parent article. The plan for the variants reads the same file ungrouped and finds the parent article again through its mapping. So the order of the plans is not cosmetics: the plan creating the parent article belongs before the one looking for it. Behind it, the first variant of every family fails and only finds its parent on the second execution.

One record set in the Media section carries exactly one image. Three image columns in one row therefore do not make three assignments but three record sets on the same layout node. The same goes for prices, stock and properties, and the same goes where a field is only meant to be set for certain rows: the condition sits as Selection on the record set, not on the individual assignment.

The Selection section decides what happens to a row read, in TRADElube, because the other side is a file and not a system in which something would have to be created. The rows of the channel's own block: Record Set says which layout node is meant, Condition narrows down which rows are eligible at all, Existing Item looks for a product that is already there, New Item decides whether an unknown one is created. Below it sits a block per further channel: setting a Condition there marks the imported product for the shop in the same execution, instead of assigning it by hand later.

Special features and limits

Images arrive as a reference, not as a file. The row names the address the image sits at, and TRADElube fetches it from there; through a Data Source from an FTP or SFTP server as well. An image that only sits on the supplier's computer does not reach TRADElube this way.

A price comes either from the net or from the gross value, and the assignment carries both as a variant. Whatever you do not supply, TRADElube works out from the tax rate.

Stock goes along where you fill the Stocks section. For the daily stock file it is still the wrong place: Stocks Import is there for that, and it does not touch the product record at all.

An execution that finds nothing changed writes nothing and still reports success. Changed means: the row or the transfer plan. Touching the plan therefore triggers a full retransfer, and resetting the mappings is not needed for it.

Further reading