Seit dem 15. März 2026 dürfen öffentlich vertrauenswürdige TLS-Zertifikate höchstens 200 Tage gültig sein (CA/Browser Forum, Ballot SC-081v3). Bis zum Vortag waren es 398 Tage (CA/Browser Forum, Baseline Requirements). Am 15. März 2027 sinkt die Obergrenze auf 100 Tage, am 15. März 2029 auf 47 Tage (CA/Browser Forum, Ballot SC-081v3). Für den Online-Shop ist das meist ein gelöstes Problem: Webserver und Hoster erneuern ihre Zertifikate seit Jahren automatisch. Für die Schnittstellen dahinter gilt das seltener. Dort stecken Zertifikate in Truststores, in Middleware-Konfigurationen, in Client-Zertifikaten für mTLS und in Altsystemen, die über Jahre unverändert bleiben. Dieser Beitrag beschreibt, wie aus dem Zertifikatslebenszyklus eine Betriebsdisziplin wird – und wie sich Schnittstellen zwischen ERP und Shop selbst erneuern, statt an einer jährlichen Kalendererinnerung zu hängen.
Das Wichtigste in Kürze
- Seit dem 15. März 2026 dürfen öffentlich vertrauenswürdige TLS-Zertifikate statt 398 nur noch 200 Tage laufen; 2027 folgen 100 Tage, 2029 47 Tage und eine Wiederverwendung der Domainprüfung von 10 Tagen (CA/Browser Forum, Ballot SC-081v3).
- In einer Shop-ERP-Landschaft brechen vier Stellen: das Serverzertifikat der ERP-API, das Client-Zertifikat bei mTLS, veraltete Truststores und CA-Bundles sowie Certificate Pinning im Konnektor. Diese vier Punkte liegen meist bei vier verschiedenen Zuständigen.
- Ein abgelaufenes Zertifikat fällt an der Schnittstelle still aus: Der TLS-Handshake scheitert, bevor eine HTTP-Anfrage entsteht (IETF RFC 8446). Shop und Kasse laufen weiter, Aufträge stauen in Retry-Queues, nach der Reparatur drohen Dubletten.
- Automatisiert wird über ACME nach IETF RFC 8555 für öffentliche Endpunkte und eine interne CA für mTLS, mit Reload statt Neustart und einem Überlappungsfenster von rund 30 Tagen (Projekterfahrung). RFC 9773 streut die Erneuerungszeitpunkte.
- Das Zertifikatsinventar führt je Verbindung Endpunkt und Zweck, Zertifikatstyp, Aussteller, Ablaufdatum, eine benannte Rolle, den Erneuerungspfad und einen Testendpunkt (NIST SP 1800-16). Die aktive Prüfung warnt bei 30 und eskaliert bei 7 Tagen Restlaufzeit.
- Außerhalb der eigenen Automatisierung liegen Truststores in Kundensystemen, Java-Keystores, CA-Bundles in Skript-Konnektoren und Kopien in Container-Abbildern. Das BSI empfiehlt TLS 1.3 bis 2032, TLS 1.2 nur bis Ende 2031 (BSI TR-02102-2).
Was sich zum 15. März 2026 konkret geändert hat
Das CA/Browser Forum ist das Gremium, in dem Zertifizierungsstellen und Browser-Hersteller die Baseline Requirements für öffentlich vertrauenswürdige Zertifikate festlegen. Mit Ballot SC-081v3 wurde ein Stufenplan beschlossen, der die maximale Laufzeit von Serverzertifikaten in drei Schritten absenkt und parallel die Wiederverwendung der Domainprüfung verkürzt (CA/Browser Forum, Ballot SC-081v3). Der erste Schritt ist seit dem 15. März 2026 in Kraft. Wer heute ein Zertifikat von einer öffentlichen Zertifizierungsstelle bezieht, erhält es mit maximal 200 Tagen Laufzeit (CA/Browser Forum, Ballot SC-081v3) – unabhängig davon, was im Bestellprozess früher möglich war.
Die zweite Stufe folgt am 15. März 2027 mit 100 Tagen, die dritte am 15. März 2029 mit 47 Tagen (CA/Browser Forum, Ballot SC-081v3). Gemessen an den 398 Tagen, die bis zum 14. März 2026 galten (CA/Browser Forum, Baseline Requirements), ist das eine Verkürzung um den Faktor achteinhalb. Für einen einzelnen Webserver ist das eine Konfigurationsfrage. Für eine gewachsene Integrationslandschaft mit ERP, Middleware, Marktplatzanbindungen und Logistikpartnern ist es eine Prozessfrage.
| Stichtag | Maximale Zertifikatslaufzeit | Wiederverwendung der Domainprüfung |
|---|---|---|
| bis 14.03.2026 | 398 Tage | 398 Tage |
| ab 15.03.2026 | 200 Tage | 200 Tage |
| ab 15.03.2027 | 100 Tage | 100 Tage |
| ab 15.03.2029 | 47 Tage | 10 Tage |
Die dritte Spalte wird häufig übersehen, hat betrieblich aber die größere Wirkung. Bis 2029 sinkt die Frist, innerhalb derer eine einmal durchgeführte Domain- und IP-Validierung wiederverwendet werden darf, auf 10 Tage (CA/Browser Forum, Ballot SC-081v3). Praktisch heißt das: Ab dieser Stufe wird bei nahezu jeder Erneuerung auch die Kontrollprüfung über die Domain neu durchlaufen. Wer die Validierung heute manuell per DNS-Eintrag oder per Datei auf dem Webserver erledigt, bindet damit ab 2029 dauerhaft Personal an einen Vorgang, der sich vollständig automatisieren lässt.
Was "öffentlich vertrauenswürdig" bedeutet – und was nicht
Warum das manuelle Modell rechnerisch nicht mehr trägt, zeigt eine einfache Überschlagsrechnung. Bei 398 Tagen genügte pro Endpunkt ein Termin im Jahr. Bei 200 Tagen sind es zwei, bei 100 Tagen vier, bei 47 Tagen rund acht bis neun (CA/Browser Forum, Ballot SC-081v3). Eine mittelgroße Handelslandschaft mit Shop, ERP, Middleware, zwei Marktplatzanbindungen, einem Versanddienstleister und einem Zahlungsabgleich kommt schnell auf 15 bis 25 TLS-Endpunkte (Projekterfahrung). Aus 20 Kalenderterminen pro Jahr werden damit bis 2029 rund 170 – verteilt über Teams, Dienstleister und Systeme, die zum Teil nicht einmal im eigenen Rechenzentrum stehen.
Der Kalendereintrag skaliert nicht mit
Vier Stellen, an denen es in der Shop-ERP-Landschaft knallt
Wer eine Integrationsstrecke auf Zertifikate absucht, findet sie an mehr Orten als erwartet. Ein Aufruf vom Shop zum ERP durchläuft in der Regel mehrere TLS-Verbindungen, und jede davon hat zwei Seiten. In einer klassischen Anbindung zwischen SAP und Shop sind das schnell vier bis sechs Übergänge. Vier Stellen fallen in der Praxis besonders häufig aus.
Server-Zertifikat der ERP-API
Das Zertifikat, mit dem sich die Schnittstelle gegenüber dem Shop oder der Middleware ausweist. Es ist der sichtbarste Fall und meist der einzige, der überhaupt in einer Erneuerungsliste steht.
Client-Zertifikat bei mTLS
Bei beidseitiger Authentisierung weist sich auch der Aufrufer mit einem Zertifikat aus. Läuft dieses ab, lehnt die Gegenseite die Verbindung ab – ohne dass am eigenen Server etwas auffällig wäre.
Truststore und CA-Bundle
Beide Seiten müssen der ausstellenden Zertifizierungsstelle vertrauen. Veraltete Wurzelzertifikate oder ein eingefrorenes CA-Bundle brechen die Verbindung, obwohl das Serverzertifikat frisch ist.
Certificate Pinning im Konnektor
Ältere Konnektoren prüfen teilweise einen fest hinterlegten Fingerabdruck. Nach einem Zertifikatstausch passt der Abdruck nicht mehr, und die Verbindung scheitert trotz gültiger Kette.
Diese vier Stellen liegen selten in derselben Verantwortung. Das Serverzertifikat betreut häufig der Hoster, das Client-Zertifikat die Integrationsabteilung, den Truststore die Systemadministration und das Pinning der Hersteller des Konnektors. Wenn eine Laufzeit von 47 Tagen greift, müssen diese vier Zuständigkeiten in einem Rhythmus arbeiten, den sie bisher nicht kannten. Wie eng technische Absicherung und Zuständigkeit zusammenhängen, zeigt auch unser Beitrag zur NIS2-konformen Absicherung von ERP-Schnittstellen.
Pinning ist die stillste Falle
Warum ein abgelaufenes Zertifikat im ERP still ausfällt
Im Shop ist ein abgelaufenes Zertifikat ein lautes Ereignis. Der Browser zeigt eine Warnseite, Kundinnen und Kunden melden sich, und der Vorfall ist binnen Minuten bekannt. Auf der ERP-Seite gibt es diesen Melder nicht. Dort spricht kein Browser mit der Schnittstelle, sondern ein Konnektor, eine Middleware oder ein Nachtlauf. Fällt die Prüfung der Zertifikatskette negativ aus, bricht der TLS-Handshake ab, bevor überhaupt eine HTTP-Anfrage entsteht. Die Anwendung sieht keinen Fehlercode aus dem ERP, sondern einen Verbindungsfehler auf Transportebene.
Genau dieser Unterschied macht den Ausfall gefährlich. TLS 1.3 verlangt in der Standardkonstellation die Authentisierung des Servers per Zertifikat (IETF RFC 8446); schlägt sie fehl, endet die Verbindung, ohne dass die darüberliegende Anwendungslogik jemals startet. Für ein Bestellsystem heißt das: Die Bestellung ist im Shop angenommen, bezahlt und bestätigt – sie kommt nur nicht im ERP an. Je nach Aufbau landen die Aufträge in einer Wiederholungswarteschlange, in einer Dead-Letter-Queue oder in einem Protokoll, das erst beim nächsten Blick geöffnet wird.
- Kein Nutzerfeedback: Der Abbruch geschieht zwischen zwei Maschinen. Der Shop bleibt bedienbar, die Kasse funktioniert, die Bestätigungsmail geht raus.
- Gefüllte Retry-Queues: Wiederholungsversuche laufen weiter und erzeugen Last, ohne das Problem zu lösen – der Fehler ist nicht transient, sondern strukturell.
- Verzögerte Sichtbarkeit: Auffällig wird der Ausfall häufig erst über Folgesymptome: fehlende Auftragsnummern, stehende Lagerbestände, ein Versandlauf ohne Datenbasis.
- Doppelte Verarbeitung nach der Reparatur: Wird die Verbindung repariert, laufen alle aufgestauten Nachrichten auf einmal ein. Ohne Idempotenzschlüssel entstehen dabei Dubletten.
- Unklare Fehlermeldung: Meldungen wie "certificate verify failed" oder "handshake failure" landen im Systemprotokoll, nicht im Fachprozess – und werden dort selten gelesen.
Im Shop meldet sich ein abgelaufenes Zertifikat beim Kunden. In der Schnittstelle meldet es sich beim Monatsabschluss.
Damit gehört der Zertifikatsablauf in dieselbe Betrachtung wie jede andere Störung der Übertragungsstrecke. Wie sich aufgestaute Nachrichten sauber nachverarbeiten lassen, ohne Dubletten zu erzeugen, beschreibt unser Beitrag zu Idempotenz und Retry-Strategien; die Frage, welche Signale eine Schnittstelle überhaupt melden sollte, behandelt der Text zu Observability und Monitoring von Schnittstellen. Für die Einordnung von Transport- gegenüber Fachfehlern lohnt zusätzlich der Blick in die Fehlerbehandlung an Schnittstellen.
Automatisierung: ACME, interne CA und Rollover
Für öffentliche Endpunkte ist der Weg standardisiert. Das Automatic Certificate Management Environment, spezifiziert in IETF RFC 8555 (März 2019), beschreibt ein Protokoll, mit dem ein Client die Domainprüfung, die Ausstellung und die Erneuerung ohne menschliches Zutun abwickelt (IETF RFC 8555). Die Spezifikation nennt als Ausgangspunkt, dass Betreiber für die Beschaffung und Installation eines Zertifikats üblicherweise eine bis drei Stunden benötigen (IETF RFC 8555) – multipliziert mit acht Erneuerungen im Jahr und zwanzig Endpunkten ist das der eigentliche Kostenblock.
ACME für öffentliche Endpunkte
Die Schnittstelle, die von außen erreichbar ist, erneuert ihr Zertifikat über das ACME-Protokoll nach RFC 8555 – inklusive der Domainprüfung, die ab 2029 fast bei jedem Durchlauf neu anfällt.
Interne CA für mTLS
Maschinelle Verbindungen zwischen ERP, Middleware und Shop laufen über eine eigene Zertifizierungsstelle. Sie stellt kurzlebige Client-Zertifikate aus, die sich in Tagen statt in Jahren messen.
Reload statt Neustart
Nach dem Tausch lädt der Dienst Schlüssel und Kette im laufenden Betrieb neu. Ein Neustart würde offene Verbindungen kappen und aus einer Routine ein Wartungsfenster machen.
1 Restlaufzeit ermitteln -> unter Schwellwert?
2 Neues Zertifikat anfordern -> ACME (RFC 8555) oder interne CA
3 Schlüssel + Kette ablegen -> atomar, alte Dateien bleiben erhalten
4 Dienst neu laden -> ohne Neustart, ohne Verbindungsabbruch
5 Testendpunkt aufrufen -> Handshake, Kette und Ablaufdatum prüfen
6 Ergebnis melden -> Erfolg protokollieren, Fehler eskalieren
7 Altes Zertifikat entfernen -> erst nach erfolgreichem TestEin Detail entscheidet darüber, ob die Automatisierung im Alltag ruhig bleibt: der Zeitpunkt der Erneuerung. Die ACME-Erweiterung für Erneuerungsinformationen, spezifiziert in IETF RFC 9773 (Juni 2025), erlaubt es der ausstellenden Stelle, ein Erneuerungsfenster vorzuschlagen, aus dem der Client einen zufälligen Zeitpunkt wählt (IETF RFC 9773). Das verhindert, dass alle Endpunkte zur selben Stunde erneuern, und gibt der Zertifizierungsstelle Handlungsspielraum, wenn Zertifikate außerplanmäßig getauscht werden müssen (IETF RFC 9773).
Überlappungsfenster statt Big-Bang-Tausch
| Aspekt | Big-Bang-Tausch | Rollover mit Überlappung |
|---|---|---|
| Zeitpunkt | ein Stichtag für alle Systeme | gestaffeltes Fenster je Endpunkt |
| Rückfallebene | nur Wiederherstellung aus Backup | altes Zertifikat bleibt bis zum Test gültig |
| Truststore-Pflege | gleichzeitig mit dem Tausch | neue Kette vorab verteilt |
| Prüfung | im Produktivbetrieb | über einen dedizierten Testendpunkt |
| Auswirkung bei Fehlern | Abbruch der Auftragsstrecke | Umschaltung wird verschoben |
| Betriebsform | Wartungsfenster | laufender Betrieb |
Das Zertifikatsinventar als Betriebsartefakt
Automatisierung setzt Kenntnis voraus. Ein Erneuerungsjob kann nur bedienen, was dokumentiert ist. Das NIST beschreibt in der Praxisrichtlinie SP 1800-16 "Securing Web Transactions: TLS Server Certificate Management" (Juni 2020) genau diesen Zusammenhang: Ein formales Programm für die Zertifikatsverwaltung soll Organisationen in die Lage versetzen, zertifikatsbezogene Vorfälle zu verhindern, zu erkennen und sich davon zu erholen (NIST SP 1800-16). Der erste Baustein eines solchen Programms ist ein vollständiges Inventar, der zweite eine klare Zuordnung von Verantwortlichkeiten (NIST SP 1800-16).
- Endpunkt und Zweck: Welcher Host, welcher Port, welche fachliche Strecke – etwa Auftragsübertragung, Bestandsabgleich oder Rechnungsexport.
- Zertifikatstyp: Serverzertifikat, Client-Zertifikat für mTLS oder Wurzel- beziehungsweise Zwischenzertifikat im Truststore.
- Ablaufdatum und Aussteller: Gültig bis wann, ausgestellt von welcher Stelle, öffentlich oder aus der internen Zertifizierungsstelle.
- Verantwortlicher: Eine benannte Rolle im Haus – nicht eine Sammeladresse, die im Zweifel bei allen und damit bei keinem landet.
- Erneuerungspfad: Automatisiert über ACME, über die interne CA oder manuell beim Dienstleister – mit dem konkreten Auslöser und der Frist.
- Testendpunkt: Die Adresse, an der sich Handshake, Kette und Ablaufdatum nach dem Tausch überprüfen lassen, ohne den Produktivfluss anzufassen.
Der zweite Teil ist die aktive Prüfung. Ein Monitoring, das erst beim Verbindungsfehler anschlägt, meldet den Ausfall – nicht die Ursache und schon gar nicht rechtzeitig. Sinnvoll ist eine eigene Prüfung, die den Handshake regelmäßig durchführt, die Restlaufzeit ausliest und unterhalb eines Schwellwerts alarmiert. Bewährt hat sich eine zweistufige Schwelle: eine Vorwarnung bei 30 Tagen Restlaufzeit und eine Eskalation bei 7 Tagen (Projekterfahrung). Bei einer Laufzeit von 47 Tagen ab 2029 rückt die Vorwarnung damit nahe an die Erneuerung – ein weiterer Grund, den Vorgang nicht von Hand zu fahren.
{
"endpoint": "erp-api.example.com:443",
"purpose": "Auftragsübertragung Shop -> ERP",
"issuer": "public-ca",
"not_after": "2026-10-15T09:12:00Z",
"days_remaining": 78,
"warn_days": 30,
"critical_days": 7,
"chain_complete": true,
"client_cert_days_remaining": 21,
"status": "warn",
"owner": "integration-betrieb"
}Die Prüfung gehört auf beide Seiten
Sonderfälle: Kundensysteme, Keystores und Konnektoren
Die unangenehmen Fälle liegen dort, wo das Zertifikat nicht im eigenen Zugriff ist. Im B2B-Handel gibt es regelmäßig Verbindungen, bei denen der Kunde oder ein Dienstleister die Gegenstelle betreibt: ein Beschaffungsportal, das per mTLS Kataloge abruft, ein Speditionssystem, das Statusmeldungen entgegennimmt, oder ein Rechenzentrum, in dem die Warenwirtschaft eines Konzernkunden steht. Hier reicht die eigene Automatisierung nur bis zur Grenze – der Rest ist Abstimmung, und die braucht Vorlauf.
- Zertifikate in Kundensystemen: Der Kunde muss die neue Kette in seinem Truststore hinterlegen. Ein Vorlauf von mehreren Wochen und eine benannte technische Ansprechperson auf beiden Seiten sind hier die eigentliche Absicherung.
- Dienstleister ohne Automatisierung: Manche Partner tauschen Zertifikate weiterhin per Ticket. Dann gehört der Vorgang mit Frist und Eskalationsstufe in den Vertrag oder zumindest in die Betriebsvereinbarung.
- Java-Keystores: Trust-Anker liegen in JKS- oder PKCS-12-Dateien, häufig neben der Anwendung und außerhalb jeder Paketverwaltung. Ohne Inventar bleibt ein solcher Speicher jahrelang unangetastet.
- PHP- und Skript-Konnektoren: Hier verweist die Konfiguration oft auf ein fest hinterlegtes CA-Bundle. Wird das Bundle nicht mitgepflegt, scheitert die Prüfung, obwohl beide Zertifikate gültig sind.
- Eingebettete Kopien: In Container-Abbildern und Altinstallationen stecken teils eigene Kopien des Vertrauensspeichers. Sie werden erst beim nächsten Neubau aktualisiert – und der steht häufig auf keinem Plan.
Für Java-Keystores und Skript-Konnektoren gilt derselbe Grundsatz wie für den Rest: Der Trust-Anker gehört ins Inventar, mit Datei, Pfad, Inhalt und Verantwortlichem. Ein Truststore ist kein statisches Artefakt, sondern eine Konfiguration mit Lebensdauer. Die praktische Konsequenz ist unspektakulär und wirksam zugleich – der Ort, an dem eine Anwendung ihre Wurzelzertifikate liest, wird explizit gesetzt, versioniert und mit derselben Automatisierung versorgt wie das Serverzertifikat. Wie sich solche Betriebsentscheidungen prüfbar dokumentieren lassen, zeigt unser Beitrag zur Verfahrensdokumentation für ERP-Shop-Schnittstellen.
Bleibt die Frage nach dem Pinning. Sinnvoll bleibt es dort, wo eine Verbindung über ein Netz läuft, dem man nicht vertraut, und wo die Gegenstelle stabil ist – etwa eine feste Anbindung an ein internes System über ein Fremdnetz. Der Anker gehört dann auf die interne Zertifizierungsstelle oder auf einen öffentlichen Schlüssel, der den Zertifikatstausch überdauert. Auf das Endzertifikat zu pinnen, war schon bei 398 Tagen mühsam; bei 47 Tagen ist es ein Vorgang, der acht- bis neunmal im Jahr Handarbeit erzwingt. Wer stattdessen die Authentisierung auf Anwendungsebene stärkt, erreicht mehr: Ein an den Absender gebundenes Token, wie es unser Beitrag zu OAuth 2.0 und Token-Sicherheit beschreibt, schützt auch dann, wenn die Transportschicht neu verhandelt wird.
Ein zweiter Blick lohnt auf die Kryptografie selbst. Das BSI empfiehlt in der aktuellen Fassung der Technischen Richtlinie TR-02102-2 (Version 2026-01 vom 27. Januar 2026) TLS 1.3 mit einem Verwendungszeitraum bis 2032 und darüber hinaus, während TLS 1.2 nur noch bis Ende 2031 empfohlen wird (BSI TR-02102-2). Als Mindestschlüssellängen nennt die Richtlinie 3000 Bit für RSA und 250 Bit für ECDSA und ECDH, ausgerichtet auf ein Sicherheitsniveau von 120 Bit (BSI TR-02102-2). Der Vorhersagezeitraum dieser Empfehlungen beträgt sieben Jahre (BSI TR-02102-2). Kurze Laufzeiten sind vor diesem Hintergrund kein Selbstzweck: Sie sind die Voraussetzung dafür, Verfahren wechseln zu können, ohne jede Schnittstelle einzeln anzufassen – ein Vorteil, der spätestens bei der Umstellung auf quantensichere Schlüsseleinigung zählt (BSI TR-02102-2).
Was das für Ihre Schnittstellen bedeutet
Der Weg vom Kalendereintrag zum Betriebsprozess lässt sich in vier Schritten gehen, und er hängt weniger an Werkzeugen als an Klarheit. Der Aufwand liegt fast vollständig im ersten Schritt: Sobald das Inventar steht, ist der Rest Routine. In einer typischen Landschaft mit Middleware zwischen Shop und ERP betrifft das die Verbindungen zum Warenwirtschaftssystem, zu Marktplätzen, zu Versanddienstleistern und zum Zahlungsabgleich.
1. Inventar aufnehmen
Jede TLS-Verbindung der Integrationsstrecke erfassen: Endpunkt, Zertifikatstyp, Aussteller, Ablaufdatum, Verantwortlicher. Truststores und Client-Zertifikate gehören ausdrücklich dazu.
2. Erneuerungspfad festlegen
Je Endpunkt entscheiden, ob die Erneuerung über ACME, über die interne Zertifizierungsstelle oder in Abstimmung mit einem Partner läuft – mit Frist und benannter Rolle.
3. Rotation und Reload automatisieren
Erneuerung, Verteilung und Neuladen ohne Neustart einrichten, mit Überlappungsfenster und einem Testendpunkt, der den Handshake nach dem Tausch bestätigt.
4. Ablaufalarm scharf schalten
Aktive Prüfung der Restlaufzeit auf beiden Seiten der Verbindung, mit Vorwarnung und Eskalation – damit der Alarm vor dem Ausfall kommt und nicht danach.
Zwei aktuelle Entwicklungen erhöhen den Druck zusätzlich, weil sie neue externe Endpunkte in die Landschaft bringen: die Meldepflichten rund um Verpackungsdaten nach der PPWR und die veränderten Datenanforderungen der Zollreform an ERP und Shop. Jede zusätzliche Anbindung an ein Behörden- oder Partnersystem ist eine weitere TLS-Verbindung mit eigenem Zertifikat, eigenem Truststore und eigener Zuständigkeit. Ohne Inventar wächst diese Liste schneller, als sie gepflegt wird – welche Anbindungen wir dabei betreuen, zeigt die Übersicht unserer Leistungen rund um ERP-Integration.
Ein Zertifikat ist kein Dokument, das man ablegt. Es ist ein Ablaufdatum, das man betreibt.
Quellen und Studien
Verwandte Artikel
Mengeneinheiten und Gebinde aus dem ERP sauber abbilden
Basis-, Lager-, Verkaufs- und Bestelleinheit trennen, Umrechnungsfaktoren aus dem ERP ziehen und Bestände, Mindestmengen sowie Grundpreise sauber abbilden.
ERP-Ausfall: Shop im Notbetrieb verkaufsfähig halten
ERP-Ausfall abfedern: letzte gültige Bestände und Preise mit Altersstempel, gepufferte Bestellungen, konservative Regeln und ein geordneter Wiederanlauf.
SAP ECC-Wartungsende 2027: Shop-Anbindung migrieren
Am 31.12.2027 endet die Wartung für SAP ECC. Jeder gekoppelte Shop-Connector muss auf S/4HANA umziehen. So planen Sie den Migrationspfad ohne Shop-Stillstand.