Was ist neu

Dynamic Catering Cut-off

• Neue Felder in den CateringMenu GET/POST/PUT/PATCH-Methoden zur Unterstützung neuer Cutoff-Einstellungen unter Catering Menu.
• Überprüfung der Annahmeschlusszeit in der CateringOrder POST-Methode.

Automatisierte Catering-Bestellungen

• Neue Endpunkte und Berechtigungen zur Unterstützung der Catering-Vorlagenfunktionalität sowie Änderungen an der Buchungsrichtlinien-API zum Anbinden von Catering-Vorlagen:
  • GET /v2/{nodeid}/catering-templates
  • POST /v2/{nodeid}/catering-templates
  • GET /v2/{nodeid}/catering-templates/{id}
  • LÖSCHEN /v2/{nodeid}/catering-templates/{id}
  • PUT /v2/{nodeid}/catering-templates/{id}
  • DATAMODEL.CateringTemplate.Create
  • DATAMODEL.CateringTemplate.Read
  • DATAMODEL.CateringTemplate.Update
  • DATAMODEL.CateringTemplate.Delete
• Folgende Änderungen wurden vorgenommen, um die Erstellung automatisierter Catering-Bestellungen bei der Buchungserstellung zu unterstützen:
  • Die TemplateId wurde zur GET-Antwort /v2/{nodeid}/bookings/{bookingid} hinzugefügt.
  • IsAutomated wurde zu POST/PUT/PATCH v2/{nodeid}/catering-order hinzugefügt.
  • Die POST-Anfrage v2/{nodeid}/bookingparties?bookingid={bookingid} sowie die IMPORT-Anfrage v2/{nodeid}/bookingparties/import/{bookingid} wurden angepasst, um die Anzahl der automatisierten Catering-Bestellungen zu erhöhen oder zu verringern, wenn sich die Teilnehmerzahl ändert.

Teilnehmerbegrenzungseinstellungen

• Zur Unterstützung der neuen Funktionalität, die die Anzahl der Teilnehmereinladungen abhängig von der Raumkapazität begrenzt:
  • Es wurde eine Berechtigungs-API.Bookings.UnlimitedCapacity hinzugefügt, die Gebäudeberechtigungen (AppliesTo) verwendet.
  • Änderungen wurden an den Endpunkten Bookings und BookingParties vorgenommen.
  • Es wurde ein neuer Endpunkt unter BookingParties POST /v2/{nodeid}/bookingparties/bookings-series/{seriesid} erstellt, um Buchungsserien zu unterstützen.
  • v2/{nodeid}/bookingparties verwendet nun Beschränkungen, die durch den Wert der Speicherplatzkapazität festgelegt sind.

Was hat sich geändert?

Gastronomie

• Wird die Cateringbestellung vor dem Annahmeschluss für das Cateringmenü storniert, ändert sich ihr Status wie folgt:
  • Wenn die Zubereitungszeit für einen der Catering-Artikel bereits begonnen hat (Vorbereitungszeit gemäß der entsprechenden Bestellrichtlinie), lautet der Status „Stornierung ausstehend“, damit das Catering-Team entscheiden kann, ob dem Benutzer Kosten entstehen.
  • Wenn die Vorbereitungszeit noch nicht begonnen hat, lautet der Status „Stornierung kostenlos“.
• Wird eine Buchung mit Catering-Aufträgen verlängert (die Endzeit erhöht), ändert sich der Status des Catering-Auftrags nicht.

Buchungen

• Der POST-Request /v2/{nodeid}/bookingparties wurde aktualisiert, sodass das Feld Booking_Parties_Formatted nun durch Kommas statt durch Semikolons getrennt ist.
• DELETE /v2/{nodeid}/bookingparties/{recordid} und PATCH /v2/{nodeid}/bookingparties/delete aktualisieren nun das Feld Booking_Parties_Formatted, um die gelöschte Partei aus dem Buchungsdatensatz zu entfernen.

• Wir haben den Buchungsexportprozess optimiert.
• Die Besucherberechtigungen wurden mit den Besuchsberechtigungen zusammengeführt und daher aus der Tabelle „Datensicherheit“ unter Admin-Portal > Einrichtung > Sicherheit > Rollen- und Datensicherheit entfernt.
• Die Buchungsanruf-Payload wurde geändert, um den Buchungsparteien-Anruf separat zu behandeln.
• Benutzer, die in AAD als Gäste eingerichtet sind, können sich beim IBSS Hub oder der API anmelden.

Was wurde behoben?

• Wir haben die Berechnungen zur Etagenverfügbarkeit für die Endpunkte korrigiert:
  • /v1/{nodeid}/Floors/{floorid}/availability
  • /v1/{nodeid}/Floors/{floorid}/availability-and-environmental

Besuche

• Der Patch `/v2/{nodeid}/bookingparties/delete` entfernt, egal ob er im Hub oder über die API verwendet wird, die buchende Person und storniert lediglich den Besuch. Zuvor wurde der gesamte Besuchsdatensatz aus dem System gelöscht.
• Beim Hinzufügen eines externen Besuchers zu einer Buchung wird ein entsprechender Besucherdatensatz erstellt, in dem die Gastgeberdaten korrekt ausgefüllt sind. Zuvor wurden die Gastgeberdaten nicht ausgefüllt.
• Wird der Gastgeber für eine Buchung mit einem externen Besucher geändert, wird der Besuchsdatensatz entsprechend mit den neuen Gastgeberdaten aktualisiert.
• Beim Erstellen eines Besuchs, der über den Endpunkt POST /v2/{nodeid}/bookingparties mit einer Buchung verknüpft ist, wird das Feld „OwnedBy“ des Besuchsdatensatzes nun korrekt auf den Buchungsinhaber gesetzt. Zuvor wurde der aktuelle Benutzer als Inhaber festgelegt.
• Wird eine Buchung mit einem externen Besucher auf eine andere Etage verschoben, wird der Besucherdatensatz nun automatisch mitverschoben. Zuvor wurde der Besucherdatensatz von der ursprünglichen Buchung getrennt.
• Wenn eine Buchung mit einem stornierten Gast auf eine andere Etage verschoben wird, wurde der stornierte Gast zuvor in der Buchung neu angelegt. Dieses Problem wurde nun behoben.

Buchung im Namen eines Besuchers

• Wenn eine Buchung im Namen eines Besuchers erstellt und anschließend die Buchungszeit aktualisiert wird, wird nun auch der entsprechende Besucherdatensatz mit der gleichen Besuchszeit aktualisiert.
• Wird eine Buchung im Namen eines Besuchers erstellt, gilt dieser Besucher als Buchungsinhaber und wird nicht als Teilnehmer gezählt. Dadurch wird der Fehler aufgrund überschrittener Raumkapazität behoben.

Gastronomie

• Der Aufruf PUT /v2/{nodeid}/catering-order/{orderId} prüft nun die Berechtigung IgnoreCutOff, wenn versucht wird, eine Catering-Bestellung nach dem Annahmeschluss des Catering-Menüs zu aktualisieren.
• Wird eine genehmigte Cateringbestellung mit einem neuen Namen oder einer neuen Beschreibung aktualisiert, ändert sich ihr Status nicht mehr. Zuvor wurde sie auf „Genehmigung ausstehend“ gesetzt.
• Wenn eine Catering-Bestellung den Status „Genehmigung ausstehend“ hat und in einen Raum verlegt wird, in dem das Menü nicht verfügbar ist, wird die Bestellung auf „Stornierung ausstehend“ gesetzt.
• Wenn ein Benutzer mit der Berechtigung „IgnoreCutOff“ eine Buchung mit der genehmigten Cateringbestellung in einen anderen Raum verschiebt, in dem dasselbe Menü verfügbar ist, bleibt der Status der Cateringbestellung „genehmigt“. Zuvor wurde er auf „Stornierung ausstehend“ gesetzt.
• Beim Aktualisieren der Teilnehmerzahl für eine Buchung mit automatisierter Cateringbestellung werden nun auch die Mengen für diese Bestellung korrekt aktualisiert.

• Bei der Aktualisierung einer Buchung mit vollständig ausgelasteter Kapazität werden keine weiteren Ressourcen zur Teilnehmerzahl hinzugefügt. Ressourcen können der Buchung bei Bedarf hinzugefügt werden.
• Wenn eine Buchung um zusätzliche Ressourcen erweitert wird, wird die Ressource, sofern verfügbar, der neuen Buchung erneut hinzugefügt.
• Sobald die der Buchung hinzugefügten Ressourcen freigegeben werden, stehen diese Ressourcen wieder zur Verfügung und können für eine andere Buchung verwendet werden.
• Bei der Erstellung einer Buchung für einen Besucher wird keine doppelte Buchungsgruppe mehr erstellt, und die Buchung wird erfolgreich erstellt, ohne dass die Kapazitätsgrenzen (fälschlicherweise) überschritten werden.
• Beim Aktualisieren einer Buchung für einen Besucher werden die folgenden Felder korrekt aktualisiert, um die an der Buchung vorgenommenen Änderungen widerzuspiegeln: Buchung ist Besucher, Anzahl der Buchungsteilnehmer, Format der Buchungsteilnehmer.

• Problem beim Erstellen einer Aufgabe für Ausrüstung behoben.
• Besuche können auch nach dem vereinbarten Besuchsbeginn verlängert werden.
• Das Problem, Teilnehmer als Buchungspartner über den Endpunkt POST /v2/{nodeid}/bookingparties/import/{bookingid} zu importieren, wurde behoben, um die Funktionalität für Ticketveranstaltungen zu unterstützen.
• Eine Reihe von Fehlermeldungen wurde korrigiert, um die Benutzerfreundlichkeit in IBSS HUB-Apps zu verbessern:
  • Die Fehlermeldung „Ungültiger Kostencode“ wurde hinzugefügt.
  • Wenn die Buchungsbeginnzeit nach der Buchungsendzeit liegt, lautet die Fehlermeldung nun Booking_Invalid_Times.
    statt Booking_Invalid_Duration_Too_Short.
  • Die Fehlermeldung zu den falsch eingerichteten verknüpften Bereichen liefert nun weitere Details, die das Problem erläutern.
  • Der Fehler beim Stornieren einer verknüpften Raumbuchung liegt nun, wie alle anderen Fehler in IBSS , im RFC 9457-Format vor.
• Ein Formatierungsproblem wurde behoben, sodass nun auch leere Kostenstellenfelder für Catering-Bestellungen akzeptiert werden.
• Beim Aktualisieren einer Buchungsrichtlinie mit PATCH /v2/{nodeid}/bookingpolicies/{bookingpolicyid}/Apply wird die neue Buchungsrichtlinien-ID in IBSS -Datenbanken gespeichert.
• Besuchertypen akzeptieren jetzt den Namen mit Apostroph.
• Die Start- und Endzeit für Buchungsserien wird nun korrekt im UTC-Format angezeigt.
• Beim Erstellen einer wiederkehrenden Buchung für einen Raum, der keine Einrichtung und keine Rücksetzzeiten erfordert, wird nun die ParentBookingId als leere Zeichenkette und nicht als Nullwert zurückgegeben.
• Da eine Aktualisierung einer Buchung innerhalb des Genehmigungszeitraums nicht zulässig ist, haben wir diese Validierung so angepasst, dass die Einrichtungs- und Rücksetzfenster um die Buchung herum berücksichtigt werden, bevor ein Fehler angezeigt wird.

Bekanntes Problem

• Beim Verschieben einer Buchung mit externen Besuchern in ein anderes Gebäude mittels POST /v2/{nodeid}/bookingparties wird das Feld „Besuchertyp“ nicht mit dem neuen Besuchertyp aktualisiert. Der Check-in für solche Besucher muss daher vorerst manuell erfolgen.
• Das Hinzufügen oder Entfernen von Teilnehmern zu einer Buchung mit Catering ändert die Mengen für automatisierte Catering-Bestellungen. Wenn jedoch im Feld „Buchungsteilnehmer“ der höhere manuell eingegebene Wert angezeigt wird, sollte dieser die Anzahl der gebuchten Veranstaltungen (Anzahl der Teilnehmer) überschreiben. Dies ist derzeit erst mit dem nächsten Produktupdate möglich.