Editorial system: Web interface for creating announcements and publishing them on TED and in the announcement service.
Does your public procurement office 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 implemented 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!

Since 04.10, 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 email 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 abbreviations are to be understood as follows:

PIN Eng: Prior Information Notice Deu: Prior information Subtype 1-14, E2 PINs are announcements that are published before the start of the "call for competition".

CN Eng: Contract Notice Deu: Open procedure / public invitation to tender Subtype 15-24, E3 CNs are notices that initiate the "call for competition".

CAN Eng: Contract Award Notice Deu: Notice (awarded contract) Subtype 25-40, E4 CANs are used to create contract award notices, which are published shortly after the contract is signed. They refer to the contract notice and contain information about the award procedure, such as the contract award, the winner, etc.

The naming of the reference documents involves the following:

eforms = standard document type PIN/CN/CAN = see above; indicates the type of notice Number 1-40 or E1-E4 = subtype of notice, where E is for subliminal notices DE = standard is eForms-DE (in)/valid = whether the file is valid or invalid according to the eForms-de specification There is not yet an example file for all types of notices. If you need an example for a specific type that does not exist in the above link, we will be happy to forward a request. Unfortunately, the EU does not provide examples for all types of notices either, which means that providing examples is sometimes quite time-consuming.

The version designations of the SDK for the respective national eForms-DE standard are based on the version designations of the eForms-DE standard. For each eForms-DE SDK, the European SDK version on which it is based is indicated. (see also explanation at https://gitlab.opencode.de/OC000008125155/SDK-eforms-de)

It is not planned that a new eForms-DE version will be published for every minor version of eForms-EU. Therefore, the versioning of eForms-EU and eForms-DE will not be directly identical in the future. However, there will always be exactly one corresponding eForms-EU version for each eForms-DE version.

Please note that a DE update is not automatically required for every EU update.
The GDK is not the responsibility of KoSIT. However, the eForms-DE specification. As was jointly determined at the 1st technical working meeting, we are currently unable to provide a simple answer with clear dates in view of the uncertainties that still exist regarding the entry into force and lifespan of the versions of the EU-SDK. What is certain is that a specific version of eForms-DE will declare itself compatible with a specific version of eForms-SDK and that this should happen as soon as possible. As currently eForms-DE 1.0.1 is compatible with eForms-SDK 1.5.1 (SDK 1.5.1 was released on January 20, 2023 and eForms-DE on February 5). This implicitly means that there will not be an eForms-DE version for every eForms-SDK version. The current eForms-DE version 1.1.0 is compatible with SDK 1.7.

Example for the FVH: To ensure that the notice is sent to the Vermittlungsdienst on the same day, we recommend that the notice be submitted to the specialized procedure manufacturer by 22:00 on the same day.

It will not be possible to query the status of an old announcement via the data service or to stop an old announcement that was not submitted via the data service, as the data service cannot send queries about announcements sent in the old format. However, the change of eSender has no influence on the possibility of referencing old notices. How references and corrections to old notices are possible is described in detail here: https://github.com/EFA-FHB/ozg-vermittlungsdienst-doku/blob/main/documentation/eForms_creation.md

For support requests regarding the operation of the Vermittlungsdienst and the eSender Hub, please contact: support-oeffentlichevergabe@bdr.de.

Questions about the announcement service can be directed to support-oeffentlichevergabe@bdr.de.

We are open to your suggestions!

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.

Under eForms Support it is documented which eForms versions the subcomponents support.
For each release, we publish releasenotes to describe which component supports which version. The versions eForms-DE 1.0.1 and 1.1.0 will be supported in all components of the public procurement data service from September 13.

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.

We process the status, the time of submission and, if applicable, the time of publication. The OJ number is no longer used in eNotices2. If you require further data from this query, please send us an email with your requirements to: support-oeffentlichevergabe@bdr.de. We will be happy to organize a bilateral exchange.

If your system no longer automatically updates the notice status after the doe_status INTERNAL_ERROR (which is NOT final), you can also check the status via the notices table in the Self-Service Portal (portal.ozg-vermittlungsdienst.de) using your system's login data for the Vermittlungsdienst. Notices will not remain in INTERNAL_ERROR status. Please do not open any tickets with the BDR for this, but contact your specialist procedure manufacturer. Only the doe_status REJECTED is final, in which case you must submit the notice with a new notice ID or version.

In the case of lawfulness warnings, an announcement is only forwarded to the BKMS 5 days after SUBMITTED in TED in order to await the manual check. However, if a situation arises in which an announcement has already been published in BKMS and then changes to NOT_PUBLISHED in TED, our system automatically stops this announcement in BKMS so that the status changes to DÖE:Stopped. In this way, we ensure that no announcements rejected by TED remain published in the BKMS. However, this scenario is very unlikely.

• The notices are linked to the procedure ID.

  Special features:

  --> Planning/PINs are not part of procedures: Use BT-125

  --> Surcharges within a framework agreement: Use OPT-100

  --> Change notice: Use BT-758

  --> Contract amendment: Use BT-1501

  --> Notices before eForms (and all other cases): Use OPP-090

• Use TED publication number ([1-8 digits]-[year]) or eForms UUID

• You can also find this information in the Developer Docs FAQ

  • For further details on linking the announcements, see https://github.com/EFA-FHB/ozg-vermittlungsdienst-doku/blob/main/documentation/eForms_creation.md

• Details on the use of the references can be found here: https://docs.ted.europa.eu/eforms/latest/schema/procedure-lot-part-information.html#previousNoticeSection

The components of the data service can only accept the new eForms structures. The award platforms currently communicate with the EU using the TED schema structures. For ongoing award procedures, it will be the case that, for example, a contract award notice is published after a contract notice or, for example, a contract modification is published for a contract award notice. Can notices for ongoing procurement procedures continue to be sent to the data service in TED 2.0.9 XML format until the cut-off date of 25.10.2023 or should they be sent directly to TED as before until the cut-off date?

Until eForms-DE becomes mandatory, the old format can be submitted directly to TED. For future submissions to the Public Procurement Data Service, only the new format of the eForms-DE standard can be used.

In principle, it is possible to correct an announcement by sending a new version of an announcement in eForms format to the data service before publication. This update is then sent to TED and TED publishes the latest version of the announcement. If the original announcement has already been published, a "change notice" must be sent.

It is currently being clarified with TED how a previous announcement in the old format can be referenced in order to link them together and to what extent the change of the submitting eSender has an influence on changes.

Both change notices and therefore the "Change Notice Version Identifier" (BT-758) as well as the "Framework Notice Identifier" (OPT-100) and "Previous Notice" (OPP-090) are TED-specific solutions that can be used directly.

Question 2 under Roadmap - The need for a rendering method has already been recorded and is currently being analyzed.

The eSender Hub will ensure that this announcement is transformed into a valid eForms-EU document in accordance with the eForms-DE version submitted in order to be able to use the TED functions.

The SDK-DE can be found at https://gitlab.opencode.de/OC000008125155/SDK-eforms-de.
The latest version of the SDK-DE belonging to the standard eForms-DE version 1.1.0 published on xeinkauf.de is 1.1.0_1.7.2:

https://gitlab.opencode.de/OC000008125155/SDK-eforms-de/-/releases/SDK-DE_1.1.0_1.7.2

According to this rule, recipients of grants under VgV can only tender for construction services, but not services. Even in award procedures under SektVO, KonzVgV or VSVgV, there are restrictions on the selection of forms applicable in an award procedure for grant recipients issuing tenders compared to other awarding bodies, which is incomprehensible.

This is a BUG in TED. This has now been fixed and is built into both the DÖE and the SDK from version 1.1.0_1.7.2; https://gitlab.opencode.de/OC000008125155/SDK-eforms-de/-/blob/SDK-DE_1.1.0_1.7.2/sdk/examples/de/notices/ContractAwardNotice_CVD3.xml?ref_type=tags

TED will unfortunately only fix this error of an overly strict rule regarding BT-743 (electronic invoicing) in version 1.10 of the TEd-SDK and higher, but not for previous versions. Platforms that send notices to the Datenservice Öffentlicher Einkauf Vermittlungsdienst in Germany will unfortunately have to deal with the error until the expected introduction of SDK-DE 1.2.0_1.10.0 in February 2024 and the subsequent implementation in the awarding platforms or editorial system.

As a transitional solution until then, contracting authorities can enter "required" in BT-743 (Electronic invoicing), but then note in BT-77 (Provisions - Financing) that although "required" is entered in BT-743, this is NOT "required" according to this regulation, but that electronic invoicing is "permitted" and desired instead.

**This is a BUG at TED. This will be fixed in 1.10 and therefore in eForms 1.2. The above workaround must be used for older versions **.

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 to 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 where 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 indicated. If several bids have been awarded, all winning bids must be listed below. In the section "Lot result" (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 form module "Tenders" (efac:LotTender) Here it is important to set an internal form reference number to the offer, as this should already be used in the previous section, for example - in the reference to the offer (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 ID, as this field is used to determine the underlying bid in a backward chaining process 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. As this is a text field, there is no technical problem here. Only one value can be inserted at the beginning of the text field: #Specially suitable for:{freelance OR self OR startup}#'. After this value, however, further explanations can be inserted as free text.

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.

Documentation can be found here: https://docs.ted.europa.eu/eforms/1.5/schema/procedure-lot-part-information.html

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.

Country-specific NUTS code lists are available in the TED SDK (https://github.com/OP-TED/eForms-SDK/blob/1.7.0/codelists/country.gc )

As the country is part of the NUTS code, it is not necessary to specify it separately.

• For API submissions, NoticeAuthorEmail should be the buyer's email - eSenders must specify the true email address of the originator in the metadata

• Notice author email receives notifications of status changes: --> Submission, Validation Failed, Stopped, Not Published, Published

• The eSender receives a copy to the e-mail address used by EU Login for the API key.

• Ongoing improvements to the content and translation of these email notifications

• New feature coming soon: Buyers will receive an email notification when an announcement with the same buyer name has been published

• Note for API testing (risk of receiving many emails): use a unique "main buyer name" for recurring buyers and a random name for multiple buyers

• Vermittlungsdienst API parameter: authorEmail Please enter the email of your end customers accordingly**