A supplier import is rarely just a file upload. Two suppliers can describe the same product with different SKUs, field names, units, categories, currencies, and data quality. The real job is repeatedly translating unreliable external data into a stable internal product model, without manually cleaning it up again on every update.
PIMSuite builds this as a reusable import pipeline. For standard files and feeds, that's ready to use directly; when a supplier or an ERP needs unusual authentication, preprocessing, or reconciliation logic, Applosive extends the ingestion layer around it as custom development.
Source schema vs. canonical model
Supplier A
ArtNo | Color | CostPrice | Weight
Supplier B
SKU | Colour | Net_Cost | NetWeight
↓
Canonical PIM model
sku | color | cost | weight
Supplier schemas should be treated as source formats, not as your internal data model. That's the same principle as the product catalog: PIMSuite doesn't prescribe a fixed format - your supplier's format is the starting point, not the destination.
A typical onboarding workflow
- get a sample feed from the supplier
- inspect the schema
- decide on stable identifiers
- map fields
- normalize values and units
- map categories
- test on a subset
- review errors
- define update behavior
- set up recurring sync
Most problems don't surface on the first import - they surface on the second or third, when the schema shifts slightly or an edge case appears that the test run didn't cover.
Any format, any structure
Import CSV, XML, JSON, and XLSX files. PIMSuite reads the file, shows you a preview of the columns and sample values, and walks you through the mapping.
Identifiers: the most important decision in the whole process
Which field recognizes the same product on every future import? Candidates include the supplier SKU, a manufacturer part number, GTIN/EAN, or an internal mapping ID. Choosing the wrong one is one of the fastest ways to create duplicates or overwrite the wrong record.
PIMSuite's duplicate handling (below) works on SKU as the match key. A configurable choice between multiple possible identifiers - GTIN instead of SKU, or a combination of both, for example - isn't a distinct configuration step beyond that today; which field serves as the key is worth deciding deliberately before the first production import, not left to an implicit default.
Four separate mapping problems
What often gets treated as one problem is really four:
1. Field mapping - ArtNo → sku
2. Value normalization - navy, Navy Blue, Dunkelblau → a single navy_blue
3. Unit conversion - 1250 g → 1.25 kg
4. Derived values - cost * 1.35 → a calculated price basis
Column mapping with formula transformations
Map each supplier column to the right field in your schema. For columns that need transformation, write a formula using a JavaScript-style syntax. An example:
Supplier value: "1,250 g"
Transformation: parse_decimal(value) / 1000
Result: 1.25 kg
PIMSuite evaluates the formula against real sample values so you can verify before running the full import. That's more than convenience: a transformation bug that looks harmless on one sample row can corrupt 50,000 products if it runs unchecked across the whole feed.
AI-assisted mapping
Supplier column:
"Net_Weight"
Sample values:
"1.25 kg"
"750 g"
"2 kg"
AI suggests:
→ weight
→ normalize to kg
Human confirms
PIMSuite analyzes the sample values in each column and suggests the right field and formula. This cuts setup time for new supplier integrations from hours to minutes. The important principle behind it: AI should accelerate mapping decisions, not silently define your canonical schema on its own - you confirm every suggestion before it runs in production.
Category mapping
Supplier:
Home > Kitchen > Coffee Machines
Internal:
Household > Kitchen Appliances > Coffee Machines
When a supplier uses their own category names, PIMSuite shows you an inline mapping workflow: see each supplier category, search your taxonomy, and assign it. AI suggestions speed this up significantly for large category lists, and mappings you've set stay in place for that supplier's future imports. Same principle as the data model overall: a supplier's taxonomy shouldn't automatically become your own.
Variant grouping rules
Supplier files often list every size and color as a separate row:
TSHIRT-BLK-S
TSHIRT-BLK-M
TSHIRT-BLK-L
A pattern identifies the parent product TSHIRT-BLK with axis size = S/M/L. Variant grouping rules let you define SKU patterns like this - PIMSuite automatically clusters matching rows into variant groups during import, so your catalog stays organized without manual work. A SKU pattern isn't always reliable, though: some suppliers mix color and size differently, or a shared attribute conflicts between rows. It's worth testing a new variant grouping rule on a subset before running it across the full feed.
One product, multiple suppliers
Canonical product
├─ Supplier A
│ cost: €12.50
│ stock: 80
│ lead time: 2 days
└─ Supplier B
cost: €11.90
stock: 0
lead time: 14 days
Each supplier is its own record in PIMSuite with contact information, address, discount rates, lead times, and minimum order quantities. Supplier data links to product records: per-product supplier associations track cost price, currency, stock quantity, and preferred supplier designation. The important principle: two suppliers carrying the same product don't become two products - which cost feeds the pricing engine is decided separately, through a cost-source strategy.
Import modes and duplicate handling
Choose how each import behaves: create new products only, update existing products only, or both. Configure what happens when a duplicate SKU is detected - update the existing record, skip it, or raise an error. When each mode makes sense:
- Initial catalog migration → create + update
- Daily inventory feed → update only
- New assortment feed → create only
- Strict master-data workflow → duplicate = error
When a product disappears from the feed
An easy-to-miss problem: a product that was in yesterday's supplier feed is missing today. That can mean several things - temporarily unavailable, discontinued, the supplier stopped carrying it, or the feed is simply incomplete. A missing product should never be deleted automatically without a deliberate policy.
PIMSuite's import modes determine what happens to rows that are present in the feed (create/update/duplicate handling). A dedicated, configurable rule for what happens to previously imported products that are missing from the current run - automatically zeroing out stock, waiting for several consecutive missing imports before deactivating, or always requiring manual review, for example - isn't a distinct feature today. Until there is one, it's worth deciding that behavior deliberately when setting up the import, rather than relying on an implicit default.
Scheduled imports
Set a cron schedule and supplier feeds update your catalog automatically. PIMSuite fetches the latest file from a URL, runs the mapped import, and reports any errors.
A resilient pipeline also needs answers for: what if the URL returns a 404? What if a file suddenly has 10 rows instead of 50,000? What if the column headers change? Sanity checks like "abort if row count drops more than 80% relative to the last successful import" or "don't mark a run successful if the error rate exceeds a threshold" aren't a distinct PIMSuite feature today - the existing mechanism is row-level error reporting per run (below), not an automatic pre-flight abort on anomalies.
Media import
Download product images directly from URLs in supplier feeds. Configure authentication headers if the supplier's CDN requires them. Images are deduplicated by hash - re-importing a feed won't add duplicate files. Details on the deduplication itself - SHA-256 combined with perceptual hashing - are on the Media & DAM page.
Row-level error reporting
Row 2184
Field: weight
Value: "approx. 12kg"
Error: expected a numeric value
Row 429
Field: color
Value: "Blu"
Error: not mapped to an allowed option
Every import run produces a detailed error log. See exactly which rows failed, which field caused the issue, and what value was invalid. "Import failed" alone is useless - actionable errors need row, field, source value, and reason.
Most of what shows up sorts into a few groups: structural issues (a missing column, a malformed CSV/XML file), validation errors (an invalid GTIN, an invalid number), mapping errors (an unknown category, an unknown option), and download errors (a media URL that's unreachable). That grouping helps you fix things even though the error log itself doesn't label errors with those category names - fix it at the source and re-import cleanly.
Tracing where a value came from
PIMSuite logs every field change with the user, timestamp, and old and new values - that includes changes originating from an import. That lets you trace, roughly, when and through what a value last changed. A complete per-field provenance chain - exactly which supplier, which feed file, which row, and which original raw value produced a stored value - isn't a distinct, consistently retrievable feature beyond that today.
How PIMSuite implements this
PIMSuite imports CSV, XML, JSON, and XLSX supplier files with flexible column mapping, formula-based transformations with live preview, AI-assisted mapping and category suggestions, configurable import modes and duplicate handling, cron-scheduled synchronization, SKU-pattern variant grouping, media import with hash-based deduplication, and row-level error reporting per run. For standard feeds, that's ready to use directly; for unusual sources, the pipeline can be extended individually.