Adobe-Commerce-Migrationen werden besonders dann unzuverlässig, wenn übertragene Datensätze von den Enterprise-Beziehungen getrennt werden, die bestimmen, wer kaufen darf, was sichtbar ist, welcher Preis gilt, von wo Bestand erfüllt wird und wann Inhalte aktiv werden. Ein Produkt kann im Admin vorhanden und dennoch kommerziell falsch sein, weil es der falschen Website zugeordnet ist, seine Configurable Children fehlen, es aus einem Shared Catalog ausgeschlossen ist oder keine nutzbare Source-/Stock-Beziehung besitzt.
Die schwerwiegendsten Fallstricke sind deshalb selten bloße fehlende Datensätze. Es sind Beziehungsfehler, die bei oberflächlicher Prüfung vollständig wirken. Vorbeugung verlangt für jede Enterprise-Regel einen klaren Adobe-Commerce-Owner, ein repräsentatives Szenario und eine eindeutige Pass-Bedingung.
Fallstrick 1: Company Accounts in voneinander unabhängige Kundendatensätze umwandeln
Was schiefgeht
B2B-Company-Accounts in Adobe Commerce können Company Administrators, Teams, Users, Rollen, Berechtigungen, Adressen, Zahlungserwartungen und Einkaufsbeziehungen enthalten. Eine Migration, die nur einzelne Customers importiert, erhält Kontaktdaten, entfernt aber die Organisation, die diese Käufer steuert.
Der Shop kann alle erwarteten E-Mail-Adressen zeigen, während Company Administrators Benutzer nicht verwalten können, Assistant Buyers zu viele Rechte erhalten und Orders nicht mehr dem richtigen Business Account zugeordnet sind.
Frühe Warnsignale
| Frühes Warnsignal | Was es zeigt |
|---|---|
| Company-, Division-, Team- und User-Datensätze werden als eine Customer-Liste exportiert. | Die B2B-Hierarchie wird in voneinander unabhängige Einzelkonten abgeflacht. |
| Administrator- und Buyer-Rollen sind nur als Freitextlabels vorhanden. | Berechtigungen und Genehmigungszuständigkeit lassen sich nicht verlässlich rekonstruieren. |
| Mehrere Käufer teilen Unternehmenspreise oder Adressen, aber es existiert keine dauerhafte Company-ID. | Gemeinsamer kommerzieller Kontext zerfällt auf einzelne Customers. |
| Die Quelle verwendet Approval-, Account-Credit- oder eingeschränktes Payment-Verhalten außerhalb des Customer-Datensatzes. | Eine kritische B2B-Funktion besitzt keinen Ziel-Owner. |
Prävention
Modellieren Sie die Company als übergeordnete Business Entity. Erhalten Sie Company Identifier, Company Administrator, untergeordnete Users, Teams, Role Assignments, Adressen, Kundengruppenbeziehung und den externen Account Key, den CRM- oder ERP-Systeme verwenden. Leiten Sie Company Membership nicht allein aus E-Mail-Domains oder ähnlichen Adressen ab.
Empfehlungsbeispiel
Verwenden Sie eine Company mit Administrator, Senior Buyer und eingeschränktem Buyer als repräsentatives Muster. Übertragen Sie Company Membership und Rolle jedes Users separat und erhalten Sie anschließend den gemeinsamen Account und den externen Company Identifier.
Pass-Bedingung
Die repräsentative Company erscheint genau einmal, enthält die richtigen Users und Teams, weist jeder Rolle die vorgesehenen Berechtigungen zu und bleibt mit der richtigen Kundengruppe, den richtigen Adressen und dem externen Account Key verknüpft.
Fallstrick 2: Shared Catalogs zuweisen, ohne unternehmensspezifische Preise zu erhalten
Was schiefgeht
Shared Catalogs können Produktauswahl und individuelle Preise für Company Accounts steuern. Werden Products und Companies ohne die Shared-Catalog-Beziehung importiert, können eingeschränkte Products öffentlich sichtbar werden, vertraglich freigegebene Artikel für berechtigte Käufer fehlen oder verhandelte Preise durch allgemeine Katalogpreise ersetzt werden.
Der Fehler lässt sich leicht übersehen, weil der Primärkatalog im Admin vollständig aussehen kann, während die Storefront-Sichtbarkeit je Company-Kontext abweicht.
Frühe Warnsignale
- Dieselbe SKU besitzt unterschiedliche Preise für verschiedene Companies oder Kundengruppen.
- Private Products sind im allgemeinen Product Export enthalten.
- Verträge oder ERP-Datensätze definieren Preise, die nicht am Quellprodukt gespeichert sind.
- Company Assignment und Catalog Assignment werden in unterschiedlichen Quellsystemen gepflegt.
Prävention
Erstellen Sie eine explizite Beziehung zwischen Company, Shared Catalog, Produktauswahl, individuellem Preis, Website-Scope und Kundengruppe. Halten Sie den öffentlichen Katalog getrennt von unternehmensspezifischen Katalogen und bewahren Sie externe Vertragskennungen auf, wenn sie die Preisquelle erklären.
Empfehlungsbeispiel
Verwenden Sie eine öffentliche SKU, eine eingeschränkte SKU und eine vertragsbepreiste SKU. Stellen Sie dar, wie jede für einen Gast, einen allgemeinen Customer und zwei Companies mit unterschiedlichen Shared Catalogs erscheint.
Pass-Bedingung
Jeder repräsentative Käufer sieht nur die vorgesehenen Products und Preise. Benutzer außerhalb der zugewiesenen Company können eingeschränkte Products oder verhandelte Werte weder über Categories, Suche, direkte URLs, Cart noch Checkout erreichen.
Fallstrick 3: Käufer neu anlegen, aber Quotes, Purchase Orders und Genehmigungsbeziehungen verlieren
Was schiefgeht
B2B-Einkauf in Adobe Commerce kann Negotiable Quotes, Purchase Orders, Approval Rules, Requisition Lists und rollenbasierten Zugriff umfassen. Diese Datensätze sind keine gewöhnlichen Orders oder Wish Lists. Werden sie in generische Notizen abgeflacht, gehen Status, Owner, Genehmigungspfad, Positionshistorie und Beziehung zum Company Account verloren.
Ein Käufer kann seine Order History behalten und dennoch einen offenen Quote, eine ausstehende Purchase Order oder die Requisition List für wiederkehrende Einkäufe verlieren.
Frühe Warnsignale
| Frühes Warnsignal | Was es zeigt |
|---|---|
| Quotes und Purchase Orders werden zusammen mit Orders exportiert, besitzen aber andere Kennungen oder Status. | Unterschiedliche Einkaufsworkflows werden zu abgeschlossener Bestellhistorie zusammengeführt. |
| Approval Limits stehen in Richtliniendokumenten oder einem externen Procurement-System. | Die Steuerlogik liegt außerhalb des migrierten Datensatzbestands. |
| Requisition Lists enthalten wiederkehrende SKU-Sets, werden aber wie Wish Lists behandelt. | Operative Einkaufsabsicht wird fälschlich als Merchandising-Präferenz klassifiziert. |
| Quote-Kommentare, Revisionen, Ablaufdatum oder verhandelte Rabatte besitzen keinen vorgesehenen Owner. | Die kommerzielle Verhandlungshistorie wird unvollständig. |
Prävention
Klassifizieren Sie jeden B2B-Workflow separat. Erhalten Sie Company, Creator, Approver, Status, Positionen, Mengen, verhandelte Anpassungen, Kommentare, Daten und externe Referenzen, sofern der Zielworkflow Kontinuität benötigt. Historische Datensätze, die nicht aktiv fortgeführt werden können, sollten dennoch genug Kontext behalten, damit Mitarbeiter und Käufer ihren Zustand verstehen.
Empfehlungsbeispiel
Wählen Sie einen offenen Negotiable Quote, eine freigegebene Purchase Order, eine noch zu genehmigende Purchase Order und eine Requisition List. Definieren Sie für jeden Datensatztyp den Ziel-Owner und die zu erhaltende Historie.
Pass-Bedingung
Das Ziel unterscheidet Quotes, Purchase Orders, Genehmigungsbeziehungen, Requisition Lists und abgeschlossene Orders. Jeder repräsentative Datensatz bleibt mit der richtigen Company und dem richtigen User verbunden und besitzt einen verständlichen Status sowie nachvollziehbare Positionshistorie.
Fallstrick 4: Adobe-Commerce-Scope über Websites, Stores und Store Views hinweg zusammenführen
Was schiefgeht
Adobe Commerce verwendet eine Hierarchie aus Websites, Stores und Store Views. Scope kann Product Assignments, Root Categories, lokalisierte Texte, URLs, Konfiguration, Währungen und B2B-Kommerzkontext beeinflussen. Ein globaler Import kann regionale oder sprachspezifische Werte überschreiben und Products oder Inhalte dem falschen Storefront zuordnen.
Die Default Store View kann korrekt aussehen, während eine andere Sprache, Marke oder Region Fallback-Text, fehlende Products oder falsche Routes zeigt.
Frühe Warnsignale
- Products oder Categories unterscheiden sich je Website oder Marke.
- Namen, Beschreibungen, Metadaten und URL Keys variieren je Store View.
- Jeder Store hat eine andere Root Category oder Navigation.
- Customers, Shared Catalogs, Währungen oder Inhalte sind an bestimmte Websites gebunden.
Prävention
Ordnen Sie die Quell-Store-Hierarchie der Adobe-Commerce-Ownership für Website, Store und Store View zu, bevor Entity Values geschrieben werden. Trennen Sie globale Attribute von website-spezifischen Preisen und Store-View-Inhalten. Bewahren Sie Source-Scope-Codes, wenn Integrationen oder Importe davon abhängen.
Empfehlungsbeispiel
Verwenden Sie ein Configurable Product und eine CMS Page mit unterschiedlichen Texten, URL Keys und Sichtbarkeit über zwei Store Views und zwei Websites. Dokumentieren Sie, welche Werte global und welche scoped sind.
Pass-Bedingung
Jede repräsentative Website, jeder Store und jede Store View zeigt die vorgesehenen Product Assignments, Root Category, lokalisierten Inhalte, URLs und den richtigen kommerziellen Kontext, ohne Werte aus einem anderen Scope zu übernehmen.
Fallstrick 5: Komplexe Produkttypen in flache Products reduzieren
Was schiefgeht
Adobe Commerce unterstützt simple, configurable, grouped, virtual, bundle, downloadable und gift-card Products. Diese Typen verwenden unterschiedliche Parent-Child-, Inventory-, Preis-, Gewichts-, Datei- und Cart-Beziehungen. Werden sie in gewöhnliche Products abgeflacht, können SKUs dupliziert, auswählbare Kombinationen entfernt, Bundle-Zusammensetzungen zerstört oder Download-Dateien getrennt werden.
Ein Product kann vollständig erscheinen und dennoch nicht mehr wie das Angebot funktionieren, das Kunden zuvor gekauft haben.
Frühe Warnsignale
- Parent- und Child-SKUs werden nicht getrennt identifiziert.
- Bundle-Komponenten oder Grouped Products stehen nur als Text in Beschreibungen.
- Download Links und Access Limits werden außerhalb des Product Export gepflegt.
- Custom Options werden mit Configurable Attributes vermischt.
Prävention
Klassifizieren Sie den Produkttyp vor dem Feld-Mapping. Erhalten Sie Configurable Parent-Child Associations, Variation Attributes, Bundle Options, Grouped Links, Downloadable Files, die Bedeutung von Virtual Shipping und die Interpretation der Order Lines. Erzeugen Sie keine Varianten aus beschreibenden Attributen, die keine eigenständig verkaufbaren Einheiten identifizieren.
Empfehlungsbeispiel
Verwenden Sie ein Configurable Product mit gemischtem Child-Bestand, ein Bundle mit dynamischem Preis, ein Grouped Product und ein Downloadable Product. Erhalten Sie jeweils die unterschiedliche Zusammensetzung und Fulfillment-Bedeutung.
Pass-Bedingung
Jedes repräsentative Product behält die korrekte Parent-Child- oder Komponentenstruktur, auswählbare Werte, SKU-Identität, Preisquelle, Bestandsfunktion, Medien und Bedeutung in Order Lines.
Fallstrick 6: Kampagneninhalt ohne seine Staging-Zeitachse importieren
Was schiefgeht
Adobe Commerce Content Staging kann Aktualisierungen von Products, Categories, Catalog- und Cart-Price-Rules sowie CMS Pages über Kampagnen planen. Werden nur aktuell sichtbare Werte importiert, können zukünftige Kampagnen, Baseline-Inhalte, Kampagnenzuordnung, Zeitfenster und die automatische Rückkehr nach einem Enddatum verloren gehen.
Eine zukünftige Promotion kann nie erscheinen, oder Kampagneninhalt bleibt dauerhaft aktiv, weil die Zeitachse auf statische Felder reduziert wurde.
Frühe Warnsignale
| Frühes Warnsignal | Was es zeigt |
|---|---|
| Die Quelle enthält geplante Product-, Preis-, Category-, Rule- oder CMS-Änderungen. | Aktuelle Werte allein bilden den Kampagnenplan nicht ab. |
| Marketingteams verwenden einen Staging-Kalender oder Kampagnennamen. | Timing und koordinierte Aktivierung gehören zur geschäftlichen Bedeutung. |
| Mehrere Entities ändern sich gemeinsam zum selben Launch-Zeitpunkt. | Ein Einzel-Datensatzimport kann die Kampagnenbeziehung nicht erhalten. |
| Aktiver Inhalt weicht von der gespeicherten Baseline-Version ab. | Die Migration kann den falschen zeitlichen Zustand erfassen. |
Prävention
Inventarisieren Sie Baseline Values, geplante Updates, Campaign Membership, Start- und Endzeitpunkte, Zeitzonenannahmen und betroffene Store Views. Entscheiden Sie, welche Kampagnen weiter relevant sind und welche als aktuelle Adobe-Commerce-Staging-Records neu aufgebaut werden sollten, statt als statische Inhalte importiert zu werden.
Empfehlungsbeispiel
Verwenden Sie eine Kampagne, die gleichzeitig einen Product Price, Category Content und eine CMS Landing Page ändert. Erhalten Sie Baseline Values und Campaign Window als getrennte Zustände.
Pass-Bedingung
Die repräsentative Kampagne besitzt die richtigen Entities, Baseline-Inhalte, Zeitplanung, Store-View-Kontext und Reversion-Verhalten. Kein zukünftiges Update wird stillschweigend in dauerhaft aktive Daten umgewandelt.
Fallstrick 7: Mengen kopieren, ohne Sources, Stocks und Sales-Channel-Beziehungen wieder aufzubauen
Was schiefgeht
Adobe Commerce Inventory trennt physische Sources von Stocks, die Sources für Sales Channels aggregieren. Eine Menge ohne Source, Stock, Website, Status und salable context kann Bestand dem falschen Lager zuordnen oder ein Product trotz positiver Menge unverfügbar machen.
Multi-Source-Shops sind besonders gefährdet, wenn alle Standorte in die Default Source summiert werden.
Frühe Warnsignale
- Warehouse-, Store-, Drop-Shipper- oder Pickup-Mengen werden getrennt geführt.
- Die Quelle verwendet Allocation, Reservation oder Channel-spezifische Availability.
- Importierte Products landen in einer Source, obwohl mehrere Standorte Orders erfüllen.
- Configurable Children besitzen unterschiedliche Location Coverage.
Prävention
Erhalten Sie Source Identity, Source Code, Source Quantity, Stock Assignment, Website Relationship, Status und External Warehouse Key. Trennen Sie On-Hand Quantity von dem Wert, der über einen bestimmten Sales Channel tatsächlich verkauft werden kann. Definieren Sie, welches System nach der Migration maßgeblich bleibt.
Empfehlungsbeispiel
Verwenden Sie eine SKU, die in zwei Lagern liegt, und ein Configurable Product, dessen Children aus unterschiedlichen Sources verfügbar sind. Ordnen Sie jede Source dem Stock zu, der die vorgesehene Website bedient.
Pass-Bedingung
Die repräsentativen Products zeigen die richtigen Source Quantities, Stock- und Website-Zuordnungen, salable availability und Fulfillment Ownership, ohne unterschiedliche Standorte in einer unerklärten Gesamtmenge zusammenzuführen.
Fallstrick 8: URL Rewrites und scoped Inhalte wie einfache Slugs behandeln
Was schiefgeht
Adobe Commerce kann URL Rewrites für Products, Categories und CMS Pages verwalten. Routes können je Website oder Store View abweichen, und Inhalte können interne Links, Media Paths, Page-Builder-Strukturen oder Kampagnenreferenzen enthalten. Wird nur der aktuelle Slug kopiert, können Redirect History verloren gehen und wertvolle Nutzerpfade brechen.
Frühe Warnsignale
- Die Quelle enthält mehrere historische URLs für dieselbe Entity.
- Product- oder Category-URL-Keys variieren je Store View.
- CMS-Inhalte enthalten fest codierte Quell-URLs oder Media Paths.
- Campaign-, Paid-Media- oder Partner-Links hängen von Legacy Routes ab.
Prävention
Behandeln Sie jeden Quellpfad als Beziehung aus Old Route, Destination Entity, Scope, Redirect Type und vorgesehener Canonical Route. Schreiben Sie interne Links und Media References entsprechend dem Ziel-Owner um. Halten Sie CMS Content, Page Builder Layout und URL History getrennt.
Empfehlungsbeispiel
Verwenden Sie ein Product mit umbenannter URL, eine Category, die in der Hierarchie verschoben wurde, und eine lokalisierte CMS Page. Erhalten Sie das kanonische Ziel und alle geschäftskritischen Quellpfade.
Pass-Bedingung
Jeder repräsentative Legacy Path erreicht das vorgesehene scoped Ziel, interne Links und Medien werden korrekt aufgelöst und eingeschränkte oder lokalisierte Inhalte werden nicht auf die falsche Website oder Store View umgeleitet.
Fallstrick 9: Order-Summen erhalten, aber Company- und Fulfillment-Kontext verlieren
Was schiefgeht
Historische Orders können Summen behalten und gleichzeitig Company Ownership, Käuferrolle, Shared-Catalog-Kontext, Quote- oder Purchase-Order-Lineage, Source Items, Shipments, Invoices, Refunds und externe Transaction Identifiers verlieren. Mitarbeiter sehen dann einen Finanzdatensatz ohne genügend Informationen, um den Käufer zu unterstützen oder die Transaktion abzustimmen.
Frühe Warnsignale
- B2B Orders sind nur mit einzelnen Customers verknüpft.
- Order Lines können das ursprüngliche Configurable Child oder Bundle Component nicht identifizieren.
- Shipment- und Refund-Datensätze werden getrennt vom Order Export gespeichert.
- ERP- oder Payment-Referenzen stehen nur in Extension Tables.
Prävention
Erhalten Sie Order Header, Company- und Buyer Identity, Adressen, Line Snapshots, Selected Options, Preise, Rabatte, Steuern, Shared-Catalog- oder Quote-Referenz, Invoices, Shipments, Refunds, Kommentare und externe IDs. Halten Sie historische Snapshots unabhängig von aktuellen Product- und Company-Einstellungen.
Empfehlungsbeispiel
Verwenden Sie eine Company Order aus einem Quote, eine teilweise versandte Order und eine erstattete Order mit Configurable Product. Verfolgen Sie jeden zugehörigen Datensatz zurück zur Order.
Pass-Bedingung
Jede repräsentative Order bleibt für Kundenservice, Finance und Operations verständlich; Company-, Buyer-, Product-, Payment-, Shipment-, Refund- und External-System-Kontext sind intakt.
Fallstrick 10: Extension- und Integrationsfelder ohne ihre verantwortliche Logik kopieren
Was schiefgeht
Adobe-Commerce-Installationen enthalten häufig Modules, Custom Attributes, Custom Tables, APIs, Event Observers, ERP- und PIM-Identifiers, Marketplace Records, Tax Integrations, Fulfillment Data und individuelle Checkout Fields. Werte in generische Felder zu kopieren erhält nicht den Workflow, der sie erstellt, aktualisiert oder verwendet.
Das Ziel kann die Daten enthalten, während jedes verbundene System sie als fehlend oder veraltet behandelt.
Frühe Warnsignale
| Frühes Warnsignal | Was es zeigt |
|---|---|
| Wichtige Werte haben Module Prefixes oder liegen in Custom Tables. | Die Daten werden wahrscheinlich von Extension Logic und nicht von einer Standard-Entity verwaltet. |
| Externe Systeme identifizieren Products, Companies, Customers oder Orders über nicht standardisierte Schlüssel. | Systemübergreifende Kontinuität hängt von Kennungen außerhalb der Default Fields ab. |
| Gültige Feldwerte werden durch Code statt Datenbankstruktur erzwungen. | Das Kopieren des Werts allein erhält seine Regeln nicht. |
| Mitarbeiter können nicht erklären, welches System für das Feld maßgeblich ist. | Ownership-Konflikte können dazu führen, dass der Wert überschrieben oder ignoriert wird. |
Prävention
Erstellen Sie ein Ownership Register für jeden Extension- und Integrationsdatensatz. Benennen Sie Parent Entity, Source Table oder API, External Key, Authoritative System, Update Direction und Destination Owner. Schließen Sie obsolete technische Rückstände aus, statt sie zu dauerhaften Custom Fields zu machen.
Empfehlungsbeispiel
Verfolgen Sie ein Product vom PIM zu Adobe Commerce, eine Company aus dem CRM und eine Order zu ERP und Fulfillment. Dokumentieren Sie Kennungen und Ownership-Grenzen an jedem Schritt.
Pass-Bedingung
Jeder erhaltene Custom- oder Integrationswert besitzt einen definierten Destination Owner, eine stabile Parent-Beziehung, ein maßgebliches System und eine nutzbare systemübergreifende Kennung. Kein wesentlicher Workflow hängt von einem verwaisten Feld ab.
Übergreifende Präventionsprioritäten
Adobe-Commerce-Prävention sollte fünf verbundene Ebenen erhalten: Company Identity, käuferspezifische Commercial Rules, scoped Storefront Data, Product- und Inventory-Beziehungen sowie External-System Ownership. Eine Korrektur in einer Ebene darf nicht stillschweigend eine andere beschädigen. Wird beispielsweise ein Shared Catalog neu aufgebaut, beeinflusst das auch Company Assignment, Category Permissions, Price Indexing und Storefront Access.
| Präventionsebene | Erforderliche Kontrolle |
|---|---|
| Company- und Buyer-Identität | Company-, Location-, Rollen-, Approval- und Customer-Beziehungen verbunden halten. |
| Commercial Assignment | Shared Catalog, Company Assignment, Variant Price und Purchasing-Rule-Kontext gemeinsam erhalten. |
| Scoped Storefront Data | Website-, Store- und Store-View-Ownership für Products, Inhalte, URLs und Customers erhalten. |
| Zeitabhängiger Content | Aktiven Zustand von geplanten Kampagnenversionen und koordinierten Änderungen trennen. |
| Externe Ownership | Extension Fields, Custom Tables und externe Kennungen einem maßgeblichen System zuweisen. |
Fazit
Adobe-Commerce-Migrationen werden unzuverlässig, wenn Enterprise-Beziehungen auf gewöhnliche Commerce-Felder reduziert werden. Companies, Rollen, Shared Catalogs, Quotes, Purchase Orders, scoped Werte, Content Campaigns, Inventory Sources, historische Orders, URL Rewrites und Integrationskennungen benötigen jeweils einen eindeutigen Owner.
Das sicherste Migrationsmodell behandelt jeden Fallstrick als gebrochene Beziehung statt als fehlende Tabellenzeile. Wenn Parent Entities, Commercial Rules, Scopes, Histories und External Keys verbunden bleiben, kann der migrierte Shop die Enterprise-Workflows unterstützen, für die diese Datensätze bestimmt waren.
Häufige Fragen
Warum sind Adobe-Commerce-Company-Users nicht mit gewöhnlichen Customers gleichzusetzen?
Company Users übernehmen geschäftlichen Kontext aus dem Company Account, darunter Rollen, Berechtigungen, Shared Catalogs und Einkaufsabläufe. Ein einzelner Customer-Datensatz erhält diese Beziehungen auf Organisationsebene nicht.
Können Shared-Catalog-Preise als gewöhnliche Product-Preise migriert werden?
Nicht sicher. Shared-Catalog-Preise gehören zu bestimmten Catalog- und Company-Beziehungen. Werden sie in allgemeine Produktpreise übertragen, können verhandelte Werte falschen Käufern sichtbar werden oder den Companies fehlen, die sie erhalten sollten.
Warum müssen Website-, Store- und Store-View-Scope getrennt erhalten werden?
Die Hierarchie kann Product Assignment, Root Categories, lokalisierte Werte, URLs, Konfiguration und kommerziellen Kontext steuern. Ein globaler Wert kann absichtlich scoped Informationen überschreiben oder in einen anderen Scope auslaufen lassen.
Was unterscheidet Content Staging von gewöhnlichem CMS Content?
Content Staging erhält Baseline Values, Scheduled Updates, Campaign Grouping, Timing und Reversion-Verhalten. Der aktuell sichtbare Wert stellt nur einen Zeitpunkt innerhalb dieser Zeitachse dar.
Warum reicht eine Quellmenge für Adobe-Commerce-Inventory nicht aus?
Die Bedeutung von Inventory hängt von physischer Source, dem Stock, der Sources aggregiert, dem Sales Channel oder der Website, dem Status und dem System ab, das weiterhin maßgeblich bleibt. Eine Menge allein beschreibt nicht, wo oder wie ein Artikel erfüllt werden kann.
Wie sollten Extension-eigene Adobe-Commerce-Daten behandelt werden?
Identifizieren Sie das Module oder externe System, die Core Entity, die es erweitert, die stabile Kennung und den Workflow, der den Wert verwendet. Behalten Sie nur Datensätze mit einem definierten Destination Owner und fortbestehendem geschäftlichen Nutzen.