Editorial system: Web interface for creating notices and publishing them on TED and in the notice service. Does your contracting authority not have software from a specialist procedure manufacturer for creating notices, does it not support all the forms you need or have you previously used TED's eNotices2? Then the editorial system is right for you!
Vermittlungsdienst: Purely technical interface for accepting, validating and forwarding notices to TED and the notice service. Does NOT provide an interface for creating announcements! Only machine-to-machine communication is possible, e.g. from an awarding authority software. This connection is usually carried out by the specialist procedure manufacturer.
Self-Service Portal: Web interface for the account management of Vermittlungsdienst accounts. Mainly used by specialist procedure manufacturers. Dashboard accounts are possible for viewing the status information of submitted notices, please contact your specialist procedure manufacturer!
Announcement service: All notices sent via the public procurement data service are published in the notice service. The announcement service offers a wide range of search options so that bidders can find announcements in line with their range of services. When using the ELSTER company account, further convenient functions such as saving search functions and notification services are also available. Furthermore, the data of the announcement service can be reused via an open data interface in the formats eForms-DE, CSV and OCDS.

Since 04.10.2023, accounts should be applied for in the Self-Service Portal. All required information is requested in the registration form for a VD account. These are:

• System environment for which access data is requested (preview, staging, production). Registration in the portal takes place for the corresponding environment, i.e. if an account is required for the staging environment, this should be requested in the staging portal.

• E-mail address to be used as the user name (this must be unique for each environment, no duplicates allowed)

• URL of the awarding platform on which the notices are published

• First name, surname and e-mail address of the representative of the FVH (specialist procedure manufacturer)

• Name of the FVH

Some awarding platforms use e.g. Dropbox or google drive or similar for hosting the award documents, which is why the platform behind it cannot be clearly identified. For this reason, this information is also necessary. The link to the tender documents remains in the XML document and this is primarily displayed in the BKMS interface. The link provided when the account is created is only displayed at the bottom right, below the notice itself, as a disclaimer/source.

The official publication of the eForms-DE standard is available at https://xeinkauf.de/eforms-de/

The associated SDK is published at https://gitlab.opencode.de/OC000008125155/SDK-eforms-de

For publications on the organizational framework, see

https://www.finanzen.bremen.de/digitalisierung/digitalisierung-von-verwaltungsleistungen-fuer-unternehmen/digitale-beschaffung-103422

Questions about the DE-SDK can be opened via issues in the repository.

The Github documentation will continue to be maintained and is the official documentation until further notice. It can also be read in the Self-Service Portal of the DÖE.

Yes, the Github documentation is updated regularly and is the official documentation until further notice. The documentation is also published in the Self-Service Portal.

In this question, the provisions of the respective directives and regulations under which the award procedure falls continue to apply.

The specification follows the EU Implementation Handbook on this point. It is a target formulation that does not require a business rule. Details: https://op.europa.eu/en/publication-detail/-/publication/73a78487-cc8b-11ea-adf7-01aa75ed71a1

eForms-DE is the implementation of the "Commission Implementing Regulation (EU) 2022/2303 of November 24, 2022 amending Implementing Regulation (EU) 2019/1780 establishing standard forms for the publication of notices for public contracts". BT-53 (Options) is explicitly specified in this directive and is an indicator that indicates whether the buyer reserves the right to "reorder" from the same buyer. In technical terms, a possible entry would be "Yes" or "No". BT-53 is not required if BT-54 (Options - Description) is filled. In other words, if there is a text that describes the options that the buyer reserves. In this case, BT-53 can automatically be set to "Yes". If BT-54 is not present, then BT-53 is automatically set to "No". This technically means that there is no need to explicitly implement BT-53, as this follows "automatically" from BT-54.

For award criteria >=10%, the information is mandatory for eForms-en; for award criteria <10%, the cardinalities of the information provided by TED currently remain unchanged.

It is strongly recommended that you also enter the information for the award criteria whose weighting is below 10% in order to comply with the 100% rule of TED.

Only the codes "ex-os" (exclusion grounds upper threshold) and "ex-us" (exclusion grounds lower threshold) have been removed, as the existing EU code "nati-ground" (purely national exclusion grounds) can be used instead.

We have updated the changelog for you: https://projekte.kosit.org/eforms/eforms-de-codelist/-/blob/main/CHANGELOG.md.

The BT-125(i) & OPP-090 are specified with the UUID (publication number) of the EU prior information notice or with the Official Journal number in order to also refer to older prior information notices.

For BT-1251, only a length restriction of 30 characters is specified in the SDK.

An awarding authority has published a prior information notice in which it announces that an invitation to tender for subject X is to take place soon. This prior information notice is now given an announcement number. Some time later, the contracting authority invites tenders for subject X in a contract notice (CN). The publication number of the prior information notice is now entered in BT-125(i) in order to refer to the prior information notice that was published some time ago. BT-1251 is a specification of the point at which information on subject X was provided. This is done in the prior information notice in Parts. So BT-1251 is the information in which part of the prior information was provided.

Please note that in eForms, contractors and clients are stored in different places in the eForms structure for awarded tenders (contracts).

The client is stored in the Contract structure. An offer is assigned to a contract and bidders are assigned to the offer. These bidders represent the contractors of the contract.

The following long version describes exactly what needs to be done to enable this backward linking and to ensure correct display in the contract notice service.

1. description of the results of the tender The results of an alert are stored in the XML in the efac:NoticeResult section. In the following sections, only the sub-sections that are required here to output the expected results in the announcement service are described.

2. description of the results of a lot

   The BT-142 (winner determined, <cbc:TenderResultCode listName="winner-selection-status">) is located in the form module "Lot result" (efac:LotResult). Behind this is a code list with the following values:

   a. A competition winner has not yet been determined, the competition is not yet closed. b. No competition winner has been determined and the competition is closed. c. At least one winner has been determined (code: selec-w).

   Only in the event that "c" was selected can a result be reported for this lot and at least the winning bid for this lot must be specified. If several bids have been awarded, all winning bids must be listed below. In the section "Result of the lots" (efac:LotResult), the relationship between the lot efac:TenderLot , BT-13713-LotResult, (procedural result lot identifier) and the tender (efac:LotTender, OPT-320-LotResult) is established.

3. description of the tender

   The description of the tenders takes place in the "Tenders" form module (efac:LotTender) Here it is important to set an internal form reference number to the tender, as this should already be used in the previous section, for example - in the reference to the tender (see efac:LotTender, OPT-320-LotResult in section 2). Here, too, the LOS to which the tender refers must be referenced again (in the Tender Lot ID field): efac:TenderLot, BT-13714-Tender>. In addition, a further reference must now be inserted at this point to the section efac:TenderingParty in the OPT-310-Tender field (identifier - bidder). This reference refers to the "Bidder" form module, which is described below.

4. description of the bidder(s) for a tender

   In the form module "Bidder" efac:TenderingParty, the details of the bidder(s) of a tender(s) must be stored. The main purpose here is to indicate whether the tender was submitted by an individual bidder or by a bidding party or by a bidder who will employ subcontractors. Only references to the bidder organizations are therefore required here. If it is a bidder in this tender, then the reference to the bidder organization must be entered in the efac:Tenderer OPT-300-Tenderer (ID - Bidder ) field. The field efac:Tenderer/efbc:GroupLeadIndicator OPT-170-Tenderer (head of the tenderer) must also be completed for each specified tenderer. At least one of the specified bidder organizations must be qualified as "leader of the tender". Bidding parties that have joined forces in subcontracts can also be specified here (however, the corresponding description of these fields is omitted here).

5. description of the contract

   Once the above requirements 2-5 have been fulfilled, the relationships that represent the technically interesting part of the contract notice service, namely the contracts that have been concluded for a lot, can be mapped. This is done in the form module "Orders" ("Contracts") efac:SettledContract. The following information should be entered in this section

   BT-721-Contract - Name of the contract

   BT-145-Contract - Date of conclusion of the contract

   BT-1451-Contract - Date of decision on the winner

   BT-768-Contract - Order as part of a framework agreement.

The following field is the most important for determining the winner:

BT-3202-Contract - Order bid identifier, as this field is used to determine the underlying bid as part of a backward chain and the bidder or head of a bidding consortium who signed the contract for the bidders

In order to also be able to map which organization on the client side signed the contract, the following field should also contain ID - contract signatory cac:SignatoryParty (OPT-300-Contract-Signatory) with a reference to the organization on the client side that signed the contract.

Setting up these references in this way according to the pattern described also fulfills another purpose: only if all references exist correctly can the requirements of BT-165 (Company size) must be filled in and BT-706 (Nationality of the beneficial owner of the winner) must be filled in, of the eForms-DE standard be fulfilled.

• It must be unique, i.e. there must be no other organization with the same identifier
• This should be used sustainably across all announcements

The use of the routing ID is recommended for public administration (as this is already frequently used for electronic invoicing). This has the following form:

0204:Routing ID

Example (fictitious):

0204:991-1234512345-06

The format specification of the routing ID (version 2.0.2) can be viewed and downloaded via the following link:

https://leitweg-id.de/wp-content/uploads/2021/08/Leitweg-ID-Formatspezifikation-v2-0-2.pdf

As long as or to the extent that this is not available, another unique identification number must be specified temporarily. If there is no other unique identification number, a telephone number of the organization can also be entered as a unique identification number. This should then have the following form:

t:03023125000

This should be entered with a prefix (t:), area code, without special characters and without spaces, as in the fictitious example.

Notes for awarding chambers:

We recommend using the identifiers in the table below for the awarding chambers. These are taken from the following page, among others:

https://www.bundeskartellamt.de/DE/UeberUns/LinksundAdressen/Vergabekammern_der_L%C3%A4nder/Vergabekammern_artikel.html

The name for BT-634 (new edition of the procedure) is less confusing in English: "Relaunch". The BT-634 should therefore not be used for an indication in the future, but as an indicator of whether a procedure or lot for the advertised item already existed and was canceled in the past. The BT-634 can then be used at procedure or lot level to indicate whether this notice is the "restart" for the annulment of a previous notice.

Assistance can be found in Annex II of the framework directive https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32007L0046:

The parties involved are aware of the imprecision resulting from the collection of structured data in unstructured fields, but are currently considered acceptable. The approach is seen as an interim solution and work is continuing on a "clean" solution. This is being done in consideration of the fact that the BKMS will be able to evaluate any data immediately from October 25th

The eSender Hub does not remove this data, the entries from this field are also forwarded 1:1 to the EU.

No, these values are essential for a better understanding of the codes

In principle, there is no automatic translation of field contents, i.e. German terms in the fields remain German. The EU has not yet decided on a uniform approach to localization.

It is possible to add free text after the code as long as the total character limit is observed. The following note has been added to BT-300 for clarification: "To the extent that it is necessary to specify one of the codes (freelance, self, startup) because of rule BR-DE-26, the code must be specified on the first line and separated from other additional information by two blank lines. The format of the first line is defined as follows: #Specially suitable for:{freelance|self|startup}."

• Date of publication of eForms notices on TED: no longer 5 fixed calendar days

• Possibility to set a preferred publication date (BT-738)

• If no date is specified, TED will publish "As soon as possible", i.e. in the next available OJS issue

  --> Announcement can appear in TED at 9:00 a.m. the next morning; maximum 2 working days

  --> less time to stop the publication

• If a date is specified, TED will publish on the preferred date or in the next available OJS issue after that date

  --> see TED publication calendar for working days

  --> preferred publication date can be up to 60 days in the future

• The working day before the expected publication date:

  --> daily export on working days between noon and midday - notification is included in OJS output

  --> overnight to "publication" status (or over the weekend or on public holidays)

According to TED, if there is 'no' lot, there must only be one technical lot entry with the value LOT-0000. If there are two lots, there are two lots with the values LOT-0001 and LOT-0002. For 5 lots, for example, LOT-0001, LOT-0002, LOT-0003, LOT-0004, LOT-0005. The structure of LOT-0000 is completely identical to that of any other LOT, including LOT-0001. Only the ID is different. See also: https://docs.ted.europa.eu/eforms-common/FAQ/index.html#_schema_and_field_definitions

For the sake of simplicity and to avoid inconsistencies with Schematron rules supplied by the EU, the SDK for the national eForms-DE standard contains fields at a technical level that are not used in accordance with the eForms-DE standard.

Lot groups are not provided for in eForms-DE.

• For API submissions, the NoticeAuthorEmail must be the email of the procurer (end user)
• The email author of the notice receives notifications about status changes: --> Submission, Stopped, Not Published, Published
• The eSender receives a copy to the email address used by EU-Login for the API key