Ein Verfügbarkeitsplan für ein Vergabeportal verbindet ein bestimmtes Verfahren, seine aktuelle Fassung, das Los und die Abgabeart mit einer datierten Beobachtung des offiziellen Plattformstatus. Er hält Wortlaut, Quelle, Prüfzeit, angekündigten Zeitraum, betroffene Funktion und Zeitzonengrundlage fest. Danach bewertet er getrennt, ob die Wartung die Arbeitszeit, den internen Abgabezeitpunkt, den Sicherheitspuffer oder die Auftraggeberfrist berührt und ob die Vergabeunterlagen einen Ausweichweg erlauben. Der Plan bleibt lesend. Er meldet sich nicht an, lädt nichts hoch und ändert weder Frist noch Abgabeweg.
Wartungsmeldungen sind bewegliche Betriebsinformationen. Ein angekündigtes Fenster kann verkürzt, verschoben oder entfernt werden. Manche Meldungen nennen Uhrzeiten, aber keine Zeitzone oder betroffene Anwendung. Gleichzeitig führt das Verfahren eine verbindliche Angebotsfrist, das Team einen früheren Zieltermin und der technische Helpdesk eigene Geschäftszeiten. Werden diese Angaben in einem einzigen Kalendertermin zusammengezogen, ist später weder die Rechtsquelle noch die Risikorechnung nachvollziehbar. Besonders gefährlich ist der Schluss, ein Supportkontakt dürfe wegen einer Wartung Angebote entgegennehmen.
Die Wartungsseite beschreibt den erwarteten Betrieb; Bekanntmachung, Aufforderung und Änderungen regeln das Verfahren. Ein Agent muss beide Ebenen verbinden, darf sie aber nicht verschmelzen. Die aktuelle Statusmeldung wird als Beobachtung mit Ablaufdatum gespeichert. Eine Uhrzeit wird erst dann in einen eindeutigen Zeitpunkt umgerechnet, wenn die Zeitzone belegt ist. Der interne Vorlauf darf verschärft werden. Ein anderer Übermittlungsweg, eine Fristverschiebung oder eine technische Probe erfordert dagegen eine ausdrückliche Verfahrensregel beziehungsweise einen gesonderten Auftrag.
Kurzantwort
Wartung verkürzt nutzbare Zeit, aber nicht automatisch die Angebotsfrist
Eine angekündigte Wartung kann genau in den Zeitraum fallen, den das Team für Verschlüsselung, Upload oder Kontrolle eingeplant hat. Dann steigt das Abgaberisiko. Die in Bekanntmachung, Aufforderung oder Änderung festgelegte Empfangsfrist bleibt trotzdem bestehen, bis der Auftraggeber sie wirksam ändert.
Der Plan führt deshalb zwei getrennte Ergebnisse. availability_state beschreibt, ob und wo das Betriebsereignis die Planung schneidet. contingency_state hält fest, ob ein aktuelles Verfahrensdokument einen anderen Weg oder eine Sicherungsmaßnahme erlaubt. Aus hohem Zeitrisiko folgt keine Ermächtigung zur E-Mail-Abgabe.
Zulässig sind zunächst interne Reaktionen: Zieltermin vorziehen, zugelassenen Portalnutzer einplanen, erforderliche Software früher prüfen und eine neue Statuskontrolle terminieren. Anmeldung, Testupload, Supportanfrage oder Versand überschreiten die reine Planung und brauchen einen eigenen Auftrag.
| Bereich | Zustand | Aussage |
|---|---|---|
| Verfügbarkeit | no_published_overlap | Keine beobachtete Meldung schneidet die geprüften Zeiträume |
| Verfügbarkeit | working_window_overlap | Die Wartung berührt verfügbare Arbeitszeit |
| Verfügbarkeit | final_buffer_overlap | Die Wartung verbraucht den eingeplanten Sicherheitspuffer |
| Verfügbarkeit | deadline_overlap | Der angegebene Zeitraum reicht bis in die Auftraggeberfrist |
| Verfügbarkeit | maintenance_time_unresolved | Die Meldung lässt sich zeitlich nicht eindeutig einordnen |
| Verfügbarkeit | affected_component_unresolved | Die betroffene Portal-Funktion ist nicht belegt |
| Verfügbarkeit | status_source_unavailable | Die offizielle Statusquelle war nicht abrufbar |
| Ausweichweg | authorized_contingency_confirmed | Die aktuelle Verfahrensregel erlaubt die Maßnahme ausdrücklich |
| Ausweichweg | conditional_contingency | Eine Maßnahme ist vorgesehen, aber Bedingungen sind offen |
| Ausweichweg | no_authorized_contingency_found | Kein anwendbarer Ersatzweg wurde gefunden |
| Ausweichweg | contingency_instruction_conflict | Aktuelle Regeln widersprechen sich |
Bundesportal
Die Statusseite der e-Vergabe ist aktuell, aber nicht unveränderlich
Die e-Vergabe des Bundes veröffentlicht Plattformstatus, Versionsangaben und voraussichtliche Wartungen auf einer eigenen Statusseite. Dort steht auch, dass Wartungsfenster mit Verfügbarkeitseinschränkung im Voraus angekündigt und nicht benötigte Zeiträume kurzfristig freigegeben und aus der Übersicht entfernt werden. Genau deshalb braucht jede Auswertung einen Abrufzeitpunkt.
Speichern Sie nicht nur das Ergebnis „Wartung vorhanden“. Halten Sie event_text_raw, observed_at, angezeigten Beginn, angezeigtes Ende, Ereignisbezeichnung und eine zulässige Inhaltskennung fest. Ist das Fenster bei der nächsten Prüfung verschwunden, entsteht eine zweite Beobachtung mit dem Zustand removed oder released. Die erste bleibt als Grundlage der damaligen Terminentscheidung erhalten.
Eine Statusseite darf den erwarteten Betrieb beschreiben. Sie ersetzt weder Bewerbungsbedingungen noch eine Änderung der Vergabestelle. Selbst eine angekündigte Migration verschiebt daher keine Angebotsfrist aus sich heraus. Umgekehrt beweist „betriebsbereit“ nur den Zustand zum Beobachtungszeitpunkt und nicht die Erreichbarkeit während der späteren Abgabe.
| Feld | Inhalt | Bei fehlender Angabe |
|---|---|---|
| status_source_url | Offizielle Status- oder Wartungsadresse | status_source_unavailable |
| observed_at | Zeitpunkt des Abrufs mit Zone | Beobachtung nicht freigeben |
| event_text_raw | Unveränderter sichtbarer Meldungstext | Keine freie Zusammenfassung als Ersatz |
| event_interval | Aufgelöster Beginn und aufgelöstes Ende | maintenance_time_unresolved |
| affected_component | Zum Beispiel Portal, eVergabeApp oder Abgabefunktion | affected_component_unresolved |
| event_status | Angekündigt, geändert, freigegeben, entfernt oder beendet | unknown |
Zeitauflösung
Nur belegte Zeitzonen gehören in die Überschneidungsrechnung
Der unveränderte Wortlaut steht zuerst. buyer_deadline_raw kommt aus der aktuellen Verfahrensquelle; announced_start_raw und announced_end_raw kommen aus der Wartungsmeldung. Für jeden berechneten Zeitpunkt braucht es eine zone_basis mit Fundstelle. Die gleiche Sprache oder Länderkennung belegt noch keine Zeitzone, und der Browserstandort des Nutzers ist dafür ungeeignet.
RFC 3339 liefert ein eindeutiges Format für Zeitpunkte mit numerischem UTC-Bezug. Es beschreibt keine Wartungsintervalle. Der Plan führt deshalb zwei Zeitpunkte und verwendet nach dokumentierter Festlegung das halboffene Intervall [Beginn, Ende). So bleibt klar, ob ein Ereignis, das genau um 14:00 endet, ein um 14:00 beginnendes Arbeitsfenster noch berührt.
Vier Vergleiche sind erforderlich. Berührt die Wartung die verfügbare Arbeitszeit? Liegt der interne Zieltermin darin? Verbraucht sie den Puffer zwischen Ziel und Rechtsfrist? Reicht sie bis zur Auftraggeberfrist? Ein einziges boolesches Feld maintenance_conflict würde diese Unterschiede verdecken.
| Zeitgrenze | Herkunft | Änderungsbefugnis |
|---|---|---|
| Auftraggeberfrist | Bekanntmachung, Aufforderung oder wirksame Änderung | Auftraggeber nach anwendbarem Verfahren |
| Arbeitsfenster | Verfügbarkeit von Personen und notwendigen Systemen | Bieterorganisation |
| Interner Zieltermin | Angebotssteuerung | Bieterorganisation |
| Sicherheitspuffer | Interne Risikoregel | Bieterorganisation |
| Wartungsintervall | Offizielle Betriebsquelle | Plattformbetreiber als Betriebsinformation |
Beispiel
Eine Wartung am Freitag macht den internen Donnerstag zum belastbaren Ziel
Ein fiktives Bundesverfahren, Kennung BUND-IT-2026-77, endet am Montag, 21. September 2026, um 10:00 Uhr mit belegter deutscher Zeitbasis. Das Team wollte am Freitag um 15:00 Uhr abgeben. Die offizielle Statusseite kündigt für die betroffene Abgabefunktion ein Wartungsfenster von Freitag 14:00 Uhr bis Samstag 23:59 Uhr an. Die Anzeige nennt in diesem Beispiel ausdrücklich die Zeitzone.
Das Wartungsereignis trifft den internen Zieltermin und fast das gesamte Wochenend-Reservefenster. Der Zustand lautet final_buffer_overlap, obwohl zwischen Wartungsende und Auftraggeberfrist noch Kalenderzeit liegt. Das Team setzt Donnerstag 16:00 Uhr als neuen internen Zieltermin, stellt einen berechtigten Nutzer bereit und plant die Kontrolle der Empfangsbestätigung. Die Angebotsfrist bleibt Montag 10:00 Uhr.
Die Anleitung des Beschaffungsamts vom 23. April 2025 stützt die Vorsicht: Erst mit „Dateien versenden“ beginnt die Übermittlung, nach vollständigem Eingang wird eine Empfangsbestätigung angeboten, und ein vor Fristende begonnener, aber danach eingegangener Versand gilt als verspätet. Die Helpdesk-Zeiten helfen bei der Personalplanung. Sie begründen weder eine Fristverlängerung noch einen anderen Eingangskanal.
| Feld | Gespeicherter Wert |
|---|---|
| procedure_id | BUND-IT-2026-77, fiktiv |
| response_kind | Angebot |
| buyer_deadline_instant | 2026-09-21T10:00:00+02:00 |
| old_internal_submit_by | 2026-09-18T15:00:00+02:00 |
| maintenance_interval | [2026-09-18T14:00:00+02:00, 2026-09-19T23:59:00+02:00) |
| availability_state | final_buffer_overlap |
| contingency_state | no_authorized_contingency_found |
| new_internal_submit_by | 2026-09-17T16:00:00+02:00, rein intern |
| receipt_check | Empfangsbestätigung verfahrens- und gegebenenfalls losbezogen sichern |
| recheck_trigger | Änderung oder Entfernung des Wartungsfensters |
Befugnis
Der technische Helpdesk ist kein Ersatzpostfach für das Angebot
Die Abgabeanleitung nennt Kontaktformular, E-Mail, Telefon und Geschäftszeiten des technischen Helpdesks. Diese Angaben bezeichnen eine Supportfunktion. Ohne ausdrückliche Regel in den aktuellen Vergabeunterlagen darf das Angebot weder an die Ticketadresse noch an eine allgemeine Adresse der Vergabestelle gesendet werden.
Ein möglicher Ausweichweg braucht eine genaue authority_source und einen instruction_anchor. Hinzu kommen auslösendes Ereignis, erlaubtes Medium, Empfänger, Eingangsfrist, Kennzeichnung, Inhaltsanforderungen und Nachweis. Fehlt eine Bedingung, lautet das Ergebnis conditional_contingency. Wurde kein anwendbarer Weg gefunden, bleibt no_authorized_contingency_found auch bei hohem Ausfallrisiko richtig.
Die technische Probe ist ebenfalls eine Handlung. Die Beschaffungsamt-Anleitung beschreibt, dass ein Nutzer den Abgabeprozess bis kurz vor dem Versand durchspielen kann. Ein Agent darf daraus keine allgemeine Erlaubnis ableiten. Anmeldung, Unternehmensvertretung, Softwareinstallation, Annahme von Bedingungen und jeder Portalentwurf müssen vom Kontoinhaber beziehungsweise Bieter freigegeben sein.
| Fundstelle | Zulässige Aussage | Nicht ableiten |
|---|---|---|
| Statusseite | Angekündigtes Betriebsereignis | Änderung der Angebotsfrist |
| Helpdesk-Seite | Weg für technische Unterstützung | Ersatzeingang für Angebote |
| Abgabeanleitung | Normaler Ablauf und Empfangsbestätigung | Sonderregel für das konkrete Verfahren |
| Aktuelle Vergabeunterlagen | Vorgesehener Abgabeweg und besondere Bedingungen | Momentane technische Verfügbarkeit |
| Änderung der Vergabestelle | Ausdrücklich geänderte Frist oder Regel | Weitere nicht genannte Ausnahmen |
Agentenvertrag
Ein Agent muss die Rechnung aus den Quellen wiederholen können
Beginnen Sie mit assessment_id, procedure_id, notice_version, lot_ids, response_kind, submission_route und assessed_at. Die Frist erhält Rohwert, berechneten Zeitpunkt, Zeitzonengrundlage und genaue Quellfundstelle. Dadurch kann ein zweiter Agent prüfen, ob überhaupt die richtige Ausschreibung und Fassung bewertet wurde.
Jede Statusbeobachtung führt URL, Quellenrolle, Abrufzeit, unveränderten Ereignistext, sichtbare Rohzeiten, aufgelöste Zeitpunkte, betroffene Funktion, behauptete Auswirkung und Ereignisstatus. Eine Inhaltskennung oder zulässige Momentaufnahme verbindet spätere Änderungen mit der früheren Auswertung. Ein fehlender Wert wird null und bekommt einen reason_code.
Die Ausgabe endet mit availability_state, contingency_state, tested_intervals, overlap_method, contingency_evidence, allowed_action, prohibited_action, review_owner, next_recheck_at und recheck_triggers. Öffentliche Rechts- und Betriebsquellen können öffentlich zitiert werden. Interne Zieltermine, Kontoinhaber und konkrete Angebotsdaten bleiben zugriffsgeschützt.
| Gruppe | Pflichtfelder | Prüffrage |
|---|---|---|
| Identität | procedure_id, version, lot_ids, response_kind | Gehören alle Daten zum selben Verfahren? |
| Frist | raw, instant, zone_basis, source_anchor | Ist der Zeitpunkt belegt? |
| Wartung | raw event, observed_at, interval, component, status | Was wurde wann offiziell angezeigt? |
| Überschneidung | method, tested_intervals, results | Welcher Planungsteil ist betroffen? |
| Ausweichweg | authority, trigger, conditions, state | Ist die Maßnahme für diesen Fall erlaubt? |
| Steuerung | owner, allowed, prohibited, recheck | Wer darf als Nächstes was tun? |
Wiederholungsprüfung
Neue Statusdaten ergänzen die Historie statt sie zu überschreiben
Der nächste Prüftermin richtet sich nach Nähe und Wirkung der Wartung. Zusätzlich lösen eine geänderte Bekanntmachung, neue Vergabeunterlagen, Portalumstellung, geänderte Authentifizierung, verschobene interne Planung oder veränderte Statusmeldung eine sofortige Prüfung aus. Kurz vor dem Puffer übernimmt der autorisierte Portalnutzer die operative Kontrolle.
Vergleichen Sie Ereignistext, Zeitraum, Funktionsumfang und Inhaltskennung. Für announced, changed, released, removed, completed und superseded braucht es jeweils eine neue Beobachtung. Ist die Statusseite beim Abruf nicht erreichbar, bleibt die letzte Meldung mit ihrem alten Zeitpunkt erhalten; der aktuelle Zustand wird status_source_unavailable.
Die Gültigkeit endet spätestens bei einer maßgeblichen Änderung oder wenn eine geplante Wartung zur tatsächlichen Störung wird. Ein abgelaufener Plan ist keine aktuelle Entscheidungshilfe mehr, bleibt aber Teil der nachvollziehbaren Angebotsakte.
Abgrenzung
Bei einem echten Fehler beginnt eine eigene Störungsakte
AN-039 endet, sobald ein berechtigter Nutzer den vorgesehenen Schritt nicht ausführen kann. Ein fehlgeschlagener Login, eine nicht startende eVergabeApp, ein abgebrochener Upload, eine Portalfehlermeldung oder eine ausbleibende Empfangsbestätigung ist kein Prognosewert mehr. Erfassen Sie Zeitpunkt, betroffenen Schritt, sichtbare Meldung, offiziellen Status und lokale Beobachtung in einem Incident-Datensatz.
Der Incident darf auf den letzten Verfügbarkeitsplan verweisen, ihn aber nicht umschreiben. Passwörter, Sitzungstoken und vertrauliche Angebotsinhalte gehören nicht in die Beweisakte. Eine Supportmeldung wird nur über den vorgesehenen Weg und durch eine befugte Person ausgelöst. Sie ist technischer Nachweis, keine Zusage der Vergabestelle.
Nach dem Versand folgt eine dritte Prüfung: Ist das Angebot vollständig eingegangen und liegt die vorgesehene, gegebenenfalls losbezogene Empfangsbestätigung vor? Diese Frage gehört zur Empfangsnachweis-Seite. Wartungsplanung, Störungsreaktion und Eingangsbeleg dürfen sich gegenseitig referenzieren, aber nicht ersetzen.
Woran gute Arbeit erkennbar ist
Konkrete Ergebnisse für Wartung Vergabeportal Abgabefenster
- Verfahren, Fassung, Los und Abgabeart begrenzen jedes Ergebnis.
- Die Auftraggeberfrist bleibt im Originalwortlaut und mit genauer Fundstelle erhalten.
- Jede Wartungsbeobachtung besitzt Quelle, Prüfzeit und unveränderten Meldungstext.
- Fehlende Zeitzone oder unklare Funktionsbetroffenheit wird als Unsicherheit ausgewiesen.
- Arbeitsfenster, interner Zieltermin, Sicherheitspuffer und Rechtsfrist werden einzeln verglichen.
- Ein aktueller grüner Status wird nicht in eine Zusage für den Abgabetag umgedeutet.
- Die Planung kann den internen Zieltermin vorziehen, ohne die Bekanntmachung umzuschreiben.
- Ein Notweg gilt nur mit aktueller verfahrensbezogener Ermächtigung.
- Änderungen der Statusseite bleiben durch aufeinanderfolgende Beobachtungen erkennbar.
- Bei einem echten Fehler wechselt die Verantwortung in die Störungsbearbeitung.
Betriebsmodell
So wird die Arbeit ausgeführt
- 01
Verfahren und Frist festschreiben
Erfassen Sie Kennung, aktuelle Unterlagenfassung, Los, Abgabeart, vorgesehenes Portal und den unveränderten Fristwortlaut mit Fundstelle.
- 02
Statusquelle beobachten
Sichern Sie URL, Abrufzeit, Meldungstext, Ereignisstatus, Beginn, Ende und genannte Plattformfunktion von der offiziellen Status- oder Wartungsseite.
- 03
Zeitangaben qualifizieren
Trennen Sie Rohwerte von berechneten Zeitpunkten und lösen Sie Uhrzeiten nur mit belegter Zeitzone auf.
- 04
Nutzbares Abgabefenster berechnen
Vergleichen Sie die Wartung nacheinander mit verfügbarer Arbeitszeit, internem Ziel, Puffer und Auftraggeberfrist.
- 05
Ausweichregel prüfen
Suchen Sie in aktuellen Vergabeunterlagen und Änderungen nach einer Regel, die genau für die betroffene Störung einen anderen Weg oder eine Sicherungsmaßnahme erlaubt.
- 06
Prüfung befristen und übergeben
Benennen Sie Zustände, zulässige nächste Handlung, Sperren, Verantwortliche und erneute Prüfzeit. Eine laufende Störung wird separat dokumentiert.
Bewertung
Fragen, die den Entscheid verändern
- Welche Verfahrensfassung und welches Los werden abgegeben?
- Wo steht die aktuell verbindliche Abgabefrist?
- Welche Portal- oder App-Funktion nimmt die Abgabe entgegen?
- Ist die gefundene Statusseite eine offizielle Betriebsquelle?
- Wann wurde die Wartungsmeldung zuletzt beobachtet?
- Nennen Beginn und Ende eine belegte Zeitzone?
- Ist Angebotsabgabe betroffen oder nur eine andere Plattformfunktion?
- Welcher Teil der Teamarbeitszeit fällt in das Wartungsfenster?
- Bleiben nach dem internen Ziel genug Zeit für Korrektur und Empfangsbestätigung?
- Erlauben die Vergabeunterlagen einen genau bezeichneten Notweg?
- Wer darf Portal, Helpdesk oder Vergabestelle gegenüber handeln?
- Welches Ereignis macht die Prüfung ungültig?
Fehlermuster
Wo Teams die Kontrolle verlieren
Der aktuelle Plattformstatus wird als künftige Verfügbarkeitsgarantie gelesen.
Jede Wartung wird ohne Beleg als vollständiger Ausfall der Abgabe behandelt.
Eine Uhrzeit ohne Zone wird automatisch als deutsche Ortszeit gespeichert.
Frist und Wartungsmeldung gehören zu unterschiedlichen Verfahrensständen.
Der interne Zieltermin ersetzt in Übersichten versehentlich die Auftraggeberfrist.
Geschäftszeiten des Helpdesks werden mit Betriebszeiten des Portals verwechselt.
Die Supportadresse wird zum angeblichen Ersatzeingang für Angebote.
Eine entfernte Wartungsmeldung löscht die Entscheidungsgrundlage des Vortags.
Ein Agent startet zur Probe eine Abgabe oder nimmt Bedingungen an.
Ein Uploadbeginn vor Fristablauf wird mit rechtzeitigem Eingang gleichgesetzt.
Eine aktive Störung bleibt ohne beweissichere Zeit- und Fehlermeldung.
Nach erfolgreichem Versand wird die Empfangsbestätigung nicht separat geprüft.
Messung
Das fertige Ergebnis messen
Gemessen wird der abgeschlossene Prozess inklusive Review-Aufwand und Ausnahmen. Reines Output-Volumen beweist noch keine bessere Arbeitsweise.
- Pläne mit vollständigem Verfahrens- und Losbezug
- Wartungsereignisse mit Rohtext, URL und beobachtet_am
- Zeitwerte mit belegter Zone oder ausdrücklich offenem Zustand
- getrennte Vergleiche für Arbeit, Zieltermin, Puffer und Rechtsfrist
- vorgezogene interne Ziele mit dokumentierter Risikobegründung
- Ausweichwege mit aktueller Klausel und erfüllten Bedingungen
- rechtzeitig nach Änderungen wiederholte Statusprüfungen
- Abgaben mit gesondert gesicherter Empfangsbestätigung
- Planungen, die beim Eintritt einer Störung korrekt eskaliert wurden
Fragen
Häufige Fragen
Verlängert ein angekündigtes Wartungsfenster die Angebotsfrist?
Nein. Erst eine aktuelle und wirksame Mitteilung der Vergabestelle kann die Frist ändern. Die Wartungsmeldung begründet nur ein Betriebsrisiko.
Darf die Zeitzone aus der deutschen Portaladresse abgeleitet werden?
Nein. Speichern Sie die sichtbaren Rohzeiten und lösen Sie sie nur mit einer belegten Zeitzonenangabe oder einer verlässlichen, anwendbaren Plattformregel auf.
Ist ein entferntes Wartungsfenster bedeutungslos?
Für die aktuelle Planung kann es entfallen. Die frühere Beobachtung bleibt dennoch erhalten, weil sie eine damalige Terminentscheidung erklären kann.
Kann das Angebot bei Wartung an den Helpdesk geschickt werden?
Nur wenn die aktuellen Vergabeunterlagen dies ausdrücklich als Abgabeweg für genau diesen Fall erlauben. Eine normale Supportadresse reicht nicht.
Reicht es, den Upload vor Fristende zu beginnen?
Nach der aktuellen Abgabeanleitung der e-Vergabe nein. Ein vor Fristende begonnener, aber erst danach eingegangener Versand gilt als verspätet.
Was darf ein Agent ohne Portalvollmacht prüfen?
Er darf öffentliche Status-, Hilfe- und Verfahrensquellen auswerten. Anmeldung, Unternehmensvertretung, Softwareinstallation, Testabgabe und externe Kommunikation brauchen einen gesonderten Auftrag.
Wann muss der Verfügbarkeitsplan erneut erstellt werden?
Nach Änderungen an Frist, Unterlagen, Portal, Authentifizierung, Wartungsmeldung oder internem Ziel sowie spätestens zum festgelegten Wiedervorlagetermin.
Was ist bei einer laufenden Störung zu tun?
Wechseln Sie in die dokumentierte Incident-Bearbeitung, sichern Sie Zeit- und Fehlerevidenz und verwenden Sie nur autorisierte Support- oder Ausweichwege.
Quellen
Primärquellen
- Plattformstatus und voraussichtliche Wartungen der e-Vergabe Beschaffungsamt des BMI
- Abgabe mit der e-Vergabe, Stand 23. April 2025 Beschaffungsamt des BMI
- Nutzungsbedingungen des EU Funding and Tenders Portal, Fassung 7.0 vom 1. Februar 2024 Europäische Kommission
- eSubmission-Anleitung für offene Vergabeverfahren Europäische Kommission
- RFC 8631 zum auffindbaren Status von Webdiensten RFC Editor
- RFC 3339 für eindeutige Internet-Zeitstempel RFC Editor
Über den Autor
Tony Kim
Tony schreibt über angewandte AI, verlässliches Product Engineering und Systeme, die komplexe Response-Arbeit kontrollierbar machen.
Zelius
Gemanagte Ausschreibungsintelligenz und Bid-Ausführung für Teams, die das Geschäftsergebnis suchen.
Anbieter, Gründerinnen und Gründer sowie Vertriebsteams für öffentliche und private Chancen. Ausgangspunkt sind der bestehende Ablauf, seine Grenzen und die vorhandenen Nachweise.