Primer¶

Attention

If you are not yet familiar with the eForms SDK, we recommend that you start with the eForms Developer Guide.

The Publications Office of the European Union created the eForms SDK to facilitate eForms implementation. While it is possible to implement eForms without the SDK, the Publications Office politely describes this as requiring "several times the effort to create and maintain." We therefore map to OCDS from the metadata-driven SDK, not directly from the UBL/XML.

The eForms SDK introduces the concept of a field. Each field corresponds to a business term defined in the annex to the eForms regulation. A same business term can have many corresponding fields, for each context in which the term is used: for example, the term Title (BT-21) can be used in the context of a lot, lot group, or part of a Prior Information Notice.

The Field mappings describe how to map each eForms SDK field to OCDS.

How eForms concepts are modeled in OCDS¶

This section explains the relationships between key concepts in eForms and OCDS, at a high level. In some cases, the relationships differ; any differences are addressed in the field mappings. This page assumes you are familiar with the terms and concepts in the eForms specification.

Procedure (one or more contracting processes)¶

In eForms, a procedure is a “series of actions conducted in a given sequence that leads to the conclusion of a public contract.”

In OCDS, a procedure is modeled as a contracting process, which is defined as “all the actions aimed at implementing one or more contracts.” A contracting process is divided into four stages: tender, award, contract and implementation. For an introduction to contracting processes in OCDS, see How does the OCDS work?

In eForms, planning information is “not associated to any Procedure,” though the buyer can define and use an internal Procedure identifier.

In OCDS, planning information is modeled as a planning process, which is defined as “all the actions aimed at planning one or more contracting processes.”

There are differences between a procedure in eForms and a contracting process in OCDS:

In OCDS, a contracting process includes an implementation stage, covering payments, progress updates and completion information. eForms does not currently cover the implementation stage; a Contract Completion form is planned.
In multi-stage procedures (e.g. framework agreements with reopening of competition), OCDS treats each round of competition as a separate contracting process; for more information, see Framework agreements. eForms treats each round of competition as occurring within the same procedure.

The following diagram illustrates the relationship between:

Procedures in eForms and planning and contracting processes in OCDS
Form types in eForms and planning and contracting process stages in OCDS

Procedures and form types diagram

Notice (one or more releases)¶

In eForms, a notice is an XML document published by a buyer about market opportunities and results.

In OCDS, a notice is modeled as a release – or as one or more releases, in the case of a PIN-only notice. A release is JSON text that describes a single contracting or planning process at a particular point in time. For an introduction to releases in OCDS, see How is OCDS data published?

Document type (release tag)¶

eForms distinguishes three document types relating to different stages of the contracting process: Prior Information Notice (PIN), Contract Notice and Contract Award Notice.

The following table describes the relationship between document types in eForms and release tags in OCDS. Release tags distinguish planning and contracting processes, and the stages of the contracting process to which a release relates.

In eForms, a PIN document is a planning notice, unless it is used as a call for competition. These two kinds of PIN documents are listed separately.

Document type	Form types	Release tags
Prior Information Notice (except Call for Competition)	Planning	planning
Prior Information Notice (Call for Competition)	Competition	tender
Contract Notice	Competition	tender
Contract Award Notice	DAP, Result, Contract Modification	award, contract

Part (release)¶

In eForms, a PIN-only notice can be divided into parts. When a call for competition is launched, each part can “become a Lot or a self-standing Procedure.” Each part is represented as a ProcurementProjectLot element whose schemeName attribute is ‘Part’.

In OCDS, each part is modeled as an individual planning release, belonging to a separate planning process.

Parts diagram

ProcurementProjectLot (lot or group of lots)¶

In addition to representing a part, the ProcurementProjectLot element in eForms can also represent a lot (with a schemeName of ‘Lot’), sometimes known as a TenderLot, or a group of lots (with a schemeName of ‘LotsGroup’).

In OCDS, a lot is modeled as a Lot object, and a group of lots is modeled as a LotGroup object.

LotTender (bid)¶

In eForms, LotTenders are “the results of the decomposition of a received tender into fragments, each corresponding to a lot or group of lots.”

In OCDS, a LotTender is modeled as a Bid object.

LotResult (award)¶

In eForms, the LotResult element contains information about the competition results for a single lot.

In OCDS, a LotResult is modeled as an Award object. There are exceptions: notably, a LotResult that represents the termination of a dynamic purchasing system is modeled as a Lot object that has a dynamic purchasing system with a status of ‘terminated’.

SettledContract (contract)¶

In eForms, the SettledContract element contains information about a contract.

In OCDS, a SettledContract is modeled as a Contract object.

Company and TouchPoint (organization)¶

In eForms, the Organization element represents a juridical person, like a buyer or winner – or a natural person, like when the winner is a self-employed individual. An Organization is composed of a Company, representing the legal entity, and one or more TouchPoints, each representing a function of the legal entity. Organization elements are nested under the Organizations (plural) element.

In OCDS, a Company and each of its TouchPoints are modeled as separate Organization objects in the parties array.

Organizations and Touchpoints diagram

In eForms, the CompanyID element (nested under the PartyLegalEntity element, under the Company element) represents the legal entity’s identifier.

In OCDS, a CompanyID is modeled as an identifier field on an Organization object. As such, the Organization objects in OCDS that represent the Company and TouchPoints of one Organization in eForms share the same identifier.

Organization identifiers diagram

UltimateBeneficialOwner (person)¶

In eForms, the UltimateBeneficialOwner (UBO) element represents a beneficial owner of a winner, tenderer or subcontractor. Like Organizations, UBOs are nested under the Organizations element. A UBO is related to a Company by its technical identifier.

In OCDS, an UltimateBeneficialOwner is modeled as a Person object in the beneficialOwners array of the Organization object that the UBO beneficially owns.

Ultimate beneficial owner diagram

What's not included¶

Notice types X01 and X02 relate to events outside the lifecycle of a contracting process.

X01 - Notice containing information relevant to Formation or Completion of the liquidation of a EEIG
X02 - Notice containing information about Registration, Deletion, Transfer-registration or Transfer-deletion of a European Company or European Cooperative Society

Furthermore, the following notice types are listed in the regulation's annex but are not described by the eForms SDK.

E1 - Prior market consultation notice
E5 - Contract completion notice type

Therefore, fields that are only used in these notice types are omitted from the guidance.