AmeriCommerce-Migrationen werden schwierig, wenn komplexe Verkaufsbeziehungen auf gewöhnliche Store-Datensätze reduziert werden. Customer Types können Preise, Sichtbarkeit, Rabatte, Shipping und Content beeinflussen. Mehrere Stores und Microstores können eine gemeinsame Administration nutzen und dennoch unterschiedliche Kataloge und Käufererfahrungen darstellen. Product Groups und Kits können Preise, Inventory sowie Parent-Child-Beziehungen steuern. Eine Migration kann deshalb bei Products, Customers und Orders vollständig aussehen und trotzdem verändern, wie das Unternehmen tatsächlich verkauft.
Die folgenden Fehlerbilder zeigen wiederkehrende AmeriCommerce-Risiken. Jedes verbindet frühe Warnsignale mit einer Präventionsentscheidung, einem praktischen Prüfbeispiel und einer Pass-Bedingung, damit das Team vor der Full Migration erkennen kann, welche Punkte noch nicht ausreichend kontrolliert sind.
Pitfall 1: Käuferdatensätze wie einfache Customer-Daten behandeln
Was schiefgeht
Customers werden als Kontaktdatensätze migriert, doch Customer Type, Firmenbeziehung, Tax-Behandlung, Katalogzugriff, Preise, Rabatte, Shipping-Erwartungen, Login-Weiterleitung und kontospezifischer Kontext gehen verloren. Mitarbeitende finden den Käufer, können aber die frühere kommerzielle Beziehung nicht mehr nachvollziehen oder reproduzieren.
AmeriCommerce Customer Types können weit mehr als Segmentierung beeinflussen. Sie können Preise, Rabatte, Content, Shipping, Sichtbarkeit und Login-Verhalten steuern. Ein Customer Type steht deshalb für eine Kombination von Käuferbehandlungen und nicht nur für ein Label.
Frühe Warnsignale
| Käuferkontext | Warnsignal |
|---|---|
| Wholesale- oder Händlerkonto | Es werden nur Kontaktfelder gemappt. |
| Steuerbefreiter Käufer | Der Tax-Status wird als Notiz gespeichert, ohne dass es eine Zielregel gibt. |
| Firmenkonto | Firmen- und Kontaktbeziehungen werden abgeflacht. |
| Eingeschränkter Käufer | Product- oder Content-Zugriff ist nicht mit dem Customer Type verbunden. |
| Customer eines externen Systems | ERP- oder CRM-Kennungen haben keinen festgelegten Zielort. |
Prävention
Erstellen Sie für jeden aktiven Customer Type eine Matrix der Käuferbehandlung. Dokumentieren Sie vorgesehene Preise, Product- und Category-Sichtbarkeit, Rabatte, Shipping, Tax, Login-Weiterleitung, individuellen Content und externe Kennungen. Trennen Sie die Customer-Identität von der Konfiguration, die das Live-Verhalten steuert.
Prüfbeispiel
Prüfen Sie einen Retail-Customer, einen Wholesale-Customer, einen steuerbefreiten Customer und einen Portal- oder Firmenkäufer. Vergleichen Sie Account-Datensatz, sichtbaren Katalog, Preise, Shipping, Tax-Behandlung und zugehörige Orders.
Pass-Bedingung
Repräsentative Käufer behalten den vorgesehenen Customer Type, die richtige kommerzielle Behandlung, Sichtbarkeit und den Kontext externer Systeme, ohne dass Mitarbeitende dafür auf Erinnerung oder nur im Quellsystem vorhandene Notizen angewiesen sind.
Pitfall 2: Mehrere Stores und Microstores zu einem generischen Storefront zusammenführen
Was schiefgeht
Mehrere AmeriCommerce Stores, Markenseiten, regionale Storefronts, Kundenportale oder Microstores werden in einen einzigen Ziel-Store überführt, ohne den Grund für ihre Trennung zu erhalten. Products, Categories, Preise, Content, Domains und Käuferpfade können in einigen Bereichen gemeinsam und in anderen Store-spezifisch sein. Eine einfache Zusammenführung kann eingeschränkte Kataloge offenlegen, Markenkontext entfernen oder gemeinsam genutzte Daten duplizieren.
Mehrere Stores können über eine gemeinsame Administrationsumgebung betrieben werden. Microstores können gleichzeitig eigenständige Katalog- und Preiserfahrungen innerhalb eines gemeinsamen Domain- und Theme-Kontexts bieten. Diese Strukturen sind nicht austauschbar.
Frühe Warnsignale
| Quellkontext | Verdecktes Risiko |
|---|---|
| Storefront mit eigener Domain | Domain-, Theme-, Katalog- und Preiszweck werden ohne Freigabe zusammengeführt. |
| Microstore | Ein kundenspezifischer Pfad wird wie ein vollständig eigenständiger Store behandelt. |
| Händler- oder Mitarbeiterportal | Eingeschränkte Products werden öffentlich sichtbar. |
| Regionaler Store | Content und Preise werden trotz regionaler Unterschiede zusammengeführt. |
| Gemeinsam genutztes Asset-Verzeichnis | Bilder oder Dokumente werden dupliziert oder uneinheitlich referenziert. |
Prävention
Inventarisieren Sie jeden Verkaufskontext und klassifizieren Sie ihn als erhalten, zusammengeführt, weitergeleitet, neu aufgebaut oder außer Betrieb genommen. Dokumentieren Sie für jeden Kontext Zielgruppe, Domain oder Pfad, Katalog, Preise, Content, Theme und Customer-Type-Beziehungen.
Gehen Sie weder davon aus, dass gemeinsame Administration eine vollständige Datenzusammenführung bedeutet, noch dass getrennte Storefronts vollständig duplizierte Products erfordern.
Prüfbeispiel
Verfolgen Sie für einen primären Retail-Store und zwei Händler-Microstores jeweils ein gemeinsam genutztes Product, ein händlerexklusives Product, einen Customer, einen Preis, eine Landingpage und eine Order durch alle relevanten Kontexte.
Pass-Bedingung
Jeder aktive Verkaufskontext hat eine freigegebene Zielgruppe, einen passenden Katalog, Preise, Content, Route und Customer-Bezug. Es gibt weder unbeabsichtigte Offenlegung noch unerklärte Duplizierung.
Pitfall 3: Categories erhalten, aber Active Catalog und Store-Sichtbarkeit verlieren
Was schiefgeht
Categories und Products werden migriert, doch ihre Store-spezifische Sichtbarkeit verändert sich. AmeriCommerce kann Active Catalogs sowie Product- oder Category-Einstellungen auf Store-Ebene verwenden. Ein Product kann deshalb in bestimmten Stores sichtbar und in anderen verborgen sein. Wird nur der globale Product-Datensatz erhalten, kann der falsche Käufer das falsche Sortiment sehen.
Frühe Warnsignale
| Sichtbarkeitssignal | Risiko |
|---|---|
| Products sind nur in ausgewählten Stores aktiv. | Sie werden überall aktiviert. |
| Categories unterscheiden sich je Storefront. | Eine globale Hierarchie ersetzt beabsichtigte Unterschiede. |
| Customer Types schränken Products ein. | Store-Sichtbarkeit und Käufer-Sichtbarkeit werden verwechselt. |
| Ein Microstore hat ein kuratiertes Sortiment. | Das Sortiment wird zu einer statischen Kopie oder verschwindet. |
Prävention
Trennen Sie globale Product-Identität von Store- und Customer-Sichtbarkeit. Erstellen Sie eine Matrix, die für repräsentative Product-Familien zeigt, in welchen Stores, Microstores, Categories und Customer Types sie sichtbar sein sollen.
Erhalten Sie Store-spezifische Category-Zuordnungen nur, wenn sie weiterhin einem geschäftlichen Zweck dienen. Veraltete Strukturen sollten bewusst konsolidiert werden.
Prüfbeispiel
Wählen Sie ein Product, das überall verkauft wird, ein Product nur für einen Store, ein auf einen Customer Type beschränktes Product und ein Product, das nur über einen Microstore verfügbar ist. Bestätigen Sie die vorgesehene Sichtbarkeit in jedem Kontext.
Pass-Bedingung
Repräsentative Products und Categories erscheinen ausschließlich in freigegebenen Stores und Käuferkontexten. Es gibt weder verdeckte globale Aktivierung noch unbeabsichtigte Einschränkung.
Pitfall 4: Product Groups, Kits, Varianten und Komponenten-Inventory abflachen
Was schiefgeht
Parent Products, Child Products, Kits, gruppierte Products, Komponenten mit transparenter Inventory-Nutzung, Varianten und erforderliche Mengen werden auf gewöhnliche eigenständige Products reduziert. Im Ziel können Name und Preis korrekt aussehen, obwohl Komponentenbestand, Pflichtbestandteile, Mengenbindungen, Suchverhalten oder Parent-Child-Routing verloren gehen.
AmeriCommerce Product Groups können unterschiedliche kommerzielle Muster abbilden, darunter informative Parents, kaufbare Kits und Parent Products, deren Bestand transparent aus Child-Komponenten stammt. Diese Muster benötigen unterschiedliche Beziehungen im Ziel.
Frühe Warnsignale
| Product-Struktur | Fehlermuster |
|---|---|
| Informatives Parent | Das Parent wird kaufbar oder Child Products verlieren ihre gemeinsame Seite. |
| Kit mit optionalen Child Products | Pflicht- und optionale Komponenten sind nicht unterscheidbar. |
| Gruppe mit transparentem Inventory | Der Bestand des Parents berücksichtigt die Verfügbarkeit der Child Products nicht mehr. |
| Mengenabhängige Komponente | Die Child-Menge skaliert nicht mit der Parent-Menge. |
| Daten auf Variantenebene | Preis, SKU oder Bestand werden falsch vom Parent übernommen. |
Prävention
Klassifizieren Sie jede Product-Beziehung nach Kaufverhalten, Darstellung, Preiszuständigkeit, Inventory-Zuständigkeit und erwarteten Order-Positionen. Erhalten Sie die Parent-Child-Beziehung nur, wenn das Ziel dasselbe Geschäftsergebnis unterstützen kann. Andernfalls ist ein bewusster Neuaufbau besser als stilles Abflachen.
Prüfbeispiel
Verwenden Sie ein informatives Parent, ein Kit, ein Product mit transparentem Komponentenbestand und ein variantenreiches Product. Vergleichen Sie Product-Seite, Warenkorb, Order-Positionen und Inventory-Auswirkung.
Pass-Bedingung
Repräsentative Product-Beziehungen erhalten das freigegebene Kauf-, Darstellungs-, Preis-, Komponenten-, Inventory- und Order-Verhalten oder besitzen einen dokumentierten Ziel-Neuaufbau mit eindeutigem Implementierungsverantwortlichen.
Pitfall 5: Komplexe Preise ohne ihre Regeldimensionen migrieren
Was schiefgeht
Preise werden als Endwerte migriert, die Bedingungen dahinter gehen jedoch verloren. AmeriCommerce kann Preise nach Store, Customer Type, Menge, Variante und Zeitraum variieren. Price Calculators können zusätzliche Regeln anwenden. Werden diese Dimensionen auf einen Product-Preis reduziert, verändert sich die Käuferbehandlung und es können Konflikte mit späteren Integrationen entstehen.
Frühe Warnsignale
| Preisdimension | Warnsignal |
|---|---|
| Store-spezifischer Preis | Ein globaler Preis ersetzt mehrere Storefront-Preise. |
| Customer-Type-Preis | Wholesale-Käufer erhalten Retail-Preise. |
| Mengenstaffel | Nur die erste Mengenstufe bleibt erhalten. |
| Variantenpreis | Der Parent-Preis überschreibt den Preis der gewählten Variante. |
| Datumsabhängiger Preis | Abgelaufene oder zukünftige Preise werden dauerhaft. |
| Price Calculator | Nur das Ergebnis wird kopiert, ohne den Regelinhaber zu erhalten. |
Prävention
Erstellen Sie ein Preisregelverzeichnis mit Product oder Variante, Store, Customer Type, Mengenschwelle, Zeitraum, Berechnungsmethode und maßgeblichem Verantwortlichen. Trennen Sie gespeicherte von berechneten Preisen sowie vertragliche von Promotion-Preisen.
Wenn das Ziel ein anderes Preismodell verwendet, muss das beabsichtigte kommerzielle Ergebnis erhalten werden, nicht die Syntax der Quellkonfiguration.
Prüfbeispiel
Wählen Sie ein Product mit Retail- und Wholesale-Preis, zwei Mengenstufen, einem Store-spezifischen Preis und einer zeitlich begrenzten Promotion. Vergleichen Sie den erwarteten Betrag für repräsentative Customers und Stores.
Pass-Bedingung
Repräsentative Preisszenarien erzeugen über Stores, Customer Types, Mengen, Varianten und Zeiträume freigegebene und erklärbare Beträge. Keine Regeldimension fehlt oder ist einem falschen Systemverantwortlichen zugeordnet.
Pitfall 6: Orders ohne Käufer- und Store-Kontext erhalten
Was schiefgeht
Orders werden mit Products, Summen und Customers migriert, aber Store, Microstore, Customer Type, Preisgrundlage, Rabatt, Tax, Payment, Shipping, Vendor, Fulfillment, Status oder externe Referenz fehlen. Mitarbeitende sehen, dass ein Verkauf stattgefunden hat, können den kommerziellen Kontext aber nicht erklären oder mit einem anderen System abstimmen.
Frühe Warnsignale
| Order-Typ | Verdecktes Risiko |
|---|---|
| Retail-Order | Basisfelder stimmen, aber die Store-Identität fehlt. |
| Wholesale-Order | Customer Type und Preisgrundlage sind unklar. |
| Multi-Store-Order | Domain- oder Storefront-Kontext geht verloren. |
| Order mit Kit oder gruppiertem Product | Parent- und Komponentenbedeutung werden abgeflacht. |
| Erstattete oder bearbeitete Order | Ausnahmehistorie ist nicht nachvollziehbar. |
| ERP-verbundene Order | Externe Invoice- oder Order-ID fehlt. |
Prävention
Definieren Sie, wofür historische Orders künftig verwendet werden und welche Evidenz dafür erforderlich ist. Erhalten Sie Customer, Store, Products, Preise, Rabatte, Tax, Payment, Shipping, Status, Notizen, Tracking, Refunds und externe Kennungen, sofern sie für diesen Zweck weiterhin benötigt werden.
Importierte Orders sollten einem klar historischen Zustand zugeordnet werden, sofern das Unternehmen sie nicht bewusst in einen aktiven operativen Ablauf überführen möchte.
Prüfbeispiel
Prüfen Sie eine abgeschlossene Retail-Order, eine Wholesale-Order, eine Microstore-Order, eine rabattierte Order, eine Order mit gruppiertem Product sowie eine erstattete oder stornierte Order. Mitarbeitende sollten jede Transaktion ohne die Quellplattform erklären können.
Pass-Bedingung
Repräsentative Orders bleiben für Support und Abstimmung verständlich, einschließlich Store- und Käuferkontext, ohne fälschlich als aktive Verarbeitungsaufgaben zu erscheinen.
Pitfall 7: Content und SEO als universelle Redirect-Aufgabe behandeln
Was schiefgeht
Die Migration erstellt Redirects, erhält aber nicht die Beziehung zwischen Store, Microstore, Customer Type, Content, Product, Category und Zielseite. Eingeschränkte oder zielgruppenspezifische Seiten können öffentlich weiterleiten, während Marken- oder regionale Landingpages ihren Kontext verlieren.
Frühe Warnsignale
| Routentyp | Risiko |
|---|---|
| Store-spezifische Product-URL | Sie führt in den falschen Store-Kontext. |
| Microstore-Pfad | Er wird als Duplikat der Haupt-Store-Seite behandelt. |
| Kundenspezifischer Content | Eingeschränkte Informationen werden öffentlich oder verschwinden. |
| Category-Landingpage | Der Redirect führt zu einer Product-Liste mit anderer Nutzerabsicht. |
| Außer Betrieb genommenes Portal | Alte Links bleiben ohne passendes Ziel aktiv. |
Prävention
Erstellen Sie das Routeninventar nach Store und Zielgruppe und nicht als eine globale Liste. Klassifizieren Sie wichtige Pfade als erhalten, weitergeleitet, zusammengeführt, neu aufgebaut, eingeschränkt oder außer Betrieb genommen. Bestätigen Sie, dass die Zielseite veröffentlicht ist und zum ursprünglichen Käuferkontext passt.
Prüfbeispiel
Ordnen Sie eine Product-URL des Haupt-Stores, eine Händler-Microstore-URL, eine Category-Landingpage und eine eingeschränkte Customer-Seite zu. Prüfen Sie, ob jedes Ziel sowohl Content-Zweck als auch Zugriffsregeln erhält.
Pass-Bedingung
Wichtige URLs führen zu relevanten Zielen im richtigen Store- und Käuferkontext. Es gibt keine pauschalen Redirects, die eingeschränkten Content offenlegen oder entfernen.
Pitfall 8: Zuständigkeit für Inventory, Vendor und Fulfillment verlieren
Was schiefgeht
Inventory wird als Product-Menge migriert, ohne festzulegen, welches System den Bestand nach dem Cutover besitzt. AmeriCommerce kann Products Store-übergreifend teilen, Inventory auf Varianten- oder Komponentenebene führen und Daten mit Vendors, Warehouses oder ERP-Systemen austauschen. Ein migrierter Anfangsbestand kann bei der nächsten Synchronisierung ersetzt, dupliziert oder der falschen Product-Beziehung zugeordnet werden.
Frühe Warnsignale
| Inventory-Abhängigkeit | Fehlermuster |
|---|---|
| Store-übergreifend geteiltes Product | Die Menge wird je Storefront dupliziert. |
| Varianten-Inventory | Bestand wird nur am Parent Product gespeichert. |
| Transparenter Kit-Bestand | Parent-Menge ignoriert die Verfügbarkeit der Child Products. |
| Vendor- oder ERP-Feed | Die nächste Synchronisierung ersetzt den migrierten Wert. |
| Store-spezifische Verfügbarkeit | Globaler Bestand wird mit tatsächlich verkaufbarer Verfügbarkeit verwechselt. |
Prävention
Definieren Sie die Bestandszuständigkeit nach Product-Ebene, Store-Kontext und externem System. Halten Sie fest, ob die migrierte Menge ein maßgeblicher Anfangsbestand, eine vorübergehende Momentaufnahme oder bewusst ausgeschlossen ist, weil ein anderes System sie initialisiert.
Erhalten Sie Vendor- und Fulfillment-Kennungen nur dort, wo ein fortgeführter Prozess sie tatsächlich nutzt.
Prüfbeispiel
Verfolgen Sie ein Store-übergreifend geteiltes Product, eine Variante und ein Kit mit transparentem Komponentenbestand durch Anfangsbestand, Store-Sichtbarkeit, Aktualisierung durch einen externen Feed und resultierende Order-Zuordnung.
Pass-Bedingung
Repräsentative Products haben genau einen benannten Inventory-Verantwortlichen, die richtige Product-Ebene, nachvollziehbare Anfangsmengen und nach Beginn der Synchronisierung keine doppelten oder widersprüchlichen Store-Bestände.
Pitfall 9: Integrations- und benutzerdefinierte Daten im falschen Datensatz verstecken
Was schiefgeht
ERP-IDs, CRM-Kontoschlüssel, benutzerdefinierte Customer-Felder, Product-Attribute, Vendor-Referenzen, Invoice-Nummern und nur für Reports verwendete Werte werden in praktische Felder kopiert, ohne ihre Datensatzebene oder den weiterhin nutzenden Prozess zu erhalten. Integrationen können Datensätze dann nicht mehr zuverlässig zuordnen oder verändern unerwartet Werte.
Frühe Warnsignale
| Datenabhängigkeit | Risiko |
|---|---|
| Product-Kennung gehört zu einer Variante. | Sie wird auf das Parent Product verschoben. |
| Firmen-ID gehört zu einer Customer-Beziehung. | Sie wird nur bei einem Kontakt gespeichert. |
| Store-spezifisches Flag steuert Sichtbarkeit. | Es wird zu einem globalen Product-Feld. |
| Externe Order-ID unterstützt Reconciliation. | Sie wird weggelassen oder umformatiert. |
| Ein benutzerdefiniertes Feld wird nicht mehr verwendet. | Veraltete Daten werden ohne Zweck übernommen. |
Prävention
Erstellen Sie ein Verzeichnis für die Zuständigkeit benutzerdefinierter Daten mit Quelldatensatz, Zieldatensatz, Format, weiterverwendendem Prozess, Lesezugriff, Schreibzuständigkeit und Entscheidung über Beibehaltung oder Außerbetriebnahme. Stabile Kennungen müssen genau auf der Ebene erhalten bleiben, die das fortgeführte System verwendet.
Prüfbeispiel
Verfolgen Sie bei einem ERP-verbundenen Wholesale-Konto Firmen-ID, Customer-Kontakt-ID, Product- oder Varianten-ID, Store-Kontext und Order-Invoice-ID durch das Ziel und die erste Synchronisierung.
Pass-Bedingung
Jeder erhaltene benutzerdefinierte oder integrationsverwaltete Wert besitzt einen benannten Nutzer, die richtige Datensatzebene, ein stabiles Format, einen zugänglichen Zielort und eine eindeutige Schreibzuständigkeit nach dem Cutover.
Pitfall 10: Jeden älteren Storefront statt seines Geschäftszwecks erhalten
Was schiefgeht
Alte Stores, Microstores, Portale, Categories, Customer Types und Preisregeln werden nachgebaut, nur weil sie existieren, obwohl einige inaktiv, doppelt, vorübergehend oder nicht mehr auf das aktuelle Geschäft ausgerichtet sind. Das Ziel übernimmt dadurch Komplexität, ohne den zugehörigen Wert zu übernehmen.
Frühe Warnsignale
| Legacy-Zustand | Warnsignal |
|---|---|
| Store hat keine aktuelle Aktivität. | Er wird ohne geschäftlichen Verantwortlichen neu aufgebaut. |
| Mehrere Customer Types überlappen. | Niemand kann den Unterschied in der Käuferbehandlung erklären. |
| Microstore gehört zu einem beendeten Programm. | Products und Routen bleiben standardmäßig im Umfang. |
| Alte Preisregeln widersprechen sich. | Das Ziel bildet beide ab, ohne eine Priorität festzulegen. |
| Benutzerdefinierte Felder sind undokumentiert. | Alles wird übernommen, weil ein Ausschluss riskant erscheint. |
Prävention
Fordern Sie für jeden nicht primären Store, Microstore, Customer Type, jede Preisregel, jedes benutzerdefinierte Feld und jede Route einen Verantwortlichen und einen fortgeführten Zweck. Klassifizieren Sie die Struktur als aktiv, konsolidiert, archiviert, weitergeleitet oder außer Betrieb. Erhalten Sie notwendige historische Evidenz, ohne veraltete Betriebsstrukturen neu aufzubauen.
Prüfbeispiel
Prüfen Sie ein ruhendes Händlerportal mit seinem Customer Type, Preisen, Products, Orders und URLs. Erhalten Sie historische Nachweise und Redirect-Wert, bauen Sie das Portal aber nur neu auf, wenn es einen aktuellen Verantwortlichen und einen aktiven Geschäftsprozess gibt.
Pass-Bedingung
Jede neu aufgebaute AmeriCommerce-Struktur hat einen aktuellen geschäftlichen Verantwortlichen und Zweck. Veraltete Komplexität wird archiviert oder außer Betrieb genommen, ohne erforderliche historische Evidenz zu verlieren.
Präventionsübersicht über alle Pitfalls
| Kontrollbereich | Abgedeckte Pitfalls | Erforderliches Ergebnis |
|---|---|---|
| Matrix der Käuferbehandlung | 1, 5 | Customer Types, Preise, Sichtbarkeit, Shipping, Content und Tax bleiben miteinander verbunden. |
| Store-Kontext-Matrix | 2, 3, 7, 10 | Stores, Microstores, Kataloge, Routen und Zielgruppen behalten sinnvolle Grenzen. |
| Modell der Product-Beziehungen | 4, 8 | Gruppen, Kits, Varianten, Komponenten und Inventory erhalten ihre kommerzielle Funktion. |
| Modell historischer Evidenz | 6 | Orders bleiben im Käufer- und Store-Kontext verständlich. |
| Verzeichnis der Integrationszuständigkeit | 8, 9 | Bestand, Kennungen, benutzerdefinierte Daten und externe Systeme besitzen definierte Verantwortliche. |
Fazit
Die Qualität einer AmeriCommerce-Migration hängt davon ab, den Kontext jedes Datensatzes zu erhalten. Customer Types beeinflussen die Käuferbehandlung, Multi-Store- und Microstore-Strukturen bestimmen die Bedeutung von Katalogen und Routen, Product Groups beeinflussen Inventory und Order-Verhalten, und komplexe Preise hängen von mehreren Regeldimensionen ab. Entscheidend ist deshalb, für jedes Risiko einen klaren Verantwortlichen, eine realistische Prüfhandlung und eine eindeutige Pass-Bedingung festzulegen.
Häufige Fragen
Warum sind Customer Types mehr als einfache Customer-Labels?
Sie können Preise, Rabatte, Product- und Content-Sichtbarkeit, Shipping, Tax-Behandlung und Login-Verhalten beeinflussen. Wird nur das Label migriert, kann sich die Käufererfahrung verändern.
Sollte jeder AmeriCommerce Store oder Microstore neu aufgebaut werden?
Nein. Jeder Kontext sollte eine aktuelle Zielgruppe, einen Zweck, Katalog, Preise, Content und einen Verantwortlichen haben. Veraltete Kontexte können konsolidiert, weitergeleitet, archiviert oder außer Betrieb genommen werden.
Warum sind Product Groups und Kits bei der Migration riskant?
Sie können Parent-Child-Darstellung, Pflichtkomponenten, Preise, Inventory, Mengen und Order-Positionen steuern. Beim Abflachen kann der Product-Name erhalten bleiben, während sich Verkaufs- und Fulfillment-Verhalten verändern.
Wie sollten komplexe Preise migriert werden?
Erhalten Sie die Regeldimensionen: Store, Customer Type, Menge, Variante, Zeitraum und zuständigen Regelinhaber. Ein kopierter Endpreis reicht nicht, wenn der Quellpreis bedingt berechnet wurde.
Kann eine Inventory-Menge für jeden Storefront verwendet werden?
Nur wenn alle Stores bewusst dasselbe Inventory-Modell verwenden. Store-Sichtbarkeit, Variantenbestand, Kits und externe Feeds können einen einzigen globalen Bestand irreführend machen.
Wie sollten benutzerdefinierte Daten und Kennungen externer Systeme behandelt werden?
Erhalten Sie sie nur mit klarer geschäftlicher oder technischer Nutzung. Dokumentieren Sie für jeden Wert Quelldatensatz, Zieldatensatz, Format, weiterverwendenden Prozess sowie Lese- und Schreibzuständigkeit. Kennungen müssen auf genau der Datensatzebene bleiben, die das fortgeführte System zur Zuordnung oder Abstimmung benötigt; nicht mehr verwendete Daten sollten bewusst archiviert oder ausgeschlossen werden.