Next-Cart

Wenn Square als mögliche Zielplattform in Betracht gezogen wird, beschreibt die Vorbereitung, welche Nachweise, Entscheidungen und Zielkonfigurationen vor der Migration geklärt werden müssen.

Wenn Square als Zielplattform ausgewählt wird, sollte die Vorbereitung damit beginnen, das künftige Betriebsmodell zu definieren: wie Square Catalog, Locations, Inventory, Customer Directory, Orders, Zahlungskontext, Fulfillment, Square Online und verbundene Anwendungen zusammenarbeiten sollen. Square bildet eine Product-Familie als Catalog Item und ihre verkaufbaren Einheiten als Item Variations ab; Modifier, Categories, Custom Attributes, Steuern, Rabatte und Locations bleiben eigenständige Beziehungen.

Ein belastbares Vorbereitungspaket hält für jeden wichtigen Bereich Aktion, verantwortliche Person, Nachweis und Freigabebedingung fest. So wird verhindert, dass eine Source-Product-Option fälschlich als Square Modifier eingeordnet, standortspezifischer Bestand auf eine Gesamtmenge reduziert oder historischer Zahlungsnachweis mit aktueller Square-Payment-Konfiguration verwechselt wird.

Square-Betriebsmodell und Standortumfang festlegen

Definieren Sie, ob Square Point-of-Sale-Aktivität, Square Online, einen oder mehrere physische Standorte, Lager, Services, Delivery, Pickup, Shipping oder externes Fulfillment unterstützen soll.

Vorbereitungsbereich Zu dokumentierende Entscheidung Verantwortlich Nachweis für Bereitschaft
Square-Kontostruktur Merchant Account, Hauptstandort, zusätzliche Locations und Geschäftseinheiten Commerce-/Operations-Verantwortlicher Übersicht über Zweck jeder Location
Verkaufskanäle POS, Square Online, externe Marketplace-Kanäle, Invoicing oder andere Channels Channel Owner Channel- und Order-Source-Inventar
Bestandsverantwortung Square, ERP, WMS, Lieferant oder anderes führendes System Inventory Owner System-of-Record-Matrix
Customer-Verantwortung Customer Directory, CRM, Loyalty, Marketing oder externes Account-System Customer Owner Customer-Domain-Übersicht
Fulfillment-Modell Pickup, Delivery, Shipping, Warehouse, Service oder externes Fulfillment Operations Owner Zusammenfassung der Fulfillment-Beziehungen
Square Online Products, Categories, Pages, Routes, Domains und Navigation im Umfang Site Owner Square-Online-Content- und URL-Inventar

Das Betriebsmodell ist vorbereitet, wenn jede Location und jeder Channel einen Zweck besitzt, jede Bestandsquelle einem verantwortlichen System zugeordnet ist und Anforderungen an Square Online von Catalog Records getrennt sind.

Zugriffe, Source-Archive und Kontrollnachweise vorbereiten

Sammeln Sie:

  • administrativen Zugriff auf das Quellsystem und die erforderlichen Square-Dashboard-Berechtigungen;
  • Zugriff auf Catalog, Items, Modifier, Categories, Locations, Inventory, Customers, Orders, Square Online und verbundene Anwendungen;
  • datierte Exporte oder Backups für Products, Customers, Orders, Content, Media, Discounts, Taxes und Custom Data;
  • Berichte zu Locations, Inventory und Fulfillment;
  • App-Exporte und Dokumentation externer Systeme;
  • externe Product-, Variation-, Customer-, Order- und Location-Identifier;
  • eine verantwortliche Person für Source-Änderungen an Catalog, Customers, Orders, Content und Stock während des Migrationsfensters.
Nachweis Warum er wichtig ist Freigabebedingung
Zugriffsprotokoll Bestätigt, dass benötigte Source- und Square-Bereiche geprüft werden können Verantwortliche Personen besitzen die benötigten Berechtigungen
Datiertes Source-Archiv Bewahrt einen wiederherstellbaren Referenzzustand Dateien lassen sich öffnen und enthalten Exportdatum
Location-Inventar Definiert den betrieblichen Umfang von Mengen und Orders Jede Source-Location besitzt ein vorgesehenes Square- oder externes Ziel
App-Inventar Macht Datensätze außerhalb von Square Core sichtbar Jede aktive Anwendung hat einen benannten Owner
Register externer IDs Schützt Reconciliation und Synchronisierung Keys sind dem richtigen Square-Objekttyp zugeordnet
Change Log Erfasst Änderungen nach dem Referenzarchiv Catalog-, Order-, Customer- und Inventory-Änderungen haben klare Zuständigkeit

Wenn ein Source-System keinen Export bereitstellen kann, dokumentieren Sie die Einschränkung und den Owner, statt daraus abzuleiten, dass die betreffenden Daten unwichtig sind.

Catalog Items, Item Variations, Options und Modifier vorbereiten

Square Catalog trennt Items, Item Variations, Item Options, Modifier, Categories, Discounts, Taxes, Images, Units und Custom Attributes. Bereiten Sie repräsentative Source-Muster vor, die diese Unterschiede sichtbar machen.

Einbeziehen sollten Sie:

  • einfache Products, die zu einem Item mit einer Item Variation werden;
  • Products mit Größe, Farbe, Stil oder anderen Variantendimensionen;
  • SKU-, Barcode-, Preis-, Unit-, Image- und Inventory-Beziehungen auf Item-Variation-Ebene;
  • wiederverwendbare Item Options und uneinheitliche ältere Variantennamen;
  • listen- und textbasierte Modifier-Anforderungen;
  • Products mit Taxes, Discounts, Maßeinheiten oder Custom Attributes;
  • Services, digitale Berechtigungen, Subscriptions, Bundles oder app-eigenes Verhalten;
  • ERP-, Warehouse-, Marketplace-, Supplier- und Accounting-Identifier.
Source-Verhalten Square-Vorbereitungsentscheidung Erforderlicher Nachweis Freigabebedingung
Source Product besitzt Child SKUs Item- und Item-Variation-Struktur definieren Parent-/Child-IDs, SKUs, Preise, Bilder, Units und Bestand Jeder verkaufbare Child hat genau eine vorgesehene Item Variation
Variation-Werte sind standardisiert Wiederverwendbare Item Options und Values definieren Option-Vokabular und Kombinationsbeispiele Gleichwertige Variations verwenden konsistente Option Values
Käufer wählt Ergänzung oder Präferenz Modifier List, Modifier oder Text Modifier definieren Auswahlgrenzen, Preise, Defaults und Order-Line-Beispiele Modifier werden nicht als bestandsgeführte Variations behandelt
Product enthält beschreibende Custom Data Catalog Custom Attribute oder externen Owner festlegen Feldzweck und konsumierendes System Jedes Feld hat einen benannten fortbestehenden Owner
Product-Verhalten gehört einer App Fortbestehende Anwendung oder Ersatz identifizieren Zugehörige Items, Customers und Orders Benötigte App-Daten erscheinen im Dependency Register

Der Catalog-Bereich ist vorbereitet, wenn jede wichtige Product-Familie – soweit relevant – eine definierte Behandlung für Item, Item Variation, Item Option, Modifier, Tax, Discount, Category und Identifier besitzt.

Categories, Images, Taxes, Discounts und Custom Attributes vorbereiten

Bereiten Sie auch die Catalog-Beziehungen außerhalb von Items und Variations vor:

  • Category-Hierarchie oder Product-Gruppierung;
  • Images, die zu Items, Item Variations oder Categories gehören;
  • Taxes und Product-Tax-Zuordnungen;
  • Discounts, Pricing Rules und historische Promotion-Kontexte;
  • Measurement Units und Mengenpräzision;
  • Definitionen und Werte von Custom Attributes;
  • Source-Visibility- oder Channel-Flags;
  • Square-Online-Product- und Category-Beziehungen.
Catalog Object Verantwortlich Nachweis Freigabebedingung
Category Merchandising Owner Category- und Item-Membership-Liste Jede Category besitzt einen aktuellen Geschäftszweck
Image Content Owner Datei, Rolle, Reihenfolge und zugehöriges Item/Variation/Category Media-Beziehungen lassen sich rekonstruieren
Tax Finance Owner Namen, Prozentwerte, Inclusivity und Item-Zuordnungen Historische Werte und aktuelle Konfiguration sind getrennt
Discount oder Pricing Rule Commercial Owner Regel, Eligibility, Daten und betroffene Items Aktive Zielregeln sind von historischen Order-Ergebnissen getrennt
Unit Catalog-/Operations-Owner Unit-Name, Präzision und betroffene Variations Mengenbedeutung ist dokumentiert
Custom Attribute Business-/Integration-Owner Definition, Object Type und Consumer Wert ist dem richtigen Square Catalog Object zugeordnet

Reduzieren Sie diese Objekte nicht auf Product-Text. Ihre Beziehungen können Checkout, Reporting, Suche, Inventory und externe Integrationen beeinflussen.

Locations, Inventory Counts und Bestandsverantwortung vorbereiten

Square Inventory wird für Item Variations an Locations berechnet. Inventory Records können aktuelle Counts, Physical Counts, Adjustments, Transfers und Zustände wie In Stock, Sold, Returned, Received oder Waste enthalten.

Bereiten Sie vor:

  • jedes Source Warehouse, jeden Store, jede Branch, Supplier Pool oder Fulfillment Location;
  • die vorgesehene Square Location für jeden Source Stock Pool;
  • Item-Variation- und Location-Identifier;
  • aktuelle Counts und den Zeitstempel, für den sie gelten;
  • reservierte, beschädigte, retournierte, in Transit befindliche oder weitere Source-States;
  • externen Bestandsführer und Synchronisierungsschlüssel;
  • Opening Physical Counts und Zuständigkeit für Source-Änderungen.
Inventory-Fall Verantwortlich Nachweis Freigabebedingung
Eine Location Inventory Owner Item-Variation-Count-Bericht Jede Menge ist genau einer Square Location zugeordnet
Mehrere Locations Operations Owner Variation-Location-Matrix Jede Source-Location besitzt ein genehmigtes Ziel
ERP-/WMS-geführter Bestand Integration Owner Externe IDs und Synchronisierungsbeispiel Square-Opening-Werte und künftige Systemhoheit sind dokumentiert
Source-State ohne direktes Zieläquivalent Operations Owner State-Definition und betroffene Beispiele Zusammenführung, Ausschluss oder externe Eigentümerschaft ist dokumentiert
Historische Adjustments Finance-/Operations-Owner Adjustment- und Physical-Count-Beispiele Aktueller Opening Count ist von historischen Bewegungsdaten getrennt

Der Bereich ist vorbereitet, wenn jede Bestandsmenge genau eine Item Variation, eine Location, einen Zeitstempel und einen autoritativen Owner besitzt.

Customer Profiles, Groups, Segments und externe Identität vorbereiten

Square Customer Profiles können Kontaktdaten, Unternehmensinformationen, Adressen, Reference IDs, Notes, Groups, Segments, Marketingpräferenzen und Custom Attributes enthalten. Bereiten Sie Identitätsdatensätze nach ihrer tatsächlichen geschäftlichen Rolle vor.

Einbeziehen sollten Sie:

  • registrierte Käufer und Guest Buyer;
  • Beispiele mit doppelter E-Mail-Adresse oder Telefonnummer;
  • Customer Groups und Segment-Beziehungen;
  • Unternehmens- oder Organisationskontext;
  • Marketingpräferenzen und Consent-Nachweise;
  • Loyalty-, Gift-Card-, Membership- oder Subscription-Beziehungen;
  • CRM-, ERP-, Marketplace- und Accounting-Identifier;
  • Order-Beziehungen und historische Adressen.
Customer-Fall Verantwortlich Nachweis Freigabebedingung
Retail Customer Customer Operations Kontakt-, Adress- und Order-Beispiele Identität und Order-Beziehungen sind dokumentiert
Guest Buyer Customer Operations Order-bezogene Identität und Adressen Guest-Historie wird nicht in eine unbegründete permanente Account-Annahme umgewandelt
Group oder Segment Commercial-/Marketing-Owner Group-Definition und repräsentative Customers Klassifikationszweck und Zieleigentümer sind bekannt
Loyalty- oder Gift-Beziehung Application-/Finance-Owner Account ID, Balance/History und Customer Link Programmdaten sind vom Basis-Customer-Profile getrennt
Externer CRM Customer Integration Owner CRM ID und Matching Rule Dauerhafte systemübergreifende Identität bleibt erhalten

Authentication, gespeicherte Zahlungsmethoden, Loyalty Ledgers und spezialisierte App Profiles benötigen separate Eigentümer. Ein Square Customer Profile stellt diese Beziehungen nicht automatisch wieder her.

Historische Orders, Payments, Fulfillment und Returns vorbereiten

Wählen Sie Orders aus, die Item Variations, Modifier, Custom Line Items, Taxes, Discounts, Service Charges, Tips, Customer References, Location, Source, Fulfillment, Payments, Refunds und externe IDs sichtbar machen.

Historischer Bereich Erforderlicher Nachweis Freigabebedingung
Gekaufte Items Item-/Variation-IDs, Modifier, Mengen und Line Prices Die gekaufte Konfiguration ist verständlich
Adjustment-Kontext Taxes, Discounts, Service Charges und Tips Historische Gesamtsummen lassen sich erklären
Customer und Location Customer ID, Guest-Kontext, Location und Order Source Betrieblicher Ursprung ist dokumentiert
Payment und Refund Payment References, Tenders, Refunds und Daten Historischer Finanzkontext ist von Live-Payment-Konfiguration getrennt
Fulfillment Pickup, Shipment, Delivery, Tracking und Status Vergangenes Fulfillment bleibt verständlich
Externe Herkunft POS-, Marketplace-, ERP-, Accounting- oder Support-IDs Reconciliation Keys bleiben am richtigen Order

Historische Orders bewahren vergangene Verkäufe und Returns. Aktuelle Payment Activation, Devices, POS-Einstellungen, Shipping, Delivery, Pickup, Taxes, Staff Permissions und Notifications bleiben separate Square-Konfiguration.

Square-Online-Inhalte, Domains, Navigation und URLs vorbereiten

Wenn Square Online Teil des Umfangs ist, bereiten Sie vor:

  • Online-Sichtbarkeit von Products und Categories;
  • Square-Online-Pages, Policy Content sowie Blog- oder Editorial Content, soweit relevant;
  • Navigation, Footer Links, Campaign Landing Pages und Internal Links;
  • Product-, Category-, Page- und Campaign-URLs;
  • Metadata, Images, Canonical Relationships und Redirects;
  • Domain Ownership und Cutover-Abhängigkeiten;
  • Pickup-, Delivery-, Shipping- und Location-Beziehungen, die online dargestellt werden;
  • eingebettete Forms, Widgets, Scripts und Application Content.
Online-Bereich Verantwortlich Nachweis Freigabebedingung
Product-/Category-Darstellung Commerce-/Site-Owner Visibility, Content, Images und Routes Catalog- und Online-Darstellungsverantwortung sind getrennt
Page- oder Policy-Content Editorial Owner Body, Media, Metadata und Quell-URL Jeder Content-Datensatz hat ein Ziel
Navigation Site Owner Menu Tree und Link Destinations Priorisierte Customer-Pfade sind dokumentiert
Domain und Redirect SEO-/Site-Owner Source-/Destination-URL-Ledger Jede priorisierte Route besitzt ein genehmigtes Ergebnis
Fulfillment-Darstellung Operations Owner Location-, Pickup-, Delivery- und Shipping-Beispiele Online-Versprechen sind mit den vorgesehenen Locations verbunden

Square Catalog Data allein stellt weder Square-Online-Seitenstruktur noch Navigation wieder her. Diese Bereiche benötigen eigene Nachweise und Owner.

Anwendungen, APIs und externe Systeme inventarisieren

Erstellen Sie ein Dependency Register für jede Square-Anwendung, Source Extension, API, jeden Webhook, jede Automation, Marketplace-, ERP-, PIM-, WMS-, CRM-, Accounting-, Tax-, Shipping-, Loyalty-, Subscription-, Booking-, Delivery-, Analytics- und Reporting-Lösung.

Dokumentieren Sie für jede Abhängigkeit:

  • Geschäftszweck;
  • betroffene Catalog Items, Item Variations, Customers, Orders, Locations, Inventory oder Content;
  • führendes System und externe IDs;
  • Export- oder API-Verfügbarkeit;
  • Owner für Konfiguration und Credentials;
  • fortbestehendes Ziel, Ersatz oder Retirement-Entscheidung;
  • Nachweise, die vor der Konfiguration des Zielworkflows benötigt werden.

Das Register ist vorbereitet, wenn jedes aktive Custom Attribute, jede Listing ID, jeder Loyalty-Wert, Stock Key oder Order Reference einen benannten Owner und ein Parent Square Object besitzt.

Repräsentative Stichproben für die Migration auswählen

Stichprobe Zweck der Vorbereitung
Einfaches Item mit einer Variation Gewöhnliches Catalog-Muster etablieren
Item mit mehreren Options und Variations Item-Option-, SKU-, Preis-, Image- und Inventory-Beziehungen sichtbar machen
Item mit Listen- und Text-Modifiern Käuferanpassungen und Order-Line-Nachweis sichtbar machen
Multi-Location-Inventory-Variation Variation-Location-Mapping und Bestandsverantwortung sichtbar machen
Customer mit Group und Orders Profile-, Group-, Reference-ID- und historische Beziehungen sichtbar machen
Komplexer Order Modifier, Taxes, Discounts, Service Charges, Payment, Refund, Fulfillment und Location sichtbar machen
Priorisierte Square-Online-Route Catalog-, Content-, Domain-, Navigations- und Redirect-Eigentum sichtbar machen
App-eigener oder externer Record Fortbestehendes System und stabile Square-Identifier sichtbar machen

Dokumentieren Sie für jede Stichprobe Quell-ID, gegebenenfalls Quell-URL, Geschäftszweck, vorgesehenes Square Object, Location, externe Keys, bekannte Ausschlüsse und verantwortliche Person für die Prüfung.

Square-Bereitschaftsprüfung abschließen

Prüffrage Erforderlicher Nachweis Freigabebedingung
Sind Zugriff und Source-Archive wiederherstellbar? Access Record und datierte Exporte/Backups Benötigte Source Records können unabhängig vom Live Store geprüft werden
Sind Betriebs- und Location-Modell definiert? Channel-, Location-, Inventory- und Fulfillment-Map Jede Location und jeder Channel hat einen Owner
Sind Catalog-Strukturen vorbereitet? Item-/Variation-/Option-/Modifier-Matrix Jedes wichtige Product-Muster besitzt eine vorgesehene Square-Darstellung
Ist Inventory Ownership vorbereitet? Variation-Location- und System-of-Record-Matrix Jede Menge hat Location, Zeitstempel und Owner
Sind Customers und Orders vorbereitet? Customer-Klassifikation und historische Order-Pakete Identität und Transaktionskontext sind verständlich
Ist Square Online vorbereitet? Content-, Navigation-, Domain- und URL-Ledger Catalog und Online-Darstellung haben getrennte Owner
Sind Anwendungen und externe Systeme inventarisiert? Dependency Register Jede kritische Abhängigkeit hat einen fortbestehenden Owner
Sind repräsentative Migrationsstichproben ausgewählt? Sample Ledger Catalog-, Location-, Customer-, Order-, Online- und Integrationskomplexität ist abgedeckt
Sind offene Punkte kontrolliert? Decision Log Jeder offene Punkt hat Owner und Fälligkeitsdatum

Die Vorbereitung ist abgeschlossen, wenn keine kritische Entscheidung zu Catalog Item, Item Variation, Modifier, Location, Inventory, Customer, Order, Square Online oder Integration mehr von einer undokumentierten Annahme abhängt.

Fazit

Die Vorbereitung einer Square-Migration sollte ein standortbezogenes Commerce-Nachweispaket ergeben. Catalog Items müssen mit Item Variations, Item Options, Modifiern, Categories, Taxes, Discounts und Custom Attributes verbunden sein. Inventory muss an der richtigen Variation und Location bleiben, Customers und Orders müssen ihre historischen Beziehungen bewahren, und Square-Online- oder App-Datensätze brauchen klar benannte Eigentümer.

Wenn diese Entscheidungen vor einer repräsentativen Migration dokumentiert sind, kann die Stichprobe das geplante Square-Betriebsmodell abbilden, ohne historische Commerce-Daten mit aktueller POS-, Payment-, Fulfillment- oder Online-Konfiguration zu verwechseln.

Häufige Fragen

Was sollte für Square zuerst vorbereitet werden?

Beginnen Sie mit Betriebs- und Location-Modell. Definieren Sie Square Locations, Verkaufskanäle, Inventory Owner, Fulfillment-Modell, Customer-Systeme und Square-Online-Umfang, bevor einzelne Datensätze vorbereitet werden.

Was ist der Unterschied zwischen einem Square Item und einer Item Variation?

Das Item ist die Product- oder Servicefamilie, während Item Variations die konkreten verkaufbaren Einheiten darstellen. SKU, Inventory, Preis, Option Values und weitere kommerzielle Daten können zur Variation gehören.

Wann sollte eine Source-Auswahl zu einem Square Modifier werden?

Ein Modifier passt, wenn die Auswahl ein Item beim Kauf anpasst, ohne eine eigenständig bestandsgeführte Variation zu erzeugen. Bereiten Sie listen- und textbasierte Beispiele einschließlich Auswahl- und Preisregeln vor.

Wie sollte Square Inventory vorbereitet werden?

Erstellen Sie eine Matrix, die jede Item Variation mit der vorgesehenen Square Location, dem aktuellen Count, Zeitstempel, Source-State und künftigen System of Record verbindet.

Sollte Square-Online-Content Teil der Katalogvorbereitung sein?

Catalog-Beziehungen und Online-Darstellung sollten gemeinsam vorbereitet, aber getrennt verantwortet werden. Pages, Navigation, Domains, Redirects und online dargestellte Fulfillment-Versprechen werden nicht allein durch Item Records wiederhergestellt.

Wann ist die Vorbereitung für Square abgeschlossen?

Wenn Zugriff, Catalog Objects, Locations, Inventory, Customers, Orders, Square Online, Anwendungen, Stichproben und offene Entscheidungen jeweils verantwortliche Owner und wiederherstellbare Nachweise besitzen.