English
Romanian
A customer orders a brake pad marked as compatible with their car in your store, but the part does not fit correctly. The usual reflex is to look for a bug in the code, but most of the time the real cause lies in how the vehicle-part compatibility mapping was built, not in an isolated programming error. Compatibility mapping in TecDoc is based on KTYPE (the technical identifier of an exact vehicle configuration) and on linkage tables, which connect each catalog article to one or more KTYPEs, through additional criteria that can be conditional or valid only within an interval (for example, an engine code or a production year).
When an online store displays a fitment error even though the API initially responded "compatible", the cause is usually a misreading of the linkageTargetType field or ignoring the conditional/interval criteria attached to the link between the article and the vehicle - not an isolated code defect. In this guide we explain exactly what KTYPE is, how linkage tables work, which criteria decide real fitment, and how to check whether the mapping in your store is built correctly.
This guide complements our article on identifying car parts by VIN with the TecDoc API , because the two topics are closely related but not identical: VIN identifies the vehicle, while the part's real fitment depends on the KTYPE mechanism and the linkage criteria described below.
What KTYPE (K-Type) Is and How It Differs from NTYPE
KTYPE is the unique numeric identifier that TecAlliance assigns to an exact technical vehicle configuration - make, model, engine, production year, and transmission - for passenger cars and light commercial vehicles. For heavy commercial vehicles (trucks, heavy-duty utility vehicles), TecDoc uses an equivalent identifier called NTYPE. In practice, every distinct technical variant of a model gets its own KTYPE or NTYPE, and this is the central element to which compatible parts are linked.
The same technical concept circulates under different names depending on the market: KTYPE is known as TSN in Germany, PR number in the United Kingdom, and MMT in Switzerland. The names differ, but the role is the same - a numeric code representing a vehicle's technical configuration, not the make/model in the broader commercial sense.
An important detail for integrators: when a user enters a license plate number or a VIN into a vehicle-identification tool, the system internally translates that code into a KTYPE anyway, in order to look it up in the same compatibility database. We return to this connection in the section on KTYPE and VIN below, because it has direct implications for the precision of the results.
How Linkage Tables Connect a Part to a Vehicle
An article in the TecDoc catalog (generically called GenArt, generic article, when referring to a part category rather than a specific manufacturer's product) does not link directly to a car model, but to one or more KTYPEs, through linkage tables. According to the official "TecDoc Data Format" specification published by TecAlliance, KType vehicles are described in a dedicated table (table 120), and the links between articles and vehicles are stored in a set of linkage tables (numbered from 400 upward), through a "linkage target" type field (named VknZielArt in the original documentation) and a target vehicle identifier (VknZielNr).
Factual transparency note: the exact field structure from the "TecDoc Data Format" specification was confirmed through indexed fragments of the official document, not by reading the full PDF at the time of writing - treat the field names above as conceptually correct, but confirm them in your own copy of the specification before using them as an exact implementation reference.
The classic KTYPE/NTYPE system covers passenger cars and commercial vehicles well, but it has limits for newer vehicle classes (electric, hybrid). TecAlliance introduced an extension - a new record type for mapping KTYPE/NTYPE to a more detailed classification - specifically for these cases, so that linkage tables can be interpreted correctly for newer vehicle classes too, not only for the historical "passenger car/commercial vehicle" classification.
At the API level, the same mechanism is exposed differently depending on the integration generation. The classic Pegasus 3.0 WSDL contract (the same webservice family verified in our article on VIN-based identification) exposes dedicated linkage operations, confirmed directly from the service's public schema: getArticleLinkedAllLinkingTarget3, getArticleLinkedAllLinkingTarget4, getLinkedArticles, and getVehicleIdsByKTypeNumber. The newer REST/JSON API documented by TecAlliance exposes a similar concept through the carId parameter (the vehicle's KTYPE number) combined with linkageTargetType, a code that classifies the target vehicle type.
The practical problem is that linkageTargetType does not have a single, universal coding scheme valid identically across every contract and every API generation. The table below summarizes the difference, based on publicly available documentation today:
| Aspect | Classic system (linkage tables 400ff, WSDL) | New REST/JSON API (TecAlliance-documented) |
|---|---|---|
| Target vehicle type coding | Numeric codes (e.g. 2 = passenger cars, 16 = commercial vehicles) | Letter codes (e.g. "P" passenger car, "O" commercial, "M" engine) |
| Vehicle identifier | VknZielNr / KTYPE-NTYPE, in the internal table structure | carId (the KTYPE number), sent as a filter parameter |
| Coverage of new vehicle classes (electric/hybrid) | Requires the extended mapping, separate from the base classification | Depends on the API version and the catalogs made available |
| Real availability for your project | Depends on your active TecAlliance contract/license | Depends on your active TecAlliance contract/license |
The practical takeaway: never assume the value of a linkageTargetType code from a generic example found online. Check exactly which values your own contract and your own WSDL/API documentation use, because differences between systems are a real source of mapping errors.
Fitment Criteria: Conditional and Interval Attributes
The fact that an article is linked to a KTYPE does not automatically mean that part fits every single unit of that vehicle configuration. Each linkage can have criteria attached - additional attributes that narrow down real compatibility. TecAlliance's "Part Linkage Search" function documentation confirms this mechanism through the fields attrId, attrName, attrValue, attrIsConditional, and attrIsInterval, attached to each vehicle-article link.
In practice, attrIsConditional marks the fact that the link is valid only if a specific condition is met (for example, a specific engine code within a broader range), while attrIsInterval marks the fact that the attribute is valid only within an interval (for example, a range of production years or chassis numbers, not the model's entire production run). At the classic WSDL level, the equivalent operations are getCriteria2, getCriteriaDialogAttributs, and getVehicleIdsByCriteria, confirmed in the Pegasus 3.0 service's public schema.
Conditional and interval criteria are, in effect, the mechanism TecDoc uses to compensate for the fact that a single KTYPE does not describe every optional equipment variant of a vehicle. If your store only reads the base link (article → KTYPE) and ignores the attached criteria, you will display parts as compatible that, in fact, only fit a sub-variant of that configuration.
Why Fitment Errors Happen Even When the System Said "Compatible"
In our experience integrating TecDoc for stores in Romania, fitment errors reported by end customers most often come down to one of these technical causes:
- Insufficient KTYPE granularity. TecDoc uses a "defined fitment" model (compatibility defined on a simple vehicle identifier), not a "configuration fitment" model (compatibility based on dozens of exact technical properties of an individual configuration). An independent technical analysis published by specialist Joan Cabós (Auto Ways) explains exactly this limitation: for parts such as gearboxes or alternators, a KTYPE-based search frequently returns several candidate articles, with no additional criterion clearly indicating the exact variant needed. Mitigation: treat results with multiple candidate articles for the same KTYPE as a signal that additional selection criteria need to be shown in the interface, not as a data error.
- Confusion between
linkageTargetTypecoding systems. Using a numeric code from a generic WSDL example in a newer REST API (which may use letters instead) produces incorrect filtering at the vehicle-type level. Mitigation: document explicitly, for your own contract, which values and which formatlinkageTargetTypeuses, before writing production code. - Ignoring conditional and interval criteria. Many implementations only read the article-KTYPE link and ignore
attrIsConditional/attrIsInterval, displaying the part as unconditionally compatible. Mitigation: evaluate these attributes explicitly before marking an article "compatible" in the final interface, not just at the internal database level. - Outdated local linkage data. TecAlliance periodically updates links and criteria; if a store keeps a local copy without a clear resynchronization process, discrepancies appear between what the store shows and what the official catalog confirms. We covered the synchronization and contractual storage compliance risks in our article on common TecDoc integration errors . Mitigation: set a fixed resynchronization schedule and a validation process after every data update.
- Assuming a 1:1 article-vehicle mapping. A single GenArt can be linked to many KTYPEs, and a single KTYPE can have several candidate articles for the same part category. Mitigation: treat the mapping as a many-to-many relationship with criteria, not as a simple "one vehicle → one part" lookup.
KTYPE and VIN-Based Search: Complementary, Not Interchangeable
A common misconception is to assume that a VIN-based search automatically removes the fitment error risk described above. It does not. According to the technical analysis cited earlier, when a user enters a VIN or license plate number, the system internally converts that code into a KTYPE anyway, in order to look it up in the same compatibility database described in the sections above. In other words, VIN solves the vehicle-identification ambiguity (which exact KTYPE corresponds to that car), but it does not, by itself, add extra granularity at the level of the part's fitment criteria.
For technical details on the real WSDL operations used for VIN-based vehicle identification (getVehicleDataByVINExt, getPartsByVINExt, and others), see our dedicated guide on identifying car parts by VIN with the TecDoc API . The two mechanisms - VIN-based identification and KTYPE/linkage mapping - complement each other: the first answers "what exactly is the vehicle", the second answers "which parts are truly compatible with that vehicle, according to the linkage criteria".
Practical Laravel/PHP Implementation: What to Check in Your Compatibility Mapping
For the full architecture of a Laravel store with TecDoc integration - the cars* tables structure, catalog_products, and the dedicated integration service - we already detailed the project in our article on Laravel architecture for auto parts stores with TecDoc . For compatibility mapping specifically, we recommend extending that architecture with a structure that explicitly stores the criteria too, not just the base link:
| TecDoc Element | Role | Recommended local mapping |
|---|---|---|
carId / KTYPE | The exact vehicle configuration | cars.tecdoc_ktype_id (unique index) |
linkageTargetType | The link's target vehicle class | catalog_products.vehicle_class |
attrId / attrValue | The exact fitment criterion | Separate fitment_criteria table, many-to-many relation |
attrIsConditional / attrIsInterval | The criterion's restriction type | Boolean columns on fitment_criteria, evaluated on display |
In practice, before marking a product as "compatible" on the listing page, the integration service should explicitly evaluate the criteria, not just the base link:
public function isCompatible(Article $article, int $ktypeId): bool { $linkage = $article->linkagesFor($ktypeId); if (!$linkage) { return false; } foreach ($linkage->criteria as $criterion) { if ($criterion->isConditional && !$criterion->matchesVehicle($ktypeId)) { return false; } if ($criterion->isInterval && !$criterion->withinInterval($ktypeId)) { return false; } } return true; }The code above is simplified for clarity and is not a complete SOAP/REST client; its purpose is to show the principle - isConditional and isInterval must be evaluated explicitly, not just stored as metadata with no use in the display logic. The real WSDL operations that feed this logic (getCriteria2, getCriteriaDialogAttributs, getVehicleIdsByCriteria) require an active TecAlliance license; the licensing steps are detailed in our complete TecDoc license guide for online stores .
Checklist: How to Audit an Existing Compatibility Mapping
- Check, in your own contract/WSDL, which values and which format
linkageTargetTypeactually uses - do not assume a generic example. - Pull a sample of KTYPEs with multiple candidate articles for the same part category and confirm whether the real difference comes from conditional criteria ignored by your current code.
- Confirm, by reading the production code, that
attrIsConditionalandattrIsIntervalare evaluated explicitly before showing the "compatible" status, not just stored as descriptive information. - Check the date of the last linkage data resynchronization against TecAlliance's updates and document a fixed resynchronization schedule.
- Test the same vehicle through both flows - direct KTYPE search and VIN-based search - and confirm the fitment results are identical.
- Document known exceptions separately (for example, universal parts with no associated KTYPE), so they are not treated as mapping errors in support reports.
FAQ: Common Questions About Compatibility Mapping in TecDoc
Is KTYPE the same as the car's license plate number or VIN?
No. KTYPE is TecDoc's internal identifier for a vehicle's technical configuration. The license plate number and VIN are data specific to one car unit, which the system internally translates into a KTYPE so it can be looked up in the compatibility database.
Why does TecDoc show multiple "compatible" parts for the same KTYPE?
Because the KTYPE model is a "defined fitment" model - a lower granularity than a full technical vehicle configuration. Several articles can correctly link to the same KTYPE, and the exact differentiation happens through the link's additional criteria, not through the KTYPE alone.
What do attrIsConditional and attrIsInterval mean in a link?
They are attributes that narrow down an article-vehicle link: attrIsConditional marks a specific condition (for example, an engine code), while attrIsInterval marks a validity limited to an interval (for example, a range of production years). Ignoring them in code leads directly to fitment errors.
Do I need to recalculate the mapping when TecAlliance updates the data?
Yes. Links and criteria are updated periodically at the TecDoc catalog level. Without a clear resynchronization and validation process, your store can end up with a mapping that is out of sync with the official catalog.
Can I rely only on VIN-based search, without dealing with KTYPE and criteria?
We don't recommend that. VIN solves exact vehicle identification, but the result is still a KTYPE looked up in the same linkage database. Without evaluating conditional/interval criteria, you risk the same fitment errors, whether the vehicle was identified by VIN or by manual make/model selection.
Conclusion: Fitment Precision Comes from KTYPE Plus Criteria, Not KTYPE Alone
Vehicle-part compatibility mapping in TecDoc works through KTYPE/NTYPE, linkage tables, and conditional/interval criteria attached to each link. Fitment errors reported by customers most often stem from ignoring criteria or misreading the linkageTargetType coding, not from missing data in the TecDoc catalog. Correct mapping treats the article-vehicle relationship as many-to-many, with criteria evaluated explicitly, not as a simple single-identifier lookup.
If you want to verify or fix the compatibility mapping in your auto parts store, the HappyWeb.ro team can review your linkage data and existing criteria with you, to remove fitment errors from production.
Need a custom solution for your auto parts catalog? Let's talk.
We build Laravel applications with TecDoc integration. See our portfolio.
Image generated with AI, used for illustrative purposes.
Write a comment