Versandfrist-Rechner
Geben Sie den zugesagten Liefertermin und die Transitzeit in Werktagen ein und erhalten Sie den letzten Versandtag: Für eine Lieferung am Montag, 27. Juli 2026, mit fünf Werktagen versenden Sie spätestens am Montag, 20. Juli. Wochenenden zählen nie. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Rechenbeispiel
- Lieferdatum
- 2026-07-27
- Transittage
- 5
- Spätester Versandtermin
- 2026-07-20
- Wochentag des Versandtermins
- Monday
- Wochentag der Lieferung
- Monday
- Wochentag des Versandtermins (ISO)
- 1
Ein Versandfrist-Rechner beantwortet die Fulfillment-Frage, der sich jedes Schaufenster und jeder Lagerplaner stellen muss: Wenn der Kunde die Bestellung an einem fest zugesagten Liefertag erhalten muss und der Spediteur eine bekannte Anzahl Werktage im Transit braucht, welches ist der letzte Kalendertag, an dem Sie das Paket noch an den Spediteur übergeben können? Geben Sie ein strenges ISO-Lieferdatum und eine nicht negative ganze Zahl an Werktagen Transit ein—beispielsweise Lieferung am Montag dem Siebenundzwanzigsten mit fünf Werktagen Transit—und das Werkzeug schreitet im gregorianischen Kalender rückwärts und überspringt jeden Samstag und Sonntag, und liefert das ISO-Versanddatum, Wochentagsnamen, ISO-Wochentagsnummern und die Kalenderspanne zwischen Versand und Lieferung. Feiertage liegen absichtlich außerhalb des Umfangs, damit regionale Kalender ein globales SLA nicht stillschweigend umschreiben.
Was Versandfrist bei Werktags-Transit bedeutet
E-Commerce und B2B-Fulfillment planen den Versand fast nie allein mit rohen Kalendertagen. Ein Versprechen von drei Werktagen Boden-Transit ab einem Montagsversand bedeutet typischerweise, dass das Paket unter einem Spediteurkalender von Montag bis Freitag am Donnerstag ankommen soll, nicht am Mittwoch, wenn man jeden Kalendertag einschließlich Wochenenden zählt.
Samstage und Sonntage zählen nie zum Transit und werden nie als Zwischenpunkte des Laufs gewählt, wenn der Transit größer als null ist; bei Transit null gleicht das Versanddatum dem Lieferdatum, selbst wenn dieser Tag auf ein Wochenende fällt, was Rückwärtsprüfungen gegenüber Werkzeugen, die Werktage vorwärts addieren, ehrlich hält. Das Lieferdatum selbst wird nicht als Transit-Schritt verbraucht: fünf Werktage vor einem Montag landen auf dem vorherigen Montag, das Inverse des Addierens von fünf Werktagen vorwärts.
Feiertage, Sperrtage und regionale Ruhekalender werden absichtlich weggelassen, weil sie nach Land, Spediteur und Lager variieren; eine einzige Feiertagstabelle in ein generisches Werkzeug zu backen würde Teams mit anderen Kalendern schaden. Kombinieren Sie das Ergebnis mit Ihrer eigenen Feiertagsliste, wenn ein Feiertag mitten in der Woche ebenfalls übersprungen werden muss.
Einordnung in reale Abläufe
Operations-Teams setzen Lager-Cut-off-Zeiten aus Marketing-Lieferversprechen: Wenn der Checkout Lieferung bis Freitag mit zwei Werktagen Transit bewirbt, muss die Versandfrist auf Mittwoch fallen, und dieser Aufruf macht dieses Datum explizit, bevor Bestellungen angenommen werden. Marktplätze und Multi-Carrier-Dashboards wandeln das Transit-SLA jedes Listings in ein einziges Versanddatum pro Bestellung um, damit Pick-and-Pack-Warteschlangen ausgerichtet bleiben. Finanz- und Customer-Care-Werkzeuge berechnen dieselbe Versandfrist neu, wenn ein Kunde fragt, ob eine Bestellung noch ein Geschenkdatum einhalten kann.
Der Browser-Pfad ist kostenlos für interaktive Prüfungen: Fügen Sie eine zugesagte Ankunft ein, geben Sie drei ein und bestätigen Sie den Versandtag, bevor Sie einen Kampagnenkalender festschreiben. Kombinieren Sie die Ausgabe mit Ihren eigenen Feiertagstabellen, wenn eine Region Feiertage mitten in der Woche beachtet; dieses Werkzeug bleibt darunter der zuverlässige Wochenendfilter. Andere Suchintention als das einfache Vorwärtsaddieren von Werktagen oder das Zählen von Geschäftstagen zwischen zwei Projektgrenzen: hier lautet die Produktfrage ausdrücklich, welcher der letzte Tag ist, an dem Sie noch versenden dürfen.
Anwendungsfälle
Lieferversprechen im Checkout
Wandeln Sie ein Schaufensterversprechen «kommt am Freitag an» und ein bekanntes Transit-SLA des Spediteurs in das letzte Lager-Versanddatum um, bevor die Bestellung angenommen wird.
Geschenk- und Eventfristen
Bei festem Geschenkdatum und Werktagen Transit teilen Sie Kunden den letzten Tag mit, an dem sie noch eine rechtzeitig versandte Bestellung aufgeben können.
Häufige Fragen
Was kostet es?
Dieselbe Berechnung läuft kostenlos in Ihrem Browser auf dieser Seite.
Sind Transittage Werktage oder Kalendertage?
Werktage. Es zählen nur Montag bis Freitag. Samstage und Sonntage werden beim Rückwärtsgehen vom Lieferdatum übersprungen.
Werden gesetzliche Feiertage übersprungen?
Nein. Nur Samstage und Sonntage werden übersprungen. Wenden Sie Ihre eigene Feiertagsliste an, wenn Region oder Spediteur es brauchen.
Warum wurde mein Datum abgelehnt?
Das Lieferdatum muss ein echter gregorianischer Kalendertag in strenger YYYY-MM-DD-Form sein. Unmögliche Tage wie der 30.
Was passiert bei null Transittagen?
Dann ist der Versandtag der Liefertermin selbst, auch wenn er auf ein Wochenende fällt. So bleibt das Ergebnis stimmig mit dem Vorwärtszählen von Werktagen ab dem Versand.
Verwandte Tools
Für Entwickler — API-Zugang
Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.
Endpunkt
Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.
Aufruf aus Ihrem Stack
curl -X POST https://api.kit.forhosting.com/date/ship-by-date \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"delivery_date":"2026-07-27","transit_days":5}'const res = await fetch("https://api.kit.forhosting.com/date/ship-by-date", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"delivery_date": "2026-07-27",
"transit_days": 5
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/date/ship-by-date",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"delivery_date": "2026-07-27",
"transit_days": 5
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/date/ship-by-date", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"delivery_date":"2026-07-27","transit_days":5}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"delivery_date":"2026-07-27","transit_days":5}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/date/ship-by-date", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"delivery_date": "2026-07-27",
"transit_days": 5
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "date.ship_by_date",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.
Preis
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
Fehler
| HTTP | Code | Bedeutung |
|---|---|---|
401 | unauthorized | Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer). |
402 | insufficient_balance | Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht. |
404 | unknown_type | Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog. |
429 | rate_limited | Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt. |
Technische Hinweise
Was Versandfrist bei Werktags-Transit bedeutet
Diese Fähigkeit modelliert diesen Vertrag ausdrücklich: transit_days ist eine Zählung nur von Montag-bis-Freitag-Schritten, und der Algorithmus startet vom zugesagten delivery_date und geht jeweils einen Kalendertag in die Vergangenheit, bis genau so viele Nicht-Wochenendtage verbraucht sind.
Aufruf und Lesen des Ergebnisses
Weil der Algorithmus nie die lokale Zeitzone abfragt, bleibt ein reiner Kalenderwert rein und rutscht nicht um einen Tag, wenn ein Server in einer anderen Zone läuft. Senden Sie zwei Felder: delivery_date als strenge YYYY-MM-DD-Zeichenkette für den zugesagten Ankunftstag des Kunden und transit_days als nicht negative ganze Zahl für den Werktags-Transit des Spediteurs. Aliasse wie delivery, due, promise_date, arrive_by und target_date für das Datum sowie transit, shipping_days, lead_days und days für die Ganzzahl werden akzeptiert, damit bestehende Formulare sauber mappen, ohne Felder umzubenennen. Ungültige Kalenderdaten scheitern sofort mit invalid_input: der dreißigste Februar, Monat dreizehn, freie Zeichenketten und nicht kanonisches Padding werden abgelehnt statt erzwungen. Eine negative Transitanzahl, eine Nicht-Ganzzahl oder ein Wert über der harten Obergrenze ist ebenfalls invalid_input, damit eine entlaufene Schleife das Isolate nicht erschöpfen kann. Eine erfolgreiche Antwort liefert ship_by_date (den letzten Tag zur Übergabe des Pakets), das widergespiegelte delivery_date, die angewandten transit_days, ship_by_weekday und delivery_weekday als englische Wochentagsnamen, ship_by_iso_weekday und delivery_iso_weekday als Nummern Montag-gleich-eins bis Sonntag-gleich-sieben, calendar_days als absolute gregorianische Spanne vom Versand zur Lieferung (mindestens transit_days und größer, wenn Wochenenden übersprungen wurden), und eine kurze Formelzeichenkette, die die Regel dokumentiert. Nutzen Sie die Wochentagsfelder in nutzerseitigen Texten und Cut-off-Bannern; nutzen Sie die ISO ship_by_date als System of Record für Pick-Wellen, Spediteur-Cut-offs und SLA-Engines. Der Preis ist pauschal $0.002 pro erfolgreicher Anfrage mit Einheit item; fehlgeschlagene Validierung wird nie berechnet.
Einordnung in reale Abläufe
Entwickler betten denselben solve in Webhooks und CRON-Jobs ein, damit jeder Dienst eine Definition des letzten Versandtags teilt, statt ad-hoc-Schleifen neu zu implementieren, die an Freitag-zu-Montag-Kanten abweichen. Der API-Pfad kostet $0.002 pro erfolgreicher Anfrage und wird pro item abgerechnet, was Massenskripte zur Auftragsplanung günstig hält und dennoch Edge-Ausführung abdeckt.
Integrationsbeispiele
Pick-Wellen und Spediteur-Cut-offs
Bündeln Sie Bestellungen nach ship_by_date, damit Pick-Wellen und Spediteurübergaben das Werktags-Transitfenster nicht verfehlen.
Technische Fragen
Was, wenn transit_days null ist?
ship_by_date gleicht delivery_date, auch wenn dieser Tag auf ein Wochenende fällt. Nutzen Sie einen positiven Transit, wenn der Spediteur Werktage in Bewegung braucht.