Mindestaufenthalt und Anreisesperren: die Regeln, die über ein Datum entscheiden

Preis und Erlaubnis sind zwei Fragen

Betreiber denken in Saisons: August kostet 140 pro Nacht, mindestens drei Nächte, keine Anreise am Samstag. Für sie ist das eine Entscheidung. Für die Software sind es zwei Fragen, zu verschiedenen Zeitpunkten und von verschiedenen Aufrufern gestellt.

Nach dem Preis wird gefragt, wenn jemand fast entschieden ist. Die Erlaubnis — darf dieser Aufenthalt existieren? — muss beantwortbar sein, bevor irgendwer einer Zahlung zugestimmt hat, denn die Verfügbarkeitsprüfung braucht sie, um ein Datum überhaupt als buchbar zu zeichnen.

Beide Antworten sollten dieselben Regelzeilen lesen. Trennt man sie in eigene Tabellen, kommt der Tag, an dem jemand den Augustpreis ändert und den August-Mindestaufenthalt zurücklässt.

Raten werden pro Nacht aufgelöst

Ein Aufenthalt, der in der Nebensaison beginnt und in der Hauptsaison endet, hat keine "eine Rate". Jede Nacht zahlt die Rate ihrer Regel, und die Summe ist der Gesamtpreis.

Das klingt selbstverständlich und wird regelmäßig falsch gemacht, weil eine Rate pro Aufenthalt viel bequemer zu speichern ist. Der Fehler ist unsichtbar: keine Meldung, keine Beschwerde, nur ein still falscher Gesamtpreis bei jeder Buchung über eine Grenze hinweg — in der Richtung, die die Implementierung unausgesprochen bevorzugt hat.

Wenn mehrere Regeln dieselbe Nacht abdecken könnten, muss der Vorrang deterministisch sein und nicht das, was die Datenbank zuerst liefert. In Boris schlägt eine Regel für ein konkretes Zimmer die Vorgabe des Spaces, und zwischen zwei Regeln derselben Ebene gewinnt das neuere Startdatum.

Beschränkungen gehören zur Anreisenacht

Mindest- und Höchstnächte sowie Anreisesperren werden anhand der Regel beurteilt, die die erste Nacht des Aufenthalts abdeckt. Das ist die Konvention jedes Channel Managers und keine willkürliche Wahl.

Man betrachte die Alternative. Würde der Mindestaufenthalt für jede berührte Regel gelten, würde ein Gast, der am 30. Juli für vier Nächte anreist, abgelehnt, weil sein Aufenthalt eine Augustregel mit drei Nächten streift: vier Nächte, abgelehnt als zu kurz. Jede Nacht zu prüfen macht aus einer Untergrenze eine Falle.

Die Abreisesperre ist die Ausnahme und das Detail, das am häufigsten fehlt: das Abreisedatum ist keine Nacht des Aufenthalts. Die Regel der Anreisenacht reicht vielleicht nicht so weit, also braucht es eine eigene Abfrage. Wer sie in die Anreiseregel faltet, bekommt einen Fehler, der nur bei langen Aufenthalten erscheint — also bei den Buchungen, die man am wenigsten falsch haben will.

Null ist keine Grenze

Eine kleine Sache mit großen Folgen: in einer nullbaren Spalte für Mindestnächte erscheinen sowohl NULL als auch 0, und beide bedeuten "keine Grenze". Ein System, das eine gespeicherte 0 als echtes Minimum nimmt, vergleicht jeden Aufenthalt damit und lehnt nichts ab — oder, bei umgekehrt geschriebenem Vergleich, alles. Das normalisiert man einmal beim Lesen, nicht in jedem Aufrufer.

Ablehnen an der Kasse ist ein Fehler, kein Schutz

Eine Beschränkung, die erst beim Absenden greift, ist zwar korrekt und trotzdem ein schlechtes Erlebnis. Der Gast hat Daten gewählt, seine Angaben eingegeben, die Zahlung erreicht — und erfährt dort, dass samstags keine Anreise möglich ist.

Die Lösung ist, die Beschränkung offenzulegen, nicht nur das Urteil. Boris' Verfügbarkeitsendpunkt kann sagen, was ein Anreisedatum verlangt — Mindest- und Höchstnächte, ob Anreise oder Abreise gesperrt ist — damit ein Storefront die Daten deaktiviert, die er ohnehin ablehnen würde. Dieselbe Regel, eine Abfrage früher, eine völlig andere Conversion.

Aus demselben Grund muss jeder Buchungsweg die Regeln konsultieren. Eine Rate oder Sperre, die im Backoffice gilt, aber nicht im Storefront, in der App oder in der API, ist schlimmer als keine: sie sieht durchgesetzt aus, und genau das hält jeden davon ab, sie zu prüfen.

Nichts ändert sich, solange keine Regel existiert

Die letzte Eigenschaft einer vernünftigen Umsetzung: deckt keine Regel den Aufenthalt ab, liefert der Resolver nichts und der Aufrufer behält den Preis, den er schon hatte. Saisonpreise einzuschalten darf keinen bestehenden Preis verändern, solange niemand bewusst eine Saison anlegt.

Lücken sollte man melden, nicht füllen. Eine nicht abgedeckte Nacht innerhalb eines Tagestarifs kann vertretbar auf dessen Preis zurückfallen. Ein Monatspreis lässt sich nicht so in Nächte teilen, dass man es einem Kunden erklären könnte — dort ist es ehrlicher, das Angebot abzulehnen, als eine Zahl zu erfinden.