ASA-Methodenzugriff verstehen
Unterscheiden Sie Steward-Berechtigungen von ASA-Kontoberechtigungen, Modulen und beobachtetem Methodenzugriff.

Zwei Berechtigungssysteme
Steward autorisiert ASA-Aufgaben über Projektrolle und Chatmodus. ASA prüft separat die Methodenberechtigungen des gespeicherten Kontos und lizenzierte Module. SOAP-Lesezugriffe funktionieren trotz POST im Modus Nur lesen. Der Bereich mit beobachtetem Zugriff dient nur zur Information und erteilt keinen Zugriff.
Der Chatmodus regelt die Ausführung; die Projektrolle bestimmt Ihre Möglichkeiten. Nur lesen verhindert Änderungen im Geschäftstool. Genehmigung anfordern erfordert die Entscheidung eines Projektmanagers. Automatisch erlaubt unterstützte Änderungen für Mitwirkende und Projektmanager, sofern keine Genehmigungsregel eine Prüfung verlangt. Ein Modus ändert keine Projektfreigabe.
Den Zugriffsbereich lesen
Wählen Sie unter Einstellungen → Verbindungen die Option ASA-Berechtigungen:
- Unbekannt: Diese Methode wurde für die aktuellen Zugangsdaten noch nicht bestätigt.
- Bestätigt: Mit den aktuellen Zugangsdaten wurde ein erfolgreicher Aufruf beobachtet. Die Berechtigungen können sich später in ASA ändern.
- Verweigert: ASA hat diese Methode ausdrücklich abgelehnt. Steward speichert diese Beobachtung fünf Minuten lang zwischen, um wiederholte Fehler zu vermeiden.
Das Herstellerpaket bietet keinen Endpunkt, der alle Berechtigungen umfassend ausliest. Verfügbare WSDL-Methoden und ein erfolgreicher getVersion-Aufruf belegen keinen Zugriff auf andere Methoden. Steward testet niemals Schreibvorgänge, um Berechtigungen zu ermitteln.
Die Modulnamen stammen aus der Methodentabelle des Herstellers. In der Regel genügt eines der aufgeführten Module; Beauty erfordert zusätzlich Data Exchange. Für Extended Reservation-Service muss außerdem der ASA-Benutzer entsprechend konfiguriert sein. getGuests und getReservations bieten ohne Data Exchange oder Cash möglicherweise nur eingeschränkte Funktionen. Fragen Sie den Administrator des Hotels, welche Konstellation zutrifft.
Standardverhalten bei Änderungen
Routinemäßige ASA-Änderungen folgen für Mitwirkende und Projektmanager dem Chatmodus. Gebühren, Gebührenbelege, Tagessummen, Reservierungserstellung, Spa-Buchungen und Statusänderungen, Beginn und Ende der Abrechnung sowie Zimmernachrichten erfordern standardmäßig eine Genehmigung. Ein Projektmanager trifft diese Entscheidung.
Alle 33 Methoden des Herstellervertrags v2.14 haben einen ausdrücklich festgelegten Standard: 21 Lesemethoden, drei routinemäßige Aktualisierungen und neun genehmigungspflichtige Änderungen. Unbekannte Methoden und Felder werden blockiert. Weder geänderte Kontoberechtigungen noch eine Genehmigungsregel können die Vertragsunterstützung erweitern.
Zum Genehmigen oder Ablehnen benötigen Sie Projektmanagerzugriff auf das Projekt des Vorschlags. Mitwirkende können Änderungen vorbereiten und die Details prüfen. Vor der Ausführung werden der aktuelle Projektzugriff der ausführenden Person und die aktivierte Verbindung erneut geprüft.
Auf einen Fehler reagieren
Bei Authentifizierungsfehlern prüfen Sie die gespeicherten Zugangsdaten. Eine verweigerte Methode benennt die Methode, die Sie mit dem ASA-Administrator besprechen sollten. Ausdrückliche Modulfehler erfordern die Aktivierung des betreffenden Moduls. Lokale Validierungsfehler bedeuten, dass das vorgeschlagene XML oder die Parameter nicht zum festgelegten Vertrag passen. Bei Ablehnungen durch Steward-Richtlinien sind die passende Berechtigung, Projektzuordnung, der passende Modus oder eine Prüfung erforderlich.
Ein unsicheres Ergebnis einer Änderung bedeutet, dass die Anfrage ASA möglicherweise erreicht hat. Prüfen Sie das Ergebnis in ASA, bevor Sie es erneut versuchen. Senden Sie dieselbe Buchung, Reservierung oder denselben Beleg niemals erneut, nur weil die Verbindung in ein Zeitlimit gelaufen ist.
Eine unsichere Ausführung prüfen
Öffnen Sie den Vorschlag in seinem Chat und sehen Sie sich die erfassten Ergebnisse an. Eine Person mit den Berechtigungen Genehmigen und Lesen sowie Mitwirkenden-Zugriff auf das Projekt muss zuerst ASA prüfen. Wählen Sie unter Unsicheres Ergebnis in ASA prüfen, ob die Änderung übernommen wurde, geben Sie die ASA-Referenz und den Prüfnachweis ein und wählen Sie Abgleich erfassen. Wiederholen Sie dies für jeden unsicheren Eintrag des Batches.
Damit wird eine separate Prüfung durch eine Person erfasst; die alte Anfrage wird weder neu gestartet noch die ursprüngliche Ausführung überschrieben. Anschließend können neue Änderungen nach den üblichen Genehmigungsregeln vorbereitet werden. Bis der Abgleich erfasst ist, sind weitere ASA-Änderungen über diese Verbindung blockiert.
Die Prüfschritte und die Einschränkung bei geschlossenen Konten finden Sie unter Ein unsicheres ASA-Ergebnis prüfen.
Mit der Berechtigung „Konfigurieren“ lädt Herstellervertrag prüfen schreibgeschützte Dienst-Metadaten herunter und stellt Änderungen zur Prüfung bereit. Damit werden keine Methoden aktiviert und auch nicht deren erteilte Berechtigungen ermittelt. Wenn das Hotel WSDL-Downloads einschränkt, bitten Sie dessen Administrator um das aktuelle Herstellerpaket.