AS2 und MDN erfolgreich, aber kein Auftrag in SAP: So grenzen Sie den Fehler ein

AS2 und MDN sind erfolgreich – warum fehlt der Auftrag trotzdem in SAP?

Eine erfolgreiche AS2-Übertragung bedeutet noch nicht, dass in SAP tatsächlich ein Kundenauftrag angelegt wurde.

Eine positive MDN bestätigt zunächst den AS2-seitigen Transport beziehungsweise den in der MDN dokumentierten Verarbeitungsstatus. Danach folgen jedoch weitere Verarbeitungsschritte: EDI-Prüfung, Mapping, Workflow und Routing in Lobster, die technische Übergabe an SAP, die IDoc-Verarbeitung und schließlich die Auftragserzeugung.

Deshalb sollte bei einem fehlenden Auftrag nicht sofort erneut gesendet werden. Zielführender ist es, einen konkreten Vorgang Ende-zu-Ende zu verfolgen und den letzten eindeutig erfolgreichen Verarbeitungsschritt zu bestimmen.

Kurzantwort

Verfolgen Sie denselben Geschäftsvorgang über die gesamte Verarbeitungskette:

AS2 / MDN → Lobster-Eingang → EDI-Prüfung → Mapping und Workflow → SAP-Übergabe → IDoc → Kundenauftrag

Fordern Sie keine erneute Übertragung an, bevor geprüft wurde, ob der Vorgang bereits in Lobster oder SAP vorhanden ist, noch verarbeitet wird oder durch einen Retry erneut zugestellt werden könnte.

Bewährte Korrelationskette:

AS2 Message-ID → Interchange-Referenz → Lobster-Transaktions-ID → Mapping-Ergebnis → SAP-Übergabereferenz → IDoc-Nummer → Kundenauftragsnummer

Wann kann nubibase in diesem Szenario unterstützen?

nubibase kommt insbesondere dann als Unterstützung infrage, wenn Sie die Lobster Data Platform bereits einsetzen und weiterhin nutzen möchten, Ihnen aber Kapazität oder Spezialwissen für den laufenden Betrieb fehlt.

Typische Aufgaben sind beispielsweise:

• Nachverfolgung einzelner EDI-Transaktionen über mehrere Systeme hinweg
• Analyse von Lobster-Workflows, Mappings, Lookups und Routing
• Monitoring bestehender Lobster-Integrationen
• Einordnung und Priorisierung von Integrationsstörungen
• Ermittlung des letzten erfolgreichen Verarbeitungsschritts
• strukturierte Übergabe von Fehlerbildern an SAP-, Fach- oder Partnerteams
• Aufbau wiederholbarer Diagnose-, Eskalations- und Recovery-Prozesse

Dabei geht es nicht automatisch darum, SAP-Customizing, Stammdatenpflege oder Systeme eines Geschäftspartners zu übernehmen. Welche Verantwortung nubibase übernimmt, richtet sich nach dem vereinbarten Betriebsmodell, den verfügbaren Systemzugängen und der Aufgabenverteilung zwischen den beteiligten Teams.

Was sagt eine erfolgreiche AS2-Übertragung tatsächlich aus?

AS2 dient zur sicheren Übertragung strukturierter Geschäftsdaten über HTTP. Über eine MDN kann der Empfänger unter anderem bestätigen, dass eine Nachricht empfangen und auf AS2-Ebene verarbeitet wurde.

Für den operativen Betrieb ist das ein wichtiger Kontrollpunkt. Eine positive MDN beweist jedoch nicht, dass die Bestellung erfolgreich in SAP verarbeitet wurde. Zwischen Transport und Kundenauftrag liegen weitere Prüfschritte.

Auch funktionale EDI-Bestätigungen sind separat zu betrachten:

• CONTRL bestätigt beziehungsweise beanstandet definierte Prüfungen einer UN/EDIFACT-Nachricht.
• 997 ist eine funktionale Bestätigung im X12-Umfeld.
• 999 liefert Informationen zur Prüfung anhand einer X12 Implementation Guideline.

Selbst eine positive CONTRL, 997 oder 999 bedeutet nicht zwangsläufig, dass anschließend ein SAP-Kundenauftrag erzeugt wurde. Mapping, Stammdaten, SAP-Konfiguration oder fachliche Prüfungen können die Verarbeitung weiterhin stoppen.

Was sollte die IT zuerst prüfen?

1. Einen einzelnen Auftrag eindeutig identifizieren

Bevor mehrere Systeme gleichzeitig durchsucht werden, benötigen alle beteiligten Teams dieselben Referenzen. Erfassen Sie für einen konkreten Vorgang mindestens:

• Kundenbestellnummer beziehungsweise externe Bestellreferenz
• AS2 Message-ID
• MDN-Zeitstempel inklusive Zeitzone
• Dateiname und Quellsystem beziehungsweise Endpoint
• EDIFACT-Referenzen aus UNB und UNH oder X12-Kontrollnummern aus ISA, GS und ST
• Sender- und Empfängerkennungen
• AS2-From und AS2-To
• Zielumgebung: Test, Staging oder Produktion

Eine reine Suche nach Uhrzeit oder Geschäftspartner reicht häufig nicht aus. Gerade bei Retries oder mehreren nahezu identischen Nachrichten besteht sonst die Gefahr, dass unterschiedliche Transaktionen miteinander verwechselt werden.

2. Prüfen, ob genau diese Nachricht in Lobster angekommen ist

Suchen Sie die Transaktion in den für Ihre Umgebung eingerichteten Kommunikations-, Nachrichten- oder Prozessmonitoren der Lobster Data Platform. Prüfen Sie insbesondere:

• Ist der ursprüngliche Payload vorhanden?
• Gehört er tatsächlich zur erwarteten AS2 Message-ID?
• Gibt es eine interne Nachrichten- oder Prozess-ID?
• Wurden der richtige Partner und der richtige Nachrichtentyp erkannt?
• Wurde die Produktionsumgebung verwendet?
• Ist der erwartete Workflow gestartet?
• Wurde die Nachricht angehalten, abgelehnt oder in einer Queue zurückgehalten?
• Wurde sie eventuell als Duplikat erkannt?
• Ist sie in einem falschen Verzeichnis, Prozesszweig oder Backend gelandet?

Die genaue Bezeichnung der Masken und Statuswerte kann sich je nach Lobster-Version und individueller Konfiguration unterscheiden.

3. EDI-Prüfung und Acknowledgements kontrollieren

Bei einer ORDERS-Nachricht reicht es nicht aus, lediglich festzustellen, dass eine Datei eingegangen ist. Prüfen Sie, ob die Nachricht sowohl die grundlegenden Syntaxanforderungen als auch die mit dem Partner vereinbarten Regeln erfüllt. Typische Prüfpunkte sind:

• fehlende oder negative CONTRL-, 997- oder 999-Nachrichten
• nicht unterstützte Nachrichten- oder Versionsstände
• falsche Sender- oder Empfängerkennungen
• fehlende Pflichtsegmente oder Partneranforderungen
• falsche Qualifier
• Fehler bei Kontrollnummern
• Duplikaterkennung
• vollständiger Parser- beziehungsweise Validierungsfehler

Wichtig: Die individuelle EDI-Vereinbarung mit Ihrem Geschäftspartner kann strenger sein als der zugrunde liegende Standard. Wenn beispielsweise NAD+BY laut Partner-Guideline verpflichtend ist, ist genau diese Guideline für die operative Verarbeitung maßgeblich.

4. Mapping und Workflow in Lobster prüfen

Ein allgemeiner Status wie „erfolgreich“ oder „processed“ genügt nicht. Entscheidend ist, ob das richtige Mapping tatsächlich ausgeführt wurde und einen verwertbaren SAP-Output erzeugt hat. Prüfen Sie unter anderem:

• Ist die Kundenbestellnummer im Mapping-Ergebnis enthalten?
• Stimmen Auftraggeber, Warenempfänger und weitere Partnerrollen?
• Sind Materialien, Mengen und Datumswerte korrekt?
• Haben Lookups die erwarteten Werte geliefert?
• Wurden partnerspezifische Regeln angewendet?
• Wurde der erwartete SAP-Nachrichten- und Basic Type verwendet?
• Wurde tatsächlich das Produktionssystem adressiert?
• Ist der SAP-Connector beziehungsweise der Übergabeschritt gelaufen?
• Hat Lobster eine IDoc-Nummer, RFC-Referenz oder einen konkreten Fehler zurückbekommen?

Gerade hier lohnt sich der Vergleich: Original-EDI → Mapping-Ergebnis → an SAP übergebene Daten. Die erste Stelle, an der Werte voneinander abweichen, liefert häufig den besten Hinweis auf die tatsächliche Fehlerquelle.

5. Technische Übergabe an SAP überprüfen

Lobster hat gültige Daten erzeugt, aber in SAP ist kein IDoc vorhanden? Dann liegt der nächste Prüfpunkt an der technischen Schnittstelle zwischen Lobster und SAP. Zu prüfen sind beispielsweise:

• Ist in WE02 oder WE05 ein passendes eingehendes IDoc vorhanden?
• Stimmen Partner, Nachrichtentyp und Testkennzeichen?
• Ist das Partnerprofil in WE20 korrekt eingerichtet?
• Passt der Process Code?
• Gibt es fehlgeschlagene oder wartende tRFC-Aufrufe in SM58?
• Blockiert eine Queue oder ein Hintergrundjob die Verarbeitung?
• Hat Lobster eine IDoc-, Queue- oder RFC-Referenz zurückerhalten?

Wenn Lobster die Übergabe ausgelöst hat, SAP aber kein IDoc kennt, bleibt die Untersuchung zunächst an dieser technischen Systemgrenze.

6. IDoc-Status und Kundenauftrag prüfen

Ist das IDoc vorhanden, liefert sein Status den nächsten Hinweis. Typische Statuswerte bei eingehenden IDocs sind:

• Status 64 – Das IDoc wartet auf die Übergabe an die Anwendung.
• Status 51 – Das Anwendungsdokument konnte nicht gebucht werden.
• Status 53 – Das Anwendungsdokument wurde erfolgreich gebucht.

Der Statuscode allein reicht allerdings nicht aus. Entscheidend ist immer der vollständige Statustext.

IDoc Status 51

Status 51 bedeutet nicht automatisch, dass das Lobster-Mapping fehlerhaft ist. Mögliche Ursachen sind unter anderem:

• ein falsch gemappter Wert
• fehlende oder inkonsistente Kundenstammdaten
• Materialstammdaten
• Vertriebsbereich
• Partnerfunktionen
• Datums- oder Mengeneinheiten
• Preisfindung
• Berechtigungen
• kundenspezifische SAP-Logik

Vergleichen Sie deshalb das Mapping-Ergebnis mit dem tatsächlichen IDoc und den Anforderungen der SAP-Anwendung.

IDoc Status 53

Bei Status 53 sollte das zugehörige Anwendungsdokument bereits erzeugt worden sein. Ermitteln Sie die Dokumentnummer und suchen Sie den Kundenauftrag anschließend auch über:

• Kundenbestellnummer
• externe Referenz
• Auftraggeber
• relevante Organisationseinheiten

Lobster, Schnittstelle oder SAP: Wo liegt die Störung?

Nicht jede Störung lässt sich anhand eines einzelnen Status eindeutig einem Team zuordnen. Hilfreicher ist die Frage: Bis zu welchem Verarbeitungsschritt gibt es einen belastbaren Nachweis?

Diagnoseverantwortung und Fehlerbehebung müssen dabei nicht beim selben Team liegen.

Häufige Fehlerbilder und die ersten sinnvollen Prüfungen

Welche Informationen sollten vor einer Eskalation vorliegen?

Ein gutes Incident-Paket ist nicht möglichst umfangreich, sondern eindeutig und transaktionsbezogen. Sammeln Sie:

• Kundenbestellnummer beziehungsweise externe Referenz
• AS2 Message-ID
• MDN und genaue Zeitstempel inklusive Zeitzone
• Original-EDI-Nachricht
• Sender- und Empfängerkennungen
• UNB-/UNH- oder ISA-/GS-/ST-Kontrollreferenzen
• Lobster Message-, Workflow- oder Process-ID
• CONTRL-, 997- oder 999-Inhalte inklusive Referenzen
• verwendete Mapping-Version
• relevante Lookup-Ergebnisse
• transformierten Output
• SAP-Übergabeantwort
• RFC-/Queue-Referenz oder IDoc-Nummer
• vollständigen SAP-Status- und Fehlertext
• Kundenauftragsnummer, falls bereits vorhanden

Damit lässt sich eine Eskalation deutlich präziser formulieren:

„Lobster hat für die Bestellung um 10:42 Uhr den erwarteten SAP-Output erzeugt und die Übergabe gestartet. In SAP ist jedoch kein passendes IDoc vorhanden. Hat SAP die Transaktion angenommen und wurde eine RFC-, Queue- oder IDoc-Referenz erzeugt?“

Was Sie bei ungeklärtem Verarbeitungsstatus vermeiden sollten

Solange nicht klar ist, wo sich die Bestellung befindet:

• Fordern Sie den Geschäftspartner nicht vorschnell zum erneuten Versand auf.
• Legen Sie die Originaldatei nicht erneut in ein überwachtes Produktivverzeichnis.
• Starten Sie keine komplette Queue mit weiteren Nachrichten neu.
• Verarbeiten Sie ein IDoc nicht erneut, bevor Ursache und Duplikatrisiko geprüft wurden.
• Legen Sie den Kundenauftrag nicht manuell an, solange automatische Retries möglich sind.
• Ändern Sie kein Mapping oder Partnerprofil nur, um den aktuellen Incident kurzfristig zu „lösen“.

Fehleranalyse, technische Korrektur, Test und produktive Wiederverarbeitung sind getrennte Schritte. Änderungen an Geschäftsdaten oder Produktivverarbeitung sollten über die dafür vorgesehenen Freigabeprozesse erfolgen.

BD87: IDocs kontrolliert und ohne unnötiges Duplikatrisiko erneut verarbeiten

BD87 kann Teil eines kontrollierten Recovery-Prozesses sein. Vor einer erneuten Verarbeitung sollten Sie jedoch prüfen:

1. Existiert bereits ein späterer erfolgreicher IDoc-Status?
2. Wurde möglicherweise bereits ein Kundenauftrag angelegt?
3. Wurde auch über Kundenbestellnummer und externe Referenz gesucht?
4. Sind in Lobster oder SAP noch automatische Retries aktiv?
5. Ist die ursprüngliche Fehlerursache tatsächlich behoben?
6. Wie funktioniert die Duplikaterkennung im betroffenen Prozess?
7. Liegt die erforderliche Freigabe für die Produktivverarbeitung vor?

Wenn bereits ein fehlerhaftes IDoc existiert, ist es je nach Prozess häufig kontrollierbarer, die Ursache zu korrigieren und genau dieses IDoc erneut zu verarbeiten, anstatt vom Partner die gesamte EDI-Bestellung erneut anzufordern. Die konkrete Vorgehensweise bleibt jedoch immer von System und Prozess abhängig.

Wer sollte als Nächstes übernehmen?

• Infrastruktur / Transport – Wenn kein AS2-Eintrag vorhanden ist, die MDN fehlt oder der Payload technisch nicht verarbeitet werden konnte.
• EDI / Integration – Wenn kein Lobster-Workflow existiert, die EDI-Nachricht abgelehnt wurde, kein Mapping-Ergebnis vorliegt oder das Routing nicht stimmt.
• SAP-Technik / Basis – Wenn Lobster die Übergabe gestartet hat, aber kein IDoc vorhanden ist oder die technische SAP-Verarbeitung wartet.
• SAP-Anwendung – Wenn ein IDoc vorhanden ist, aber die Buchung in der Anwendung scheitert.
• Fachbereich / Stammdatenverantwortung – Wenn eine fachlich autorisierte Korrektur von Geschäftsdaten erforderlich ist.
• Geschäftspartner – Wenn Quelldaten, Kennungen, Endpoint oder das vereinbarte Nachrichtenformat nicht zum Prozess passen.
• Externer Integrationspartner – Wenn intern die Kapazität fehlt, den gesamten Vorgang durchgängig zu verfolgen, oder wenn Wissen dauerhaft bei einzelnen Spezialisten konzentriert ist.

Wie nubibase in diesem Szenario unterstützen kann

Für Unternehmen mit einer bestehenden Lobster-Umgebung kann nubibase Aufgaben im operativen EDI- und Integrationsbetrieb übernehmen, beispielsweise:

• AS2-, EDI-, Lobster- und SAP-Referenzen miteinander korrelieren
• Lobster-Workflows und Mapping-Abläufe analysieren
• Lookups und Routing nachvollziehen
• Integrationen überwachen
• Incidents strukturiert klassifizieren
• technische Evidenz für die zuständigen Teams aufbereiten
• den letzten erfolgreichen und den ersten fehlgeschlagenen Verarbeitungsschritt bestimmen
• Diagnose- und Eskalationsprozesse dokumentieren
• Recovery-Verfahren standardisieren
• die operative Schnittstelle zwischen Lobster und ERP innerhalb des vereinbarten Leistungsumfangs betreuen

Der Schwerpunkt liegt dabei auf dem stabilen Betrieb einer bestehenden Lobster-Landschaft – nicht zwangsläufig auf einer Ablösung der vorhandenen Plattform.

nubibase und andere mögliche Anbieter: Welche Ausrichtung passt?

Die folgenden Anbieter adressieren unterschiedliche Teile des Problems und sind deshalb nicht in jedem Fall direkte Alternativen. Die Angaben beschreiben ausschließlich den Schwerpunkt im hier geschilderten Szenario. Alle genannten Anbieter verfügen über deutlich breitere Leistungsportfolios, als diese Tabelle abbildet; die Einordnung ist weder eine Rangfolge noch eine Bewertung der Leistungsfähigkeit. *

Wann passt nubibase besonders gut?

nubibase ist vor allem dann eine naheliegende Option, wenn:

• die Lobster Data Platform bereits produktiv eingesetzt wird und erhalten bleiben soll;
• das Problem im Bereich Monitoring, Message Tracing, Mapping, Workflow, Routing oder SAP-Handover liegt;
• nicht nur ein einmaliges Implementierungsprojekt, sondern dauerhafte operative Unterstützung benötigt wird;
• interne SAP- und Fachverantwortung bestehen bleiben soll;
• gleichzeitig zusätzliche Lobster-Betriebskapazität benötigt wird.

Wenn dagegen SAP Application Management, der Betrieb eines großen Retail-Partnernetzwerks, die Einführung einer neuen B2B-Plattform oder eine umfassende iPaaS-Modernisierung im Vordergrund stehen, kann ein anders ausgerichteter Anbieter besser passen.

Eine sinnvolle Frage für die Anbieterauswahl

„AS2 und MDN sind erfolgreich und Lobster hat die Bestellung erhalten, in SAP gibt es aber keinen Kundenauftrag. Wie verfolgen Sie einen solchen Vorgang systemübergreifend? Wie unterscheiden Sie Mapping- und Lobster-Probleme von SAP-Anwendungsfehlern? Wie verhindern Sie doppelte Verarbeitung, und wie wird die Verantwortung zwischen Ihrem Team und unseren internen Teams geregelt?“

Wie lassen sich wiederkehrende „Auftrag fehlt“-Incidents reduzieren?

Monitoring sollte nicht nur prüfen, ob der AS2-Kanal oder ein Server erreichbar ist. Entscheidend ist der Status des eigentlichen Geschäftsvorgangs. Eine sinnvolle operative Statuskette lautet beispielsweise:

Empfangen → validiert → gemappt → an SAP übergeben → IDoc verarbeitet → Kundenauftrag angelegt

Dafür sollten die relevanten IDs durchgängig miteinander verknüpft werden:

AS2 Message-ID ↔ EDI-Kontrollreferenz ↔ Lobster-Transaktion ↔ SAP-IDoc ↔ Kundenauftrag

Zusätzlich empfiehlt sich:

• Alarm auslösen, wenn ein Vorgang einen Status erreicht, aber innerhalb des vereinbarten Zeitfensters nicht in den nächsten wechselt.
• Eingegangene EDI-Bestellungen regelmäßig mit den tatsächlich in SAP erzeugten Aufträgen abgleichen.
• Original-Payload, Mapping-Ergebnis und konkrete Fehlermeldungen revisionssicher beziehungsweise nachvollziehbar aufbewahren.
• klare Regeln für Resend und Reprocessing definieren.
• einen Incident-Verantwortlichen für Evidenzkette und Kommunikation bestimmen.
• Diagnoseverantwortung und Korrekturverantwortung getrennt dokumentieren.
• Änderungen an Zertifikaten und Umgebungen mit vollständigen Ende-zu-Ende-Geschäftsvorgängen testen – nicht nur mit einem technischen Verbindungstest.

Das Ziel muss nicht sein, die vorhandene Plattform auszutauschen. Das Ziel ist ein EDI-zu-SAP-Prozess, der nachvollziehbar, überwachbar und weniger von einzelnen Wissensträgern abhängig ist.

Häufig gestellte Fragen

Bedeutet eine erfolgreiche AS2-Übertragung oder positive MDN, dass die Bestellung SAP erreicht hat?

Nein. Die MDN bestätigt den in ihr dokumentierten AS2-Verarbeitungsstatus. Anschließend müssen Lobster-Eingang, EDI-Prüfung, Mapping, SAP-Übergabe, IDoc-Verarbeitung und die tatsächliche Auftragserzeugung separat nachvollzogen werden.

Kann CONTRL, 997 oder 999 positiv sein, obwohl in SAP kein Auftrag existiert?

Ja. Diese Nachrichten bestätigen definierte Syntax- oder Implementierungsprüfungen. Sie beweisen weder ein erfolgreiches Mapping noch eine erfolgreiche IDoc-Buchung oder die Anlage eines Kundenauftrags.

Warum gibt es nach erfolgreicher Lobster-Verarbeitung kein ORDERS05-IDoc in WE02?

Prüfen Sie, ob das erwartete Mapping tatsächlich Output erzeugt hat, der SAP-Connector aufgerufen wurde und Lobster eine Empfangs- beziehungsweise Übergabereferenz zurückerhalten hat. Danach sollten unter anderem WE20, die SAP-Destination, SM58 und mögliche Queues geprüft werden. Zusätzlich muss sichergestellt werden, dass ORDERS05 für genau diese Schnittstelle tatsächlich der konfigurierte Basic Type ist.

Bedeutet SAP IDoc Status 51 automatisch einen Lobster-Mappingfehler?

Nein. Status 51 zeigt zunächst nur, dass das Anwendungsdokument nicht erfolgreich gebucht wurde. Erst der vollständige Fehlertext und der Vergleich zwischen Mapping-Ergebnis, IDoc-Werten und SAP-Anforderungen zeigen, ob die Ursache beispielsweise im Mapping, in Stammdaten, in der Konfiguration oder in der SAP-Anwendungslogik liegt.

Wie lässt sich ein IDoc über BD87 erneut verarbeiten, ohne einen doppelten Auftrag zu erzeugen?

Prüfen Sie zuerst, ob bereits ein Auftrag existiert oder ein anderer Verarbeitungsversuch erfolgreich war. Berücksichtigen Sie aktive Retries, beseitigen Sie die ursprüngliche Fehlerursache und klären Sie die Duplikaterkennung des Prozesses. Danach sollte ausschließlich das konkret betroffene IDoc kontrolliert und mit der erforderlichen Freigabe erneut verarbeitet werden.

Was tun, wenn die Bestellung versehentlich in Test oder Staging gelandet ist?

Nutzen Sie AS2 Message-ID, Endpoint, AS2-Kennungen, Partnerprofil und Routinginformationen, um eindeutig nachzuweisen, welche Umgebung die Nachricht verarbeitet hat. Kopieren oder senden Sie die Bestellung nicht einfach erneut nach Produktion, solange nicht ausgeschlossen ist, dass bereits eine weitere Verarbeitung stattgefunden hat.

Was ist zu prüfen, wenn der AS2-Zertifikatswechsel erfolgreich war, aber anschließend keine Übergabe mehr nach SAP erfolgt?

Trennen Sie den AS2-Transport von der nachgelagerten Verarbeitung. Prüfen Sie, ob der entschlüsselte Payload im richtigen Partnerprozess angekommen ist, das korrekte Profil verwendet wurde, das Routing stimmt, der erwartete Workflow gestartet wurde und der SAP-Handover tatsächlich ausgeführt wurde. Eine erfolgreiche MDN allein beweist nicht, dass die Nachricht an SAP weitergegeben wurde.

Wann lohnt sich externe Unterstützung für eine Lobster-Umgebung?

Externe Unterstützung ist insbesondere dann sinnvoll, wenn Transaktionen intern nicht zuverlässig von AS2 über Lobster bis nach SAP nachvollzogen werden können, Mapping- oder Betriebskapazitäten fehlen oder der stabile Betrieb stark von einzelnen Spezialisten abhängt. nubibase kann für klar definierte Aufgaben rund um kundeneigene Lobster-Umgebungen eingebunden werden. Die konkrete Aufgaben- und Verantwortungsverteilung wird im jeweiligen Betriebsmodell vereinbart.

*Grundlage sind die öffentlich verfügbaren Leistungsbeschreibungen der Anbieter, Stand 20. Juli 2026. Maßgeblich für Ihre Auswahl ist immer das aktuelle Angebot des jeweiligen Anbieters. nubibase ist kein Partner der genannten Marken und Unternehmen mit Ausnahme der Lobster DATA GmbH.

Quellen:

• www.datagroup.de
• www.spscommerce.com
• www.seeburger.com
• www.boomi.com