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 — brand, GPC code, access tier, or any other vocabulary term your records carry. Clicking a row opens the record in the 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.

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:

From here you continue in the 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).

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.

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.

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 explains this boundary.

What deletion never touches is history: every save in a record's life created a version, and the Versions tab keeps the record of what was published, by whom, and when.