...
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:
Mit der XVergabe-Kommunikationsschnittstelle sind derzeit die folgenden Verfahrensarten abbildbar:
Verfahrensart | Bezeichnung in der XVergabe-Kommunikationsschnittstelle |
---|---|
Unterschwellige Verfahrensarten | |
Freihändige Vergabe | SINGLE_TENDER_ACTION |
Freihändige Vergabe mit Teilnahmewettbewerb | SINGLE_TENDER_ACTION_WITH_PARTICIPATION_CONTEST |
Öffentliche Ausschreibung | PUBLIC_TENDER |
Beschränkte Ausschreibung | RESTRICTED_TENDER |
Beschränkte Ausschreibung mit Teilnahmewettbewerb | RESTRICTED_TENDER_WITH_PARTICIPATION_REQUEST |
Verhandlungsverfahren | NEGOTIATED_PROCEDURE |
Verhandlungsverfahren mit Teilnahmewettbewerb | NEGOTIATED_PROCEDURE_WITH_PARTICIPATION_REQUEST |
Oberschwellige Verfahrensarten | |
Offenes Verfahren | OPEN_PROCEDURE |
Nicht-Offenes Verfahren mit Teilnahmewettbewerb | RESTRICTED_PROCEDURE |
Verhandlungsverfahren | NEGOTIATED_PROCEDURE |
Verhandlungsverfahren mit Teilnahmewettbewerb | NEGOTIATED_PROCEDURE_WITH_PARTICIPATION_REQUEST |
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.
Die nachfolgende Abbildung verdeutlicht den logischen Aufbau der Schnittstelle:
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 | ||||
---|---|---|---|---|
|
Die XVergabe-Kommunikationsschnittstelle umfasst die Zusammenstellung der folgenden Artefakte:
Folgende WSDL-Dateien sind Bestandteil der XVergabe-Kommunikationsschnittstelle und MÜSSEN von einer XVergabe-konformen Plattform implementiert werden:
Datei | Namespace | Beschreibung |
build/wsdl/xvergabe-service.wsdl | Definition der Operationen der XVergabe-Kommunikationsschnittstelle. Eine Plattform MUSS den darin definierten XVergabeService bzw. dessen Port „XVergabePort“ mit einer konkreten Adresse parametrisieren, unter der die Plattform den Dienst anbietet. Um Probleme aufgrund von Firewallrestriktionen bieterseitig zu minimieren, SOLL der Port auf einem HTTP- bzw. HTTPS-Standardport (also 80 oder 443) oder einem jeweiligen Alternativport (also 8080 oder 8443) erreichbar gemacht werden. | |
build/wsdl/service_policy.wsdl | Ausgelagerte Security Policies des Web-Services (bspw. bzgl. HTTPS-Binding oder Authentifizierung mittels UserName-Token). Diese Policies MÜSSEN unverändert implementiert werden. |
Folgende XML Schema Dateien sind Bestandteil der XVergabe-Kommunikationsschnittstelle und MÜSSEN von einer XVergabe-konformen Plattform implementiert werden:
Datei | Namespace | Beschreibung |
build/xsd/xvergabe-codelists.xsd | definierte Codelisten (Wertelisten, Aufzählungswerte) die in den übrigen Schnittstellen-Komponenten genutzt werden (bspw. Code.ProcedureType für Verfahrensarten) | |
build/xsd/xvergabe-datatypes.xsd | eigens definierte Basisdatentypen, die in den übrigen Schnittstellen-Komponenten genutzt werden (bspw. GUID). | |
build/xsd/xvergabe-documents.xsd | fachliche Dokumente, die über in den Nachrichten über die Schnittstelle ausgetauscht werden | |
build/xsd/xvergabe-messages.xsd | Transport-unabhängige Definition der Nachrichten, die die fachlichen Dokumente über die Schnittstelle austauschen. | |
build/xsd/xvergabe-service.xsd | Definition der Datentypen, die von der WSDL-Beschreibung zur Transport-spezifischen Definition der WebService-Nachrichten genutzt werden. | |
build/ext/xhtml1-transitional-redefined.xsd | Die Redefinition eines XHTML 1.0 Datentyps zur eingeschränkten Strukturierung von formatiertem Text. Die Redefinition wurde außerhalb des technischen Datenmodells erstellt, da dies durch das technische Datenmodell nicht unterstützt wird. | |
build/ext/xhtml1-transitional-redefined-basictype.xsd | http://xvergabe.org/client-interface/basic-xhtml-redefinition/4 | die Datentypdefinition als Einschränkung des redefinierten Datentyps zur eingeschränkten Strukturierung von formatiertem Text. Wird vom technischen Datenmodell referenziert und eingebunden (XÖV-Adapter). |
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.
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.
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.
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 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 über die XVergabe-Kommunikationsschnittstelle ausgetauschten Nachrichten sind generell immer nach folgendem Schema aufgebaut:
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.:
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 | ||||
---|---|---|---|---|
|
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:
Ü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:
Anchor | ||||
---|---|---|---|---|
|
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:
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.
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.
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:
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.
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.
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.
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.
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:
Anchor | ||||
---|---|---|---|---|
|
...