Zum Inhalt

Behördenseite (Authority)

Diese Seite beschreibt die Vorgänge, die eine zuständige Behörde (Competent Authority, CA) an einer Notifizierung oder einem Movement auslöst: Eingangsbestätigung, Nachforderung, Vorbedingungs-Signale, Entscheidung, Antwort auf einen Änderungsantrag, Rücknahme-Anordnung.

Für die meisten Leser ist das kein eigener Anwendungsfall

Wer ein Unternehmenssystem anbindet, baut die Company-Seite — Notification (Company) und Movement (Company). Die Behördenrolle setzt einen Account voraus, dem eine CA zugeordnet ist; ein Unternehmens-Account kann sie nicht einnehmen.

Trotzdem gehört diese Seite zur Pflichtlektüre, wenn du die Company-Seite baust: Fast jeder Zustandswechsel deiner Notifizierung wird von der Behördenseite ausgelöst. Du musst wissen, welche Vorgänge von dort kommen, in welcher Reihenfolge sie kommen, welche davon unumkehrbar sind und welche dir Schreibrechte an deinem eigenen Dokument wieder nehmen. Der Abschnitt Was davon bei dir ankommt fasst genau das zusammen.

Voraussetzungen für die Behördenrolle:

Mit dem .NET SDK

Den Code zu dieser Anleitung zeigt Behördenseite mit dem SDK.

Die Behördenoberfläche im Überblick

Die Behördenvorgänge liegen auf einer eigenen API (AuthorityDocumentApi), getrennt von der Company-API. Sie hat neun Operationen:

Vorgang Ebene Nutzlast SDK-Methode
SubmitAcknowledgement Notifizierung AcknowledgementDocumentType AuthorityNotificationDocumentHandler.SubmitAcknowledgement
SetRequestInformation Notifizierung RequestInformationDocumentType AuthorityNotificationDocumentHandler.SetRequestInformation
SetDecision Notifizierung DecisionDocumentType AuthorityNotificationDocumentHandler.SetDecision
ReplyToRequestForChangeAfterConsent Notifizierung ReplyToRequestForChangeAfterConsentDocumentType AuthorityNotificationDocumentHandler.ReplyToRequestForChangeAfterConsent
SubmitNotificationSignal Notifizierung NotificationSignalDocumentType AuthorityNotificationDocumentHandler.SubmitNotificationSignal
SetMovementTakeBack Movement MovementTakeBackDocumentType AuthorityMovementDocumentHandler.SetMovementTakeBack
SubmitMovementSignal Movement MovementSignalDocumentType AuthorityMovementDocumentHandler.SubmitMovementSignal
SetByIntent Notifizierung, Annex VII Retrieval-Dokument + DiwassIntents client.BxaApi.AuthorityDocumentApi.SetByIntent
GetDocument alle — nicht über die Handler; lesen läuft über Refresh()

SetByIntent ist eine generische Alternative für formularbasierte Oberflächen: statt einer typisierten Operation schickst du das vollständige Retrieval-Dokument plus den Intent, und der Server extrahiert den passenden Abschnitt. Fachlich äquivalent zu den typisierten Operationen. Movement-Dokumente sind ausdrücklich ausgenommen — dort führt nur der typisierte Weg.

Notifizierung: die Vorgänge im Detail

Eingangsbestätigung (SubmitAcknowledgement)

Die Eingangsbestätigung startet die Entscheidungsfrist. Für Behörden, die direkt im EU-Zentralsystem arbeiten, erzeugt DiWaSS sie selbst; über die API wird sie nur gebraucht, wenn eine Behörde im Auftrag einer anderen Behörde handelt.
Vorbedingung Notifizierung im Status Submitted; für die betreffende Behörde existiert noch keine Bestätigung
Pflichtfelder UserCompetentAuthorityDomainId, NotificationId, Acknowledgement (mit ReceiptDate und SentDate)
Wirkung Eingang bestätigt. Keine Zustimmung — der Notifizierende darf noch nicht verbringen

Nachforderung (SetRequestInformation)

Nur Behörden können nachfordern; nur der Notifizierende kann antworten. Das Nachforderungsfenster ist die einzige Gelegenheit, an einer eingereichten Notifizierung noch etwas zu ändern — siehe Das Änderungsfenster.
Vorbedingung Notifizierung im Status Submitted; die vorige Nachforderung derselben Behörde ist beantwortet
Obergrenze Maximal drei Nachforderungen pro Behörde und Notifizierung
Aktualisierbar Ja, beliebig oft — solange die Nachforderung unbeantwortet ist und von derselben Behörde stammt
Pflichtfelder Statement (mit NotificationId, Text und Signatur). AdditionalDaysToReply ist optional
Wirkung Entscheidungsfrist ausgesetzt; die Notifizierung wird für den Notifizierenden wieder änderbar

Nach ProperlyCarriedOut darf die Versandbehörde nicht mehr nachfordern

Die Reihenfolge ist eine Einbahnstraße: Sobald die Versandbehörde ihr Vorbedingungs-Signal gesetzt hat, ist ihr Nachforderungsrecht verbraucht. Bestimmungs- und Durchfuhrbehörden können danach weiter nachfordern.

Vorbedingungs-Signale: ProperlyCarriedOut und ProperlyCompleted

Vor der Entscheidung stellen die Behörden fest, dass die Notifizierung aus ihrer Sicht in Ordnung ist. Beide Signale laufen über dieselbe Methode SubmitNotificationSignal, unterschieden allein durch Statement.Signal.TypeCode.

Die Reihenfolge ist strikt und für die Company-Seite folgenreich:

  1. Nach dem Einreichen kann nur die Versandbehörde am Dokument handeln. Alle anderen beteiligten Behörden sehen es, können aber nichts setzen.
  2. Die Versandbehörde fordert ggf. nach und setzt dann einmal ProperlyCarriedOut.
  3. Erst danach können Bestimmungs- und Durchfuhrbehörden nachfordern und je einmal ProperlyCompleted setzen.
  4. Wenn die letzte davon ProperlyCompleted gesetzt hat, wechselt der Status — und erst dann sind Entscheidungen zulässig.
Signal Wer Wie oft Vorbedingung
ProperlyCarriedOut Versandbehörde (WSRDISP) genau einmal Status Submitted
ProperlyCompleted Bestimmungsbehörde (WSRDEST), zusätzlich die Durchfuhrbehörden (WSRTRAN) je Behörde einmal ProperlyCarriedOut liegt vor

Signale sind unumkehrbar

Ein gesendetes Signal lässt sich weder zurücknehmen noch in seinen Parametern ändern. Das unterscheidet Signale von der Entscheidung, die aktualisierbar ist. Baue in deiner Oberfläche eine Rückfrage vor das Absenden — es gibt keine Korrektur danach.

Ein Sonderfall, mit dem eine Statusanzeige rechnen muss: Für Durchfuhrbehörden lässt der Durchführungsrechtsakt ein stillschweigendes ProperlyCompleted zu, wenn die Behörde innerhalb der Frist nicht nachgefordert hat und die Bestimmungsbehörde die Notifizierung als ordnungsgemäß abgeschlossen gekennzeichnet hat. Der Status kann sich also ohne ein Signal weiterbewegen, das du gesehen hättest.

Entscheidung (SetDecision)
Vorbedingung Alle Vorbedingungs-Signale liegen vor (Status Satisfied)
Wie oft Eine Entscheidung pro Behörde. Aktualisieren darf jede Behörde nur ihre eigene, beliebig oft
Pflichtfelder UserCompetentAuthorityDomainId, NotificationDocumentId, Decision (mit DecisionDate, DecisionType_, DecisionJustification)
Erstentscheidung nur CONSENT oder OBJECTED. WITHDRAWN ist als Erstentscheidung nur einer Durchfuhrbehörde erlaubt, und nur wenn die Notifizierung schon konsentiert ist und diese Behörde noch nicht entschieden hat
Aktualisierung alle drei Typen: CONSENT, OBJECTED, WITHDRAWN

Zusatzangaben je Typ: CONSENT kann über Decision.SpecificConditions die Zustimmung auf eine kleinere Masse (ConsentValidMass), ein kleineres Volumen (ConsentValidVolume) oder eine geringere Zahl von Verbringungen (ConsentValidShipmentCount) begrenzen, dazu ValidFromDate/ValidToDate. OBJECTED trägt die Begründung in Decision.ObjectionDescription. Eine Begründung in DecisionJustification ist immer Pflicht, unabhängig vom Typ.

Eine gedeckelte Zustimmung ist eine Zustimmung mit anderen Zahlen

Wer die SpecificConditions beim Auslesen ignoriert, plant Verbringungen gegen die ursprünglich beantragte Menge statt gegen die genehmigte — und läuft in eine Ablehnung des Movements. Zum Kontingent siehe Feldregeln.

→ Umsetzung mit dem .NET SDK

DecisionType_ — der Unterstrich ist kein Tippfehler

Das Feld DecisionType liegt in der Message DecisionType. Der Protobuf-Generator hängt in diesem Fall einen Unterstrich an, um die Namenskollision aufzulösen. In C# heißt das Feld deshalb DecisionType_.

Aus demselben Grund kollidieren die Proto-Messages DecisionType und SignalStatementType mit den gleichnamigen SDK-Hilfs-Enums. Im SDK-Beispiel zu SetDecision stehen DiwassDecisionType und CompetentAuthorityDomain für Aliase auf Zedal.Sdk.Apis.Diwass.Enums.*; ToWire() kommt aus DiwassEnumExtensions, die Kurzkonstruktoren Sf/DateUtc aus Zedal.Sdk.Protobuf.ProtoFields.

Woraus sich der Status der Notifizierung ergibt

Der Status ist nicht das Ergebnis eines einzelnen Vorgangs, sondern wird aus allen abgegebenen Entscheidungen neu berechnet — nach jeder Änderung.

Übergang Auslöser
Submitted → Satisfied Versandbehörde hat ProperlyCarriedOut gesetzt, Bestimmungs- und Durchfuhrbehörden haben ProperlyCompleted gesetzt
Satisfied → Consent alle beteiligten Behörden haben entschieden, und alle auf CONSENT (stillschweigende Zustimmung eingeschlossen)
Satisfied → Objected die erste Entscheidung vom Typ OBJECTED liegt vor
Consent → Objected eine Behörde ändert ihre Zustimmung in OBJECTED
Objected → Consent alle OBJECTED-Entscheidungen sind in CONSENT geändert und alle Behörden haben entschieden
Objected → Satisfied alle OBJECTED-Entscheidungen sind in CONSENT geändert, aber es fehlen noch Entscheidungen
Consent → Withdrawn eine Behörde zieht ihre Zustimmung zurück
Withdrawn → Consent alle zurückgezogenen Entscheidungen sind wieder Zustimmungen
Submitted → Invalid eine Behörde setzt NotificationInvalid
Invalid → Submitted dieselbe Behörde setzt NotificationRevalidated
Submitted/Consent/Objected → Cancelled der Notifizierende storniert

Wo diese Statusnamen wirklich stehen

Im Mutations-Datenmodell gibt es kein Status-Feld. In der Retrieval-Sicht dagegen schon: NotificationInformationType.notificationStatus ist dort Pflicht und im Schema auf DRAFT, SUBMITTED, SATISFIED, CONSENT, INVALID, WITHDRAWN, OBJECTED, CANCELLED eingeschränkt. Das Pendant am Movement ist GetMovementTemplateType.movementStatus mit DRAFT, ANNOUNCED, SUBMITTED, MOVING, RECEIVED, ACCEPTED, REJECTED, COMPLETED, CANCELLED, TAKE_BACK.

Beide sind Zeichenketten mit Schema-Wertemenge, kein C#-Enum. Und sie sagen dir wo der Vorgang steht, nicht was du als Nächstes tun darfst. Das steht in handler.FollowupIntents — siehe Zustand bestimmen.

Durchfuhrbehörden müssen nicht entscheiden

Die Zustimmung einer Durchfuhrbehörde kann stillschweigend eintreten: Sind seit dem Erreichen von Satisfied 30 Tage vergangen und haben Versand- und Bestimmungsbehörde zugestimmt, wechselt die Notifizierung nach Consent, auch wenn eine oder mehrere Durchfuhrbehörden nichts abgegeben haben. Das gilt nur, wenn die betreffenden Durchfuhrbehörden EU- oder EWR-Staaten vertreten.

Für deine Anwendung heißt das: „konsentiert” ist nicht gleichbedeutend mit „von jeder Behörde eine Consent-Entscheidung gesehen”. Wer den Consent über das Vorhandensein von N Entscheidungen berechnet, blockiert Verbringungen, die zulässig wären.

Antwort auf einen Änderungsantrag (ReplyToRequestForChangeAfterConsent)

Nach erteilter Zustimmung kann der Notifizierende Änderungen beantragen (Art. 17). Darauf antwortet jede beteiligte Behörde.
Vorbedingung Notifizierung konsentiert; ein Änderungsantrag liegt vor
Wie oft Jede Behörde antwortet auf denselben Antrag genau einmal. Die Antwort ist nicht änderbar
Pflichtfelder UserCompetentAuthorityDomainId, RequestForChangeAfterConsentId, AgreementChangeRouteRequest, Signature
Wirkung Erst wenn alle betroffenen Behörden zugestimmt haben, ist die beantragte Änderung wirksam

Das SDK prüft vor dem Versand, dass RequestForChangeAfterConsentId gesetzt ist und auf einen bekannten Antrag zeigt; sonst wirft es ArgumentException bzw. InvalidOperationException, ohne zu senden.

UnansweredRequestForChangeAfterConsent ist keine To-do-Liste für alle Behörden

Die Property handler.UnansweredRequestForChangeAfterConsent listet Änderungsanträge, zu denen noch keine Antwort verlinkt ist. Ein Antrag erwartet aber mehrere Antworten — typischerweise Versand- und Bestimmungsbehörde. Sobald die erste Behörde geantwortet hat, fällt der Antrag aus dieser Liste heraus, obwohl die zweite noch antworten darf und muss.

Nutze die Liste als Anzeige für „hier ist noch gar nichts passiert”, nicht als Prüfung, ob deine Behörde noch am Zug ist.

Signale auf Notifizierungsebene

Alle Signale gehen über SubmitNotificationSignal. Unterschieden werden sie über Statement.Signal.TypeCode; die zulässigen Werte stehen im SDK als Zedal.Sdk.Apis.Diwass.Enums.SignalStatementType.

TypeCode Wer Wann zulässig Wirkung
ProperlyCarriedOut Versandbehörde Status Submitted, einmal Vorbedingung für die Entscheidungen
ProperlyCompleted Bestimmungs- und Durchfuhrbehörden nach ProperlyCarriedOut, je einmal mit dem letzten Signal wechselt der Status nach Satisfied
NotificationInvalid jede beteiligte Behörde Status Submitted Status Invalid; das Dokument ist für alle nur noch lesbar — außer für die Behörde, die invalidiert hat
NotificationRevalidated dieselbe Behörde, die invalidiert hat Status Invalid zurück nach Submitted. Bereits gesetzte Vorbedingungs-Signale bleiben erhalten
RejectPreConsentedFacility jede beteiligte Behörde Status Submitted, Notifizierung war auf vorkonsentierte Anlagen ausgelegt der Vorkonsent-Indikator wird auf false gesetzt; danach ist der Vorgang nicht mehr verfügbar
NoPreConsentedFacilityTimeline jede beteiligte Behörde wie oben die Fristenlogik fällt auf den Normalablauf zurück statt auf den Vorkonsent-Ablauf (Art. 14 Abs. 16)
NotificationCancelled der Notifizierende, nicht die Behörde Status Submitted, Consent oder Objected Status Cancelled, endgültig lesend, kein Rückweg
NotificationWithdrawn der Notifizierende nicht belegt Rücknahme der Notifizierung. Ältere Stände der Proto-Definitionen kennen diesen Wert nicht; generiere deine Stubs gegebenenfalls neu
NotificationCompleted Behörde nicht belegt Abschluss der Notifizierung (Art. 27 Abs. 1)
MovementCancelled, Annex7Cancelled siehe Movement — gehören ans Movement- bzw. Annex-VII-Dokument, nicht an die Notifizierung

Der Signal-Datensatz ist immer gleich aufgebaut: Nummer des betroffenen Dokuments, TypeCode, optionaler Freitext (Statement.Description — bei einigen Typen Pflicht), Signatur der handelnden Person, optional Anhänge.

Zwei Vorgänge im Signal-Enum sind Sache des Notifizierenden

NotificationCancelled und NotificationWithdrawn sind über dieselbe SDK-Methode erreichbar, aber laut Spezifikation nur dem Notifizierenden erlaubt. Sie sind daher auch auf dem Company-Handler NotificationDocumentHandler.SubmitNotificationSignal verfügbar — dort ohne UserCompetentAuthorityDomainId, weil der Notifizierende keine Behörde ist. Wer die Company-Seite baut, findet das unter Notification (Company).

Movement: die behördlichen Eingriffe

Auf Movement-Ebene gibt es genau einen behördlichen Vorgang: die Rücknahme-Anordnung.

Rücknahme (SetMovementTakeBack)
Wer jede beteiligte Behörde — nicht nur Versand oder Bestimmung
Wann Movement im Status Announced, Moving oder Received
Wie oft eine Rücknahme pro Movement. Aktualisieren darf sie beliebig oft die Behörde, die sie eingereicht hat
Pflichtfelder UserCompetentAuthorityDomainId, MovementIdentifier, MovementTakeBack (mit Quantity, Reasons, TakeBackDate), CompetentAuthoritySignature
Wirkung Status wechselt nach Take back. Der Lebenszyklus endet dort — kein Empfang, kein Abschluss mehr

SetMovementTakeBack gibt es auch am Company-Handler — die Anordnung bleibt trotzdem behördlich

Die Methode gibt es auf AuthorityMovementDocumentHandler und auf MovementDocumentHandler, und die Permission-Matrix des SDK führt die Rücknahme-Intents (CreateMovementTakeBack, UpdateMovementTakeBack) auch für die Rolle Notifier. Nach der DiWaSS-Spezifikation ordnen die beteiligten Behörden die Rücknahme an.

Die Nutzlast setzt deshalb einen Behördenkontext voraus: UserCompetentAuthorityDomainId und CompetentAuthoritySignature sind im MovementTakeBackDocumentType Pflichtfelder. Ob die Rücknahme für dich zulässig ist, zeigt handler.FollowupIntents als Serversicht, nicht die Permission-Matrix.

SubmitMovementSignal ist die Stornierung des Notifizierenden

Das Signal-Enum führt auf Movement-Ebene genau einen Wert: MovementCancelled. Nach der Spezifikation darf ihn nur der Notifizierende setzen, und nur solange das Movement noch nicht unterwegs ist:
Wer der Notifizierende
Wann Status Draft oder Announced — nach Moving nicht mehr
Wirkung Status Cancelled

Die Methode ist auf beiden Handlern verfügbar. Für die Behördenseite ist sie nur dann interessant, wenn eine Behörde das Signal im Auftrag des Notifizierenden abgibt; UserCompetentAuthorityDomainId ist im MovementSignalDocumentType deshalb optional.

Wie eine Behörde identifiziert wird

Behörden sind in DiWaSS keine Operator-Partei. Sie haben keine OperatorInternalId, stehen in keinem der Beteiligten-Slots der Submission und lassen sich deshalb auch nicht aus einem Dokument ableiten. Für die Rollen-Inferenz des SDK heißt das: Role.Authority muss explizit übergeben werden.

Identifiziert wird eine Behörde auf drei verschiedenen Ebenen — die Unterscheidung ist Fehlerquelle Nummer eins:

Ebene Feld Werte
Rolle im Verfahren UserCompetentAuthorityDomainId an jedem Behördendokument WSRDISP (Versand), WSRTRAN (Durchfuhr), WSRDEST (Bestimmung) — SDK: CompetentAuthorityDomain
Organisation CompetentAuthorityType mit PartyUuid und CompetentAuthorityId fachlicher Behördencode, z. B. DE014
Verortung im Vorgang CompetentAuthority innerhalb von ExportState, ImportState und je TransitState der Submission pro betroffenem Land genau eine Behörde

Die dritte Zeile ist der Grund, warum eine Behörde ohne eigenen Party-Slot trotzdem „beteiligt” sein kann: Sie hängt am Land, nicht an der Beteiligtenliste. Wer die beteiligten Behörden einer Notifizierung ermitteln will, liest sie aus Export-, Import- und Transit-Staaten aus.

Die Domain-Codes gehören nicht ins Behördenverzeichnis

WSRDISP/WSRTRAN/WSRDEST sind Werte des Notifizierungsmodells. Das Behördenverzeichnis führt ein anderes Rollenfeld mit eigener Codeliste. Wertetabellen dazu: Codelisten → Behördenbereich.

Behörden suchen lässt sich über das Verzeichnis.

→ Umsetzung mit dem .NET SDK

Das Verzeichnis sagt nicht, wer Durchfuhrbehörde sein darf

ListAuthorities und FindActivities liefern die WSR-Behörden eines Landes, aber nicht, welche Notifizierungs-Domain eine Behörde abdeckt. Welche Behörde als Durchfuhrbehörde zulässig ist, musst du fachlich wissen. AUTHORITY-ID-NOT-FOUND ist deshalb eine Zuständigkeits-, keine Existenzaussage — Details unter Feldregeln → Zuständigkeit der Durchfuhrbehörde.

Beachte außerdem: Im Dokument steht der Ländercode dreistellig numerisch (056), im Verzeichnis-Lookup dagegen alpha-2 (BE). Ein numerischer Code liefert dort null Treffer ohne Fehlermeldung. Siehe Codelisten.

„Im Auftrag” handeln (OnBehalfOfCA)

Nicht jede Behörde ist an DiWaSS angeschlossen, und nicht jeder Beteiligte arbeitet im EU-System. Für diese Fälle trägt fast jedes Behördendokument ein optionales OnBehalfOfCa (OnBehalfCAType):

Feld Pflicht Inhalt
CompetentAuthorityId ja Behörde, für die gehandelt wird
CompetentAuthorityDomainId ja WSRDISP, WSRTRAN oder WSRDEST
CountryId nein Land der vertretenen Behörde

Verfügbar an AcknowledgementDocumentType, DecisionDocumentType, RequestInformationDocumentType, ReplyToRequestForChangeAfterConsentDocumentType, NotificationSignalDocumentType und MovementSignalDocumentType — nicht an MovementTakeBackDocumentType.

UserCompetentAuthorityDomainId bleibt dabei die Rolle der handelnden Behörde; OnBehalfOfCa benennt die vertretene. Der allgemeinere Typ OnBehalfOfType deckt zusätzlich die Vertretung eines Landes oder eines Operators ab und lässt genau einen der drei Zweige zu.

Was davon bei dir ankommt

Der Nutzen dieser Seite für eine Company-Integration steckt in dieser Tabelle: welcher Behördenvorgang was an deinem Dokument verändert.

Behördenvorgang Was du siehst Was sich für dich ändert
Eingangsbestätigung neue Version mit Eintrag in acknowledgement nichts — Bestätigung ist keine Zustimmung
Nachforderung Eintrag in requestInformation, neue Followup-Intents Du bist am Zug. Und: die Notifizierung ist wieder änderbar
ProperlyCarriedOut / ProperlyCompleted Eintrag in signals, geänderte Followup-Intents Sind alle gesetzt und keine Nachforderung offen, ist das Änderungsfenster zu
Entscheidung Eintrag in decisions je Behörde Erst wenn alle vorliegen (oder stillschweigend gelten), darfst du Movements anlegen. SpecificConditions beachten
Antwort auf Änderungsantrag Eintrag in replyRequestForChangeAfterConsent je Behörde Die Änderung greift erst, wenn alle zugestimmt haben
NotificationInvalid notificationStatus = INVALID Deine Notifizierung ist nur noch lesbar, bis dieselbe Behörde revalidiert
Rücknahme-Anordnung takeBack am Movement gesetzt Das Movement ist beendet. Kein Empfang, kein Abschluss mehr

Zwei Punkte, die dabei regelmäßig unterschätzt werden:

Fremde Änderungen brauchen Zeit — und den Inbox-Import

Rechne mit zwei bis drei Minuten, bis eine Änderung der Behörde in ZEDAL ankommt. Bis dahin liefert ein erneutes Laden das Ausgangsdokument ohne den Behördenblock. Der Inbox-Import ist dabei der Zustellweg, nicht bloß Aufräumen — ohne ihn erscheint die neue Version nicht. Siehe Aufrufe und Synchronisation.

Leite den Zustand nicht aus Listenlängen ab

Weder „so viele Entscheidungen wie beteiligte Behörden” noch „requestInformation länger als replyRequestInformation” ergibt einen verlässlichen Zustand: Zustimmungen können stillschweigend eintreten, und Antworten auf Nachforderungen landen in derselben Liste wie die Nachforderungen. Werte handler.FollowupIntents aus — die Liste kommt vom Server. Siehe Zustand bestimmen.

Was als Nächstes