Kommt Square als mögliche Zielplattform in Betracht, muss die Datenmodellbewertung die Darstellung von Quelldaten und ihrer Geschäftsbedeutung im Ziel erklären. Bei einer Migration zu Square geht es nicht darum, Felder eins zu eins zu kopieren. Square bildet Katalog, Bestand, Customers und Transaktionen über miteinander verbundene Objekte ab, die unterschiedliche betriebliche Aufgaben erfüllen. Ein Product aus dem Quellshop kann zu einem Catalog Item mit einer oder mehreren Item Variations werden. Ein auswählbarer Wert kann ein Item Option Value, eine verkaufbare Variation, ein Modifier oder eine vom Käufer eingegebene Information darstellen. Bestand gehört zu einer bestimmten Variation in einem bestimmten Standortkontext. Ein historischer Order bewahrt, was passiert ist, wird aber nicht zur Konfiguration für künftige Zahlungen, Fulfillment, Steuern oder Online-Darstellung.
Die zentrale Frage ist deshalb nicht, ob Square ein Feld mit einem vertrauten Namen besitzt. Entscheidend ist, ob der Zieldatensatz dem richtigen Square-Objekt zugeordnet ist und mit den Datensätzen verbunden bleibt, die ihm seine geschäftliche Bedeutung geben. Bleiben diese Beziehungen erhalten, können Mitarbeitende die richtige Variation verkaufen, Bestand je Standort verstehen, Customers und Orders finden, externe Kennungen abgleichen und konsistente Square-Online-Inhalte veröffentlichen. Werden die Beziehungen abgeflacht, kann der Datenbestand vollständig wirken und trotzdem falsch funktionieren.
Die Datenbedeutung in Square entsteht aus verbundenen Commerce-Objekten
Der Square-Katalog besteht aus typisierten Objekten und nicht aus einem universellen Product-Datensatz. Catalog Items beschreiben Produkte oder Dienstleistungen. Item Variations stehen für konkret kaufbare Ausführungen. Item Options können die Werte standardisieren, durch die Variations definiert werden. Modifier Lists beschreiben Änderungen oder Ergänzungen beim Verkauf. Categories organisieren Items. Steuern, Rabatte, Pricing Rules, Bilder, Maßeinheiten und Custom Attributes können Teil dieser übergreifenden Katalogbeziehungen sein.
Eine Quellplattform kann mehrere dieser Bedeutungen in einer einzigen Product-Tabelle, einem konfigurierbaren Product oder einer app-eigenen Struktur speichern. Für die Zielabbildung muss der Source-Datensatz daher in jene Square-Objekte aufgeteilt werden, die das jeweilige Verhalten tatsächlich besitzen.
| Annahme im Quellshop | Bedeutung der Square-Beziehung | Konsequenz für die Zielabbildung |
|---|---|---|
| Eine Product-Zeile ist die vollständige verkaufbare Einheit | Item und Item Variation können getrennte, aber verbundene Objekte sein | Das Parent Item bleibt erhalten; SKU, Preis, Bestand und weitere verkaufsrelevante Identität werden der richtigen Variation zugeordnet. |
| Jede Option ist eine Variante | Manche Auswahlwerte definieren Variations, andere Modifier oder Käuferangaben | Die geschäftliche Wirkung der Auswahl muss vor dem Erstellen von Zieldatensätzen eingeordnet werden. |
| Eine Bestandszahl gehört zum Product | Bestand ist an Item Variation und Standortkontext gebunden | Eine Menge ist ohne die verkaufbare Variation und den betrieblichen Standort unvollständig. |
| Categories bilden die gesamte Storefront nach | Catalog Categories und Square-Online-Site-Struktur sind verbunden, aber nicht gleichbedeutend | Katalogklassifikation getrennt von Seiten, Navigation und URL-Darstellung erhalten. |
| Customer-Historie stellt das alte Kontoverhalten wieder her | Customer Profiles bewahren Identität und Commerce-Beziehungen, nicht jedes Login- oder Mitgliedschaftsmodell der Quelle | Dauerhafte Customer-Daten von Source-spezifischem Zugriff und App-Verhalten trennen. |
| Importierte Orders konfigurieren künftigen Verkauf | Orders dokumentieren historische oder aktuelle Transaktionen; Zahlungen, Fulfillment, Steuern und andere Square-Einstellungen bleiben separate Konfiguration | Den Transaktionsstand bewahren, ohne ihn als Betriebskonfiguration zu behandeln. |
Diese objektbezogene Sicht erklärt auch, warum externe Kennungen wichtig sind. Eine Source-Product-ID, ein Lager-Schlüssel, eine CRM-Customer-ID oder eine Buchhaltungsreferenz sollte an dem Square-Objekt liegen, das vom angebundenen System erkannt wird. Eine allgemeine Notiz am Parent Item ersetzt keinen variation-spezifischen Lageridentifier, wenn das Lagersystem jede Variation als eigenen Bestandsartikel behandelt.
Items, Variations, Options und Modifier tragen unterschiedliche Verkaufsbedeutung
Die wichtigste Katalogunterscheidung besteht zwischen Item und Item Variation. Ein Item beschreibt die Product- oder Servicefamilie. Eine Variation bezeichnet eine kaufbare Ausführung und kann eigene SKU-, Preis-, Maßeinheits-, Bild- und Bestandsbedeutung haben. Selbst ein Source Product ohne sichtbare Optionen kann in Square als ein Item mit einer Standard- oder einzigen Variation abgebildet werden, weil die Variation das verkaufbare Objekt ist, auf das andere Square-Beziehungen verweisen.
Item Options bieten eine standardisierte Möglichkeit, Varianteneigenschaften wie Größe, Farbe oder Stil zu beschreiben. Eine Variation kann auf die gewählten Option Values verweisen, sodass Square die Kombination versteht und nicht nur einen uneinheitlichen Anzeigenamen übernimmt. Source-Variants sollten daher sowohl über ihr Parent Product als auch über die Werte interpretiert werden, die die verkaufbare Kombination eindeutig machen.
Modifier haben eine andere Funktion. Sie stehen für eine beim Verkauf ausgewählte Änderung oder Ergänzung und erzeugen nicht automatisch eine eigene bestandsgeführte Identität. Extra Käse, Geschenkverpackung, Zubereitungswunsch oder Zusatzservice können Modifier sein. Eine Größe mit eigener SKU und eigenem Bestand ist dagegen typischerweise eine Variation. Wird ein Modifier als Variation behandelt, entstehen künstliche Bestandsdatensätze; wird eine echte Variation als Modifier behandelt, geht die verkaufbare Identität verloren, die Bestand und externe Systeme benötigen.
| Source-Muster | Wahrscheinlicher Square-Eigentümer | Bedeutung, die erhalten bleiben muss |
|---|---|---|
| Einfaches Product mit einer SKU | Item plus eine Item Variation | Product-Beschreibung auf Item-Ebene; verkaufbare SKU-, Preis- und Bestandsidentität auf Variation-Ebene. |
| Größen- und Farbkombinationen | Item Options, Option Values und Item Variations | Jede kaufbare Kombination bleibt unterscheidbar und mit dem richtigen Parent Item verbunden. |
| Optionales Topping oder Zusatzservice | Modifier List und Modifier | Auswahl und Preiseffekt beim Verkauf, ohne eine künstliche, bestandsgeführte SKU zu erzeugen. |
| Gravur oder Käuferanweisung | Je nach unterstütztem Verhalten Modifier, Custom Input, Order-Line-Notiz oder Datensatz einer angebundenen Anwendung | Der vom Customer angegebene Wert bleibt an der gekauften Position und für Fulfillment sichtbar. |
| Kit, Bundle oder Paket | Item, Komponentenbeziehung, Pricing Rule, angebundene Anwendung oder externe Systemstruktur | Komponentenidentität, Preisbildung, Bestandsverantwortung und Reporting-Zweck sind eindeutig zugewiesen. |
| Service, Termin, Abonnement oder digitale Berechtigung | Catalog Item plus der Square-Produktbereich oder das angebundene System, das Terminierung, Wiederholung oder Zugriff besitzt | Der Katalogdatensatz bleibt getrennt vom System, das Zeit, Abrechnung oder Berechtigung steuert. |
Bilder, Steuern, Rabatte, Maßeinheiten und Custom Attributes müssen mit derselben Sorgfalt zugeordnet werden. Ein Bild kann zu einem Item, einer Variation oder einer Category-Beziehung gehören. Steuer oder Rabatt kann ein wiederverwendbares Katalogobjekt sein, auf das Items und Orders verweisen. Ein Custom Attribute sollte einen bekannten Verbraucher haben, etwa Mitarbeitende, Reporting, eine Integration oder einen anderen Square-Ablauf. Werte ohne eindeutig bestimmten Zieleigentümer erzeugen Datenrauschen statt erhaltener Geschäftsbedeutung.
Categories, Menüs, Bilder und Merchandising-Beziehungen
Source Categories übernehmen häufig mehrere Aufgaben gleichzeitig: Hierarchie, Browsing, Merchandising, Reporting, Zugriffskontrolle, SEO-Landingpages und Kampagnendarstellung. Square Catalog Categories bewahren die Katalogklassifikation, während Square-Online-Seiten, Navigation und Merchandising-Darstellung eigene Site-Beziehungen einführen können. Eine Migration sollte den dauerhaften Klassifikationszweck erhalten, ohne anzunehmen, dass sich der alte Storefront-Baum allein durch Category-Datensätze nachbauen lässt.
Eine tiefe Source-Hierarchie kann zu einer flacheren Katalogklassifikation plus Square-Online-Navigation oder Seitenstruktur werden. Eine Source Collection kann eine dauerhafte Abteilung, eine temporäre Kampagne, ein Filterergebnis oder eine redaktionelle Landingpage darstellen. Diese Bedeutungen dürfen nicht zusammenfallen, nur weil alle vier im alten Shop als Links erschienen sind.
| Source-Struktur | Frage zur Zielverantwortung |
|---|---|
| Dauerhafte Abteilungshierarchie | Welche Square Categories bewahren die langfristige Product-Klassifikation? |
| Temporäre Kampagnen-Collection | Ist die Beziehung eine Category, eine Square-Online-Seite, eine Merchandising-Darstellung oder eine Preis-/Rabattregel? |
| Marken- oder Herstellergruppe | Gehört sie zur Katalogklassifikation, zu einem Custom Attribute, zu durchsuchbarem Content oder in ein externes Product-Information-System? |
| Technischer Filter | Wird der Wert für Vergleich, Suche, Reporting oder Product-Auswahl genutzt, und welches Square-Objekt oder verbundene System besitzt diese Nutzung? |
| Product-Galerie und Variation-Bild | Welches Bild gehört zur Item-Familie und welches kennzeichnet eine bestimmte verkaufbare Variation? |
| Menübezeichnung und Landingpage | Verweist der Datensatz auf Category, Item, Square-Online-Seite, externe URL oder Kampagnenziel? |
Diese Trennung schützt Commerce und Content zugleich. Eine Category kann die maßgebliche Product-Klassifikation bleiben, während eine Square-Online-Seite bestimmt, wie diese Gruppe vorgestellt wird. Ein Menülink kann zum passenden Ziel führen, ohne Eigentümer der Katalogbeziehung zu werden. Bilder können am richtigen Item oder an der richtigen Variation verbleiben, auch wenn das Online-Layout neu aufgebaut wird.
Standorte und Bestand bilden eine betriebliche Beziehung
Square-Bestand ist keine einzelne Menge, die auf ein Item kopiert wird. Er ist mit einer Item Variation und dem Standort verbunden, für den ein Bestandsstatus gilt. Square zeichnet Bestandsentwicklung zudem über physische Zählungen und Zustandsänderungen auf. Eine aktuelle Menge ist damit das Ergebnis einer Bestandsentwicklung und kein isoliertes Product-Feld.
Ein Quellshop, Lager, eine Filiale, ein Stock Pool oder Verkaufskanal entspricht nicht zwingend eins zu eins einem Square Location. Die Zielabbildung muss bestimmen, welche Source-Menge zu welcher Ziel-Location und welcher verkaufbaren Variation gehört. Mehrere Source-Lager zu einer Gesamtmenge zusammenzuführen ist nur sinnvoll, wenn die Zielumgebung bewusst mit einem gemeinsamen Bestandspool arbeitet. Eine Source-Gesamtmenge auf mehrere Locations aufzuteilen erfordert eine autoritative Zuordnung und darf nicht geschätzt werden.
| Bestandssignal | Zielbeziehung |
|---|---|
| Product-Bestand ohne Varianten | Die Menge gehört zur einzigen Item Variation am vorgesehenen Square-Standort. |
| Variant-spezifischer Bestand | Jede verkaufbare Source-Kombination wird zuerst ihrer Square Variation zugeordnet; danach wird der Bestand angehängt. |
| Lagerbezogene Menge | Source-Lager oder Filiale wird mit der Square Location abgeglichen, die für die Menge verantwortlich ist. |
| Reservierter, beschädigter, retournierter oder unterwegs befindlicher Bestand | Die Statusbedeutung bleibt nur erhalten, wenn Ziel oder angebundenes Bestandssystem denselben Lifecycle versteht. |
| Externes Bestandsführungs-System | Variation-ID und externer Bestandsschlüssel sind dauerhafter als eine einmalig importierte Menge. |
| Historische Bestandskorrektur | Bleibt von der aktuellen physischen Menge getrennt, außer ein Integrations- oder Audit-System benötigt sie. |
Die Grenze zum führenden System ist entscheidend. Wenn Square nach dem Go-live den Bestand führt, müssen Mengen und Variation-Beziehungen in Square konsistent sein. Wenn ERP, Warehouse-System oder Marketplace Hub führend bleiben, benötigt Square stabile Variation- und Location-Identifiers, über die die Integration den Bestand pflegen kann. Die importierte Menge ist dann lediglich ein Anfangszustand und nicht die dauerhafte Quelle der Wahrheit.
Customers, Groups, Segments und Identitätsbeziehungen
Square Customer Profiles können Namen, Unternehmensinformationen, E-Mail-Adressen, Telefonnummern, Adressen, Notizen, Reference IDs, Group Memberships, Segment-Beziehungen, Marketingpräferenzen und Custom Attributes enthalten. Customer IDs verbinden Customers außerdem mit Orders und anderen Square-Datensätzen. Dadurch wird ein Square Customer Profile jedoch nicht automatisch gleichwertig mit jedem Source-Kontomodell.
Ein Source Account kann zusätzlich Passwörter, Buyer Roles, Organisationshierarchien, Steuerbefreiungen, Loyalty-Guthaben, Mitgliedschaften, Abonnements, gespeicherte Zahlungsmittel, Portalzugriff oder app-eigene Präferenzen enthalten. Ein Teil davon kann zu Square Customer Data gehören, anderes zu einem separaten Square-Produktbereich, einer angebundenen Anwendung oder einem externen System.
Beim Identitätsabgleich müssen sowohl falsche Zusammenführungen als auch unnötige Dubletten vermieden werden. E-Mail, Telefonnummer, Source Customer ID, externe CRM ID, Order-Beziehungen und Unternehmenskontext können gemeinsam die Entscheidung stützen. Eine gemeinsam genutzte Familienadresse bedeutet nicht automatisch, dass zwei Käufer dieselbe Person sind. Eine geänderte E-Mail-Adresse bedeutet nicht zwingend einen neuen Customer. Guest Orders sollten ihren Käuferkontext behalten, ohne nachträglich eine permanente Account-Beziehung zu erfinden.
| Source-Identitätsmuster | Bedeutung in Square |
|---|---|
| Registrierter Retail Customer | Customer Profile verbunden mit unterstützten Kontaktdaten, Adressen, Groups, Segments, Attributes und Orders. |
| Gastkäufer | Customer-Kontext auf Order-Ebene; dauerhaftes Profile nur, wenn die Identitätsregeln des Ziels dies unterstützen. |
| Unternehmenskontakt | Customer Profile plus Unternehmens-/Referenzdaten oder angebundener B2B-/CRM-Eigentümer; nicht automatisch eine vollständige Organisationshierarchie. |
| Loyalty-Mitglied | Customer-Identität verbunden mit dem Square- oder externen Loyalty-Datensatz, der Guthaben und Aktivität führt. |
| Marketing-Abonnent | Customer-Präferenz oder Datensatz im Marketing-System, wobei Einwilligungsbedeutung getrennt von Kaufhistorie erhalten bleibt. |
| Doppelte Source Accounts | Nur zusammenführen, wenn Identitätsnachweise, Consent, Order-Zuordnung und externe Referenzen die Zusammenführung stützen. |
Das dauerhafte Ziel ist eine Customer-Beziehung, die Mitarbeitende und verbundene Systeme verstehen können. Eine allgemeine importierte Notiz reicht nicht aus, wenn derselbe Wert als Reference ID durchsuchbar, als Custom Attribute strukturiert oder von einem CRM geführt werden sollte.
Orders bewahren Transaktionsbeziehungen, nicht künftige Konfiguration
Square Orders können Line Items, Item-Variation-Referenzen, Modifier, Mengen, Steuern, Rabatte, Service Charges, Tips, Fulfillment-Details, Location, Order Source, Customer-Verknüpfungen, Summen sowie Zahlungs- oder Refund-Kontext enthalten. Diese Beziehungen machen historische Orders für Customer Service, Abstimmung und Reporting nützlich, konfigurieren aber keine zukünftigen Transaktionen.
Die Order Line sollte das zum Kaufzeitpunkt erworbene Product oder die Variation bewahren, auch wenn sich der aktuelle Katalog später ändert. Modifier-Auswahlen und Käuferangaben gehören zur gekauften Position. Steuer-, Rabatt-, Service-Charge- und Tip-Werte erklären, wie die historische Summe entstanden ist. Fulfillment-Daten zeigen, ob der Order abgeholt, versendet, geliefert, storniert oder anders bearbeitet wurde. Source und Location zeigen, wo die Transaktion entstanden ist.
| Historischer Wert | Bedeutung im Square Order |
|---|---|
| Source Order Number | Dauerhafte Referenz für Support, Finance und systemübergreifende Nachverfolgung. |
| Product- oder Variation-Position | Gekaufte verkaufbare Identität, Menge, Preis und beschreibender Zustand zum Kaufzeitpunkt. |
| Modifier oder Anpassung | Verkaufsauswahl, die an der richtigen Order Line erhalten bleibt. |
| Steuer, Rabatt, Service Charge oder Tip | Bestandteil der historischen Gesamtsumme und keine aktive Pricing Rule. |
| Zahlungs- oder Tender-Referenz | Nachweis der abgeschlossenen oder versuchten Transaktion und keine wiederverwendbare Zahlungskonfiguration. |
| Fulfillment und Tracking | Historischer Liefer- oder Abholkontext und keine Definition aktueller Fulfillment-Methoden. |
| Refund oder Adjustment | Finanzhistorie, die mit dem ursprünglichen Order und der Transaktion verbunden bleibt. |
| Location und Source | Betrieblicher Ursprung des Orders und Beziehung zum Square- oder externen Kanal. |
Auch historische Ad-hoc-Positionen benötigen besondere Behandlung. Ein Source Order kann auf ein Product verweisen, das nicht mehr existiert, oder eine anwendungsseitig erzeugte Gebühr ohne heutiges Katalogäquivalent enthalten. Der Order kann Beschreibung und Betrag historisch bewahren, sollte aber keinen künstlichen aktuellen Katalogartikel erzeugen, sofern das Unternehmen diesen nicht erneut verkaufen will.
Square-Online-Inhalte, URLs und Site-Verantwortung
Square Online ergänzt die Square-Commerce-Daten um eine Site-Schicht. Catalog Items und Categories können für Onlineverkauf genutzt werden, während Seiten, Navigation, Domains, URL-Pfade, Redirects, SEO-Felder, Richtlinieninhalte, Blog Posts, Medienplatzierung und individuelle Darstellung eigene Site-Bedeutung besitzen.
Eine Source-Product-URL kann sich ändern, wenn das Product zu einer Square-Online-Item-Seite wird. Eine Source-Category-Landingpage kann statt nur einer Catalog Category ein Square-Online-Ziel benötigen. Eine CMS Page kann zu einer Site Page werden, in eine andere Seite integriert werden oder außerhalb der Commerce-Site bleiben. Blog Posts, redaktionelle Collections, Download-Ressourcen und Kampagnenseiten sollten ihre Content-Beziehungen und vorgesehenen Ziele bewahren, selbst wenn das visuelle Design neu erstellt wird.
| Source-Web-Asset | Zieleigentümer |
|---|---|
| Product-Titel, Beschreibung und Product-Medien | Catalog Item und dessen Online-Darstellungsbeziehung. |
| Product- oder Category-URL | Square-Online-Route plus erforderliche Source-zu-Ziel-Redirect-Beziehung. |
| Richtlinien- oder Informationsseite | Square-Online-Seite oder ein anderes definiertes Content-Ziel. |
| Blog Post oder redaktionelles Archiv | Unterstütztes Publishing-Ziel oder ein separat verantwortetes Content-System. |
| Menüeintrag | Site-Navigationsbeziehung zu Item, Category, Seite oder externer URL. |
| Theme Block, Custom Script oder App Widget | Site-Darstellung oder Integrationskonfiguration, nicht gewöhnlicher Kataloginhalt. |
| Domain und Redirect | Site- und Routing-Konfiguration, die mit dem erhaltenen Content-Ziel verbunden ist. |
Das Content-Modell muss daher maßgebliche Commerce-Daten von den Site-Komponenten trennen, die sie darstellen. Ein Product bleibt ein Catalog Item, auch wenn mehrere Square-Online-Seiten darauf verlinken. Eine Seite bleibt Content, auch wenn sie Product-Referenzen enthält. Ein Redirect bleibt eine Routing-Beziehung und ersetzt den Zieldatensatz nicht.
Custom Attributes, Anwendungen und externe Kennungen
Square unterstützt Custom Attributes für verschiedene Objekttypen. Gleichzeitig verwenden viele Unternehmen Buchhaltungs-, CRM-, Loyalty-, Liefer-, Restaurant-, Retail-, Termin-, Reporting-, Marketplace- und Bestandsanwendungen. Dass in beiden Systemen ein Custom Field vorhanden ist, beweist nicht, dass beide Felder denselben Eigentümer oder Lifecycle haben.
Custom Data sollte nach Parent Object, Geschäftszweck, führendem System und weiterem Verbraucher klassifiziert werden. Ein warehouse-spezifischer Schlüssel auf Variation-Ebene gehört zur Variation und Lagerbeziehung. Eine CRM Customer ID gehört zur Customer- und CRM-Beziehung. Eine Marketplace Order ID gehört zum Order und zur Kanalbeziehung. Eine Site-Script-Einstellung gehört zur Site-Konfiguration und nicht zu einem Customer- oder Product-Datensatz.
| Custom- oder externes Signal | Richtige Eigentumsdefinition |
|---|---|
| ERP Product Key | Das Item oder die Variation, die das ERP gemäß seiner eigenen Product-Granularität erkennt. |
| Warehouse SKU | Bestandsgeführte Variation plus Standort- oder Lagerbeziehung. |
| CRM Customer ID | Customer Profile plus externes CRM, in dem diese ID führend ist. |
| Marketplace Listing ID | Item-/Variation-/Kanalbeziehung und keine allgemeine Product-Notiz. |
| Loyalty-Guthaben oder Membership ID | Customer plus Loyalty-System, das Ledger und Status führt. |
| Custom Order Attribute | Order oder Line Item plus Anwendung, die den Wert erzeugt und verwendet. |
| Square-Online-Widget-Daten | Site- oder App-Konfiguration plus Referenzen auf die zugrunde liegenden Commerce-Datensätze. |
| Nicht unterstützte Source-Tabelle | Parent Entity, Schlüssel, Lifecycle und Zieleigentümer müssen vor dem Beibehalten eines Wertes eindeutig feststehen. |
Dieses Eigentumsmodell verhindert zwei Fehler: jeden Quellwert in das nächstgelegene Square-Feld zu zwingen und Custom Data zu behalten, ohne zu wissen, wozu sie gehören. Ein Wert ist nur dann nützlich, wenn das Team weiß, welcher Datensatz ihn besitzt, welches System ihn erkennt und ob er eine aktuelle Entität, eine historische Transaktion oder Darstellungsverhalten beschreibt.
Zielentscheidungen für typische Source-Muster
Das endgültige Square-Zielmodell sollte als Beziehungssystem und nicht als Feldliste beschrieben werden. Repräsentative Muster machen diese Beziehungen sichtbar, bevor Mapping in großem Umfang definiert wird.
| Source-Muster | Square-Zielbeziehung |
|---|---|
| Konfigurierbares Bekleidungs-Product | Item → Item Options → Option Values → Item Variations → Variation-Bilder/SKUs → Bestand je Location. |
| Restaurant-Menüeintrag mit Extras | Item/Variation → Modifier List → Modifier → Order-Line-Auswahlen → Fulfillment-Kontext. |
| Multi-Warehouse-Katalog | Item Variation → Square Location oder externes Warehouse → Inventory State → externer Bestandsschlüssel. |
| Retail Customer mit Loyalty | Customer → Kontakt-/Referenzdaten → Orders → Loyalty-Datensatz, geführt von Square oder einem angebundenen System. |
| Marketplace Order | Order → Source-/Kanalreferenz → Line-Item-Variation oder Ad-hoc-Snapshot → Zahlungs-/Fulfillment-Historie → externe Marketplace ID. |
| SEO-sensitive Category-Seite | Catalog Category → Square-Online-Ziel → Navigationslink → Redirect von Quell-URL → referenzierte Items. |
| Individueller Product-Konfigurator | Catalog Item/Variation → app-eigene Konfiguration → Order-Line-Ausgabe → externe Fulfillment-Identifier. |
Diese Beziehungsketten machen den Migrationsumfang explizit, weil sie Zieleigentümer, abhängige Datensätze und extern fortbestehendes Verhalten sichtbar machen. Sie zeigen außerdem, wo ein einzelner Source-Datensatz in mehrere verbundene Square-Objekte aufgeteilt werden muss. Eine Kette ist erst vollständig, wenn Mitarbeitende und angeschlossene Systeme Item, Customer, Order, Content oder externe Kennung durch die Zielumgebung verfolgen können, ohne das Quellsystem zur Erklärung zu benötigen.
Fazit
Die Übersetzung eines Source-Datenmodells in Square hängt davon ab, jeden Wert dem Square-Objekt zuzuordnen, das seine geschäftliche Bedeutung besitzt. Items, Item Variations, Options, Modifier, Categories, Locations, Bestand, Customers, Orders, Square-Online-Inhalte, Custom Attributes und externe Kennungen sind verbunden, aber nicht austauschbar.
Ein belastbares Zielmodell bewahrt Parent-Child- und systemübergreifende Beziehungen. Variation-Identität bleibt mit Bestand und Standorten verbunden, Customer-Identität mit Orders und externen Referenzen, historische Transaktionen bleiben von künftiger Konfiguration getrennt und Square-Online-Darstellung bleibt von den maßgeblichen Katalogdatensätzen abgegrenzt. Dadurch sind migrierte Daten nicht nur vorhanden, sondern verständlich und nutzbar.
Häufige Fragen
Was ist der Unterschied zwischen einer Square Item Variation und einem Modifier?
Eine Item Variation ist eine kaufbare Ausführung eines Items und kann SKU-, Preis-, Bild-, Maßeinheits- und Bestandsbedeutung tragen. Ein Modifier ist meist eine Ergänzung, Entfernung oder Präferenz, die beim Verkauf gewählt wird. Entscheidend ist, ob die Auswahl eine eigene verkaufbare und bestandsgeführte Identität erzeugt.
Sollte jede Product-Option aus dem Quellsystem zu einer Square Item Option werden?
Nein. Item Options passen, wenn Option Values standardisierte Variation-Auswahlen definieren. Personalisierung, optionale Extras, Käuferhinweise oder appgesteuerte Auswahlwerte können besser zu Modifiern, Order-Line-Daten, Custom Attributes oder einem anderen verantwortlichen System gehören.
Warum ist der Square-Standort für die Bestandsmigration wichtig?
Square-Bestand ist nur im Zusammenhang mit einer bestimmten Item Variation und Location sinnvoll. Eine numerisch korrekte Menge kann trotzdem dem falschen betrieblichen Kontext zugeordnet sein, wenn Variation oder Standort nicht stimmen.
Können Square Customer Profiles jede Account-Funktion aus dem Quellsystem nachbilden?
Nein. Customer Profiles können unterstützte Identitäts-, Kontakt-, Group-, Segment-, Präferenz-, Custom-Attribute- und Order-Beziehungen bewahren. Passwörter, B2B-Hierarchien, Mitgliedschaften, Loyalty-Ledger, Abonnements und app-eigene Berechtigungen können andere Zieleigentümer haben.
Konfigurieren migrierte Square Orders Zahlungen und Fulfillment?
Nein. Orders bewahren Line Items, Adjustments, Location, Source, Zahlungskontext, Fulfillment-Historie und weitere Transaktionsnachweise. Aktuelles Zahlungs-, Steuer-, Fulfillment-, Benachrichtigungs- und App-Verhalten bleibt separate Konfiguration.
Wie sollten Custom Fields und externe IDs in Square dargestellt werden?
Jeder Wert sollte dem Item, der Variation, dem Customer, Order, Line Item, Site-Datensatz, der Anwendung oder dem externen System zugeordnet werden, das ihn tatsächlich besitzt. Zusätzlich muss der Schlüssel erhalten bleiben, den das konsumierende System benötigt; ein allgemeines Notizfeld zerstört die Beziehungsbedeutung.