Wenn Adobe Commerce als Zielplattform ausgewählt wird, sollte die Vorbereitung das Enterprise-Betriebsmodell in ein kontrolliertes Nachweispaket überführen, bevor ein Migrationslauf beginnt. Das Team muss wissen, wie B2C-Kunden, B2B-Unternehmen, Company Users, Shared Catalogs, Websites, Stores, Store Views, Produkttypen, Inventory Sources, historische Bestellungen, Inhalte und externe Systeme im Zielshop dargestellt werden sollen.
Ein brauchbares Vorbereitungspaket beantwortet für jeden wichtigen Bereich vier Fragen: Welche Maßnahme ist erforderlich? Wer ist verantwortlich? Welche Informationen stützen die Entscheidung? Welche Bedingung muss erfüllt sein, damit der Bereich als vorbereitet gilt? So wird verhindert, dass Unternehmensbeziehungen, käuferspezifische Preise, regionale Storefronts oder ERP-eigene Kennungen erst auffallen, nachdem bereits Beispieldatensätze migriert wurden.
Die Betriebsentscheidungen für Adobe Commerce festlegen
Beginnen Sie mit einer kompakten Beschreibung des Betriebsmodells. Darin sollte festgelegt werden, welche Commerce-Strukturen in Adobe Commerce bestehen müssen und welche Systeme außerhalb der Plattform weiterhin maßgeblich bleiben.
| Vorbereitungsbereich | Zu dokumentierende Entscheidung | Verantwortlich | Nachweis für Bereitschaft |
|---|---|---|---|
| Käufermodell | B2C-Kunden, B2B-Unternehmen, Company Locations, Company Users, Rollen, Genehmiger und Sales Representatives | B2B- und Customer Operations | Freigegebenes Beziehungsdiagramm der Accounts mit repräsentativen Quelldatensätzen |
| Katalogmodell | Produkttypen, Attribute Sets, Kategorien, Shared Catalogs, Käufersichtbarkeit und regionale Sortimente | Katalog- und Merchandising-Verantwortliche | Matrix aus Produktfamilie und Katalog-Scope |
| Storefront-Scope | Websites, Stores, Store Views, Sprachen, Währungen, Marken, Regionen und Domains | Commerce-Architecture-Verantwortlicher | Website-/Store-/Store-View-Map |
| Pricing-Verantwortung | Basispreise, Tier Prices, verhandelte Preise, Shared-Catalog-Preise und externe Vertragspreise | Commercial- und Integrationsverantwortliche | Preisquellen-Register und Beispiel-Käuferszenarien |
| Inventory-Verantwortung | Sources, Stocks, Websites, Lager, Drop Shippers, Pickup Points und externe Bestandssysteme | Inventory- und Fulfillment-Verantwortliche | Source-/Stock-Ownership-Map |
| Integrationsmodell | ERP-, PIM-, CRM-, WMS-, Procurement-, Accounting-, Tax-, Shipping-, Search- und Reporting-Abhängigkeiten | Technischer Owner | Abhängigkeitsregister mit dauerhaften Kennungen |
Das Dokument sollte konkret genug sein, um die Vorbereitung zu steuern, ohne zu einer Adobe-Commerce-Konfigurationsspezifikation zu werden. Sein Zweck besteht darin, den Ziel-Owner jeder geschäftlichen Beziehung festzulegen.
Zugänge, Quellnachweise und wiederherstellbare Backups vorbereiten
Stellen Sie die Zugänge und Quellinformationen zusammen, die erforderlich sind, um den Quellshop unabhängig von undokumentiertem Mitarbeiterwissen zu interpretieren.
Bereiten Sie vor:
- Administratorzugang zum Quellshop und zur Adobe-Commerce-Umgebung mit dem erforderlichen Berechtigungsniveau;
- datierte Exporte oder Berichte für Produkte, Kategorien, Kunden, Unternehmen, Company Users, Bestellungen, Inhalte, Reviews, Promotions und andere Datensätze im Scope;
- Datenbank- und Medien-Backups, soweit verfügbar;
- Referenzen für Produktattribute, Attribute Sets und Produkttypen;
- Inventare von Websites, Stores, Store Views, Sprachen, Währungen und Domains;
- Beispiele für B2B-Unternehmen, Rollen, Shared Catalogs, Preise und Kredit;
- Berichte zu Inventory Sources, Stocks, Lagern und Auftragsabwicklung;
- Inventare zu Extensions, Custom Modules, APIs und externen Systemen;
- Listen wertvoller URLs, Redirects, CMS Pages, Blocks und Kampagnen;
- Screenshots oder Berichte, die wichtige Quellfunktionen erklären.
| Nachweis | Warum er benötigt wird | Bereitschaftsbedingung |
|---|---|---|
| Zugangsprotokoll | Bestätigt, dass erforderliche Quell- und Zielbereiche geprüft werden können | Erforderliche Konten funktionieren und Berechtigungsverantwortliche sind benannt |
| Exportarchiv | Bewahrt einen datierten Referenzzustand | Dateien lassen sich öffnen und enthalten die erwarteten Datensatzfamilien |
| Datenbank-/Medien-Backup | Schützt Datensätze, die in gewöhnlichen Exporten nicht enthalten sind | Speicherort, Datum und Wiederherstellungsverantwortlicher sind dokumentiert |
| Feldverzeichnis | Erklärt Custom Labels, Flags und Kennungen | Jedes wichtige Feld besitzt Zweck, Owner und Beispielwert |
| Scope-Map | Verhindert das Abflachen von Website-, Store-View-, B2B- und Inventory-Beziehungen | Jede Business Unit und jeder Storefront im Scope besitzt ein vorgesehenes Ziel |
Wenn ein Export Extension- oder B2B-Datensätze auslässt, dokumentieren Sie die Lücke und weisen Sie einen Owner zu. Fehlende Nachweise sind ein Bereitschaftsproblem und kein Beweis dafür, dass die Daten nicht existieren.
B2B-Unternehmen, Benutzer, Rollen und Einkaufskontext vorbereiten
B2B-Beziehungen in Adobe Commerce benötigen mehr Vorbereitung als einzelne Kundenprofile. Ein Unternehmen kann Benutzer, Teams, Rollen, Berechtigungen, Shared-Catalog-Zuordnungen, Kredit, Purchase-Order-Funktionen, Zahlungsbeschränkungen, Versandbeschränkungen und externe Kontokennungen enthalten.
Bereiten Sie repräsentative Nachweise vor für:
- rechtliche Unternehmensidentität, Status, Steuerkennungen, Reseller-Kennungen und rechtliche Adresse;
- Beziehungen zwischen Unternehmensadministrator und Company Locations;
- Käufer, Genehmiger, Filialbenutzer, Einkaufsteams und Benutzer, die mehreren Unternehmen zugeordnet sind;
- Rollen und Berechtigungen für Bestellungen, Quotes, Purchase Orders, Benutzer, Teams und Company Credit;
- Kreditlimit, verfügbares Guthaben, Währung, Payment-on-Account-Kontext und gegebenenfalls Kredithistorie;
- erwartete Purchase-Order-Genehmigungen und Einkaufsreferenzen;
- zulässige Zahlungs- und Versandmethoden;
- Sales-Representative-, ERP-Account-, Händler-, Procurement- und CRM-Kennungen.
| Vorbereitungspunkt | Owner | Erforderlicher Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Unternehmensidentität | B2B Operations | Unternehmensstammliste und Quell-IDs | Jedes Unternehmen besitzt genau einen vorgesehenen Adobe-Commerce-Company-Datensatz |
| Benutzermitgliedschaft | Customer Operations | User-to-Company- und User-to-Team-Matrix | Jeder Company User besitzt definiertes Unternehmen, Status und Rolle |
| Berechtigungsmodell | B2B Process Owner | Beispiele für Rollen und Berechtigungen | Erforderliche Einkaufsverantwortungen sind dokumentiert |
| Kredit- und PO-Kontext | Finance und Procurement | Repräsentative Company-Credit- und Purchase-Order-Datensätze | Finanz- und Genehmigungsbeziehungen besitzen einen Ziel-Owner |
| Externe Account-Schlüssel | Integration Owner | ERP-, CRM-, Procurement- und Händler-IDs | Jeder Schlüssel ist der richtigen Unternehmens- oder Benutzerebene zugeordnet |
Wenn B2B-Bedeutung in Kundengruppen, Tags, Custom Fields, Tabellen oder externen Systemen verborgen ist, erstellen Sie ein Übersetzungsregister für die Beziehungen, statt diese Werte in gewöhnliche Kundenfelder zu zwingen.
Shared Catalogs, Preise und Produktsichtbarkeit vorbereiten
Shared Catalogs können Produktverfügbarkeit und individuelle Preise für Company Accounts steuern. Die Vorbereitung sollte festlegen, welche Kataloge relevant sind, welchen Unternehmen sie zugeordnet werden, welche Produkte dazugehören und welches Pricing-System maßgeblich ist.
| Katalog- oder Pricing-Datensatz | Vorbereitungsmaßnahme | Nachweis |
|---|---|---|
| Öffentlicher Katalog | Produkte und Kategorien definieren, die gewöhnlichen Kunden zur Verfügung stehen | Stichprobe der Produkt- und Kategoriemitgliedschaft |
| Custom Shared Catalog | Unternehmenszuordnung, Produktmitgliedschaft und individuelle Preise definieren | Company-to-Catalog- und Product-to-Catalog-Matrix |
| Kundengruppenpreis | Beziehung zwischen Kundengruppe und Produkt bestimmen | Repräsentatives Produkt-/Kundengruppenbeispiel |
| Tier- oder Mengenpreis | Produkt, Schwellenwert, Käufer-Scope und Betrag dokumentieren | Preisstufen-Beispiel mit Source Owner |
| Vertrags- oder Verhandlungspreis | Externen oder internen Price Owner festlegen | Buyer-/Product-Preisbeispiel und Schlüssel des externen Systems |
| Eingeschränktes Sortiment | Definieren, welche Unternehmen oder Gruppen das Produkt sehen oder kaufen dürfen | Sichtbarkeitsbeispiel und Ausnahmeliste |
Normalisieren Sie doppelte Katalognamen, veraltete Preislisten, abgelaufene Ausnahmen und uneinheitliche Produktkennungen, bevor daraus Adobe-Commerce-Strukturen werden. Der Bereich ist vorbereitet, wenn jedes priorisierte Unternehmen einem vorgesehenen Katalog und einer Preisquelle zugeordnet werden kann, ohne sich auf das Erinnerungswissen einzelner Mitarbeiter zu verlassen.
Produkttypen, Attribute und Katalog-Governance vorbereiten
Wählen Sie repräsentative Produkte nach Struktur aus, nicht nur nach Popularität. Adobe Commerce unterstützt mehrere Produkttypen, und die Quelldatensätze müssen danach klassifiziert werden, wie sie verkauft und gepflegt werden.
Berücksichtigen Sie Beispiele für:
- Simple Products;
- Configurable Products mit separat bestandsgeführten Child SKUs;
- Grouped und Bundle Products;
- Virtual und Downloadable Products;
- Gift-Card- oder Custom Product Types, sofern relevant;
- Produkte mit Custom Options;
- Produkte mit lokalisierten oder website-spezifischen Werten;
- Produkte mit Custom Attributes, externen IDs oder integrationsverwalteten Daten;
- Produkte, die mehreren Kategorien oder eingeschränkten Katalogen zugeordnet sind.
Erstellen Sie eine Attribut-Governance-Übersicht:
| Quellfunktion | Vorbereitungsentscheidung in Adobe Commerce | Nachweis für Bereitschaft |
|---|---|---|
| Wert definiert eine verkaufbare Variante | Configurable Product, Child Simple Products und Variantenattribute festlegen | Parent-/Child-IDs, SKUs, Attributwerte und Bestandsbeispiel |
| Wert ist beschreibend | Zielfeld und Scope bestimmen | Feldname, Beispielwert und Store-View-Anforderung |
| Wert steuert Filterung oder Suche | Such- und Filterrolle des Attributs definieren | Attributkonfiguration und Beispielabfrage |
| Wert steuert Preis, Promotion oder Regel | Geschäftsregel und Ziel-Owner dokumentieren | Regelbeispiel und erwartetes Ergebnis |
| Produkt ist Bundle oder Group | Komponenten und kommerzielle Beziehung definieren | Komponentenliste, Mengen, Preise und Inventory Owner |
| Wert ist Metadatum eines externen Systems | Auf Produkt- oder Child-SKU-Ebene erhalten, die vom externen System verwendet wird | Externer Schlüssel und Lookup-Beispiel |
Entfernen Sie nicht verwendete Attribute, normalisieren Sie kontrollierte Werte, bestimmen Sie erforderliche Attribute Sets und dokumentieren Sie Felder, die ausgeschlossen werden sollen. Der Katalog ist vorbereitet, wenn jede wesentliche Produktfamilie einen eindeutigen Produkttyp, ein Attribute Set, Child-Beziehungen, Category Ownership und einen Plan für externe Kennungen besitzt.
Websites, Store Views, Inhalte, URLs und Kampagnendatensätze vorbereiten
Ordnen Sie die Storefront-Struktur des Quellsystems den Websites, Stores und Store Views in Adobe Commerce zu. Dokumentieren Sie, welche Werte nach Marke, Region, Sprache, Währung, Domain oder Rechtseinheit variieren.
Bereiten Sie vor:
- Website-/Store-/Store-View-Hierarchie;
- Sprach- und Währungszuordnungen;
- Produkt- und Kategorieinhalte je Scope;
- CMS Pages, CMS Blocks, Page-Builder-Inhalte, Formulare, Banner und Medien;
- geplante oder gestagte Kampagnendatensätze, die weiterhin relevant sind;
- Product-, Category-, CMS-, Campaign- und lokalisierte URLs;
- Redirect-Historie und besonders wertvolle Quellpfade;
- interne Links in Produktbeschreibungen und CMS-Inhalten.
| Quellroute oder Inhalt | Vorbereitungsfrage | Nachweis für Bereitschaft |
|---|---|---|
| Produkt- oder Kategorie-URL | Welche Website und Store View besitzen die Zielroute? | Source-/Destination-Route-Ledger |
| Lokalisierter Inhalt | Welche Werte sind übersetzt oder regionsspezifisch? | Store-View-Content-Matrix |
| CMS Page oder Block | Handelt es sich um wiederverwendbaren Inhalt, Seiteninhalt, Kampagneninhalt oder reine Präsentationsdaten? | Content-Inventar mit Ziel-Owner |
| Geplante Kampagne | Wird der Inhalt noch benötigt, ist er nur historisch oder wird er bewusst eingestellt? | Kampagnenentscheidung und Content Owner |
| Interner Link | Welche Zielroute soll den Quellpfad ersetzen? | Link-Rewrite-Liste für priorisierte Inhalte |
Der Bereich ist vorbereitet, wenn jede priorisierte öffentliche Route und jedes relevante Content Asset ein vorgesehenes Ziel, einen Scope oder eine dokumentierte Retirement-Entscheidung besitzt.
Bestand, Kunden und historische Bestellungen vorbereiten
Inventory-Nachweise sollten die Beziehung zwischen Quellstandorten, Adobe-Commerce-Sources, Stocks, Websites, salable quantity und einem gegebenenfalls externen Inventory Owner beschreiben. Bereiten Sie Beispiele für Single-Source- und Multi-Source-Produkte, Configurable Child SKUs, Backorders, Pickup Locations, Drop Shippers und ERP- oder WMS-gesteuerten Bestand vor.
Für Kunden und Bestellungen sollten Stichproben die historischen Beziehungen sichtbar machen, die Mitarbeiter später verstehen müssen:
- registrierte B2C-Kunden, Guest Buyers, mehrere Adressen, Kundengruppen, Steuerbehandlung und externe IDs;
- Company Customers und Company Users;
- Bestellungen mit configurable, bundle, virtual, downloadable oder Custom-Option-Produkten;
- Rabatte, Steuern, Versand, Payment Labels, Rechnungen, Sendungen, Credit Memos, Returns, Kommentare und externe Referenzen;
- Bestellungen aus jeder wichtigen Website, Währung, Region, Company oder jedem Fulfillment-Pfad.
| Bereich | Owner | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Inventory Sources und Stocks | Inventory Operations | Source-/Stock-/Location-Map und SKU-Stichproben | Jede priorisierte SKU besitzt einen definierten Stock Owner und eine Website-Beziehung |
| Kundenidentität | Customer Operations | Beispiele für Duplikate, Guest, Adresse, Gruppe und externe ID | Identitäts- und Merge-Regeln sind dokumentiert |
| Bedeutung historischer Bestellungen | Support und Finance | Repräsentatives Order-Paket | Produktpositionen, Summen, Status, Fulfillment, Refunds und Referenzen sind nachvollziehbar |
| Sensible Daten | Legal und Data Owner | Freigegebene Feldliste | Nicht erforderliche personenbezogene oder finanzielle Daten sind ausgeschlossen |
Historische Bestellungen sollten als Nachweis des früheren Commerce-Betriebs vorbereitet werden. Die aktuelle Konfiguration von Payment, Shipping, Tax, Inventory und Fulfillment in Adobe Commerce bleibt eine separate Implementierungsverantwortung.
Extensions, Custom Modules und externe Systeme inventarisieren
Erstellen Sie ein Abhängigkeitsregister für jede Extension, jedes Custom Module, jede Integration, jeden Scheduled Job, jede Custom Table, API und jedes externe System, das Datensätze im Scope erstellt oder verändert.
Dokumentieren Sie für jede Abhängigkeit:
- geschäftlichen Zweck;
- erweiterte Core-Datensätze;
- erzeugte Tabellen, Attribute, Status oder Kennungen;
- Data Owner und Technical Owner;
- Export- oder API-Verfügbarkeit;
- Ziel-Owner oder Ersatzsystem;
- stabile Schlüssel für die Wiederverknüpfung;
- Datensätze, die eingestellt oder archiviert werden können.
Zu den priorisierten Abhängigkeiten gehören häufig ERP, PIM, CRM, WMS, Procurement, Search, Subscriptions, Loyalty, Reviews, Tax, Payment, Shipping, Marketplaces, Analytics, Reporting und individuelle B2B-Workflows.
Das Register ist vorbereitet, wenn jede wichtige Abhängigkeit einen benannten fortbestehenden Owner besitzt und kein kritisches Feld lediglich mit „wurde von der Extension verarbeitet“ beschrieben wird.
Repräsentative Migrationsstichproben auswählen
Wählen Sie eine Stichprobe, die die zuvor vorbereiteten Enterprise-Entscheidungen sichtbar macht. Verwenden Sie nicht nur zufällige Produkte oder ausschließlich einfache Bestellungen.
| Stichprobe | Zweck der Vorbereitung |
|---|---|
| Simple- und Configurable-Product-Familie | Produkttyp, Child SKU, Attribute, Medien und Bestandsmuster festlegen |
| Bundle oder Grouped Product | Komponenten- und Preisbeziehungen sichtbar machen |
| B2B-Unternehmen mit mehreren Benutzern | Company-, Team-, Rollen- und externe-ID-Beziehungen sichtbar machen |
| Shared-Catalog-Produkt | Unternehmenszuordnung, Sichtbarkeit und Pricing-Nachweise sichtbar machen |
| Multi-Source-Inventory-SKU | Source-, Stock-, Website- und externe Bestandsverantwortung sichtbar machen |
| Lokalisiertes Produkt oder CMS Page | Store-View-Scope und Route Ownership sichtbar machen |
| Komplexe historische Bestellung | Produktpositionen, Summen, Fulfillment, Credit Memos und externe Referenzen sichtbar machen |
| Extension-eigener Datensatz | Custom Fields, Tabellen und Ziel-Ownership-Entscheidungen sichtbar machen |
Dokumentieren Sie für jede Stichprobe Source ID, gegebenenfalls Source URL, geschäftlichen Grund, erwarteten Adobe-Commerce-Owner, zugehörige externe Kennungen, bekannte Ausschlüsse und den verantwortlichen Reviewer. Dadurch erhält jede Stichprobe eine nachvollziehbare Quellerwartung und einen benannten Prüfer.
Bereitschaft für Adobe Commerce abschließend prüfen
| Bereitschaftsfrage | Erforderlicher Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Sind Zugänge und Backups verfügbar? | Zugangsprotokoll und datiertes Archiv | Erforderliche Systeme und Quellnachweise sind wiederherstellbar |
| Ist das Betriebsmodell dokumentiert? | Buyer-, Storefront-, Catalog-, Pricing- und Inventory-Maps | Jede wesentliche Beziehung besitzt einen Owner |
| Sind B2B-Strukturen vorbereitet? | Nachweise zu Company, User, Rolle, Catalog, Credit und PO | Repräsentative Unternehmensbeziehungen sind vollständig |
| Sind Produktfamilien klassifiziert? | Produkt- und Attributmatrix | Jedes wesentliche Produktmuster besitzt eine vorgesehene Adobe-Commerce-Struktur |
| Sind Inhalte und URLs zugeordnet? | Route- und Content-Ledger | Priorisierte Routes besitzen Ziele oder Retirement-Entscheidungen |
| Sind Integrationen inventarisiert? | Abhängigkeitsregister | Jede kritische Abhängigkeit besitzt einen fortbestehenden Owner und Schlüssel |
| Sind repräsentative Migrationsstichproben ausgewählt? | Sample Ledger | Gewöhnliche und außergewöhnliche Datensätze sind abgedeckt |
| Sind offene Punkte kontrolliert? | Decision Log | Jeder offene Punkt besitzt Owner und Fälligkeitsdatum |
Die Vorbereitung ist abgeschlossen, wenn die Nachweise von einer Person verstanden werden können, die den Quellshop nicht selbst konfiguriert hat, und keine kritische B2B-, Produkt-, Inventory-, Bestell-, URL- oder Integrationsentscheidung von undokumentierten Annahmen abhängt.
Fazit
Die Vorbereitung für Adobe Commerce sollte ein Enterprise-Nachweispaket erzeugen und keine generische Export-Checkliste. Unternehmen, Benutzer, Rollen, Shared Catalogs, Produkttypen, Attribute, Store Views, Inventory Sources, historische Bestellungen, Inhalte und Integrationen brauchen eindeutige Verantwortliche und repräsentative Datensätze.
Wenn diese Entscheidungen vor dem repräsentativen Migrationstest dokumentiert sind, kann das Team die geplante Adobe-Commerce-Abbildung anhand kontrollierter Nachweise beurteilen, statt das Betriebsmodell aus einzelnen migrierten Datensätzen rekonstruieren zu müssen.
Häufige Fragen
Welcher Vorbereitungsnachweis sollte für Adobe Commerce zuerst erstellt werden?
Beginnen Sie mit der Betriebsmodell-Map für Käufer, Websites, Store Views, Kataloge, Preise, Inventory und externe Systeme. Sie bestimmt, welche detaillierten Nachweise und Verantwortlichen erforderlich sind.
Wie sollten B2B-Unternehmen für Adobe Commerce vorbereitet werden?
Bereiten Sie Unternehmensidentität, Administrator, Benutzer, Teams, Rollen, Berechtigungen, Kredit, Purchase-Order-Kontext, Catalog-Zuordnungen und externe IDs als verbundene Datensätze vor. Reduzieren Sie ein Unternehmen nicht auf eine gewöhnliche Kundengruppe.
Welche Nachweise werden für Shared Catalogs benötigt?
Dokumentieren Sie Katalogmitgliedschaft, Unternehmenszuordnung, Produktsichtbarkeit, Preisquelle, Ausnahmen und repräsentative Produkt-/Käuferbeispiele. Jeder Katalog sollte einen klaren kommerziellen Owner besitzen.
Wie sollten Configurable Products vorbereitet werden?
Dokumentieren Sie Parent Product, Child Simple Products, Variantenattribute, SKUs, Bestand, Preise, Bilder und externe Kennungen. Identifizieren Sie außerdem Quellwerte, die nur Beschreibungen oder benutzerdefinierte Eingaben und keine echten Varianten darstellen.
Welche Bestandsdatensätze benötigen besondere Vorbereitung?
Priorisieren Sie Multi-Source-SKUs, Configurable Child SKUs, Pickup- oder Drop-Ship-Standorte, Backorders und extern synchronisierten Bestand. Jede Menge benötigt eine definierte Beziehung zu Source, Stock, Website und führendem Bestandssystem.
Wann ist die Vorbereitung für Adobe Commerce abgeschlossen?
Sie ist abgeschlossen, wenn Zugänge und Backups wiederherstellbar sind, B2B- und Katalogstrukturen Verantwortliche besitzen, priorisierte Routes und Integrationen dokumentiert sind, repräsentative Stichproben ausgewählt wurden und jede offene Entscheidung einen verantwortlichen Owner hat.