Synchronization basics
The shop shows a different price than the ERP system, a deleted product is back, or a description changed by hand is the old one again the next day. This page explains how that happens, in a way that lets you place the cause yourself, even without a technical background.
Interfaces are complex, because they connect systems that each have their own logic and their own data. In practice we therefore repeatedly see the interface being blamed prematurely when there is a discrepancy, whether by people inside the company or by external IT service providers. Where the actual cause then lies in the ERP system or in the shop, that costs additional analysis effort, yours as much as our support's. So that we can operate TRADElube on fair terms and sustainably, it helps if we deal with such situations together and purposefully. This page is meant to contribute to that, through transparency, technical basics and comprehensible examples.
What does "synchronization" mean?
In TRADElube, synchronization means that data from a source, the ERP system or an import file for instance, is processed and reconciled with a target system, a shop such as Shopware, WooCommerce or Shopify. TRADElube makes sure that the data in the target system matches what is currently held as "valid" in TRADElube.
You set what happens per task:
- Which fields are synchronized and which are not,
- whether a field is always overwritten, only when a product is newly created, or not at all,
- whether scripts of your own change the data on the way,
- which records are affected, so products, categories, manufacturers or media.
Note: In the following the text mostly speaks of "products", as this is the most common case. The described principles apply analogously to categories, manufacturers, media and the remaining object types TRADElube synchronizes.
Why does data in the shop sometimes not match expectations?
There are several reasons why the data in the shop can feel "wrong". The most frequent causes are:
1. Manual changes in the shop
If you make manual changes to a product in the shop, for example to the description, the stock level or the price, and those fields have not been explicitly excluded from synchronization, those changes can be overwritten again by TRADElube later. This does not happen immediately, but only once TRADElube registers a change to that product, for example through an import from the ERP system or an edit inside TRADElube. The affected product is then fully reconciled with the shop again, and your manual change is gone.
It is important to understand: TRADElube does not permanently monitor the shop system and cannot detect changes made there by hand. Synchronization is always based on the data known to TRADElube, not on a comparison with the current state in the shop. Technically, permanent monitoring of the shop system would hardly be practical either, because it would mean regularly walking through all products in the shop via the interface (API), which would cause considerable overhead and unnecessary system load.
Depending on the configuration the task's Renewal Time also applies: a product is synchronized again after a set period, a week for instance, even without a detectable change, in order to refresh the data in the shop. More on this under Tasks. This too can overwrite a manual change.
Solution: Talk to us about which fields are to be maintained by hand. Those can be excluded explicitly in the configuration, and for most cases a rule can be found that leaves the shop's value standing.
2. Restoring old data (e.g. from a backup)
A frequent, but hard to trace source of error is the unnoticed restore of an outdated shop backup. As a result, products, categories or media can reappear that from TRADElube's point of view were deleted or changed long ago.
TRADElube no longer recognizes this data as valid, because it is already registered as deleted. It is therefore not deleted again and leads to deviations.
Important: That does not mean somebody is "to blame". Sometimes a backup is restored by a third party IT service provider for a good reason, without the connection to TRADElube being considered. The deviation arises all the same and has to be corrected technically.
Solution: Talk to us and we will trigger a complete reconciliation. Products that are deleted in TRADElube and back in the shop through the backup have to be removed by hand, because TRADElube does not know them any more.
3. Faulty data from the source (e.g. the ERP system)
Another frequent reason for unexpected data in the shop lies not in the interface but in the source data, so in the ERP system for instance. If the price, the stock level or a category is maintained incorrectly there, TRADElube transfers this data correctly, even if the result in the shop then looks wrong.
The fault is not always visible in the ERP system itself. Often it is caused by the vendor specific interface software sitting between the ERP system and TRADElube. For TriData that connection is described under TriData anbinden.
TRADElube can therefore only synchronize the data it receives, and if that data is faulty, the fault is carried into the shop.
Example: In the ERP system an article is listed with 0 items in stock, although goods would actually still be available. TRADElube takes this stock level over and enters it correctly into the shop. The fault therefore does not lie with the interface but with the originating data source.
Solution: TRADElube records per record and field which value was transferred when and where. That lets you check for yourself whether the value already arrived wrong or only went wrong on the way. How to do that is under Traces.
4. Third party systems or plugins
Plugins or automatic processes inside the shop system, such as price rules, caching or background jobs, can also change or overwrite shop data. These changes happen outside of TRADElube and are invisible to the interface for the same reason a change by hand is: TRADElube synchronizes what is known to it and does not read the shop out continuously.
The role of the configuration
What is synchronized, when, how and in which direction is not random, it is set per task. That is exactly where the strength lies, and exactly where the price lies too: what is not set does not happen, and what is set happens even where you would have wanted it otherwise in an individual case.
Only through careful coordination and documentation of the configuration can it be ensured that
- fields are updated correctly,
- manual changes in the shop are not overwritten unintentionally,
- data is not duplicated or deleted by accident,
- individual business rules, price or text logic for instance, are taken into account.
Important: If TRADElube "does something other than expected", in most cases this is because the expectation is not yet reflected in the configuration.
Recommendations for everyday work
- 🔄 Avoid manual changes in the shop unless they have been explicitly excluded by the configuration.
- 💾 Clarify backup restores beforehand, before TRADElube synchronizes actively again.
- 🧾 Use the traces to follow a deviation back to where it came from.
- 🛠️ Report discrepancies objectively, without pre-judging the interface. We support you in analyzing the cause.
- 📘 Document your business logic and individual configurations, in order to detect or avoid unwanted behavior early.
When in doubt, contact us. We are happy to help optimize your configuration and analyze unexpected effects.