XML Import to PrestaShop Without Duplicates: Identifiers and Update Rules

XML import without duplicates starts with a stable, unambiguous identifier and a saved relationship between the supplier record and the product in PrestaShop. Before the first run, determine what the importer may create, which fields it updates, and what the absence of a product in the next file means. A technically correct XML alone does not answer these questions.

This guide is intended for stores planning an import from a wholesaler or another system. Two small demonstration files show how to distinguish a new product, a data change, and a missing record. They are not a real supplier feed or a universal format supported by every importer.

1. Choose the system responsible for each field

First, decide where the correct price, stock level, name, and description come from. Often the wholesaler is responsible for availability and purchase price, while the store maintains its own description and sales price calculated according to a rule. If the importer overwrites all fields on every update, it may remove editorial work done in the store.

With multiple suppliers, also clarify whether they offer the same goods or separate offers. Handling multiple sources does not automatically mean summing stock, choosing the lowest price, or switching suppliers. Such a rule must be designed and then confirmed in the specific solution.

2. Do not confuse the supplier ID with the product ID in the store

The record A-100 in XML may correspond to product 501 in PrestaShop. These numbers do not have to be identical. The importer should know their relationship and use it during the next read. Creating a new product card every time the name changes is an identification model error.

The identifier must be stable over time and unambiguous within the selected scope. If two wholesalers use the number 100, a safe link should include the source, not just that number. Also, do not assume that EAN is always available and unique: the file may contain missing values, errors, or duplicates that require clarification.

Before the first match to the existing catalog, prepare a report of missing and duplicate keys. Do not automatically choose the “first found” product if there are two product cards with the same index.

3. Product and variant need separate rules

One product card may have several combinations, each with its own stock, index, image, or price impact. Determine whether the XML record describes the entire product card or a single variant. If the supplier sends separate sizes as separate records, combining them into one card requires a grouping rule.

Also check the meaning of the variant price: it may be the full price or a difference relative to the base product. Using the difference as the final price gives an incorrect result. Similar caution applies to attribute sets — changing a color name should not create another variant without a decision.

If the importer synchronizes the full set of combinations, determine whether variants absent from the file should be kept, disabled, or removed. This is especially important when some variants are maintained by the store independently.

4. Two XML versions and the expected result

The structure below has been prepared solely for demonstration. Prices are net input prices in PLN. In the example, we do not create variants; each record corresponds to one product card. The parser or adapter of a specific importer must be adjusted to the actual source structure.

First full file

  
    DEMO-BUTELKA
    Butelka oliwkowa
    50.00
    12
  
  
    DEMO-KUBEK
    Kubek kremowy
    20.00
    8
  

Next full file

  
    DEMO-BUTELKA
    Butelka oliwkowa
    55.00
    0
  
  
    DEMO-KOC
    Koc beżowy
    40.00
    5
  

The attribute complete="true" is part of our example, not a standard guarantee of XML completeness. In a real implementation, it must be determined how the supplier confirms completeness and how the importer recognizes it.

These are the expected results of the scenario, not the result of a completed import. Product numbers in the store are examples. The two files above use the illustrative schema; they are not input files for the module’s sample adapter.

Reprocessing the same correct file should not create another bottle or another blanket. Comparison after the second run is a simple acceptance criterion for matching. For an importer that skips unchanged records, skipping them may also be the correct result.

Separate mapping test in module code 2.0.5

On 27 September, we checked the SampleAdapter::mapProduct() method in memory on three small XML files, on PHP 7.0 and 8.1. This adapter expects the structure and the fields nazwa, cena_netto, and stan_magazynowy. This differs from the illustrative schema above. We did not perform URL retrieval or import into the store database.

Download the data and saved mapping test results (ZIP, 4.4 kB): three XML files, PHP 7.0 and 8.1 results, and comparison instructions. These are materials from the described test of 27.09.2026, made available on 28.09.2026. The package does not include the module or configuration for a full import. The result 19,99 → 19 documents a price format error, not the correct price.

Test boundary: this is the result of field mapping, not proof of creating or updating product cards, handling variants, or the absence of duplicates after reimport. SampleAdapter is excluded from selection in the panel and is itself marked as an example unsuitable for production. Do not run a full import of a short sample on an existing source: the rule for products absent from the file may change the state of the catalog. Full acceptance requires an isolated copy of the store, confirmation of feed completeness, and comparison of product cards before and after the run.

5. A missing record does not always mean missing goods

A product may disappear from a full catalog, but it may also be absent from a file containing only changes. An empty file, login error, partial download, or incomplete import are other situations. They should not automatically lead to disabling the entire assortment.

Before performing operations for missing products, confirm correct download, reading, and completion of the proper import type. Also determine the scope: only product cards linked to this source. The disappearance of a record from wholesaler A should not automatically modify a manually added product or an offer from wholesaler B.

In the example, we leave the missing mug for review to show the difference between missing information and an explicit zero stock level. This is a chosen demonstration rule, not a setting appropriate for every store. For production, the decision must be linked to the nature of the source and the risk of selling unavailable goods.

6. Full import vs. quick update

In the code of Import hurtownia Pro / pdxmlimport 2.0.4, full import and quick update have different scopes. The full path may create products and update data handled by the adapter according to the configuration. Quick update concerns prices and quantities of base products already linked to the source; it is not a path for creating new product cards or updating stock levels of individual combinations.

Do not assume that the switches for overwriting names and descriptions control every operation of the module. Before scheduling, indicate the exact action, source, and scope. A change in the pricing rule may also require reprocessing the data despite unchanged XML.

If you only need to update existing product cards from CSV, see the separate guides on prices and on stock levels. The choice of format should result from the data and operations that actually need to be performed.

7. Schedule only after checking the result

Perform the first test on a small, representative set including a new product, an already linked product, a missing identifier, a collision, and variants. Compare the number of added, changed, skipped, and erroneous records. Open the product cards and check the sales price, stock level, images, and category mapping.

Only then set the order of downloading and processing batches and the CRON frequency. The schedule should take into account the supplier’s file publication and the actual import time. Determine who responds to an error and how they recognize an incomplete run. Simply triggering the CRON address is not proof of updating the entire catalog.

Send a sample of the XML structure without confidential data and describe the update rules. After checking the fields and variants, the scope of PrestaShop data import and export can be determined. If the existing adapter supports this structure, check Import hurtownia Pro; a different data layout requires adjustment and a test on a copy of the store.

Catalog import does not automatically mean sending orders to the wholesaler, reserving goods, or two-way synchronization. These needs must be included separately in the integration scope.

Verification of the original text: 13 September 2026 in pdxmlimport 2.0.4 code. Separate mapping test: 27 September 2026 in local 2.0.5 code on PHP 7.0 and 8.1, without import into the store. The XML files and product numbers are demonstrational; they do not contain data or the structure of a protected wholesaler feed.