Wenn Bagisto als Zielplattform ausgewählt wird, muss die Vorbereitung sowohl die Commerce-Datensätze als auch die Laravel-Anwendungsstrukturen dokumentieren, denen diese Datensätze gehören. Products können unterschiedliche Produkttypen, Attributfamilien, Channels, Locales, Währungen, Bestandsquellen, Customer-Gruppen, Categories, Medien, Preise und URL-Keys verwenden. Erweiterungen und individuelle Packages können Marketplace-, B2B-, Buchungs-, Abonnement-, Zahlungs-, Versand-, API- oder Headless-Datensätze außerhalb des gewöhnlichen Katalogmodells einführen.
Jede vorbereitende Maßnahme sollte Verantwortliche, Nachweise und eine klare Ready-Bedingung festhalten. Das Vorbereitungspaket muss außerdem Quellnachweise von der Zielimplementierung trennen: Product-Beziehungen, historische Orders, CMS Pages, URLs, externe Kennungen und Package-eigene Datensätze gehören zur Migrationsbereitschaft. Aktuelles Zahlungs-, Versand-, Steuer-, Queue-, Such-, Theme- und Checkout-Verhalten bleibt dagegen Aufgabe der Implementierung im Zielshop.
Zugriff auf Bagisto, Laravel, Datenbank, Storage und Wiederherstellung absichern
Bestätigen Sie den Zugriff auf Bagisto Administration, Hosting- oder Cloud-Umgebung, Laravel-Anwendungsdateien, Environment-Konfiguration, Datenbank, öffentlichen und privaten Storage, Product-Medien, herunterladbare Dateien, Queue- und Scheduler-Konfiguration, Logs, Package-Verwaltung und angebundene Services. Geheimnisse gehören nicht in redaktionelle oder Migrationsunterlagen; dokumentiert werden nur die verantwortliche Stelle und der Ort, an dem Zugangsdaten verwaltet werden.
| Vorbereitungsmaßnahme | Verantwortlicher | Nachweis | Ready-Bedingung |
|---|---|---|---|
| Administrationszugriff bestätigen | Bagisto-Administrator | Funktionierendes Konto und Berechtigungsübersicht | Products, Attribute, Customers, Orders, Channels, Bestand und CMS-Datensätze können geprüft werden. |
| Anwendungs- und Datenbankzugriff bestätigen | Technischer Verantwortlicher | Übersicht zu Hosting, Laravel-Projekt, Datenbank, Storage, Queue, Scheduler und Deployment-Zugriff | Die vollständige führende Quelle kann eindeutig identifiziert werden. |
| Wiederherstellbare Backups erstellen | Infrastrukturverantwortlicher | Datenbank-Dump, Anwendungsarchiv, Storage-/Medien-/Download-Archiv und benannter Restore-Verantwortlicher | Der Quellshop kann unabhängig von der Live-Umgebung wiederhergestellt werden. |
| Versionen und Packages dokumentieren | Entwicklungsverantwortlicher | Inventar von Bagisto-, Laravel-/PHP-, Datenbank-, Theme-, Package-, Modul- und Custom-Code-Versionen | Versionsabhängige Datensätze und Erweiterungen sind nachvollziehbar. |
| Externe Systeme erfassen | Integrationsverantwortliche | ERP-/PIM-/WMS-/CRM-/Marketplace-/Search-/Payment-/Fulfillment-Endpunkte und Kennungszuordnungen | Weiterbetriebene Systeme und die jeweilige Synchronisierungsautorität sind bekannt. |
Interne und externe Kennungen sollten für Products, Product-Children, Attribute, Attributfamilien, Categories, Channels, Bestandsquellen, Customers, Orders, Rechnungen, Sendungen, Erstattungen, CMS-Datensätze, Packages und Integrationen erhalten werden.
Produkttypen und verkaufbare Beziehungen vorbereiten
Bagisto unterstützt mehrere Produkttypen mit unterschiedlichen Datensätzen und Geschäftsbeziehungen. Einfache Products bilden gewöhnliche verkaufbare Artikel ab. Konfigurierbare Products verwenden auswählbare Attribute und zugehörige Child Products. Gruppierte und Bundle-Products referenzieren andere Products. Downloadable und Virtual Products haben eine andere Fulfillment-Bedeutung, während Booking Products Termin-, Event-, Miet-, Tisch-, Slot-, Kapazitäts- und Datumsbeziehungen enthalten können.
| Produkttyp oder Muster | Vorzubereitende Nachweise | Ready-Bedingung |
|---|---|---|
| Simple Product | Product-ID, SKU, Preis, Tax Category, Bestand, Maße, Category, Channel, Locale, Medien und Order | Ein Datensatz identifiziert eindeutig den verkauften und erfüllten Artikel. |
| Configurable Product | Parent, zugehörige Child Products, konfigurierbare Attribute, Optionswerte, Child-SKUs, Preise, Bestand und Bilder | Jedes verkaufbare Child lässt sich auf Parent und gewählte Attribute zurückführen. |
| Grouped Product | Parent, verknüpfte einfache Products, Standardmengen, Sortierreihenfolge und repräsentative Order | Die Gruppe bleibt von der Identität der Komponenten-Products getrennt. |
| Bundle Product | Bundle-Optionen, Eingabetypen, verknüpfte Products, Standardmengen, Pflichtstatus, Preise und Order-Positionen | Bundle-Konfiguration und Komponentenbeziehungen sind vollständig dokumentiert. |
| Downloadable Product | Dateien/Links, Titel, Preis, Beispiel, Limits, Product-Verknüpfung und abgeschlossene Order | Nachweise für digitalen Zugriff sind wiederherstellbar. |
| Virtual Product | Service-Identität, Preis, Verfügbarkeit und Order-Kontext | Versand und physischer Bestand werden nicht künstlich eingeführt. |
| Booking Product | Buchungstyp, Daten, Slots, Kapazität, Standort, Ticket- oder Mietwerte, Stornierungsstatus und Order-/Buchungsdatensatz | Zeit- und kapazitätsbezogene Beziehungen sind dokumentiert. |
Ein Quell-Product mit Optionen sollte nicht automatisch zu einem Configurable Product werden. Dokumentieren Sie, ob eine Auswahl ein eigenständig verkaufbares Child, ein beschreibendes Attribut, eine Bundle-Auswahl, eine Buchungswahl oder eine einmalige Customer-Eingabe erzeugt.
Attribute, Attributfamilien, Categories und Medien vorbereiten
Bagisto-Attribute können Typen wie Text, Textarea, Preis, Boolean, Select, Multi-Select und Date-Time verwenden. Attributfamilien gruppieren Attribute für Product-Erstellung und -Bearbeitung. Categories organisieren Products, während Medien und URL-Keys an bestimmte Products oder Categories gebunden bleiben.
| Struktur | Nachweise | Verantwortlicher | Ready-Bedingung |
|---|---|---|---|
| Attribut | Code, Typ, Bezeichnungen, Optionen, Pflicht-/Eindeutigkeitsstatus, Filter-/Vergleichsnutzung sowie Locale-/Channel-Verhalten | Katalogverantwortlicher | Die geschäftliche Funktion jedes Attributs ist bekannt. |
| Attributfamilie | Familiencode/-name, gruppierte Attribute, Product-Zuordnungen und Abhängigkeiten von Custom Packages | Katalogverantwortlicher | Products können zugeordnet werden, ohne Pflichtfelder zu verlieren. |
| Konfigurierbares Attribut | Attribut, Optionswerte, Parent Product, Child Products und Bezeichnungen in Order-Positionen | Katalogverantwortlicher | Variantenidentität bleibt von beschreibenden Product-Daten getrennt. |
| Category | Category-ID, Hierarchie, Product-Zuordnungen, Channel-/Locale-Sichtbarkeit, Medien, Metadaten und URL-Key | Content-/Katalogverantwortliche | Taxonomie und öffentliche Routenverantwortung sind vollständig dokumentiert. |
| Medien | Product-/Category-Eigentümer, Primär-/Galerierolle, Dateipfad oder Remote-Quelle, Sortierung und Alt-Kontext | Content-Verantwortlicher | Jedes priorisierte Asset ist verfügbar und mit dem richtigen Datensatz verknüpft. |
| benutzerdefiniertes Feld aus einem Package | Schema, Entitätseigentümer, Typ, Beziehungen und konsumierendes Package | Entwicklungsverantwortlicher | Package-Daten werden nicht mit Bagisto-Core-Attributen verwechselt. |
Erstellen Sie ein Feldverzeichnis, das verkaufbare Identität, Product-Beschreibung, Filterung, Administration, Integrationskennungen und Package-eigenen Zustand voneinander trennt. Ähnliche Feldbezeichnungen sollten nur zusammengeführt werden, wenn auch ihre geschäftliche Funktion gleich ist.
Channels, Locales, Währungen und Bestandsquellen vorbereiten
Bagisto-Channels können Hostname, Root Category, Locales, Währungen, Theme, Bestandsquellen und weitere Storefront-Kontexte definieren. Bestandsquellen stellen Lagerorte dar, die Channels zugeordnet werden können; Product-Mengen können je Quelle geführt werden.
| Kontextbereich | Vorzubereitende Nachweise | Ready-Bedingung |
|---|---|---|
| Channel | Channel-ID/-Code, Hostname, Root Category, Locales, Währungen, Theme, Bestandsquellen und Verantwortlicher | Jeder kundenrelevante Kontext ist genau einmal erfasst. |
| Locale | Locale-Code, übersetzte Product-/Category-/Content-Felder, Fallback-Verhalten und Channel-Zuordnungen | Lokalisierte Datensätze bleiben mit dem vorgesehenen Channel verbunden. |
| Währung | Währungscode, Basis-/Standardverwendung, Channel-Zuordnung und Preisverantwortung | Kommerzielle Werte werden nicht vom Währungskontext getrennt. |
| Bestandsquelle | Quellen-ID/-Code, Name, Adresse, Status, Priorität, Channel-Zuordnungen und externe Warehouse-ID | Jeder Lagerort besitzt eine stabile Identität. |
| Product-Menge | Product-/Child-ID, Quellen-ID, Menge, reservierte/verfügbare Bedeutung soweit relevant und führendes System | Verkaufbare Einheit und Standort jeder Menge sind bekannt. |
| Channel-spezifischer Product-Zustand | Product/Child, Channel, Status, Sichtbarkeit, Preis- oder Inhaltsunterschiede und Category | Product-Umfang ist explizit und wird nicht global angenommen. |
Wenn ERP, WMS, Marketplace oder Lieferantenfeed den Bestand steuern, dokumentieren Sie das führende System und den Schlüssel, der es mit Bagisto-Product und Bestandsquelle verbindet.
Customer-Gruppen, Customers, Adressen und Authentifizierung vorbereiten
Die Vorbereitung von Bagisto-Customers sollte Customer-Identität, Customer-Gruppe, Adressen, Kontostatus, Einwilligungen, Reviews, Unternehmens- oder Steuerinformationen soweit vorhanden, externe IDs und Authentifizierungsabhängigkeiten umfassen. Erweiterungs-Packages können Marketplace-Verkäufer, Unternehmensaccounts, Quotes, Abonnements, Loyalty oder andere Profile ergänzen.
| Kontobereich | Nachweis | Verantwortlicher | Ready-Bedingung |
|---|---|---|---|
| Customer-Identität | Customer-ID, E-Mail, Name, Status, Gruppe, Locale-/Channel-Kontext und externe ID | Customer-Datenverantwortlicher | Dubletten und Guest-Identitäten werden bewusst aufgelöst. |
| Customer-Gruppe | Gruppen-ID/-Code, Mitglieder, Preis-/Zugriffsfolgen und Package-Abhängigkeiten | Commerce-Verantwortlicher | Gruppenbedeutung ist über die Bezeichnung hinaus dokumentiert. |
| Adresse | Adress-ID, Customer-Verknüpfung, Rechnungs-/Versandverwendung, Länder-/Bundeslandreferenzen, Unternehmen und Steuerfelder | Customer-Service-Verantwortlicher | Gespeicherte Adressen bleiben von historischen Order-Snapshots getrennt. |
| Guest Customer | E-Mail auf Order-Ebene, Adressen und Support-Kontext | Order-Datenverantwortlicher | Guest-Historie benötigt kein künstlich erzeugtes Konto. |
| Authentifizierung | Passwortschema, Social Login/SSO, MFA, Reset-Pfad und Kommunikationsverantwortlicher | Security-Verantwortlicher | Kontozugriff ist geplant, ohne Übertragbarkeit von Zugangsdaten vorauszusetzen. |
| Erweiterungsprofil | Customer-/User-ID, Package-Entität, Rolle, Status und zugehörige kommerzielle Datensätze | Package-Verantwortlicher | Spezialisierte Kontodaten haben ein Ziel oder einen verbleibenden Eigentümer. |
Nehmen Sie Customers aus unterschiedlichen Gruppen, Guest-Käufer, mehrere Adressen, inaktive Konten und erweiterungsdefinierte Kontotypen auf, wenn diese Orders oder Zugriffsrechte beeinflussen.
Orders, Rechnungen, Sendungen, Erstattungen und Transaktionen vorbereiten
Bereiten Sie Orders als historische kommerzielle Nachweise vor. Dazu gehören Order-Header, Customers oder Guests, Adressen, Product- und Child-Positionen, gewählte Optionen, Mengen, Preise, Rabatte, Steuern, Versand, Zahlungsbezeichnungen, Statushistorie, Rechnungen, Sendungen, Erstattungen, Transaktionen, Notizen und externe Referenzen. Booking-, Marketplace-, B2B- oder Custom Packages können zusätzliche Beziehungen beisteuern.
| Order-Nachweis | Verantwortlicher | Ready-Bedingung |
|---|---|---|
| Order-Header und Positionen | Order-Datenverantwortlicher | Product-/Child-IDs, Snapshot-Bezeichnungen, ausgewählte Werte, Mengen, Preise und Customer-Kontext sind vollständig. |
| Summen und Anpassungen | Finance-Verantwortlicher | Zwischensumme, Rabatt, Steuer, Versand, Gebühren, Erstattungen und Endsumme stimmen miteinander überein. |
| Rechnung und Sendung | Finance-/Fulfillment-Verantwortliche | Dokumentnummern, versandte Positionen, Mengen, Carrier/Tracking, Daten und Dateien sind wiederherstellbar. |
| Erstattung | Finance-/Support-Verantwortliche | Beträge, betroffene Positionen, Gründe, Status und zugehörige Transaktions-IDs sind dokumentiert. |
| Transaktion | Finance-Verantwortlicher | Zahlungsartbezeichnung, Transaktionsreferenz, Betrag, Status und externer Provider-Schlüssel sind bekannt. |
| Package-eigener Order-Datensatz | Package-Verantwortlicher | Buchungs-, Verkäufer-, Quote-, Abonnement- oder Custom-Workflow-Datensätze bleiben mit der Order verknüpft. |
| Externe Order-ID | Integrationsverantwortlicher | Herkunft in ERP, Marketplace, Accounting oder Fulfillment bleibt nachvollziehbar. |
Historische Summen sollten als Snapshots erhalten bleiben. Sie dürfen nicht aus aktuellen Preisen, Tax Categories, Customer-Gruppen, Versand- oder Zahlungskonfigurationen neu berechnet werden.
CMS Pages, URLs, Suche und kommerzielle Inhalte vorbereiten
Bagisto-Inhalte können CMS Pages, Product- und Category-Beschreibungen, Metadaten, URL-Keys, Navigation, Theme-Blöcke, Banner, Suchbegriffe, Warenkorbregeln, Katalogregeln sowie E-Mail- oder Benachrichtigungsinhalte umfassen. Erweiterungen können Page Builder oder Headless-Inhaltsquellen ergänzen.
| Inhaltsbereich | Vorzubereitende Nachweise | Ready-Bedingung |
|---|---|---|
| CMS Page | Page-ID, Titel, URL-Key, Channel-/Locale-Kontext, Status, Inhalt, Metadaten und Navigationsplatzierung | CMS-Inhalt bleibt von Theme-Darstellung getrennt. |
| Product-/Category-Inhalt | Entitäts-ID, Locale/Channel, Beschreibung, Metadaten, Bilder und priorisierte Route | Katalogeigene Inhalte bleiben mit der richtigen Entität verbunden. |
| Navigation und Theme-Block | Eigentümer, Hierarchie/Platzierung, verknüpftes Objekt, Medien und Package-/Theme-Abhängigkeit | Customer-Pfade werden nicht allein aus CMS- oder Category-Datensätzen abgeleitet. |
| Priorisierte URL | Product-/Category-/Page-Eigentümer, Locale/Channel, Quellpfad, Backlinks oder Traffic-Wert und Zielabsicht | Für jeden wichtigen Pfad existiert eine Entscheidung: behalten, ändern, zusammenführen, stilllegen oder weiterleiten. |
| Suche und Merchandising | Suchbegriffe, Synonyme, Regeln, Categories, Featured-/New-Status und verantwortliches System | Such- und Merchandising-Inputs bleiben von Product-Stammdaten getrennt. |
| Historische Promotion | Regel/Code, Zeiträume, Bedingungen, betroffene Products/Customers und Order-Referenzen | Historische Rabattnachweise bleiben von künftiger Zielkonfiguration getrennt. |
Ermitteln Sie priorisierte Pfade aus Analytics, Suchdaten, Backlinks, Kampagnen, Customer-Kommunikation und interner Navigation statt ausschließlich aus einer Sitemap.
Packages, benutzerdefinierte Tabellen, APIs und Headless-Abhängigkeiten inventarisieren
Bagistos Laravel-Architektur erlaubt Packages und individuellem Code, Entitäten, Tabellen, Events, Jobs, APIs, Marketplace- oder B2B-Strukturen, Buchungslogik, Zahlungs- und Versandverhalten, Suche, Feeds und externe Integrationen zu registrieren. Erstellen Sie vor der Entscheidung zum Migrationsumfang ein Eigentumsverzeichnis.
| Abhängigkeit | Vorzubereitende Nachweise | Ready-Bedingung |
|---|---|---|
| Package/Modul | Name, Version, Anbieter, Status, Zweck, Konfigurationsverantwortlicher, Migrations/Tabellen, Modelle und betroffene Datensätze | Package-eigene Daten haben ein Ziel oder einen verbleibenden Eigentümer. |
| benutzerdefinierte Tabelle oder Modell | Schema, Schlüssel, Beziehungen, Events, Jobs und konsumierender Code | Individuelle Datensätze können interpretiert statt blind kopiert werden. |
| API oder Headless-Client | Endpunkte, Ressourcen, Authentifizierungsverantwortlicher, IDs, Payload-Annahmen, Routen und Deployment-Verantwortlicher | Frontend- und Integrationsabhängigkeiten sind dokumentiert, ohne Geheimnisse offenzulegen. |
| Marketplace-/B2B-Package | Verkäufer/Unternehmen, Rollen, Kataloge, Quotes, Provisionen, Auszahlungen, Freigaben und verknüpfte Orders | Spezialisierte kommerzielle Datensätze bleiben von Core-Customers und Orders getrennt. |
| Such-/Indexdienst | Indexierte Felder, externe IDs, Quelldatensätze, Verantwortlicher für Rebuild und Synonyme/Regeln | Generierte Indexdaten werden nicht mit führendem Content verwechselt. |
| Queue/geplanter Prozess | Job, Trigger, Payload, Ziel, Retry-/Fehlerverantwortlicher und betroffene Entitäten | Operative Automatisierung bleibt von statischen Migrationsdaten getrennt. |
| Generierte Daten | Cache, Logs, Sessions, Queues, Indizes, temporäre Importe und verlassene Tabellen | Nicht führende technische Daten werden bewusst ausgeschlossen. |
Inaktive Packages sollten im Verzeichnis verbleiben, wenn ihre Daten weiterhin in Products, Customers, Orders, Buchungen, Verkäuferdatensätzen oder Reports auftauchen.
Repräsentative Migrationstestfälle auswählen
Wählen Sie Datensätze, die die tatsächlichen Produkttypen, Channels, Bestandsstrukturen, Customer-Kontexte, Orders, Inhalte und Packages des Shops sichtbar machen. Dokumentieren Sie Quell-IDs, SKUs, URL-Keys, Channel/Locale, Bestandsquelle, externe Schlüssel, verknüpfte Datensätze und den Grund für die Auswahl jedes Beispiels.
| Beispiel | Vorzubereitende Nachweise | Zweck der Vorbereitung |
|---|---|---|
| Simple Product | Preis, Steuer, Bestand, Category, Channel, Locale, Medien und Order | Bildet den gewöhnlichen Product-Basisfall ab. |
| Configurable-Product-Familie | Parent, Children, konfigurierbare Attribute, Optionen, SKUs, Preise, Bestand je Quelle, Bilder und Orders | Repräsentiert Variantenidentität. |
| Bundle-/Grouped-/Booking-Product | Komponenten- oder Slot-Beziehungen, Mengen, Preise, Kapazität, Package-Daten und Order-Positionen | Repräsentiert nicht einfache kommerzielle Strukturen. |
| Multi-Channel-Bestandsfall | Product/Child, Channels, Locales, Währungen, Bestandsquellen, Mengen und externe Warehouse-IDs | Repräsentiert Kontext und Bestandsverantwortung. |
| Customer-Gruppe oder Erweiterungsaccount | Customer, Gruppe/Profil, Adressen, Zugriffs-/Preisfolgen und relevante Order | Repräsentiert segmentierte oder Package-definierte Identität. |
| Komplexe Order | Produkttyp, Optionen, Rabatt, Steuer, Rechnung, Sendung, Erstattung, Transaktion und externe IDs | Repräsentiert historische Commerce-Nachweise. |
| CMS-/URL-Fall | CMS Page oder Kataloginhalt, Locale/Channel, URL-Key, Metadaten, Links und Zielabsicht | Repräsentiert Inhaltseigentum und Routenverantwortung. |
| Package-eigener Datensatz | Core-Entität, Package-Modell/-Tabelle, benutzerdefinierte Felder, Jobs/Events und Integrationsschlüssel | Macht Nicht-Core-Umfang vor der Ausführung sichtbar. |
Das Bagisto-Testpaket ist bereit, wenn für jeden ausgewählten Datensatz ein Quell-Erwartungsblatt, Channel- und Bestandskontext, zugehörige Dateien und ein benannter Reviewer vorliegen.
Abschließendes Readiness-Gate für Bagisto
| Bereitschaftsbereich | Ready-Bedingung |
|---|---|
| Zugriff und Recovery | Administration, Laravel-Anwendung, Datenbank, Storage, Medien/Downloads, Backups und Restore-Verantwortung sind bestätigt. |
| Katalog | Produkttypen, Children/Komponenten, Attribute, Familien, Categories, Medien, Preise, Bestand und Kennungen sind nachvollziehbar. |
| Channels und Bestand | Channels, Locales, Währungen, Bestandsquellen, Product-Zuordnungen, Mengen und externe Autoritäten sind dokumentiert. |
| Customers und Orders | Konten, Gruppen, Adressen, Orders, Positionen, Summen, Rechnungen, Sendungen, Erstattungen, Transaktionen und externe IDs sind belegt. |
| Inhalte und URLs | CMS Pages, Kataloginhalte, Navigation, priorisierte Pfade, Metadaten, Links und Redirect-Entscheidungen sind dokumentiert. |
| Abhängigkeiten | Packages, benutzerdefinierte Tabellen/Modelle, APIs, Headless-Clients, Jobs, Suche und externe Systeme haben benannte Verantwortliche. |
| Beispiele | Repräsentative Datensätze decken alle wesentlichen Produkttypen, Channels, Customers, Orders, Inhalts- und Package-Muster ab. |
Der Bagisto-Umfang ist bereit, wenn sich jeder wesentliche Datensatz zu seinem Quelleigentümer, den verbundenen Entitäten, einem Nachweis und dem vorgesehenen Ziel oder weitergeführten System zurückverfolgen lässt.
Fazit
Die Vorbereitung einer Bagisto-Migration erfordert abgestimmte Nachweise zu Laravel- und Datenbankzugriff, Produkttypen, Attributen und Familien, Categories, Channels, Bestandsquellen, Customers, Orders, CMS-Datensätzen, URLs, Packages, APIs und externen Systemen. Die Checkliste sollte diese Beziehungen vor der Ausführung sichtbar machen, statt Bagisto als einfache Product-Customer-Order-Datenbank zu behandeln.
Ein vollständiges Readiness-Paket sichert wiederherstellbare Quellnachweise, trennt Core-Datensätze von Package-eigenen Strukturen, unterscheidet historische Transaktionen von Live-Konfiguration und weist jeder Integration oder individuellen Abhängigkeit einen Verantwortlichen zu.
Häufige Fragen
Was sollte für eine Bagisto-Migration zuerst vorbereitet werden?
Bestätigen Sie den Zugriff auf Bagisto Administration, Laravel-Anwendung, Datenbank, Storage, Medien, Downloads, Queue, Scheduler und Packages. Erstellen Sie wiederherstellbare Backups und dokumentieren Sie die Versionen von Bagisto, Laravel, PHP, Datenbank, Theme und Packages.
Warum müssen Bagisto-Produkttypen separat inventarisiert werden?
Configurable, Grouped, Bundle, Downloadable, Virtual und Booking Products verwenden unterschiedliche Child-, Komponenten-, Datei-, Slot-, Kapazitäts- und Order-Beziehungen. Werden sie wie einfache Products behandelt, gehen genau die Strukturen verloren, die sie verkaufbar machen.
Wie sollten Attribute und Attributfamilien vorbereitet werden?
Dokumentieren Sie Attributcodes, Typen, Bezeichnungen, Optionen, Filter- oder Vergleichsnutzung, Pflicht- oder Eindeutigkeitsstatus, Familienzuordnung, Product-Zuordnung und ob das Feld zum Bagisto-Core oder zu einem Custom Package gehört.
Warum gehören Channels und Bestandsquellen zur Vorbereitung?
Channels können Hostname, Locale, Währung, Root Category, Theme und Bestandsquellen-Umfang definieren. Product-Mengen können bestimmten Bestandsquellen gehören; eine globale Bestandszahl erhält deshalb weder Standort- noch Channel-Bedeutung zuverlässig.
Welche Bagisto-Orders sollten als repräsentative Beispiele ausgewählt werden?
Nehmen Sie einfache und konfigurierbare Products, Bundles oder Bookings soweit genutzt, Rabatte, mehrere Steuerfälle, Rechnungen, Sendungen, Erstattungen, Transaktionen, Guest- und gruppierte Customers, externe IDs und Package-eigene Order-Beziehungen auf.
Was gehört in das Bagisto-Verzeichnis für Packages und individuelle Daten?
Erfassen Sie jedes Package, benutzerdefinierte Tabelle/Model, jede API, jeden Headless-Client, Job, Event, Suchdienst, jede Marketplace- oder B2B-Komponente und jeden externen Connector, der Geschäftsdaten erzeugt oder verwendet. Für jedes Element braucht es einen Verantwortlichen, betroffene Datensätze, Nachweise und eine Entscheidung zum Ziel oder weitergeführten System.