--- title: "Managing Products" description: "The DDM product catalog — creating products from a passport type, importing in bulk, and keeping the catalog tidy." canonical_url: "https://openepcis.io/docs/digital-data-management/product-catalog" last_updated: "2026-08-26T20:11:04.677Z" --- ## The product list **Products** lists every GTIN-keyed record in your tenant. Each row shows the product's thumbnail, name and GTIN, plus whichever columns you have [picked](/docs/digital-data-management/getting-started#finding-things) — brand, GPC code, access tier, or any other vocabulary term your records carry. Clicking a row opens the record in the [passport editor](/docs/digital-data-management/passport-editor); the trash icon deletes it, after a confirmation that names exactly what will be removed. So far, so much like any catalog application. What is different about DDM's catalog begins the moment you create a record. ## Creating a product **Add Product** opens a fresh passport, and the first thing DDM asks is not the product's name — it is the **passport type**. ![The passport type picker | Figure 1: Creating a product starts with choosing a passport type](/img/13.Digital-Data-Management/product-type-picker.png) Why does the type come first? Because in DDM, the form you fill in is not a fixed screen someone designed once. It is **generated from a vocabulary** — a formal, machine-readable description of which fields a product of this kind has, what each field means, and what values it may hold. The passport type selects that vocabulary. Choose **Product** and you get the generic GS1 Web Vocabulary profile, the right choice when no product-group regulation applies. Choose **Battery**, **Detergent Product**, **Electronic Device**, **Iron & Steel Product**, **Packaging (PPWR)** or one of the three **Textile** types, and you get a form that already knows its regulation: the EU Battery Regulation's mandatory fields are marked mandatory, the recommended ones recommended, each traceable to the clause that demands it. This is worth pausing on, because it explains a lot of what follows in this guide. Since the form is generated, it is always in step with the vocabulary — when the regulation profile gains a field, every deployment gains that field without anyone redesigning a screen. And since every field *is* a vocabulary term, the data you enter is born interoperable: what you store is standard GS1 Web Vocabulary JSON-LD that any other compliant system can read. Choose a type, press **Generate form**, and the sections of the chosen vocabulary appear — for a battery, straight from the EU Battery Regulation profile: ![A new battery passport, freshly generated | Figure 2: The generated form for a new battery product — every field a vocabulary term](/img/13.Digital-Data-Management/product-new-battery.png) From here you continue in the [editor](/docs/digital-data-management/passport-editor). ### The GTIN, and why DDM is strict about it The GTIN you enter becomes the product's identity — it appears in the QR code, in every link, in the GS1 network. A mistake here is expensive, so DDM checks twice. The first check is arithmetic: a GTIN's last digit is a check digit computed from the others, which is how a typo announces itself. DDM validates length and check digit as you type and, on a mismatch, tells you which digit it expected. The second check is against reality: DDM asks **Verified by GS1**, the global GS1 registry, whether this GTIN is actually registered and to whom. A verified GTIN shows its licensee right in the form — and if that licensee is the brand owner, one click adopts it into the record. An *unverified* GTIN blocks creation, and the reason is practical, not bureaucratic: a passport published under a GTIN that GS1 does not know is a passport the world cannot reliably find. The one exception is the GS1 test range — keys beginning with 952 are demo keys by definition, get a friendly note instead of a verification, and are how you experiment freely (see [test prefixes](/docs/digital-data-management/resolver-domains#test-prefixes-952-range)). ![Verified by GS1 during creation | Figure 3: The GTIN checks out — the licensee appears inline and can be adopted as brand owner](/img/13.Digital-Data-Management/verify-gs1.png) If you do not have a GTIN at hand at all, the **Draw** button next to the field takes the next free number from your licensed GS1 company prefix — the mechanics of that pool are explained in [GS1 Germany Sync](/docs/digital-data-management/gs1-sync#the-gs1-company-prefix-pool). ## Bulk import Nobody types a catalog of five thousand products into a form. The upload icon next to **Add Product** imports records in bulk — for products, organizations and places alike. ![The bulk import dialog | Figure 4: Bulk import — CSV or JSON-LD, with a preview of the first rows before anything is written](/img/13.Digital-Data-Management/bulk-import.png) Two formats are accepted, and they serve different situations. **CSV** is for data coming out of spreadsheets and legacy systems — download the template for your record kind to see the expected columns. **JSON-LD** is for data that already speaks GS1 Web Vocabulary, for example an export from another passport system; it arrives with its full structure intact, nothing flattened into columns. Before anything is written, the dialog shows a **preview of the first five rows exactly as DDM parsed them**. This is the moment to catch a mis-mapped column — much cheaper here than after five thousand records. **Confirm & Start Import** then hands the file to a background job; you can keep working, and imported records appear in the list as they are written. Imported rows pass the same validation as records saved by hand. A row with a broken check digit or a malformed field is rejected individually — it does not take the rest of the file down with it. ## Deleting, and what deletion touches Deleting a product removes the catalog record, and with it everything the system derived from that record — most notably the resolver links that were generated from its data. Links you registered *by hand* on the same anchor survive, because they were never derived from the record in the first place; the [linkset ownership model](/docs/digital-data-management/linksets#who-owns-a-link) explains this boundary. What deletion never touches is history: every save in a record's life created a version, and the [Versions tab](/docs/digital-data-management/passport-editor#versions--change-history) keeps the record of what was published, by whom, and when.