PrestaShop-APIs und Integrationen: Webservice, ERP, Zapier und Make

So würden wir vorgehen

Wir würden bei der messbaren manuellen Aufgabe oder Störung beginnen und dann prüfen, ob Ihre vorhandene Integration sie bereits bewältigen kann. Beginnen Sie für einen laufenden Austausch mit einem geplanten inkrementellen Job, sofern der Betrieb die Verzögerung toleriert. Wählen Sie einen gepflegten Konnektor, wenn er den vollständigen Ablauf abdeckt. Beauftragen Sie einen Worker oder ein Modul, wenn die fehlenden Geschäftsregeln eigenen Code rechtfertigen.

Der Weg hängt von Ihren installierten PrestaShop- und PHP-Versionen, Modulen, weiteren Integrationen, Theme- und Kassenanpassungen, der Datenqualität, Varianten und Multistore-Konfiguration ab. Berücksichtigen Sie Ihre Märkte, Währungen und Steuerfälle, die Möglichkeiten des empfangenden Systems und das für den Betrieb verfügbare Team. Proben Sie eine Änderung auf einer Staging-Kopie mit repräsentativen Daten und derselben relevanten Konfiguration, getrennt von echten Kunden-E-Mails, Lagerauslieferungen und produktiven Schreibzugriffen auf andere Systeme. Planen Sie Umstellung und Rückkehr zum bisherigen Stand, bevor Sie den produktiven Schreibprozess aktivieren.

Benötigen Sie einen Konnektor auf Grundlage dieser Regeln, beginnt der PrestaShop Custom Module Development Service mit einer schriftlichen Spezifikation und Abnahmekriterien für die vereinbarten Verbindungen.

Den kleinsten Weg wählen, der die Anforderung erfüllt

Wählen Sie die API und definieren Sie die Integrationsvereinbarung

Der klassische Webservice gehört zum Kernsystem. Er bietet ressourcenorientierten HTTP-Zugriff, XML-Anfragen und XML- oder JSON-Antworten in PrestaShop 1.7.8 und 9.1. PrestaShop 9 hat außerdem eine Admin API mit OAuth2 und JSON. Diese APIs unterscheiden sich bei Authentifizierung, Routen und Funktionsumfang.

Listen Sie vor der Auswahl die genau benötigten Vorgänge auf: Produkterstellung, Variantenzuordnung, Bestandsaktualisierung, Bestellexport, Erstattungen, Sendungsverfolgung oder Buchhaltungsbelege. Prüfen Sie die Ressourcenliste und generierte Dokumentation des installierten Shops. Gehen Sie nicht davon aus, dass eine der APIs jeden Vorgang in jeder Version abdeckt. Dokumentieren Sie für jeden Vorgang Quelle, Ziel, Shop-Kontext, Pflichtfelder, erwartete Geschäftsauswirkungen und Bestätigungsantwort. Ein Konnektor, der eine Bestellung liest, kann trotzdem den für Ihren Prozess benötigten Gutschrift- oder Sendungsverfolgungsvorgang vermissen lassen.

Bevorzugen Sie für laufende Schreibvorgänge eine API oder einen unterstützten Anwendungsdienst. Direktes SQL umgeht Anwendungsvalidierung, Hooks und weitere Verarbeitung. Eine spezialisierte Migration muss Zuordnungen, Indexierung, Bestände, Medien und Cache-Invalidierung ausdrücklich behandeln; allein den Cache zu leeren reicht nicht aus. Es gibt keinen allgemeinen Schwellenwert für die Kataloggröße, ab dem direktes SQL die richtige Wahl wäre.

Dieser Leitfaden beginnt mit der Funktionsweise des Webservice und behandelt anschließend ERP-Planung und Automatisierungsplattformen. Einzelheiten zur installierten Version finden Sie in der offiziellen Webservice-Dokumentation.

Aktivieren Sie den Zugriff und prüfen Sie das Routing

1. Öffnen Sie Erweiterte Einstellungen, Webservice. Aktivieren Sie den Webservice.
2. Erstellen Sie für jede Integration einen eigenen aktiven Schlüssel.
3. Erlauben Sie im richtigen Shopkontext nur die benötigten Ressourcen und Methoden.
4. Speichern Sie den Schlüssel in einem sicheren Speicher für Zugangsdaten oder einer geschützten Zugangsdaten-Datei außerhalb der Versionsverwaltung.
5. Testen Sie den Zugriff über HTTPS von der tatsächlichen Ausführungsumgebung der Integration aus.

Bei HTTP Basic Authentication ist der Schlüssel der Benutzername und das Passwort leer. Der Dispatcher akzeptiert auch ws_key in einer Abfragezeichenfolge; vermeiden Sie diesen Übertragungsweg jedoch, weil URLs in Protokollen, Verläufen und Analysesystemen landen können.

Die Beispiele verwenden eine private curl-Konfigurationsdatei, deren Name in WS_CURL_CONFIG steht. Geben Sie in Bash die tatsächliche HTTPS-Basis-URL des Shops einschließlich eines möglichen Installationsunterverzeichnisses und den Integrationsschlüssel ein. Die temporäre Zugangsdaten-Datei wird beim Beenden dieser Shell gelöscht. Lassen Sie dieselbe Shell für die späteren curl-Beispiele geöffnet.

umask 077
read -r -p 'Shop HTTPS base URL: ' SHOP_URL
read -r -s -p 'Webservice key: ' WS_KEY
printf '\n'
WS_CURL_CONFIG="$(mktemp)"
trap 'rm -f "$WS_CURL_CONFIG"' EXIT
printf 'user = "%s:"\n' "$WS_KEY" > "$WS_CURL_CONFIG"
unset WS_KEY
curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/?output_format=JSON"

Die API-Route und der Dispatcher

/api ist normalerweise eine virtuelle Route. Die erzeugten Apache-Regeln leiten sie an webservice/dispatcher.php weiter und verwenden dabei einen url-Parameter. Diese API-Regel wird unabhängig von der Einstellung für suchmaschinenfreundliche URLs des Shops erzeugt.

Erhalten Sie bei Nginx Ressourcenpfad und ursprüngliche Argumente. Die standardmäßige Rewrite-Form in der offiziellen Konfiguration lautet:

rewrite ^/api/?(.*)$ /webservice/dispatcher.php?url=$1 last;

Passen Sie für einen unter /shop/ installierten Shop beide Seiten an:

rewrite ^/shop/api/?(.*)$ /shop/webservice/dispatcher.php?url=$1 last;

Diese Regeln gehören in einen korrekt konfigurierten Server mit seiner bestehenden PHP-Verarbeitung. Beispielsweise muss /shop/api/products?limit=5 den Dispatcher mit url=products und limit=5 erreichen. Nginx hängt bei dieser Rewrite-Form die ursprünglichen Argumente an. Testen Sie nach dem Neuladen die wirksame Serverkonfiguration und beide Zugangswege.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/webservice/dispatcher.php?url=products&limit=1"

Wenn der direkte Dispatcher-Zugriff funktioniert, die API-Route aber nicht, prüfen Sie Rewriting, Basispfad und Proxy-Routing. Wenden Sie IP-Beschränkungen und Ratenbegrenzungen sowohl auf die lesbare Route als auch auf den tatsächlichen Dispatcher an. Eine .htaccess-Datei in einem nicht vorhandenen Verzeichnis /api/ schützt den PHP-Endpunkt nicht. Prüfen Sie Beschränkungen nach jedem internen Rewrite.

Erkunden Sie Ressourcen, Schemas und Antwortformate

Die API-Wurzel zeigt die Ressourcen, die dem authentifizierten Schlüssel zur Verfügung stehen. Häufige Gruppen umfassen Produkte, Kategorien, Varianten, Attribute, Kunden, Adressen, Bestellungen, Bestelldetails, Bestellverläufe, Versanddienste und Bestandsverfügbarkeit. Bilder haben eigene Verwaltungsrouten.

Übernehmen Sie keine vermeintlich allgemeingültige Ressourcenliste aus einer anderen Version. Beispielsweise steht supply_orders in der Ressourcenliste von PrestaShop 1.7.8, fehlt aber in der Liste von 9.1.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error --get \
  --data-urlencode 'display=[id,reference,active]' \
  --data-urlencode 'limit=5' --data-urlencode 'output_format=JSON' \
  "$SHOP_URL/api/products"

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error --get \
  --data-urlencode 'display=[id,id_product,id_product_attribute,quantity]' \
  --data-urlencode 'limit=5' --data-urlencode 'output_format=JSON' \
  "$SHOP_URL/api/stock_availables"

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/products?schema=synopsis"

Ohne eine Feldauswahl liefern Ressourcensammlungen häufig IDs und Links. Nutzen Sie ausgewählte Felder für Listen, display=full für den vollständigen beschreibbaren Kontext oder rufen Sie einzelne Ressourcen ab. Prüfen Sie die tatsächliche Antwort vor der Zuordnung zu einem anderen System. Kontrollieren Sie in einem Automatisierungseditor, ob die Antwort eine Sammlung ist und wie daraus einzelne Zielaktionen werden. Wer nur das erste zurückgegebene Objekt zuordnet, kann einen Test mit einer Bestellung bestehen und den Rest der Seite dennoch verlieren.

schema=blank liefert eine Ressourcenvorlage. schema=synopsis ergänzt Pflichtfeldkennzeichnungen, Validierungsformate, Längen und Informationen zum Schreibschutz. Es ist keine Auflistung aller Filter, die die API akzeptiert.

Eckige Klammern gehören zur Abfragesyntax des Webservice. Anführungszeichen um eine URL schützen sie vor der Shell, deaktivieren aber nicht curls eigene URL-Musterauflösung. Verwenden Sie --globoff, kodieren Sie die Klammern oder erstellen Sie Abfragen mit --get --data-urlencode. Siehe das curl-Handbuch.

Filtern, sortieren und paginieren Sie ohne Änderungsverluste

Fügen Sie bei Filtern auf date_add oder date_upd auch date=1 hinzu. Ohne diese Angabe entfernen PrestaShop 1.7.8 und 9.1 diese Felder aus der Liste erlaubter Filter, sodass die Anfrage HTTP 400 zurückgeben kann.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error --get \
  --data-urlencode 'date=1' \
  --data-urlencode 'filter[date_upd]=[2026-10-01 00:00:00,2026-10-02 00:00:00]' \
  --data-urlencode 'sort=[date_upd_ASC,id_ASC]' \
  --data-urlencode 'display=[id,reference,current_state,date_upd]' \
  --data-urlencode 'limit=0,100' --data-urlencode 'output_format=JSON' \
  "$SHOP_URL/api/orders"

Eine vollständige Abfrage neuer Bestellungen

1. Speichern Sie die letzte erfolgreich verarbeitete Bestell-ID dauerhaft, mit einem eigenen Wert je Shop oder Quelle.
2. Rufen Sie Bestellungen mit einer ID über dieser Fortschrittsmarke in aufsteigender Reihenfolge ab. Ein begrenzter Bereich wie filter[id]=[next_id,upper_id] kann einen Durchlauf definieren.
3. Paginieren Sie, bis alle passenden Bestellungen verarbeitet wurden. Eine Stichprobe der letzten fünf ist keine vollständige Abfrage.
4. Gestalten Sie die Aktion im Zielsystem idempotent und dokumentieren Sie den Erfolg.
5. Verschieben Sie die Fortschrittsmarke nur über erfolgreich abgeschlossene Arbeit hinaus oder speichern Sie fehlgeschlagene Elemente dauerhaft, bevor Sie fortfahren.

Verwenden Sie für Aktualisierungen bestehender Bestellungen ein begrenztes Änderungszeitfenster und ein stabiles zusätzliches Sortierkriterium wie die ID. Behalten Sie Überlappungen bei und deduplizieren Sie Datensätze, weil Zeitstempel gleich sein können und gleichzeitige Änderungen Zeilen zwischen Seiten verschieben können. Speichern Sie das Zeitfenster erst nach seinem Abschluss. Verknüpfte Datensätze brauchen eine eigene Änderungsverarbeitung: Die Aktualisierung einer Sendungsverfolgungsnummer beim Bestellversanddienst aktualisiert nicht zwingend den Zeitstempel der übergeordneten Bestellung. Gleichen Sie verknüpfte Daten ab, statt sich auf eine reine Bestellabfrage zu verlassen.

Wählen Sie Intervalle anhand gemessener Latenz, Bestandsumschlag und API-Last. Ein stündlicher Katalogauftrag und ein häufig laufender Bestands-Worker haben unterschiedliche Anforderungen. Es gibt kein einzelnes optimales Intervall für jeden Shop.

Erstellen und aktualisieren Sie vollständige beschreibbare Ressourcen

Verwenden Sie für die Erstellung ein leeres Schema, füllen Sie die Pflichtfelder aus und validieren Sie IDs im Zielshop. Gehen Sie nicht davon aus, dass Kategorie 2, Sprache 1 oder Steuergruppe 1 die beabsichtigte Bedeutung hat. Prüfen Sie bei einem Produkt Namen und suchmaschinenfreundliche URL je Sprache, Standardkategorie, Kategoriezuordnungen, Preis, Steuerkonfiguration, Aktiv-Kennzeichnung und Veröffentlichungsstatus.

Rufen Sie für ein PUT die Ressource ab, vergleichen Sie sie mit ihrer Synopsis, entfernen Sie nicht beschreibbare Felder und erhalten Sie die benötigten beschreibbaren Felder und Zuordnungen. Ändern Sie die vorgesehenen Werte und übermitteln Sie XML mit dem richtigen Content-Type. Ein Produkt-GET kann ein nicht beschreibbares Feld wie manufacturer_name enthalten; das unveränderte Zurücksenden der Antwort kann fehlschlagen.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/products/42" -o product.xml

# Edit and validate product.xml, removing read-only fields first.
curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  --request PUT --header 'Content-Type: application/xml' \
  --data-binary @product.xml "$SHOP_URL/api/products/42"

Verwenden Sie für Schreibbeispiele nur entbehrliche Staging-Datensätze. Im Webservice von PrestaShop 9.1 unterstützt PATCH Teilaktualisierungen. Prüfen Sie vor der Auswahl installierte Version, Schlüsselberechtigungen und Ressource; PrestaShop 1.7.8 unterstützt PATCH nicht.

Für einen Bestandsdatensatz in PrestaShop 9.1, dessen ID Sie geprüft haben, enthalten partielle Nutzdaten dessen Ressourcen-ID:

<prestashop>
  <stock_available>
    <id>89</id>
    <quantity>100</quantity>
  </stock_available>
</prestashop>

Senden Sie dies mit PATCH an /api/stock_availables/89, nicht als verkürztes PUT. Wenn PATCH nicht verfügbar ist, rufen Sie den Bestandsdatensatz per GET ab und erhalten Sie alle benötigten beschreibbaren Werte für PUT. Prüfen Sie in beiden Fällen vor dem Schreiben Produkt, Variante und Shop und lesen Sie die Menge anschließend erneut aus.

Prüfen Sie Transportfehler, HTTP-Status und Antwortinhalt für jedes Element eines Stapels. Wiederholen Sie vorübergehend fehlgeschlagene Lesezugriffe mit wachsenden Wartezeiten, maximaler Verzögerung und einer Begrenzung der Versuche oder Gesamtdauer. Beachten Sie Antworten zur Ratenbegrenzung. Halten Sie ausgeschöpfte Elemente wiederaufnehmbar vor und benachrichtigen Sie den Betreiber. Gleichen Sie nach einem Schreibzugriff mit ungewissem Ausgang das tatsächliche Ergebnis ab, bevor Sie ihn wiederholen. Eine blinde Wiederholung einer Erstellungsanfrage oder Bestandsdifferenz kann ihre Wirkung verdoppeln. Pflegen Sie eine dauerhafte Zuordnung zwischen externen und lokalen Kennungen und erfassen Sie ungeklärte Elemente zur Wiederaufnahme.

Verwenden Sie einen XML-Serialisierer zum Maskieren von Text. CDATA kann Markup enthalten, muss aber seine eigene Abschlusssequenz korrekt behandeln. Senden Sie UTF-8 und ein Wurzelelement prestashop.

Löschen

DELETE ist destruktiv und bietet keinen allgemeinen Papierkorb. Deaktivieren Sie ein Element vorzugsweise, wenn dies den geschäftlichen Bedarf erfüllt. Nur für entbehrliche Datensätze verwendet das Massenlöschen kommagetrennte IDs wie ?id=[42,43,44] bei deaktivierter curl-Musterauflösung. Senkrechte Striche gehören zur Filtersyntax, nicht in diese Löschliste.

Berücksichtigen Sie Bilder, Varianten und Bestandskontext

Bilder

Der Bildupload verwendet Multipart-Daten statt Produkt-XML. Prüfen Sie Bildtypen und Verarbeitungslimits im Zielshop.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  --form 'image=@photo.jpg;type=image/jpeg' \
  "$SHOP_URL/api/images/products/42"

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/images/products/42"

Eine bestimmte Bild-/Typ-Route kann beispielsweise /api/images/products/42/15/large_default lauten, wenn dieser Typ existiert. Das Löschen von Bildern verwendet die Bildressourcenroute und DELETE. Testen Sie Abmessungen, Format, Uploadlimits, Speicher und Vorschaubilderzeugung mit repräsentativen Dateien. Es gibt keine allgemeine Fehlergrenze von 2048 Pixeln oder 5 MB.

Varianten

1. Erstellen Sie die Attributgruppe, etwa Größe, über product_options oder ordnen Sie sie zu.
2. Erstellen Sie ihre Werte, etwa M, über product_option_values oder ordnen Sie sie zu.
3. Erstellen Sie die Variante für das übergeordnete Produkt und verknüpfen Sie die richtigen Wert-IDs.
4. Speichern Sie eine stabile externe Zuordnung und eine eindeutige Referenz für den verkaufbaren Artikel.

Der Preis einer Variante ist eine Auswirkung auf den Grundpreis des Produkts, nicht dessen endgültiger Verkaufspreis. Wenn die Quelle einen endgültigen Preis aus Grundpreis und Auswirkung liefert, berechnen Sie die Auswirkung mit der richtigen Währung und Steuerbasis. Setzen Sie andere Pflichtwerte wie die Mindestmenge anhand von Schema und Geschäftsanforderungen.

Bestandsverfügbarkeit

Suchen Sie stock_availables anhand von Produkt-ID, Varianten-ID und dem richtigen Shop- oder gemeinsam genutzten Shopkontext. Produkte ohne Varianten verwenden die Attribut-ID null. Aktualisieren Sie bei Produkten mit Varianten die vorgesehenen Variantendatensätze; überschreiben Sie nicht die Gesamtsumme auf Produktebene, als repräsentiere sie eine bestimmte Größe oder Farbe.

Erhalten Sie Einstellungen zum Verhalten bei fehlendem Bestand und zur Bestandsabhängigkeit. Legen Sie fest, ob Werte absolute Momentaufnahmen oder Differenzen sind, wer für Reservierungen zuständig ist und wie noch nicht im ERP eingegangene Bestellungen berücksichtigt werden. Eine verzögerte maßgebliche Momentaufnahme kann dennoch eine neuere lokale Bestandsreduzierung überschreiben, wenn diese Vereinbarung falsch ist.

Exportieren Sie Bestellungen und steuern Sie Status-, Tracking- und E-Mail-Auswirkungen

Lesen Sie eine Bestellung über /api/orders/1234 und die zugehörigen Zeilen aus order_details, gefiltert nach id_order. Prüfen Sie die vom empfangenden System benötigten Adressen, Währungen, Steuersummen, Rabatte, Zahlungsinformationen, Rechnungen und Gutschriften.

Ermitteln Sie order_states aus dem tatsächlichen Shop. Kodieren Sie die üblichen numerischen Standard-IDs nicht fest. Statuskennzeichnungen können Bestände, Rechnungs- oder Lieferverarbeitung sowie Benachrichtigungen beeinflussen.

Erstellen Sie für einen bewussten Workflow-Übergang per POST einen order_history-Datensatz. Fordern Sie eine E-Mail ausdrücklich mit sendemail=1 an, wenn dies gewünscht ist; auch die E-Mail-Konfiguration des Status und eine gültige Vorlage sind wichtig.

<prestashop>
  <order_history>
    <id_order>1234</id_order>
    <id_order_state>4</id_order_state>
  </order_history>
</prestashop>

Dies ist ein Staging-Beispiel mit beispielhaften IDs. Sein E-Mail anfordernder Endpunkt ist /api/order_histories?sendemail=1. Ohne dieses Flag ändert OrderHistory::addWs() den Status und speichert den Verlauf, ohne selbst die Status-E-Mail anzufordern. Andere Module, die auf Statusänderungen reagieren, können eigene Auswirkungen haben. Ändern Sie Status nicht bloß, um eine Nachricht erneut zu senden.

Sendungsverfolgungsnummern werden über order_carriers abgebildet. Rufen Sie den richtigen Versanddienstdatensatz ab, erhalten Sie beschreibbare Felder und aktualisieren Sie die Sendungsverfolgungsnummer. Prüfen Sie das resultierende E-Mail- und Versanddienst-Link-Verhalten in Ihrer Version; gehen Sie nicht davon aus, dass jeder API-Schreibzugriff dieselben Nebenwirkungen wie jeder Backoffice-Befehl hat.

Bestellerstellung

Die Methode zur Bestellerstellung des Webservice ruft validateOrder() des angegebenen Zahlungsmoduls auf. Sie umgeht nicht einfach Bestellvalidierung, Bestandsverarbeitung und Hooks. Sie benötigen einen gültigen Warenkorb, Kundenkontext, ein kompatibles Zahlungsmodul und eine Konfiguration des Webservice-Zahlungsstatus einschließlich PS_OS_WS_PAYMENT.

Validieren Sie Beträge, Steuern, Versand, Währung, Zahlungsbedeutung und Duplikatschutz im Staging. Eine importierte Marktplatzzahlung ist keine neue Kartenbelastung. Prüfen Sie alle vom gewählten Weg erzeugten E-Mails und Bestandsauswirkungen. Verwenden Sie einen unterstützten Connector oder einen eigenen Anwendungsvorgang, wenn Sie ausdrückliche Kontrolle über eine komplexere Transaktion benötigen.

Nutzen Sie den PHP-Client und stellen Sie Moduldaten gezielt bereit

Der offizielle PHP-Webservice-Client bietet XML-Hilfsfunktionen für HTTP-Anfragen. Wählen Sie eine mit Ihrer Laufzeitumgebung kompatible Bibliotheksversion, lassen Sie Debugging im Produktivbetrieb deaktiviert und schreiben Sie weder Zugangsdaten noch vollständige API-Antworten mit Kundendaten in Protokolle.

composer require prestashop/prestashop-webservice-lib

Bei einer inkrementellen Abfrage müssen die Client-Optionen auch das Datumsflag enthalten. Dieses Beispiel setzt voraus, dass Client und Zugangsdaten bereits initialisiert sind:

$options = [
    'resource' => 'orders',
    'date' => 1,
    'filter[date_upd]' => '[2026-10-01 00:00:00,2026-10-02 00:00:00]',
    'display' => '[id,reference,current_state,date_upd]',
    'sort' => '[date_upd_ASC,id_ASC]',
    'limit' => '0,100',
];
$xml = $ws->get($options);

Dies ist eine Seite einer begrenzten Abfrage, keine vollständige Synchronisierungsschleife. Wenden Sie die zuvor beschriebene Verarbeitung von Fortschrittsmarke, Seitennavigation und Fehlern an. Weisen Sie bei Bestandsaktualisierungen leere oder mehrdeutige Suchergebnisse zurück, bevor Sie einen zurückgegebenen Datensatz bearbeiten.

Ein Modul kann sein eigenes ObjectModel über addWebserviceResources bereitstellen. Beispielsweise kann eine Artikelressource die Klasse Article des Moduls angeben und DELETE verbieten. Definieren Sie ihre Datenstruktur mit $webserviceParameters, begrenzen Sie die bereitgestellten Felder und prüfen Sie Berechtigungen und Synopsis-Ausgabe. Die Klasse und ihre Validierung müssen tatsächlich existieren; eine Ressourcendeklaration allein implementiert nicht das Geschäftsmodell eines Endpunkts.

Nutzen Sie bei der Implementierung dieser Schicht die Dokumentation zu eigenen Ressourcen und den offiziellen Quellcode des PHP-Clients.

Bewerten Sie die PrestaShop 9 Admin API separat

Die Admin API verwendet OAuth2-Client-Zugangsdaten, bereichsgebundene Autorisierung und JSON über eine Symfony/API-Platform-Implementierung. Die verfügbaren Vorgänge und Berechtigungsbereiche finden Sie unter dem installierten /admin-api/docs und in der Dokumentation der Admin API.

Die Token-Route lautet /admin-api/access_token. Übermitteln Sie die konfigurierten Client-Zugangsdaten und benötigten Berechtigungsbereiche und verwenden Sie dann das zurückgegebene Zugriffstoken als Bearer-Token. Lesen Sie die Ablaufzeit aus der Antwort, statt eine Lebensdauer von einer Stunde fest zu kodieren. Fordern Sie bei Client-Zugangsdaten bei Bedarf ein weiteres Token an; setzen Sie keinen Refresh-Token-Ablauf voraus.

Erstellen Sie einen eigenen Client für die Integration und gewähren Sie ihm die dokumentierten Berechtigungsbereiche. Verwenden Sie keinen klassischen Webservice-Schlüssel wieder und nehmen Sie nicht an, dass eine ähnlich benannte Ressource dieselbe Route oder dieselben Nutzdaten verwendet. Testen Sie den gesamten benötigten Ablauf, bevor Sie die Admin API wählen oder beide APIs kombinieren.

Diagnostizieren Sie Antworten und schützen Sie beide API-Zugangswege

Vergleichen Sie die API-Route mit dem direkten Dispatcher unter Verwendung desselben Schlüssels und derselben Anfrage. Die Beispiele nutzen --fail von curl, wodurch HTTP-Fehlerantwortinhalte unterdrückt werden. Verwenden Sie zur Diagnose --fail-with-body, sofern Ihr curl dies unterstützt, prüfen Sie Status und Antwortinhalt und entfernen Sie sensible Angaben vor der Weitergabe. Kontrollieren Sie die Weiterleitung des Authorization-Headers, Shop-Kontext, Methodenberechtigungen, genaue Ressourcennamen und kodierte Abfrageparameter.

Verwenden Sie getrennte Zugangsdaten, minimale Berechtigungen, HTTPS und ein dokumentiertes Verfahren für Austausch und Widerruf. Beschränken Sie den Zugriff nach Möglichkeit auf bekannte aufrufende Server. Schützen Sie sowohl den Dispatcher als auch die umgeschriebene URL mit passenden Raten- und Zugriffskontrollen.

Protokollieren Sie Vorgangskennungen, Quelle, Richtung, Laufzeiten, Status, Wiederholungen und eine hilfreiche, um sensible Angaben bereinigte Fehlermeldung. Nutzen Sie möglichst Nutzdaten-Hashes oder minimierte Diagnosedaten. Protokollieren Sie niemals Schlüssel, Authorization-Header oder unnötige personenbezogene Informationen. Definieren Sie Zugriff und Aufbewahrung. API-Auditing ist eine sinnvolle Sicherheitskontrolle, keine allgemeingültige gesetzliche Vorgabe zur Aufzeichnung jedes Ressourcenzugriffs.

Planen Sie ERP-Zuständigkeiten, Wiederholungsversuche und Abgleiche

Beginnen Sie mit einer Zuständigkeit je Feld. Eine mögliche Aufteilung sind vom ERP verwaltete Produkt-, Preis- und Bestandsdaten sowie aus PrestaShop nach außen übermittelte Bestellungen und Kundenänderungen. Ein anderes Unternehmen nutzt möglicherweise ein PIM oder WMS für einen Teil dieser Aufgabe. Dokumentieren Sie die Aufteilung ausdrücklich, statt dem ERP immer Vorrang zu unterstellen.

Speichern Sie stabile externe IDs zusammen mit lokalen IDs. Namen sind keine Kennungen, und Referenzen können bearbeitet oder doppelt vergeben werden, sofern Sie ihre Stabilität nicht erzwingen. Ordnen Sie Produkte und Varianten separat zu.

Verwenden Sie einen Idempotenzschlüssel, der Quelle, Entität, Vorgang und stabiles Ereignis oder Version kennzeichnet. Eine Wiederholung darf keine Rechnung oder Bestandsreduzierung verdoppeln, während eine spätere gültige Aktualisierung weiterhin verarbeitet werden muss. Markieren Sie Erfolg erst nach Abschluss und bewahren Sie behebbare Fehler auf.

PrestaShops Standard-Hooks sind lokale Ereignisse, kein allgemeiner dauerhafter Dienst für ausgehende Webhooks. Verwenden Sie actionValidateOrder für das Bestellerstellungsereignis des Zahlungsmoduls. Verwenden Sie actionOrderStatusPostUpdate für ausdrückliche Statusübergänge mit Deduplizierung, nicht als austauschbaren Auslöser für neue Bestellungen.

Bei actionProductUpdate enthalten einige Auslösungen nur id_product. Ermitteln und validieren Sie ein Product, wenn kein Objekt bereitgestellt wird, und beziehen Sie den richtigen Shop- und Sprachkontext ein. Bestandsereignisse benötigen Varianten- und Shopkennungen. Stellen Sie Übermittlungen in eine Warteschlange, statt einen Speichervorgang im Backoffice oder die Kasse durch eine entfernte HTTP-Anfrage zu blockieren.

Signieren oder authentifizieren Sie ausgehende Ereignisse anderweitig, verwenden Sie Zeitlimits und Wiederholungsversuche und planen Sie doppelte oder in falscher Reihenfolge eintreffende Übermittlungen ein. Gleichen Sie Bestände und Bestellungen regelmäßig ab. Melden Sie Abweichungen und nehmen Sie Korrekturen nur nach dokumentierten Zuständigkeits- und Reservierungsregeln vor.

Praxisbeispiel: Die Bestellung erreicht das Lager, die Antwort geht verloren

Angenommen, Ihr Lagersystem ist für verkaufbaren Bestand und Versanddetails maßgeblich, während PrestaShop die Kundenbestellung erstellt. Das Lager übernimmt Bestellungen zur Abwicklung erst in der vereinbarten Zahlungs- oder Freigabephase. Eine neue und eine abwicklungsbereite Bestellung sind unterschiedliche Ereignisse. Dokumentieren Sie die Freigaberegel, statt jede erstellte Bestellung an die Kommissionierung zu senden.

1. Der Worker liest eine freigegebene Bestellung, löst ihre Variantenzuordnungen auf und übermittelt die Lageranfrage mit einem stabilen Schlüssel der Quellbestellung.
2. Das Lager nimmt sie an, doch im Netzwerk tritt eine Zeitüberschreitung auf, bevor der Worker die Annahmereferenz erhält. Lassen Sie das Element ungeklärt. Eine Zeitüberschreitung beweist keine Ablehnung durch das Lager.
3. Suchen Sie den Schlüssel der Quellbestellung im Lager. Existiert er, speichern Sie seine Annahmereferenz. Unterstützt der Empfänger eine wiederholungssichere Übermittlung mit diesem Schlüssel, verwenden Sie das dokumentierte Verfahren. Verlangen Sie andernfalls vor einer erneuten Übermittlung einen Abgleich.
4. Nach dokumentierter Annahme darf eine Wiederholung keinen weiteren Kommissionierungsauftrag erzeugen. Eine spätere Stornierung oder Änderung folgt einem eigenen Vorgang mit Bestätigung, statt als doppelte Bestellung unterdrückt zu werden.
5. Vergleichen Sie freigegebene Quellbestellungen mit angenommenen Lageraufträgen und machen Sie nicht zugeordnete Datensätze sichtbar. Ordnen Sie eingehende Sendungsverfolgungsdaten unabhängig von der ursprünglichen Bestellabfrage zu.

Betrachten Sie nun einen Bestandsstand, der erstellt wurde, bevor diese Bestellung das Lager erreichte. Enthält er noch die vom Shop abgezogene Einheit, kann seine unveränderte Übernahme diese erneut verkaufbar machen. Die Vereinbarung muss offene Reservierungen und die Reihenfolge der Bestandsstände festlegen. Testen Sie diese Überschneidung mit einem verzögerten Export, bevor Sie automatische Bestandskorrekturen erlauben.

Es gibt keine allgemeingültige Cron-URL im Kernsystem. Benennen Sie den tatsächlichen Befehl oder unterstützten Modulendpunkt, dessen Ausführungsdienst und die Fehlerbenachrichtigung. Cron Manager bietet Aufgabenverwaltung für unterstützte Jobs, wie seine Hilfeseite erläutert. Die Planung einer Aufgabe erstellt weder ERP-Konnektor noch Zuordnungs- oder Abstimmungslogik.

Entscheiden Sie, ob ein ERP oder ein kleinerer Export gerechtfertigt ist

Achten Sie auf wiederholte Bestellneuerfassung, unzuverlässige Bestände, langsame Monatsendabgleiche, mehrere Verkaufskanäle und unklare Zuständigkeiten bei der Auftragsabwicklung. Dies sind zu messende Symptome, keine Schwellenwerte für Bestellvolumen oder Teamgröße, die einen ERP-Bedarf beweisen.

1. Erfassen Sie während einer repräsentativen Woche die Zeit für das erneute Eingeben von Bestellungen, Rechnungen, Adressen, Beständen und Sendungsverfolgung.
2. Multiplizieren Sie diese Stunden mit den vollen Personalkosten der ausführenden Personen.
3. Erfassen Sie tatsächliche Korrekturkosten: Rückgaben, doppelte Rechnungen, Erstattungen, Überverkäufe und Abgleichsarbeiten.
4. Prüfen Sie, ob der Prozess eine plausible Steigerung, etwa 50 % mehr Bestellungen, bewältigen kann. Dies ist ein Planungsszenario, kein Branchenschwellenwert.
5. Vergleichen Sie die wiederkehrende Belastung mit Kosten für Implementierung, Lizenzen, Hosting, Wartung, Support und Fehlerbehebung.

Einen Buchhaltungsexport vor dem ERP-Kauf durchspielen

Angenommen, Mitarbeiter kopieren Bestellpositionen in die Buchhaltung und Lieferdetails separat in ein Lagerwerkzeug. Testen Sie den Buchhaltungsexport mit einer Datei, die Ihre Buchhaltung tatsächlich importieren kann. Entfällt dadurch die Buchhaltungseingabe, während Lagereingabe und Erstattungsprüfungen bleiben, zählen Sie nur die tatsächlich eingesparte Arbeit. Rechnen Sie dem Export keine Einsparungen zu, die eine spätere Integration voraussetzen.

Rechnen Sie monatliche Fehler- und Abonnementkosten vor dem Vergleich auf denselben Zeitraum wie das wöchentliche Zeitprotokoll um. Sind laufende Einsparungen positiv, reichen aber nicht aus, um die Einrichtungskosten innerhalb Ihres Planungszeitraums zu decken, begrenzen Sie den Umfang oder behalten Sie den wiederholbaren manuellen Ablauf. Überwiegen wiederholte Bestandsfehler die Kosten, lässt ein reiner Buchhaltungsexport das Hauptproblem ungelöst. Für die Belegzuordnung verwenden Sie den Leitfaden zu Buchhaltung und Rechnungen.

Ein wiederholbarer manueller Dateiexport kann einen Engpass lösen. Ein geplanter Austausch benötigt eine tatsächlich unterstützte Ausführungsumgebung. Es gibt keine feste Grenze von 100 Bestellungen pro Tag zwischen Dateien, Automatisierung und ERP.

Orders CSV List Exporter bietet authentifizierte Backoffice-Exporte und zeitgesteuerte Zustellung per E-Mail oder an einen Server. Prüfen Sie die Zeitplanoptionen der installierten Version, den benötigten Ausführungsdienst und die Empfänger, bevor Sie sich auf unbeaufsichtigte Exporte verlassen.

Informationen zu rechnungsspezifischen Exportfunktionen finden Sie auf der Hilfeseite zu Invoice CSV List Exporter.

Priorisieren Sie das gemessene Problem. Bestellungen an die Buchhaltung, Bestandsaktualisierungen, Sendungsverfolgung und Kundendatensätze haben unterschiedliche Zuordnungen und Risiken. Benennen Sie eine Person, die die Integration nach dem Start überwacht. Eine zuständige Instanz für den Bestand schafft Klarheit, verhindert allein aber keine Überverkäufe.

Vergleichen Sie Zapier, Make und eine direkte Integration

Nutzen Sie eine Automatisierungsplattform, wenn ihre verfügbaren Apps und ihre Fehlerbehandlung zum Ablauf passen. Prüfen Sie das aktuelle App-Verzeichnis, unterstützte Vorgänge und die PrestaShop-Version, statt einen offiziellen Konnektor vorauszusetzen oder ihn wegen des selbst gehosteten Shops auszuschließen. Vergleichen Sie auch die Ziel-App: Make kann den benötigten Shop-Vorgang anbieten, während Zapier das andere Werkzeug besser unterstützt, oder umgekehrt. In Zapier heißt ein Ablauf Zap, in Make Szenario. Testen Sie die gesamte Kette mit Ihren Beispieldaten, statt nach der Anzahl der Apps zu wählen.

Make bietet eine PrestaShop-App. Behandeln Sie ein Watch-Modul nicht als sofortigen Webhook, ohne seinen Auslösertyp zu prüfen. Allgemeiner HTTP-Zugriff ist eine Alternative, wenn eine App die benötigte Ressource nicht bereitstellt.

Zapier zählt Aufgaben nach den Regeln seines Tarifs. Make verwendet inzwischen Credits: Gewöhnliche Vorgänge ohne KI verbrauchen meist einen Credit, während manche Funktionen anders abgerechnet werden. Vergleichen Sie einen repräsentativen Durchlauf einschließlich Suchen, Schleifen, Leerprüfungen, Wiederholungsversuchen und nachgelagerten Aktionen. Verwenden Sie alte vorgangsbasierte Preistabellen nicht als aktuelle Preise.

Bei einer beispielhaften Arbeitslast ergeben 200 Bestellungen pro Tag mal fünf Aktionen mal 30 Tage insgesamt 30.000 Aktionsausführungen. Das sind bei keinem der Dienste automatisch 30.000 abrechenbare Einheiten; wenden Sie die aktuellen Abrechnungsregeln an. Auch ein natives Modul verursacht Hosting-, Wartungs- und möglicherweise Kosten externer Dienste.

Make veröffentlicht zonenspezifische ausgehende IP-Adressen ohne die angenommene Beschränkung auf kostenpflichtige Tarife. Zapier dokumentiert Unterstützung für statische IP-Adressen ab Professional für bestimmte Apps einschließlich Webhooks. Verwenden Sie die aktuelle Liste für die tatsächliche App und Zone.

Belassen Sie buchhalterische Genauigkeit, Bestandsreservierungen und komplexe Varianten in einem Ablauf, der sie korrekt implementiert. Dass ein Werkzeug lokal arbeitet oder einen Hook verwendet, garantiert weder sofortige Übermittlung noch geringere Kosten oder Verfügbarkeit während des Ausfalls eines anderen Anbieters.

Mailchimp Integration synchronisiert die Zielgruppenzugehörigkeit nach Einwilligung und wiederholt fehlgeschlagene Kontaktsynchronisierungen. Eine Synchronisierung von Katalog, Segmenten oder Bestellungen bietet es nicht, wie die Modulhilfe erläutert. Prüfen Sie An- und Abmeldungen, bevor Sie einen weiteren Schreibprozess für die Zielgruppe anbinden. Ein Kundenkonto allein ist kein Auftrag zur Newsletter-Anmeldung.

Erstellen und betreiben Sie eine vollständige erste Automatisierung

Ein einfacher erster Ablauf ist eine Bestellbenachrichtigung oder Berichtszeile. Richten Sie für einen Tabellenversuch die Basic-Authentifizierung in den Zugangsdatenfeldern der Plattform ein, mit dem Webservice-Schlüssel als Benutzername und leerem Passwort. Rufen Sie die benötigten Bestellfelder ab, verarbeiten Sie jede zurückgegebene Bestellung und ordnen Sie Shop, Bestell-ID, Referenz und aktuellen Status der Aktion zum Erstellen einer Tabellenzeile zu. Wenden Sie die folgende Wiederherstellungscheckliste an: Ein Polling-Auslöser, der ein Element als gesehen markiert, belegt nicht den Abschluss seiner Zielaktion. Belassen Sie den Ablauf lesend, während Sie Zugangsdaten, Datenzuordnung und Fehlerbehandlung prüfen. Vermeiden Sie vollständige Kundendetails in einer Teamnachricht, wenn Bestellreferenz und geschützter Backoffice-Link genügen.

1. Wählen Sie einen unterstützten Abfrageauslöser oder Zeitplan. Schedule by Zapier dokumentiert stündliche und längere Auslöser; es ist kein allgemeiner Auslöser für alle 15 Minuten.
2. Prüfen Sie für eine Abfrage Retrieve Poll von Webhooks by Zapier und das von Ihrem Konto unterstützte Intervall oder implementieren Sie eine begrenzte zeitgesteuerte Abfrage.
3. Lesen Sie alle Bestellungen oberhalb einer gespeicherten Fortschrittsmarke in aufsteigender Reihenfolge und paginieren Sie. Ordnen Sie entweder ausgewählte Felder oder ausdrücklich abgerufene vollständige Ressourcen zu.
4. Verarbeiten Sie jede Bestellung mit einem stabilen Deduplizierungsschlüssel. Speichern Sie das Ergebnis im Zielsystem dauerhaft und aktualisieren Sie den Fortschritt erst, wenn die Aktion sicher aufgezeichnet ist.
5. Testen Sie mehr Bestellungen, als auf eine Seite passen, ein doppeltes Ereignis, eine Zeitüberschreitung und eine fehlgeschlagene Zielaktion.
6. Aktivieren Sie Benachrichtigungen bei Fehlern und dokumentieren Sie Verantwortliche, Zugangsdaten, Zeitplan, Zuordnungen und Wiederherstellungsverfahren des Ablaufs.

Für die Push-Übermittlung muss ein Modul das passende Ereignis an den Catch Hook des Empfängers oder eine entsprechende URL senden. Die Installation eines Empfängers veranlasst PrestaShop nicht dazu, ausgehende Ereignisse zu senden. Halten Sie Nachrichten zu Statusänderungen und Bestellerstellungen getrennt.

Validieren Sie bei rückschreibenden Abläufen das XML und verwenden Sie die richtige Ressource, Variante und den richtigen Shop. Ein formularbasierter Automatisierungseditor ersetzt kein Verständnis von PUT, PATCH, Steuer- oder Bestellauswirkungen. Halten Sie bei Schritten über reine Lesezugriffe hinaus die Schreibzugangsdaten getrennt und gewähren Sie sie nur dem Worker, der sie benötigt. Kann der Editor die beschreibbare Ressource nicht erhalten oder einen unklaren Schreibzugriff nicht sicher auflösen, verwenden Sie für diesen Schritt eine gepflegte Brücke oder einen Anwendungsvorgang.

Prüfen Sie den Ausführungsverlauf regelmäßig und nach Shop- oder Modulupdates. Testen Sie Kunden-E-Mails über den vorgesehenen Shop- oder Anbieterversand, statt versehentlich einen zweiten Weg für Bestellbestätigungen einzurichten. Nehmen Sie jeweils einen Ablauf in Betrieb, mit einer klaren Möglichkeit, Arbeit sicher zu stoppen und erneut auszuführen. Bewahren Sie eine erfolgreiche Beispielantwort und das erwartete Zielergebnis für Regressionstests nach Updates auf. Eine geänderte Feldstruktur oder leere Zuordnung kann trotz erfolgreicher HTTP-Anfrage einen unvollständigen Zieldatensatz erzeugen. Prüfungen des E-Mail-Transports erläutert der Leitfaden zur E-Mail-Konfiguration.

Fragen an Ihren Entwickler oder Ihre Agentur

Geben Sie der umsetzenden Person Beispieldatensätze aus Shop und Zielsystem, eine Beschreibung des bisherigen manuellen Ablaufs und das für Mitarbeiter sichtbare Soll-Ergebnis. Nehmen Sie schwierige Fälle aus Ihren eigenen Daten auf: Varianten, Rabatte, unterschiedliche Steuerbehandlung, Erstattungen, geänderte Adressen und gegebenenfalls aufgeteilte Abwicklung. Verlangen Sie schriftliche Antworten auf diese Fragen, bevor Sie den Entwicklungsumfang abnehmen.

• Was passt bereits? Welcher installierte Konnektor, integrierte Export oder unterstützte API-Vorgang lässt sich weiterverwenden und welche genaue Anforderung benötigt Entwicklung?
• Wie sieht die Zuordnung aus? Welche Quellfelder werden zu welchen Zielfeldern, mit welcher Währung, Steuerbasis, Rundung, Sprache und welchem Shop-Kontext? Wer gibt eine abgewiesene oder mehrdeutige Zuordnung frei?
• Wann ist Arbeit freigegeben? Welches Zahlungs- oder Bestellereignis erlaubt den Export, was gilt als Annahme und wie werden spätere Änderungen, Retouren und Stornierungen abgebildet?
• Welche Verarbeitungszeit wird zugesagt? Legen Sie eine akzeptable Gesamtdauer, erwartete Last, Rückstau bei Ausfällen und ein Wiederherstellungsziel fest. Messen Sie den Abschluss im Zielsystem, nicht nur den Abfragezeitplan.
• Wie funktioniert der Support? Wer verantwortet Zugangsdaten, Code, Zuordnungen und Hosting, wer reagiert auf Fehler und wer testet nach Updates von Shop, Modul oder empfangender API erneut? Nehmen Sie Zugang zu Quellen, Anleitungen und Wiederherstellungsaufzeichnungen in die Übergabe auf.

Abnahmenachweise vereinbaren

Änderung proben und Live-Umstellung planen

1. Die isolierte Kopie vorbereiten. Ersetzen Sie kopierte Produktivschlüssel und Empfänger-URLs, deaktivieren Sie produktive zeitgesteuerte Sender und leiten Sie E-Mails an ein Testziel. Prüfen Sie vor dem Erstellen von Probebestellungen jeden ausgehenden Weg, einschließlich vorhandener Module.
2. Den Ausgangsstand festhalten. Dokumentieren Sie Versionen, Einstellungen, Zuordnungen, aktuellen Integrationsfortschritt sowie repräsentative Bestands- und Bestellergebnisse. Belegen Sie, dass sich die relevanten Sicherungen wiederherstellen lassen, und speichern Sie die zur Rückkehr zum bisherigen Weg nötige Konfiguration.
3. Die Abnahmefälle durchspielen. Nutzen Sie entbehrliche Staging-Datensätze und Testkonten auf der Empfängerseite. Beziehen Sie Ihre tatsächliche Kasse, Zahlungsmodule und Mitarbeiteraktionen ein, damit Ereignisse und Nebenwirkungen aus dem später produktiv verwendeten Ablauf stammen.
4. Die Übergabegrenze festlegen. Vereinbaren Sie beim Ersetzen einer Integration das letzte abgeschlossene Element oder Zeitfenster des alten und das erste des neuen Prozesses. Übergeben Sie offene Fehler und Zuordnungen und verhindern Sie, dass beide Worker während der Umstellung dieselben Felder schreiben.
5. Im vereinbarten Zeitfenster umstellen. Speichern Sie den Fortschritt, pausieren Sie den bisherigen Schreibprozess, wenden Sie die geprüfte Konfiguration an und aktivieren Sie den neuen Ausführungsdienst. Prüfen Sie neben erfolgreichen HTTP-Antworten auch Annahme im Zielsystem und Alter der Warteschlange. Benennen Sie die Person, die die Änderung bei fehlgeschlagener Abnahme stoppen kann.
6. Ein Wiederherstellungsprotokoll führen. Bewahren Sie die auf beiden Seiten der Grenze angenommenen Anfragen auf. Ein Rückgängigmachen kann Code oder Einstellungen wiederherstellen, aber angenommene Rechnungen, Kommissionierungen, E-Mails und Bestandsänderungen brauchen einen eigenen Abgleich. Setzen Sie den bisherigen Schreibprozess erst an einer geprüften Grenze fort, die bereits erledigte Arbeit berücksichtigt.

Vergleichen Sie nach der Umstellung für denselben Zeitraum freigegebene Quellvorgänge, angenommene Zieldatensätze und ungeklärte Fehler. Prüfen Sie das älteste unverarbeitete Element und den letzten abgeschlossenen Abgleich, nicht nur den letzten geplanten Start. Vereinbaren Sie, wer eine Warnung bearbeitet und wann sie eskaliert wird. Ein grüner Zeitplaner allein belegt keinen abgeschlossenen Geschäftsaustausch.

Häufige Fragen von Shopbetreibern

Muss ich mein vorhandenes ERP ersetzen?

Prüfen Sie zuerst, ob es die vereinbarten Daten über einen unterstützten Konnektor, Dateien oder eine API empfangen und zurückgeben kann. Eine fehlende Verbindung kann eine kleine Brücke rechtfertigen. Ein Wechsel des Backoffice-Systems benötigt eine gesonderte Wirtschaftlichkeitsbegründung.

Kann ich das ohne Entwickler erledigen?

Ein gelegentlicher Export oder eine rein lesende Benachrichtigung lässt sich möglicherweise mit Ihren vorhandenen Werkzeugen umsetzen. Prüfen Sie vor Schreibzugriffen durch einen Editor, ob Sie seine Fehler erklären und beheben können. Nutzen Sie die Wegauswahl für die erste Entscheidung und die Abnahmetabelle zur Bewertung des Ergebnisses.

Behebt ein Theme-Wechsel eine Integration?

Verfolgen Sie zuerst das fehlende Feld oder Ereignis. Ein Fehler in der API-Zuordnung braucht eine Datenkorrektur. Eine angepasste Kasse, die die Bestellerstellung verändert, muss mit der Integration getestet werden. Erhalten Sie deshalb das relevante Theme- und Kassenverhalten in der Probekopie.

Kann ich zum Testen eine echte Bestellung ans Lager senden?

Vereinbaren Sie zuerst ein Testkonto oder ein kontrolliertes Verfahren mit dem Empfänger. Eine kopierte Bestellung kann weiterhin eine echte Kommissionierung, Rechnung oder Kundenmitteilung auslösen, wenn der Staging-Sender produktive Zugangsdaten verwendet.

Macht das Abschalten des Moduls seine Sendungen rückgängig?

Nein. Ermitteln Sie mit dem Wiederherstellungsprotokoll aus der Umstellungscheckliste bereits angenommene Vorgänge. Veranlassen Sie erforderliche Stornierungen oder Korrekturen im jeweils verantwortlichen System, bevor Sie einen anderen Schreibprozess fortsetzen.

Was sollte ich bei der Übergabe erhalten?

Die vereinbarten Zuordnungen, getesteten Fälle, Anleitungen für Ausführungsdienst und Zugangsdaten, Zuständigkeit für Warnungen und ein vorgeführtes Stopp- und Wiederherstellungsverfahren. Klären Sie Verantwortung und Kosten künftiger Kompatibilitätsarbeiten getrennt von der Behebung von Mängeln im gelieferten Umfang.