Ist die Bieterregistrierung vor der Vergabefrist fertig?

Direkte Antwort

Die Registrierung passt nur, wenn ihr kritischer Pfad vor dem Arbeitsbeginn im Portal endet

Der Angebotsstichtag ist nicht der Fertigstellungstermin der Registrierung. Ziehen Sie zuerst die Zeit für Verfahrenszuordnung, Zugriffstest, Upload, Freigabe und Empfangskontrolle ab. So entsteht registration_required_by. Erst davor darf der Registrierungsweg enden.

Führen die belegten Planungszeiten und eine ausgewiesene Reserve vor diesen Zeitpunkt, ist feasible_with_buffer möglich. Hängt das Ergebnis an einer bestimmten, noch prüfbaren Annahme, verwenden Sie feasible_with_conditions. Hat eine notwendige externe Prüfung keine belastbare Obergrenze, lautet das Ergebnis support_or_validation_dependent, auch wenn das Formular wahrscheinlich schnell ist.

ready_verified verlangt mehr als eine sichtbare Organisationsnummer. Ein erlaubter Test muss zeigen, dass der richtige Nutzer mit dem richtigen Bieter und der nötigen Rolle den relevanten Verfahrensschritt erreichen kann. Dieser Test genehmigt weder das Angebot noch die Einreichung.

Zieldefinition

EU Login, PIC, Validierung und Verfahrensrolle sind nicht derselbe Meilenstein

Für die Vergabeverfahren der EU-Kommission beschreibt die aktuelle Teilnahmehilfe eine konkrete Reihenfolge. Jede handelnde Person benötigt ein EU Login. Die Organisation wird im Participant Register erfasst und erhält einen neunstelligen PIC. Erst danach wird sie in eSubmission ausgewählt und der Antwort zugeordnet.

Die Quelle setzt eine wichtige Grenze: Ein neu erzeugter PIC hat zunächst den Status declared und kann für Teilnahmeantrag oder Angebotsabgabe verwendet werden. Die zentrale formale Validierung folgt bei erfolgreichem Verfahren vor Vertragsunterzeichnung. Legen Sie diesen späteren Prüfschritt nur dann auf den Einreichungspfad, wenn die konkrete Ausschreibung das abweichend verlangt.

Vor einer Neuanlage verlangt das Online Manual die Suche nach einem bestehenden PIC und empfiehlt mehrere Namensvarianten. Das ist keine lästige Vorarbeit. Ein Duplikat kann Zuständigkeiten, hinterlegte Daten und Benachrichtigungen trennen. Halten Sie Suchbegriffe, geprüfte Treffer und den freigegebenen Organisationsbezug fest.

Auch ein declared PIC beendet den Pfad nicht automatisch. Der erlaubte Nutzer muss zur richtigen Organisation und Submission gelangen. Bei einer Bietergemeinschaft können weitere Organisationskennungen erforderlich sein. Die Verfahrensunterlagen entscheiden, welcher Beteiligte wann erfasst sein muss.

Zeitrechnung

Der längste abhängige Weg bestimmt die Dauer, nicht die Summe aller Stunden

Zeichnen Sie Aufgaben als gerichteten Ablauf. Während ein Mitarbeiter sein EU Login einrichtet, kann der Registerverantwortliche die amtliche Firmenbezeichnung und Rechtsform prüfen. Die PIC-Anlage wartet jedoch auf diese Daten. Der Submission-Test wartet wiederum auf den PIC. Nur diese Abhängigkeiten gehören nacheinander auf denselben Pfad.

Jede Dauer braucht einen Typ. official_range übernimmt eine ausdrückliche Betreiberangabe. internal_observation stützt sich auf datierte vergleichbare Fälle und nennt Stichprobe sowie Quantil. owner_commitment ist eine interne Zusage einer benannten Person. unknown bleibt eine Unbekannte und wird nicht zu null. Verwenden Sie für fristkritische Schritte ein Planungsmaß, das den Fehlerpreis berücksichtigt.

Ordnen Sie den Kalender der ausführenden Stelle zu. Eine interne Datenfreigabe kann am Schweizer Arbeitstag stattfinden, der EU-Support arbeitet nach mitteleuropäischem Werktag, und der Käufer nennt seine eigene Frist. Erst ein bereits geklärter Fristzeitpunkt darf in die Rückwärtsrechnung eingehen.

Dokumentieren Sie latest_safe_start = registration_required_by minus critical_path_duration minus contingency. Ist dieser Start verstrichen, darf eine optimistische Formulardauer das Ergebnis nicht retten. Nur ein offiziell verfügbarer anderer Pfad oder eine veränderte Anforderung kann die Rechnung ändern.

Supportgrenze

Ein erreichbarer Service verspricht noch keine Lösung bis zur Frist

Die EU-Hilfeseite nennt für den allgemeinen IT Helpdesk werktägliche Verfügbarkeit während mitteleuropäischer Arbeitszeiten. Der Leitfaden für offene eSubmission-Verfahren nennt für technischen Support 08:00 bis 20:00 CET oder CEST und weist darauf hin, dass dieser Service auf Englisch arbeitet. Die beiden Angaben sind weder Rund-um-die-Uhr-Support noch eine Lösungsfrist.

Ordnen Sie die Störung richtig zu. Ein EU-Login-Problem, eine Frage zur Organisationsvalidierung und ein Fehler innerhalb einer bestimmten Submission können verschiedene Stellen betreffen. Ein falsch adressiertes Ticket verbraucht Reserve, selbst wenn jede Stelle erreichbar ist.

Fehlt eine zugesagte Antwort- oder Lösungszeit, bleibt die Ausnahme unbestimmt. Interne Erfahrungswerte dürfen bei ausreichender Vergleichbarkeit eine zusätzliche Szenariospalte füllen, aber sie werden nicht zur Aussage der Kommission. Veröffentlichen Sie niemals Ticketinhalt, persönliche Kontaktdaten oder geschützte Organisationsangaben.

Der Eskalationspunkt liegt vor dem Verlust der Reserve. Wer erst am operativen Stichtag um Hilfe bittet, hat keinen Alternativpfad mehr. Ein früher Trigger kann lauten: Wenn der PIC am Freitag um 16:00 Uhr nicht in der erlaubten Test-Submission auswählbar ist, wechselt die Entscheidung auf dependent und geht an den benannten Portalverantwortlichen.

Beispiel

Ein declared PIC kann rechtzeitig sein, ohne die spätere Validierung vorzuverlegen

Eine fiktive offene EU-Ausschreibung endet am Donnerstag, 19. November 2026, um 17:00 Uhr CET. Das Team will den Verfahrenszugang bis Mittwoch um 12:00 Uhr getestet haben. Am Freitag, 13. November, um 09:00 Uhr besitzt die zuständige Person bereits ein EU Login. Für die Organisation wurde noch kein PIC bestätigt.

Der Plan beginnt mit einer Suche nach vorhandenen Einträgen unter drei Namensvarianten. Der Registerverantwortliche hat bis 14:00 Uhr die amtliche Bezeichnung, Adresse, Rechtsform und Registrierungsangaben freigegeben. Die Selbstregistrantin sagt zu, den Assistenten bis 16:00 Uhr vollständig abzuschließen. Nach der aktuellen Teilnahmehilfe kann der daraus erzeugte declared PIC für die Submission verwendet werden.

Am Montag ordnet eine berechtigte Nutzerin den PIC der Test-Submission zu und prüft bis 12:00 Uhr den erlaubten Zugriff. Dienstag bleibt als Kontingenz für einen innerhalb des veröffentlichten Supportfensters lösbaren Bedienfehler. Der Zustand ist feasible_with_conditions, weil die Formularzeiten interne Zusagen sind und kein Betreiber eine konkrete End-to-End-Dauer garantiert.

Findet die Suche einen vorhandenen PIC mit ungeklärter Zuständigkeit oder ist die Kennung am Freitag nicht nutzbar, wechselt der Befund auf support_or_validation_dependent. Die formale Validierung des Rechtsträgers wird nicht vorsorglich in die Submission-Woche gezogen; sie bleibt gemäß allgemeiner Quelle ein späterer Schritt, sofern die konkrete Ausschreibung nichts anderes anordnet.

Agentenvertrag

Die Ausgabe zeigt Abhängigkeiten, Belege und die Grenze der Agentenbefugnis

Der strukturierte Datensatz enthält assessment_id, supplier_entity_ref, procedure_id, notice_id, lot_ids, response_kind, portal_name, public_portal_url, checked_at, target_state, target_state_source, buyer_deadline_raw, buyer_deadline_instant, registration_required_by, task_id, predecessor_ids, task_kind, responsible_party, requirement_source, current_state, minimum_duration, planning_duration, maximum_duration, duration_basis, business_calendar, support_window, external_dependency, completion_evidence, exception_branch, critical_path_finish, slack, contingency, feasibility_state, blockers, assumptions, confidence, valid_until, review_owner, escalation_trigger und next_authorized_action.

Der Agent darf aktuelle öffentliche Portalhilfen abrufen, Kalenderarithmetik ausführen und freigegebene nicht geheime Statusaussagen in den Pfad einordnen. Er stoppt bei ungeklärter Zielanforderung oder Frist, fehlender Berechtigung zur Kontoansicht, privaten Kennungen, unbelegter Dauer und jeder geplanten Außenhandlung.

Nicht umfasst sind Kontoanlage, Zustimmung zu Bedingungen, Eingabe von Register-, Steuer- oder Personendaten, Identitätsprüfung, Rolleneinladung, Zertifikatskauf, Kontakt mit Support oder Käufer, Upload und Einreichung. Ein fertiger Portalzustand beweist außerdem weder Eignung noch Dokumentvollständigkeit, Kapazität, Preisfreigabe oder Vertretungsmacht.