---
title: Model SKU details as a reusable field schema
---

> Agent instructions:
> **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown.
>
> - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version.
> - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt).

## Model SKU details as a reusable field schema

The _Content modeling MCP server_ initially generated a simple _SKU_ field directly on the _Product_ content type. This works for basic scenarios, but as commerce implementations grow, you'll often need more sophisticated SKU management across multiple product types.

Besides SKU identification, products often also require additional identifiers for [inventory management](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/model-product-catalog/model-product-stock.md), _barcode scanning_, _manufacturer part numbers_, or integration with external systems. To avoid duplication and inconsistency, you can create a dedicated _ProductSKU_ reusable field schema. This schema will include fields _ProductSKUCode_, _ProductSKUBarcodeEAN_, _ProductSKUBarcodeUPC_, _ProductSKUMPN_, _ProductSKUExternalId_, and other project-specific fields.

#### When a simple SKU field is enough

Not every implementation needs the full _ProductSKU_ schema. For simple catalogs with no integration requirements, a single SKU field may suffice.

#### When _ProductSKU_ should be a reusable schema

The _CoreContentSchema_ defined [above](https://docs.kentico.com/modules/commerce-content-modeling/define-core-product-schema.md#define-the-corecontent-reusable-field-schema) supports all content, including non-product content types, such as _articles_, _featured content_, or _press releases_.

A dedicated _ProductSKU_ RFS offers several advantages:

- **Cross-type consistency**. Whether you're working with a dog collar (_Product_) or a fish (_Pet_), SKU-related data is captured and structured identically. This consistency makes queries, integrations, and reporting significantly easier.
- **Centralized evolution**. When you need to add new identifier types, such as GTIN for Google Shopping or ISBN for pet care books, you update the ProductSKU schema once, and all content types using it automatically gain the new field.
- **Integration readiness**. External systems (for example, inventory management, POS, or marketplaces) expect standardized product identifiers. A reusable schema ensures your content model speaks the same language as these systems.
- **Integration signal.** Use the SKU schema to signal to integrations. Developers can build mechanism that determines when event handlers or scheduled tasks should propagate product updates to inventory, pricing, or other external systems.

If you answer "yes" to any of these questions, consider using the _ProductSKU_ schema approach:

- Do multiple product types require SKU identification?
- Will you integrate with inventory, ERP, or marketplace systems?
- Do you need barcode scanning capabilities?
- Do you sell products from multiple manufacturers with unique part numbers?
- Might you need additional identifier types in the future?

For _Pawsome Pets_, we chose a simple _ProductSKU_ field on the _Product_ content type for simplicity.

When finalizing your project’s _Product_ fields, aim to balance simplicity with scalability. Starting too simple, you may face technical debt later. Overengineer early can slow your team. Aim for a solution that fits your current needs and allows for future growth.

Consider the above questions before defaulting to an overly simple commerce content type model.

## When to use reusable field schema vs. direct content type fields

You might wonder when to use a reusable field schema versus adding fields directly to a content type. Here's the general guidance:

| Use RFS when:                                                                                                                                                                                                                              | Use direct fields when:                                                                                                                                           |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The fields are reused across multiple content types.<br>You want to maintain consistency in how certain data is captured.<br>The fields form a logical grouping relevant across contexts.<br>You expect that the schema evolves over time. | The field is unique to a single content type.<br>The field serves a specific, non-replicable purpose.<br>You need maximum flexibility without schema constraints. |