Die Unterteilung der eBeschaffungsprozesskette in „Pre-Awarding“ und „Post-Awarding“ Phase wurde der Vollständigkeit halber mit aufgeführt. Sämtliche Prozesse nach Zuschlag an den Auftragnehmer sind nicht Teil der XVergabe-Kommunikationsschnittstelle und werden im Rahmen anderer Standardisierungsaktivitäten beschreiben (bspw. Steuerungsprojekt „E-Rechnung“ des IT-Planungsrats).

Mit XVergabe sind somit die Prozesse und Anwendungsfälle bis inkl. Zuschlag an den Auftragnehmer abbildbar. Eine Besonderheit bildet die Prozessgruppe „eNotice“, die den elektronischen Austausch von Bekanntmachungen beschreibt. Diese wird zwar durch eine XVergabe-Arbeitsgruppe technisch ausgeprägt, jedoch ist dies NICHT Teil der hier beschriebenen XVergabe-Kommunikationsschnittstelle.

Die XVergabe-Kommunikationsschnittstelle unterstützt somit die folgenden Prozessgruppen:

• eSubscription: Ein Wirtschaftsteilnehmer meldet sich innerhalb eines Vergabeverfahrens an, um Aktualisierung innerhalb des Verfahrens zu erhalten. Dies ist nicht mit einem Teilnahmeantrag o.ä. gleich zu setzen, sondern dient lediglich dazu einen Teilnehmer (technisch) einem Verfahren zuzuordnen. Die XVergabe-Kommunikationsschnittstelle bietet hierfür eine „subscribe“-Möglichkeit (Operation in der Schnittstelle), die von einem Bieterclient aufgerufen werden kann. Diese bildet die Grundlage für den weiteren Nachrichtenaustausch. Ein Teilnehmer kann ohne vorherige subscribe keine Kommunikation mit der Vergabeplattform (und somit der Vergabestelle) innerhalb des Vergabeverfahrens durchführen.
• eAccess: Diese Prozessgruppe umfasst den Zugang zu Auftragsunterlagen im Vergabeverfahren durch einen (angemeldeten) Teilnehmer. Im Rahmen der XVergabe-Kommunikationsschnittstelle stellt die Vergabeplattform der Bieteranwendung in Abhängigkeit des Vergabeverfahrens nach erfolgreicher Anmeldung (eSubscription) eine Nachricht zum Abruf bereit - entweder „InvitationToTender“ (ITT), wenn das Verfahren ohne vorgeschalteten Teilnahmewettbewerb abläuft, oder „InvitationToParticipation“ (ITP), wenn ein vorgeschalteter Teilnahmewettbewerb durchgeführt wird. Diese Nachricht kann ein Client über die XVergabe-Kommunikationsschnittstellen-Operation getMessages abrufen. Die Nachricht selbst enthält noch nicht die Auftrags- bzw. Teilnahmeunterlagen sondern lediglich Referenzen auf diese. Ein Client SOLL diese über die XVergabe-Kommunikationsschnittstellen-Operation getDocuments anschließend separat von der Plattform abrufen. Der Teilnehmer bzw. Bieter erhält somit in dieser Prozessgruppe alle für die Erstellung eines TNAs bzw. Angebots relevanten Auftrags- bzw. Teilnahmeunterlagen. Ebenso erfährt der Teilnehmer bzw. Bieter durch die ITP- bzw. ITT-Nachricht wie der Teilnahmeantrag bzw. das Angebot zu strukturieren, welche Bestandteile zu signieren, ob und wie TNA bzw. Angebot zu verschlüsseln und ob die TNA- bzw. Angebotsabgabe über die XVergabe-Kommunikationsschnittstelle selbst oder über OSCI-Transport erfolgen muss. Er wird somit in die Lage versetzt einen TNA bzw. ein Angebot aufzubereiten und die Einreichung durchzuführen.
• eEnquiry: Diese Prozessgruppe bildet die Bieterkommunikation innerhalb eines Verfahrens ab. Somit wird es ermöglicht, Bieterfragen zu stellen und die konsolidierten Antworten der Vergabestelle allen Bietern mitzuteilen. Ebenso wird hierdurch ein normaler Kommunikationsweg, auf dem die Vergabestelle mit dem Bieter kommunizieren kann eröffnet. Die XVergabe-Kommunikationsschnittstelle unterstützt dies durch so genannte „Inquiry“-Nachrichten, die der Bieter mittels der sendMessage-Operation der XVergabe-Kommunikationsschnittstelle an die Plattform übermittelt. Die Vergabestelle stellt Antworten ebenfalls als „Inquiry“-Nachrichten dem Bieter zum Abruf mittels getMessages zur Verfügung. Inquiry-Nachrichten können Anlagen enthalten bzw. referenzieren.
• eSubmission: Die Kernprozessgruppe im Vergabewesen zur Einreichung eines Angebots durch den Bieter. Wie oben bereits aufgeführt unterstützt die XVergabe-Kommunikationsschnittstelle zwei Möglichkeiten und überlässt der jeweiligen Plattform bzw. Vergabestelle die Wahl: Im Standardfall werden Angebote in einer „Offer“-Nachricht mittels sendSynchronousMessage-Operation der XVergabe-Kommunikationsschnittstelle an die Plattform zugestellt. Im Gegensatz zur sendMessage-Operation, die für eEnquiry genutzt wird, erhält die Bieteranwendung mit der sendSynchronousMessage-Operation direkt eine fachlich-inhaltliche Antwort zurück: die Zustellquittung der Plattform über den Eingang des Angebots. Wie das Angebot in der Offer-Nachricht aufzubauen ist, MUSS die Bieteranwendung aus der im Rahmen von eAccess bereitgestellten ITT-Nachricht entnehmen. Alternativ legt die Vergabeplattform bzw. Vergabestelle in der ITT-Nachricht fest, dass die Angebotsabgabe via OSCI-Transport erfolgen soll und definiert in der ITT-Nachricht auch die hierfür notwendigen technischen Parameter. In diesem Fall MUSS die Bieteranwendung das aufbereitete Angebot über einen definierten Ablauf unter Nutzung der getOSCITransferID-Operation der XVergabe-Kommunikationsschnittstelle und anschließender Übermittlung einer OSCI-Transport-Nachricht an den in der ITT-Nachricht definierten Zustellpunkt (OSCI-Intermediär) übertragen. 
  Über die Angebotsabgabe hinaus sind auch Teilnahmeantrags-Abgabe und Rückzüge von Angeboten bzw. TNAs zur Prozessgruppe eSubmission zu zählen. Die TNA-Abgabe läuft analog zur beschriebenen Angebotsabgabe ab: Im Falle der TNA-Einreichung via XVergabe-Schnittstelle wird eine „Participation“-Message via sendSynchronousMessage-Operation der XVergabe-Kommunikationsschnittstelle an die Plattform zugestellt und die Bieteranwendung erhält die Eingangsquittung von der Plattform zurück. Alternativ wird der TNA mittels OSCI-Transport wie beschrieben zugestellt. Im jeweiligen OSCI-Transport-Fall werden zwei Quittungen ausgestellt: Einmal bei der Einreichung des Angebots bzw. TNAs beim OSCI-Intermediär durch diesen – diese ist die rechtlich bindende Eingangsquittung. Zusätzlich MUSS ihm eine Zustellquittung im XVergabe-Datenmodell asynchron zum Abruf mittels getMessages-Operation der XVergabe-Kommunikationsschnittstelle zur Verfügung gestellt werden. Die Quittungen, die die Plattform nach dem XVergabe-Datenmodell ausstellen MUSS, MUSS – unabhängig davon ob der Zustellweg OSCI-Transport oder XVergabe-Kommunikationsschnittstelle war – eine Referenz auf das Angebot bzw. den TNA enthalten, unter der die Plattform das Angebot bzw. den TNA verwaltet. Diese Referenz MUSS der Bieter beim Rückzug des Angebots oder des TNAs angeben. Auch ein Rückzug wird analog zur Abgabe des Angebots bzw. des TNAs über die zwei beschriebenen Wege durch die XVergabe-Kommunikationsschnittstelle unterstützt. Sofern eine Plattform die Angebots- bzw. TNA-Abgabe via OSCI-Transport definiert, so SOLL sie eine Abgabe via XVergabe-Kommunikationsschnittstelle nicht zulassen. Weiterhin SOLL die Plattform dann auch den jeweiligen Rückzug via OSCI-Transport abbilden.
  Angebots- bzw. TNA-Rückzüge SOLLEN explizit erfolgen, d.h. es soll eine Rückzugsnachricht an die Plattform übermittelt werden.
• eAward: Zuschlagsmitteilungen bzw. Absagen werden von der Vergabestelle an die Bieter versendet. Die XVergabe-Kommunikationsschnittstelle unterstützt diese Prozesse durch den Nachrichtentyp „ResultNotice“. Diese Nachrichten werden durch die Vergabeplattform einer Bieteranwendung zum Abruf mittels getMessages-Operation angeboten. Im Positivfall enthalten sie die Zuschlagsentscheidung der Vergabestelle. Ebenso werden mittels ResultNotices auch die Ergebnisse des Ausgangs des Teilnahmewettbewerbs abgebildet. Werden also Teilnehmer nach Auswertung des Teilnahmewettbewerbs nicht zum Angebot aufgefordert, so SOLL die Plattform diesen Nutzern eine negative ResultNotice übermitteln. Positive ResultNotices können im Teilnahmewettbewerb entfallen – die zu berücksichtigenden Bieter erhalten im Rahmen von eAccess dann eine Aufforderung zur Angebotsabgabe (ITT).

Unterstützte Verfahrensarten

Mit der XVergabe-Kommunikationsschnittstelle sind derzeit die folgenden Verfahrensarten abbildbar:

Verhandlungsverfahren können lt. VOF und VOB auch unterschwellig angewandt werden, lt. VOL nur oberschwellig – die XVergabe-Kommunikationsschnittstelle unterscheidet dies nicht explizit bzgl. der Schwellwerte.

Preisanfragen werden nicht explizit aufgeführt, da diese in der Regel wie Freihändige Vergaben durchgeführt werden.

Auch Verfahren nach VSVgV werden nicht explizit aufgeführt. Die Klarstellung, dass es sich um Verfahren nach VSVgV handelt, erfolgt in der Regel in den Auftragsunterlagen direkt. Eine Auswirkung auf die Umsetzbarkeit innerhalb der XVergabe-Kommunikationsschnittstelle ist nicht gegeben. 

Weitere Verfahrensarten (insb. Wettbewerblicher Dialog, Interessensbekundungsverfahren mit Interessensbestätigung, Innovationspartnerschaften, Dynamisches Beschaffungssystem sowie Auktionen) werden im Rahmen der Weiterentwicklung der XVergabe-Kommunikationsschnittstelle hinsichtlich ihrer Umsetzung mit XVergabe geprüft.

Logischer Aufbau der XVergabe-Kommunikationsschnittstelle

Die nachfolgende Abbildung verdeutlicht den logischen Aufbau der Schnittstelle:

Image Removed

Image Added

Wie bereits ausgeführt, beschreibt die XVergabe-Kommunikationsschnittstelle eine SOAP Web-Service-Schnittstelle einer Vergabeplattform. Hierfür wird eine technische Beschreibung in Form einer WSDL-Datei als Teil der XVergabe-Kommunikationsschnittstelle bereitgestellt. Dieser Web-Service bildet die Transport-Ebene.

Die über die darin definierten Operationen auszutauschenden fachlichen Nachrichten bilden die nächste Ebene der XVergabe-Kommunikationsschnittstelle. Diese fachlichen Nachrichten werden im Datenmodell „Messages“ genannt. Sie unterscheiden sich von den Web-Service-Messages, weil sie vom Transportprotokoll (hier SOAP) abstrahieren und auch über andere Transportwege übermittelt werden können (bspw. OSCI-Transport).

Die Nachrichten selbst enthalten wiederum die fachlichen Informationen, die die innerste Ebene „Documents“ darstellen. Diese fachlichen Informationen sind vorerst soweit strukturiert, wie sie für eine Prozesssteuerung notwendig sind. Die eigentlichen Daten bleiben vorerst in binären Anlagen (bspw. PDF-Dokumenten) ausgelagert.

Anchor
bestandteile bestandteile

Bestandteile der XVergabe-Kommunikationsschnittstelle

Die XVergabe-Kommunikationsschnittstelle umfasst die Zusammenstellung der folgenden Artefakte:

• eine Menge von WSDL-Dateien, die die Web-Service-Schnittstelle definieren,
• eine Menge von kommentierten XML Schema Dateien, die die Datenstrukturen für den Datenaustausch definieren,
• eine Menge von HTML-Dateien, die die XML Schema Dateien (visuell) dokumentieren (technische Dokumentation), automatisiert generiert aus den XML Schema Dateien,
• das technische Datenmodell in Form von XÖV-profilierten UML-Klassendiagrammen, aus denen über die XÖV-Werkzeugkette die XML Schema Dateien generiert wurden,
• diese Dokumentation, 
• zukünftig auch: diese Dokumentation zusätzlich in englischer Sprache. 

WSDL-Dateien

Folgende WSDL-Dateien sind Bestandteil der XVergabe-Kommunikationsschnittstelle und MÜSSEN von einer XVergabe-konformen Plattform implementiert werden:

XML Schema Dateien

Folgende XML Schema Dateien sind Bestandteil der XVergabe-Kommunikationsschnittstelle und MÜSSEN von einer XVergabe-konformen Plattform implementiert werden:

Technische Dokumentation (HTML)

Die technische Dokumentation wird aus den XML Schema Dateien in Form einer HTML-Datei (doc/html/xvergabe-service.html) automatisch generiert. Sie enthält einen Großteil der Dokumentation und Spezifikation der XVergabe-Kommunikationsschnittstelle. Sie beschreibt die Datentypen, Dokumente, Nachrichten und deren Attribute im Detail. 

Technisches Datenmodell

Das technische Datenmodell wird als MagicDraw-Projektdatei (derzeit: MagicDraw Version 16.8) bereitgestellt (magicdrawsource/xvergabe_2015.mdzip). Die Projektdatei enthält XÖV-profilierte UML-Klassendiagramme, aus denen die oben aufgeführten XML Schema Dateien automatisiert generiert werden (können) – mit Ausnahme der unter „build/ext“ extern eingebundenen XML Schema Dateien. Für die Projektdatei sowie die automatische Generierung von XML Schema Dateien enthält das Verzeichnis zusätzlich notwendige Dateien, die entweder von MagicDraw oder von der XÖV-Werkzeugkette benutzt werden.

Web-Service

Nachfolgend wird der in der XVergabe-Kommunikationsschnittstelle definierte Web-Service kurz beschrieben. Der Web-Service wird technisch durch zwei WSDL 1.1 Dateien (siehe oben) beschreiben und sieht als Kommunikationsprotokoll SOAP 1.2 vor. Fehler werden nicht auf Ebene von SOAP als SOAP-Faults definiert, sondern Transport-Unabhängig auf Nachrichten- bzw. Dokumentenebene (ResponseDocument), die Responses auf SOAP-Ebene nutzen jedoch das ResponseDocument. Somit werden ggf. auftretende Fehler innerhalb des SOAP-Bodys transportiert.

Operationen

Die Kommunikation mit dem Webservice wird immer durch die Bieteranwendung ausgelöst. Er bietet die folgenden Operationen, die immer aus einer jeweiligen Request- (Anfrage) und Response- (Antwort) Nachricht bestehen. Die nähere Definition der Requests und Responses ist der technischen Dokumentation zu entnehmen.

Generell gilt für alle Operationen:

• Die aufrufende Bieteranwendung MUSS von der Plattform als XVergabe-konformer Client authentifiziert werden. Dies wird mittels HTTPS-Clientauthentifizierung und Überprüfung auf Verwendung eines vom BeschA ausgestelltem Zertifikat sichergestellt.
• Die Nachricht der Bieteranwendung MUSS von der Plattform auf syntaktische und inhaltliche Korrektheit hin (bspw. ob die referenzierten Anlagen (und nur diese) in der Nachricht vorhanden sind) überprüft werden. Entsprechende Verstöße sind mittels eines Errorcodes in der jeweiligen Response anzuzeigen.
• Der aufrufende Nutzer der Bieteranwendung MUSS durch die Plattform authentifiziert werden, um die Zuordnung von Nachrichten und Verfahren für und von dem Nutzer abzubilden. Authentifizierungsfehler müssen von der Plattform durch einen entsprechenden ERROR-Code angezeigt werden. Die Plattform KANN zusätzlich in der jeweiligen Response auf eine Plattform-spezifische Web-Seite verweisen, mit der die Authentifizierungsmittel überprüft bzw. geändert werden können (bspw. Seite für Passwortänderungen). 
  Sofern die Operation ohne Authentifizierungsmittel (also ohne Username-Token) des Bieters aufgerufen wird, MUSS die Plattform einen entsprechenden Errorcode in der Response zusammen mit einer URL zur Registrierungs-Webseite angeben, damit ein Nutzer der Bieteranwendung in die Lage versetzt wird, die Registrierung dort durchzuführen und in den Besitz von Nutzername und Passwort zu kommen, aus dem das Username-Token gebildet werden kann.
• Der aufrufende Nutzer MUSS für die jeweilige Aktion autorisiert werden, d.h. es MUSS bspw. überprüft werden, ob der Nutzer für das angegebene Vergabeverfahren berechtigt ist, die entsprechende Aktion auszuführen oder ob der Benutzer berechtigt ist auf ein angegebenes Dokument zuzugreifen. Sofern ein Autorisierungsverstoß festgestellt wird MUSS die Plattform dies der Bieteranwendung durch einen entsprechenden Errorcode anzeigen.
• Die Plattform MUSS sicherstellen, dass die Operation und darüber transportierte Nachricht innerhalb des Verfahrensstatusmodells zulässig ist. Verstöße dagegen MÜSSEN der Bieteranwendung durch einen Errorcode angezeigt werden. Bestimmte Anwendungsfälle im Verfahrensstatusmodell obliegen der Auslegung der Vergabeplattform bzw. Vergabestelle (bspw. Annahme eines abgegebenen Angebots nach Angebotsfrist aber vor Zuschlag). Solche werden in der Regel mit einem Warningcode ggü. der Bieteranwendung angezeigt.

Absicherung des Services

Die XVergabe-Kommunikationsschnittstelle definiert für den Web-Service eine Sicherheitspolicy nach dem Web Services Policy Standard unter Verwendung des WS-Security Policy Standards. Diese Policy MUSS von der Plattform umgesetzt werden, die die XVergabe-Kommunikationsschnittstelle anbietet. Diese Policy wird an die Bieteranwendung als Teil der Servicebeschreibung mit ausgeliefert.

Hierbei werden folgende Sicherheitsziele adressiert und wie beschrieben umgesetzt:

• Die Vertraulichkeit der Kommunikation MUSS mittels Absicherung der http-Verbindung über SSL (HTTPS) umgesetzt werden. Hierzu wird die „HTTPS_policy“ in der WSDL:Binding-Definition geführt.
• Die Authentizität der Bieteranwendung (XVergabe-Konformität) MUSS mittels https-Clientauthentifizierung umgesetzt werden. Hierzu MUSS sich die Bieteranwendung eines Zertifikats bedienen, welches das BeschA nach erfolgreicher Konformitätsprüfung an den Hersteller vergibt. Eine Plattform MUSS somit das bei der Clientauthentifizierung präsentierte Zertifikat auf den Aussteller „BeschA“ hin überprüfen. Details hierzu regelt die Konformitätsprüfung.
• Für die Authentizität der Plattform MUSS diese für die HTTPS-Verbindung ein Plattformspezifisches Zertifikat präsentieren. Dieses Zertifikat SOLL von einer vertrauenswürdigen Zertifizierungsstelle (bzw. einer solchen, die in den entsprechend verteilten CA-Listen enthalten ist) ausgestellt worden sein, um Warnungen vorzubeugen, die den Bieter irritieren können.
• Für die Authentizität des Nutzers SOLL die Bieteranwendung in den oben aufgeführten Operationen ein Username-Token im WSA-Security-Header jeder SOAP-Nachricht mitführen. Das Username-Token wird aus dem Benutzernamen und SHA512-gehashten (ohne salt) Passwort des Nutzers für die jeweilige Plattform gebildet. Aufgrund bekannter Interoperabilitätsprobleme zwischen .NET und WCF-basierten Web-Service-Implementierung, SOLL eine Bieteranwendung nicht das „type“-Attribut des „password“-Elements im Username-Token verwenden.

Nachrichten und Dokumente

Nachrichtenaufbau

Die über die XVergabe-Kommunikationsschnittstelle ausgetauschten Nachrichten sind generell immer nach folgendem Schema aufgebaut:

Image RemovedImage Added

Die jeweilige Nachricht enthält neben dem auszutauschenden fachlich-inhaltlichen Informationen (Document, je nach Nachricht spezifisch) auch einen Nachrichtenkopf (MessageHeader). Dieser enthält eine Reihe von Informationen, die zur Steuerung der Nachricht notwendig sind, u.a.:

• eindeutige Nachrichten-ID der Nachricht
• eindeutige Verfahrens-ID, auf die sich die Nachricht bezieht, d.h. die Referenz des Verfahrens in dem die Nachricht übermittelt wird.
• Informationen zum Absender der Nachricht und dessen eingesetzter Anwendung/Software (Herstellername, Produktname, Produktversion, Verweis auf eine Webseite mit Informationen zum Support)

Weiterhin kann die Nachricht im Nachrichtenkopf so genannte Credential-Items aufnehmen. Diese transportieren in der Regel das zu verwendende Schlüsselmaterial für die Verschlüsselung bzw. für die OSCI-Transport-Kommunikationsparameter notwendigen Intermediärs- und Postfachzertifikate. Credential Items SOLLEN Plattform-seitig also nur bei ITP- und ITT-Nachrichten eingesetzt werden. Bieteranwendungs-seitig SOLLEN Credential-Items lediglich für den Transport des asymmetrisch verschlüsselten symmetrischen Schlüssels bei der Hybrid-Verschlüsselung dienen (in einer Offer- bzw. Participation-Nachricht).

Nachrichten von einer Bieteranwendung KÖNNEN in Abhängigkeit der konkreten Nachricht auch Anlagen enthalten. Diese werden parallel zum MessageHeader und zum Document geführt und sind somit Bestandteil der Nachricht.

Anchor
strukturierungITTITP strukturierungITTITP

Strukturierung im ITT bzw. ITP

Wie oben ausgeführt dienen die ITT- bzw. ITP-Nachrichten der Strukturierung der Auftrags- bzw. Teilnahmeunterlagen und der Definition der Struktur des erwarteten Angebots bzw. des TNAs. Nachfolgend soll kurz charakterisiert werden, wie dies durch die XVergabe-Kommunikationsschnittstelle umgesetzt wird.

Die Auftrags- bzw. Teilnahmeunterlagen bestehen in der ITT bzw. ITP aus mindestens einem oder mehreren Dokumenten mit folgenden Informationen:

• Eindeutige Dokumenten-ID, welche in einem Angebot/TNA referenziert werden kann. Die Dokumenten-ID wird weiterhin im Rahmen der Versionierung der Unterlagen benötigt, um Bieteranwendungs-seitig feststellen zu können, ob sich das betreffende Dokument verändert hat (zur Versionierung siehe Kapitel „Versionierung von Auftrags- und Teilnahmeunterlagen“).
• Dokumentenbezeichnung unter der die Bieteranwendung das Dokument dem Nutzer anzeigen SOLL.
• optionale, durch die Vergabestelle zu vergebende Dokumentenkategorie-Bezeichnung.
• optionale, durch die Vergabestelle festzulegende Ordnungsnummer (Sortierung) des Dokuments innerhalb der Kategorie
• sofern für das Öffnen des Dokuments eine spezielle Software benötigt wird: Ein Verweis (URL) auf eine Webseite, die Informationen über die Software sowie deren Bezug enthält
• Differenzierung:
  • ob es sich um ein Dokument handelt, welches die Vergabestelle über die Plattform dem Bieter/Teilnehmer zur Verfügung stellt (Teil der Auftrags- bzw. Teilnahmeunterlagen), bspw. ein Formular
    • Veröffentlichungszeitpunkt (für Versionierung des Dokuments notwendig)
    • Name des Dokuments
    • Dateigröße
    • Dokumenten-Referenz zum Abruf via getDocument-Operation
    • Angabe, ob das Dokument als Bestandteil des Angebots/TNAs einzureichen/zurückzugeben ist (oder beim Bieter/Teilnehmer verbleibt)
    • sofern notwendig: Angaben wie das Dokument umzuwandeln ist (bspw. notwendig für GAEB-Dateien):
      • optionaler Zieldateiname
      • optionale Zieldateiendung
      • optionaler Ziel-MIME-Type
      • optionaler Verweis (URL) auf eine Webseite, die Informationen über die Software sowie deren Bezug enthält, mit der die Transformation abgebildet werden kann
  • ob es ein Dokument ist, was der Bieter/Teilnehmer (ohne Vorlage) beibringen SOLL:
    • Name des Dokuments
    • Beschreibung des Dokumenteninhaltes, der im Angebot/TNA erwartet wird
    • sofern das Dokument durch den Bieter/Teilnehmer als Teil des Angebots/TNAs einzureichen/zurückzugeben ist:
      • Angabe, ob das Dokument signiert werden SOLL
      • Angabe, ob das Dokument in den primaryContainer eingebracht werden soll

Dokumente ohne Nachricht

Über die vorgenannten Nachrichten und Dokumente hinaus definiert die XVergabe-Kommunikationsschnittstelle zwei weitere Dokumente, welche nicht über Nachrichten ausgetauscht werden.

Diese zwei Dokumente (OfferContent bzw. ParticipationContent) beschreiben ein Datenmodell für jeweils eine XML-Datei (OfferContent.XML bzw. ParticipationContent.XML), die als Meta-Datei Teil des (verschlüsselten) Angebots- bzw. TNA-Containers sein MUSS. Eine Bieteranwendung MUSS diese Datei somit erzeugen und in die Angebotscontainer vor Verschlüsselung einstellen. Sofern eine Containersignatur im ITT bzw. ITP seitens der Vergabeplattform gefordert wurde, so MUSS die Bieteranwendung diese Datei (und NUR diese) mit dem geforderten Signaturniveau elektronische signieren. Wird keine Containersignatur gefordert SOLL die entsprechende Datei nicht signiert werden. Die Datei MUSS in den jeweiligen primaryContainer eingestellt werden. Sie DARF NICHT im secondarycontainer geführt werden. Die Datei SOLL bei Öffnung des Angebots/des TNAs durch die Plattform/das Vergabemanagementsystem ausgewertet werden können. Eine darauf aufbauende Kommunikation in Richtung des Bieters/Teilnehmers ist in der XVergabe-Kommunikationsschnittstelle nicht vorgesehen.

Die Dokumente enthalten folgende Informationen:

• Titel des Angebots/des TNAs (vergeben durch den Bieter/Teilnehmer)
• Erstellungszeit der Datei (Bieter-/Teilnehmer-seitig)
• Eine Auflistung ALLER Dateien, die der TNA bzw. das Angebot umfasst (nicht nur bezogen auf den primaryContainer):
  • Dateiname
  • Zuordnung zu der (bzw. zu ggf. mehreren) geforderten Dokumenten-ID aus der ITT/ITP
  • SHA-512 Hashwert der Datei
• bei OfferContent zusätzlich:
  • Angabe ob es sich um ein Hauptangebot handelt
  • sofern zutreffend: Angabe des oder der Lose, auf die sich das Angebot bezieht

Anchor
verfahrensstatusmodell verfahrensstatusmodell

Verfahrensstatusmodell

Ein Vergabeverfahren durchläuft unterschiedliche Phasen, die eine Plattform über die XVergabe-Kommunikationsschnittstelle mitteilen MUSS, da hiervon die weitere Steuerung der möglichen und notwendigen Nachrichtenarten abhängt. Darüber hinaus dient das Status-Modell auch der informatorischen Anzeige ggü. dem Bieter.

Der Phasen- bzw. Statusübergang in Abhängigkeit von Entscheidungspunkten im Verfahren wird durch nachfolgende Abbildung verdeutlicht:

Image RemovedImage Added

Beschreibung der Phasen und Status

Participation Phase

Dies ist der initiale Status eines Verfahrens mit Teilnahmewettbewerb. Daher DARF dieser Status NICHT für Verfahren ohne TNW genutzt werden (bspw. offenes Verfahren). Innerhalb dieser Phase erstellen die potentiellen Teilnehmer basierend auf den bereitgestellten Teilnahmeunterlagen eigene Teilnahmeanträge und reichen diese auf der Plattform ein.

Diese Phase endet mit der Frist zur Einreichung von Teilnahmeanträgen. Wird diese Frist erreicht, MUSS eine Plattform den Verfahrensstatus auf „Participation Evaluation Phase“ ändern und dies durch das Versenden einer aktualisierten TMI-Nachricht an alle am Verfahren angemeldeten Nutzer bekanntgeben.

In diesem Status MUSS die Plattform alle WebService-Operationen sowie alle darin übermittelten Nachrichten und Dokumente unterstützen. Sie KANN jedoch Nachrichten zur Angebotseinreichung bzw. -rückzug ablehnen.

Participation Evaluation Phase

In der “Participation Evaluation Phase” eines Verfahrens werden die eingereichten Teilnahmeanträge ausgewertet. Sie MUSS somit mit der Erreichung der TNA-Einreichungs-Frist beginnen. Die Phase DARF KEIN valider Ausgangs- bzw. Start-Status eines Verfahrens sein und DARF NUR bei Verfahren mit Teilnahmewettbewerb auftreten.

In dieser Phase MUSS eine Plattform alle WebService-Operationen mit Ausnahme der subscribe-Operation unterstützen. Die Plattform MUSS weiterhin alle austauschbaren Nachrichten und Dokumente unterstützen. Sie KANN jedoch Nachrichten zur Angebotseinreichung bzw. -rückzug ablehnen. Die (verspätete) Einreichung von Teilnahmeanträgen bzw. deren Rückzüge KANN durch eine Plattform weiterhin auch nach Erreichen der TNA-Einreichungsfrist unterstützt werden.

Diese Phase endet mit der Auswahl derjenigen Bieter, die zur Angebotserstellung aufgefordert werden sollen. Die Plattform MUSS den Statuswechsel durch das Versenden einer aktualisierten TMI an alle am Verfahren angemeldeten Teilnehmer anzeigen. Mit Bereitstellung einer TMI MUSS sie ebenfalls Invitation To Tender Nachrichten (Aufforderungen zur Angebotsabgabe), die die Vergabeunterlagen enthalten, an die ausgewählten Bieter sowie Result Notices an die nicht ausgewählten Teilnehmer bereitstellen.

Bidding Phase

Die “Bidding Phase” eines Verfahrens ist die Phase, in der die Vergabeunterlagen den (ggf. zuvor ausgewählten) Bietern zugänglich gemacht werden und in der die Angebote der Bieter erstellt und eingereicht werden.

Es muss hinsichtlich der Durchführung eines Teilnahmewettbewerbs unterschieden werden:

• Wird das Verfahren ohne Teilnahmewettbewerb abgewickelt (bspw. offenes Verfahren):
  • So MUSS diese Phase den initialen Status eines Verfahrens darstellen.
  • Die Plattform MUSS alle WebService-Operation inkl. subscribe unterstützen.
• Sofern das Verfahren mit Teilnahmewettbewerb durchgeführt wird:
  • MUSS dieser Status auf die „Participation Evaluation Phase“ folgen.
  • Die Plattform MUSS alle WebService-Operation mit Ausnahme der subscribe-Operation unterstützen.

Der Beginn dieser Phase MUSS die Bereitstellung einer TMI-Nachricht angezeigt werden. Ebenso MÜSSEN den (ggf. durch TNW ausgewählten) Bietern die Vergabeunterlagen mittels ITT-Nachricht bereitgestellt werden.

Handelt es sich um Verhandlungsverfahren, so MUSS aus TMI und ITT die Verhandlungsrunde eindeutig hervorgehen. Die Angaben MÜSSEN in Abhängigkeit des Fortschritts des Verhandlungsverfahrens NICHT übereinstimmen.

Weiterhin MUSS die Plattform alle Nachrichten/Dokumente AUSGENOMMEN denen zur Einreichung bzw. Rückzug von Teilnahmeanträgen unterstützen.

Diese Phase endet mit Erreichen der Angebotseinreichungsfrist und MUSS durch die Plattform durch Bereitstellung einer aktualisierten TMI Nachricht an alle am Verfahren angemeldeten Teilnehmer angezeigt werden.

Tender Evaluation Phase

In der “Tender Evaluation Phase” werden die durch die Bieter eingereichten Angebote durch die Vergabestelle ausgewertet. Diese Phase MUSS mit Erreichen der Angebotseinreichungsfrist beginnen und durch das Versenden einer aktualisierten TMI an alle Verfahrensteilnehmer angezeigt werden.

In dieser Phase MÜSSEN alle WebService-Operationen mit AUSNAHME der subscribe-Operation durch die Plattform unterstützt werden. Ebenso MÜSSEN alle Nachrichten- und Dokumente mit AUSNAHME von TNA-Einreichungen und -Rückzügen unterstützt werden. Eine Plattform SOLL weiterhin die Nachrichten zur Angebotsabgabe und -Rückzug auch nach Erreichen der Angebotseinreichungsfrist unterstützen.

Die Phase endet mit dem Bereitstellen einer aktualisierten TMI an alle Verfahrensteilnehmer. Dies bedeutet auch, dass die Result Notices, welche den Zuschlag an den ausgewählten Bieter bzw. die Absage an die unterlegenen Bieter innerhalb dieser Phase übermittelt werden MÜSSEN.

Handelt es sich beim Vergabeverfahren um ein Verhandlungsverfahren kann auf die Tender Evaluation Phase eine neue Bidding Phase folgen. Dies muss durch das Hochzählen des Verhandlungsrundenzählers im TMI angezeigt werden.

Closed

Dieser Verfahrensstatus wird mit dem Zuschlag vergeben. In dieser “Phase” MUSS das Verfahren für die Verfahrensteilnehmer sichtbar bleiben und noch weitere (Bieter-) Kommunikation ermöglichen. Über den Zeitraum, für wie lange nach dem Zuschlag dieser Status aufrechterhalten bleiben muss, entscheidet die Vergabestelle bzw. deren Vergabeplattform.

In dieser Phase des Verfahrens SOLL die Plattform lediglich die WebServices-Operationen und die darin auszutauschenden Nachrichten und Dokumente unterstützen, die für eine Bieterkommunikation notwendig sind. Dies bedeutet die Plattform MUSS die Operationen „sendMessage“, „getMessages“, „getDocument“ und „getTenderIDs“ für das Verfahren unterstützen. Die Operationen „sendSynchronousMessage“ und „getOSCITransferID“ MUSS eine Plattform für ein Verfahren dieses Status mit einem Errorcode zurückweisen, da sie lediglich der Angebots- bzw. TNA-Einreichung bzw. deren Rückzügen dienen. Ebenso KANN die Plattform die subscribe-Operation unterbinden, um nicht weitere (unnötige) Anmeldungen zu diesem Verfahren zu ermöglichen.

Weiterhin MUSS die Plattform lediglich Inquiry-Nachrichten/Dokumente für das Verfahren unterstützen. Die weiteren Nachrichten/Dokumente MUSS sie ablehnen.

Die Phase endet mit der Entscheidung der Vergabestelle bzw. -plattform, das Verfahren zu archivieren. Dies wird einem Teilnehmer (bzw. dessen Client) nicht explizit angezeigt. Durch das Archivieren des Verfahrens wird es via XVergabe-Kommunikationsschnittstelle nicht mehr zugänglich gemacht.

Cancelled

Wenn eine Vergabestelle entscheidet, das Verfahren einzustellen bzw. aufzuheben, so MUSS diese Entscheidung technisch durch die Bereitstellung einer aktualisierten TMI-Nachricht an alle Verfahrensteilnehmer bekanntgemacht werden. Die Phase/Status ist identisch zum Status „CLOSED“, macht jedoch den Fakt der Aufhebung explizit deutlich.

Archived

Dies ist kein “offizieller” Verfahrensstatus aus Sicht der XVergabe-Kommunikationsschnittstelle, sondern eher ein aus Sicht der Plattform interner Verfahrensstatus. In diesem ist das Verfahren für den Zugriff via XVergabe nicht (mehr) sichtbar. Für ein archiviertes Verfahren stehen somit keine WS-Operationen zur Verfügung und MÜSSEN von der Plattform somit abgewiesen werden.

Die Entscheidung, wann ein Verfahren archiviert wird, obliegt der Vergabestelle bzw. deren -plattform.

Der Ablauf ist schematisch in nachfolgender Abbildung zusammengefasst:

Image RemovedImage Added