Cumulative content of Working Group Meetings in 2023

The modelling of ELI was presented. It was noted that ELI includes Manifestation concept, which is not required within eAccess.
It was discussed that ELI will be imported into the ontology and the concepts required will be reused and not customised:

Since the concepts in the ELI model can be used even if ELI is not implemented in the given Member State the following concepts were removed: cccev:ReferenceFrankework epo-acc:Legistion epo-acc:Article.

As the subcriterions ar only used for National Criterion it was decided to change the predicate epo-acc:hasSubcriterion to epo-acc:includesNationalCriterion.

To simplify the reading of the model for business people, it was decided to create specialisations of the CCCEV concepts.
If an entity needs to exist you need explicity to show it. An entity should be a whole.

It was suggested to add a composition relation (the idea of one concept containing another) between:

However, the composition relation type is not foreseen in model2owl.

Continuing with the NLS:

*

The Requirement for the Selection Criterion is not mandatory in ESPD version 3.

*

Changing the NLS below to reflect what was mentioned above:

But epo:ExclusionGroundsSummary is directly a subclass of cccev:Requirement, and not of cccev:Criterion (which is linked to at-voc:criterion) and that is why in ePO we can not provide a type for epo:ExclusionGroundsSummary:

We have 3 option for fixing this in ePO:

Next on:

General Yearly Turnover

Paloma presents the calendar of the future ESPD and ePO meetings.
The General Yearly Turnover slides where then worked on for the ESPD-EDM OUC Meeting.
It was noted that the question to ask during the presentation should be: Where is the Threshold per year checkbox in the mock-ups from the ESPD-EDM repository GitHub issue 44?
Pascaline showed that in the ESPD-EDM technical handbook there is another mock-up which seems more up-to-date: https://docs.ted.europa.eu/ESPD-EDM/latest/xml_technical_handbook.html#_turnovers

EG_misrepresentation is used to check if the Tenderer has been misrepresented, withheld information, unable to provide required documents and obtained confidential information of this procedure.

All {ADDITIONAL_DESCRIPTION_LINE} tags need to be answered by the Tenderer.

This should not be in the ePO model, but as part of the definition of the misrepresentation element code (exclusion ground) used.
Below is a screenshot from the Belgian ESPD service:

Going through the NLS one by one:

This is an open question since in ePO we provide both ways.
An email is sent by Lorent to Marc Christopher to ask this question. To be confirmed with GROW.

The predicate epo-acc:refersToNotice was added between epo-acc:ESPDRequest and epo:Notice

There is an idea in the ESPD community to remove certain data from the ESPD, since the data is already in the Notice, so the ESPD Request can focus only on the Qualification Criteria.

It was decided that docref-content-type controlled vocabulary is not needed in the ePO.

We should take a decision on whether to remove the epo-acc:concernsProcedure predicate between epo-acc:ESPDRequest and epo:Procedure:

Why are there two relations between cac:TenderingCriterion and cac:ProcurementProjectLot?
They are used to express the different cardinalities between Selection Criterion and Exclusion Ground.
Exclusion Ground is at the Procedure level and not at the Lot level.

The cac:TenderingCriterion concept includes the attribute ProcurementProjectLotReference, but has also links to cac:ProcurementProjectLot class as depicted below:

This should be handled by the ESPD team.

The Legislation concept is only a reference to the actual legislation, so it should not be treated as a Document.

A question once again came up about the Criterion versus Subcriterion. Pascaline asked why don’t we create a special class for SubCriterion or for REQUIREMENT_GROUP. After that it was said that Subcriterion might not really be used in ESPD Request.

It was mentioned that at the ePO level a Subcriterion is just another Criterion and we don’t need to create it. It was decided that at the moment we will keep the model as it is, without differentiating between ProcurementCriterion and Subcriterion.

The first QUESTION_SUBGROUP for the General Yearly Turnover use-case was discussed:

The proposed instantiation for the above QUESTION_SUBGROUP is:

The second QUESTION_SUBGROUP is presented:

with its proposed instantiation:

Pascaline will look at the rest of 3 question subgroups for the next time.
Continued with presenting where the documentation for the ePO exists.

Since cccev:ReferenceFramework represents the legislative part in CCCEV, epo-acc:Legislation and epo-acc:Article were added as subclasses of cccev:ReferenceFramework.

This implies that we no longer need epo:ProcurementCriterion epo-acc:implementsLegislation epo-acc:Legislation and epo:ProcurementCriterion epo-acc:implementsArticle epo-acc:Article.

These two relations are deleted and _cccev:Requirement cccev:isDerivedFrom cccev:ReferenceFramework _is implemented instead.

From the explanatory example, we can see that CCCEV uses ELI for the Reference Framework, making them able to point directly to an article by using an URI.

The ESPD Request does not have an use case for providing the issuer of the Criterion.

Question: In the ESPD Request does the LEGISLATION apply to all the concepts nested within a given CRITERION tag?

The only link that the ESPD provide is the link between the CRITERION and LEGISATION. They do not need to represent the links between LEGISLATION and REQUIREMENT or QUESTION.

Question: What is the difference between cccev:InformationRequirement and cccev:InformationConcept?

Definition for Information Requirement is: "Requested data that is to be proven by Evidence."
Definition for Information Concept is: "Piece of information that the Evidence provides or the Requirement needs."

Based on the diagram above, the InformationConcept will be used to link to the SupportedValue of the Evidence in the ESPD Response.

(cac::TenderingCriterionPropertyGroup)

In the ESPD Request, cac::TenderingCriterionPropertyGroup is defined as "the sets of properties that can be used to fulfil the tendering criterion."

Financial ratio criterion (finan-rat) has a REQUIREMENT_GROUP with a cardinality of [1..n], meaning that we should have an additional layer between the instance of epo:SelectionCriterion and cccev:InformationRequirement instances. This instance will only provide an Identifier and will group together all the InformationRequirement instances for that specific Criterion.

After discussing the REQUIREMENTS from the ESPD Request side, all the related InformationRequirement instances have been moved at the level of the Group instance as per the diagram below:

The meeting ended with presenting the first QUESTION_SUBGROUP from the General Yearly Turnover:

Working Group meeting
Date: 03/10/2023
Participants: Peter van Borresen, Pascaline Laure Tchienehom
Model editor: Andreea Pasăre
Note editor: Andreea Pasăre

The discussion started around the github issue on the ESPD-EDM github repository.
The resolution of the GH ticket above is unclear therefore it is decided to open a new issue taking into consideration the discussion at the end of the last meeting (26/09/2023). To model correctly we need to know whether there is a requirement to specify different values per year.
The difference between the General Yearly Turnover and the General Average Turnover is that the first one provides a Threshold per year requirement..
The difference between a General Turnover and a Specific Turnover is that the Specific Turnover is for a particular business domain and it does not have a threshold per year.
This means that in a Specific Yearly Turnover the Buyer requires the same minimum amount for each fiscal year.
General Yearly Turnover:

General Average Turnover:

Specific Yearly Turnover:

Specific Average Turnover:

Question: What is the difference between Specific Yearly Turnover and Specific Average Turnover?
Answer:
For Specific Yearly Turnover, the EO is required to provide the amount for all the fiscal years defined in the requirement.

For the Specific Average Turnover, the EO is required to provide the average amount for all the fiscal years defined in the requirement.

This also applies to the General Turnover.
Based on ESPD-EDM GitHub issue 44, the figure below illustrates a possible user interface from the Buyer’s point of view with the modifications discussed above:

A discussion around the REQUIREMENT_GROUP concept from ESPDRequest has emerged. There is a request to add REQUIREMENT_GROUP as a concept in ePO as well since there might be use-cases when a Criterion can have multiple Requirement Groups.
We might need to add a new InformationRequirement instance between the SelectionCriterion and all the other InformationRequirement instances.

The following github issues were discussed, the resulting discussions and solutions are listed below:

#463 To link GoodsItem and Item
GoodsItem and Item could be linked via their Ids epo-ful:GoodsItem epo-ful:hasTraceID and epo-cat:Item has epo:hasSerialID.

Definition for epo-ful:hasTraceID:
The identifier used for tracking the goods item

Additional information:
An example is the EPC number used in RFID.

WG approval 21/09/2023

The origin of the ticket was that Veit had investigated information about the GoodsItem and was wandering why there is no link between the Item and GoodsItem.

Peter questioned whether you can know the packaging in the Catalogue because it does not exist at the time of the catalogue

It is decided to have epo-cat:Item epo-cat:foreseesPackage epo-ful:Package.
As a consequence the epo-ful:Package epo-ful:containsGoodsItem epo-ful:GoodsItem needs to be less restrictive and the cardinality is changed to 0..* rather than 1..* as the eCatalogue will not use the GoodsItem.
The Quantity is on the epo-fulAbstractContainer so it can also be used by the Catalogue.
It was decided that it was more appropriate to put the association of the Package to the Catalogue Line rather than the Item. The model created:

#426 Validity periods for Catalogues and Catalogue Items
Validity period for the Catalogue Item exists, however it is missing for the Catalogue. It existed in v3.1.0 but somehow it has been lost, it was reintegrated in the meeting.
The definition in v4.0.0 for hasValidityPeriod (it is used for different domains and ranges) is an improvement on that used in v3.1.0, therefore the definition already in v4.0.0 is kept:

epo:hasValidityPeriod: the relation indicating until when a given instance of a concept is applicable. WG approval 30/05/2023

The epo-cat:hasCatalogueLineValidity has no definition the following is agreed:
The relation indicating until when a Catalogue Line instance is applicable.

WG approval: 21/09/2023

#453 This ticket provides the basic model for the Catalogue Response. Veit gave a quick overview and the Package was created in the conceptual model.

The outcome of the discussion was the following model:

This will be reviewed and rediscussed at a later date.

The model created in the last meeting (12/09/2023) was discussed.

There seems to be no link between epo-ful:DespatchLine and the epo-cat:Item. It is shown that it exists as the epo-ful:DespatchLine is a specialisation of epo-cat:Line

The following diagram shows how a document can be associated to the DespatchLine.

It was agreed that Peter would provide a list of the business terms used in the eFulfilment use cases so that the mappings to the ontology could be inserted and then checked together at a later date.
Veit will provide a similar file for eCatalogue for information as the mappings have already been done.

Since 28/08/2023 the Contract Award Notices (except those for Defence) are available in rdf format from the Publications Office. It was presented how to visualise the triples of a given notice in Cellar:

Via the link

The text in the Query Text

prefix cdm: http://publications.europa.eu/ontology/cdm# select * where {?s ?p ?o} limit 100
is replaced by the following query

SELECT * WHERE { graph http://data.europa.eu/a4g/resource/2023/519294_2023 {?s ?p ?o } }

And then press “Run Query”.

Where 519294-2023 can be any valid Contract Award Noice published on the TED website based on standard forms and not eForms and excluding eForms.

Due to the code freeze for the v.4.0.0 it was decided to concentrate on the user stories for the ESPD Request.

Exclusion Ground is a Criterion that describes a legal requirement to be met by the Economic Operator to be a Candidate in the Procurement.

Selection Criterion is a Criterion that describes a capacity Requirement that the Economic Operator needs to fulfill to participate in the procurement.
Selection criteria may relate to:
(a) suitability to pursue the professional activity;
(b) economic and financial standing;
(c) technical and professional ability.

The user stories were reviewed and developed:

An Instance diagram showing the modeling of a requirement for a epo:ProcurementCriterion, by using the epo:hasRequirement property defined in the cccev:Requirement.

The ESPD resquester request an ESPD from the ESPD provider. The request is partly reused as a template for the response.

A first use case was defined below, concerning the ESPD Request

The first user stories were defined:

Similar user stories to the ones of relied upon entities can be defined for subcontractors.

Can the ESPD Business Handbook (ESPD Request part only) be considered as requirements for eAccessalong with the documentation of ○%09https:/wiki.ds.unipi.gr/display/ESPDInt/BIS+41+-+ESPD+V2.1.0#BIS41ESPDV2.1.0-tbr070-007[ESPDint]?

Is it necessary for Buyers and Economic Operators to create a new ESPD document for each procedure? Instead, is it possible to re-use an ESPD in different procurement procedures, facilitating the tasks of users.

Reuse in the previous sentence implies partial reuse of the content in the xml file. Paloma will ensure the ESPD documentation reflect the meaning of the re-use more accurately.

Requirements of ESPD and eAccess should not be considered the same. We should consider the ESPD Request as part of eAccess. The ESPD Response should be considered part of eSubmission.

Is it necessary for Buyers and Economic Operators to create a new ESPD document for each procedure? Instead, is it possible to re-use an ESPD in different procurement procedures, facilitating the tasks of users.

The Lot is defined at the ESPDResponse level as depicted in the image below:

It would appear that each ESPDRequest has a different identifier for each Procedure concerned which implies that the ESPDRequest as a whole cannot be reused across procedures.

During the meeting, the participants validated the definitions of the following terms:

It was noted that the models had become easier to work with after the changes made during the previous post-award meeting. In the updated models, each line can now have a description and specify an item. The Information Hub has a direct link to the line, and the AllowanceChargeInformation could be defined at both the Document and Line levels.

The participants then discussed modeling virtual locations for service deliveries it was decided to use location based on coordinates, indicating a geographical location where the delivery could take place.
It was noted after the WGM that a virtual delivery location should be represented as a URL and further discussion is needed on this matter.

The Contract model was presented whereby a Contract is a Document and is subject to Contract Terms. It is signed by both the Contractor and the Buyer(s). It has reference to the Lot(s).
The contract model requirements were mapped to the ePO ontology as follows, where the main bullet represents the requirement, and the sub-bullets represent the corresponding ePO mapping:

The property epo:hasAccessURL has been removed from the Contract class because it was inherited from the Document class.
The property epo:hasHomePage was changed to epo:hasInternetAddress in cpov:ContactPoint class.
It was noted that epo:hasInternetAddress is used in various places

The Contract class has an Amended Contract subclass. The Amended Contract class inherits all attributes from the Contract class.

The following Notices were discussed, and it was suggested to update the Notice modules accordingly to implement them.

A Framework Agreement results from a Lot Award Decision, which concerns a specific Lot that uses the framework technique. The Lot Award decision which is used to establish the Framework Agreement specifies the different Qualification Criterion and Award Criterion (Procurement Criterion) to be used. The Mini Competition that may be launched within the Framework Agreement follows the rules set by the Framework Agreement and involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
The model below was validated:

A DPS (Dynamic Purchasing System) uses a DPS Technique. In the first stage, the different Qualification Criterion are specified and there is no Award Decision, however a Candidate List is created which lists the economic operators that are admitted to subsequent Mini-Competitions. The subsequent Mini Competitions involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
The model below was validated:

To ensure Award Decisions exist for both the Framework Agreement and the Mini Competitions the Award Decision has become a superclass of Lot Award Decision and Mini Competition Award Decision allowing for the different instantiations required for different use cases. The Award Decision comprises Tender Award Outcome which indicates award of Lot to a winner. These relations are inherited by the Lot Award Decision and Mini Competition Award Decision. See diagram below.

After meeting note: as the Mini Competition inherits from the Award Decision the relation “indicatesAwardOfLotToWinner” needs to be reviewed maybe to “indicatesAwardToWinner”
During the WGM, the relations describesLot and describesMiniCompetition were changed to concernsLot and concernsMiniCompetition respectively. Additionally, the relations, epo:hasRestated AwardedValue and epo:hasRestatedEstimatedValue were removed from the model.

During the meeting, the participants defined the following terms:

During the discussion, participants debated whether the Charge Information should be at the Item level or Line level. To illustrate the point an example of countries where certain charges are associated with food items containing sugar. For instance, if an item is priced at 1 euro, the actual amount paid might be 1.7 euros due to the sugar charge. This charge is applied at the price level.
One suggestion put forward was to have the price at the item level, establishing a direct association between the item and its price. However, after further deliberation, the decision was made to maintain the price at the line level while establishing a reference between the line and the item.

In PEPPOL the price is specified based on the location, and the order reflects the price based on quantities. There are two types of discounts: line-level discounts and price-level discounts. Line-level discounts can be defined as a specific amount per line, such as a discount of 100 euros per line. Price-level discounts, on the other hand, are expressed as a certain amount per unit, such as cents per orange.
As a result of the discussion, it was decided to remove the epo-ord:PriceDiscountInformation element and introduce new associations for enhanced clarity and consistency. The new associations are epo-ord:hasPriceDiscountInformation between epo-cat:Price and epo-ord:isSpecificToOrderLine, as well epo:hasPriceSurchargeInformation between epo-cat:Price and epo-cat:ChargeInformation.

The participants agreed to replace the relation adms:identifier with epo:hasBatchID to improv clarity and consistency. The epo: hasCatalogueItemID is replaced by epo:hasSellerItemID
As part of the discussion, it was agreed to add definitions for all epo:Item and epo:Batch IDs:

To illustrate these concepts, an example was discussed: when purchasing a new mobile phone, the seller ID and the manufacturer ID may differ, but a generic buyer ID would be used.
Organisation and Person Certificates
It was agreed upon by the participants to introduce the epo:hasCertification relation between epo:Certificate and epo:Organization, epo:Person, and epo:Item. This new relation allows for the association of certifications with these entities.
Furthermore, the definitions for the following concepts were updated as follows:

During the working group meeting, it was agreed by the participants to rename the entity epo-ord:DeliveryTerm to epo-ord:DeliveryAgreement. By changing the name of the concept there is no conflict with the Term hierarchy of the ontology and the original modelling can be reused. The update was made directly in the meeting.
.

The participants revised the definitions with respect to the concepts that were discussed during the meeting.

Action Points:

Can the ESPD Business Handbook (ESPD Request part only) be considered as requirements for eAccessalong with the documentation of ○%09https:/wiki.ds.unipi.gr/display/ESPDInt/BIS+41+-+ESPD+V2.1.0#BIS41ESPDV2.1.0-tbr070-007[ESPDint]?

Is it necessary for Buyers and Economic Operators to create a new ESPD document for each procedure? Instead, is it possible to re-use an ESPD in different procurement procedures, facilitating the tasks of users.

Reuse in the previous sentence implies partial reuse of the content in the xml file. Paloma will ensure the ESPD documentation reflect the meaning of the re-use more accurately.

Requirements of ESPD and eAccess should not be considered the same. We should consider the ESPD Request as part of eAccess. The ESPD Response should be considered part of eSubmission.

Is it necessary for Buyers and Economic Operators to create a new ESPD document for each procedure? Instead, is it possible to re-use an ESPD in different procurement procedures, facilitating the tasks of users.

The Lot is defined at the ESPDResponse level as depicted in the image below:

It would appear that each ESPDRequest has a different identifier for each Procedure concerned which implies that the ESPDRequest as a whole cannot be reused across procedures.

It was noted that the models had become easier to work with after the changes made during the previous post-award meeting. In the updated models, each line can now have a description and specify an item. The Information Hub has a direct link to the line, and the AllowanceChargeInformation could be defined at both the Document and Line levels.

The participants then discussed modeling virtual locations for service deliveries it was decided to use location based on coordinates, indicating a geographical location where the delivery could take place.
It was noted after the WGM that a virtual delivery location should be represented as a URL and further discussion is needed on this matter.

The Contract model was presented whereby a Contract is a Document and is subject to Contract Terms. It is signed by both the Contractor and the Buyer(s). It has reference to the Lot(s).
The contract model requirements were mapped to the ePO ontology as follows, where the main bullet represents the requirement, and the sub-bullets represent the corresponding ePO mapping:

The property epo:hasAccessURL has been removed from the Contract class because it was inherited from the Document class.
The property epo:hasHomePage was changed to epo:hasInternetAddress in cpov:ContactPoint class.
It was noted that epo:hasInternetAddress is used in various places

The Contract class has an Amended Contract subclass. The Amended Contract class inherits all attributes from the Contract class.

The following Notices were discussed, and it was suggested to update the Notice modules accordingly to implement them.

A Framework Agreement results from a Lot Award Decision, which concerns a specific Lot that uses the framework technique. The Lot Award decision which is used to establish the Framework Agreement specifies the different Qualification Criterion and Award Criterion (Procurement Criterion) to be used. The Mini Competition that may be launched within the Framework Agreement follows the rules set by the Framework Agreement and involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
The model below was validated:

A DPS (Dynamic Purchasing System) uses a DPS Technique. In the first stage, the different Qualification Criterion are specified and there is no Award Decision, however a Candidate List is created which lists the economic operators that are admitted to subsequent Mini-Competitions. The subsequent Mini Competitions involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
The model below was validated:

To ensure Award Decisions exist for both the Framework Agreement and the Mini Competitions the Award Decision has become a superclass of Lot Award Decision and Mini Competition Award Decision allowing for the different instantiations required for different use cases. The Award Decision comprises Tender Award Outcome which indicates award of Lot to a winner. These relations are inherited by the Lot Award Decision and Mini Competition Award Decision. See diagram below.

After meeting note: as the Mini Competition inherits from the Award Decision the relation “indicatesAwardOfLotToWinner” needs to be reviewed maybe to “indicatesAwardToWinner”
During the WGM, the relations describesLot and describesMiniCompetition were changed to concernsLot and concernsMiniCompetition respectively. Additionally, the relations, epo:hasRestated AwardedValue and epo:hasRestatedEstimatedValue were removed from the model.

During the meeting, the participants defined the following terms:

During the discussion, participants debated whether the Charge Information should be at the Item level or Line level. To illustrate the point an example of countries where certain charges are associated with food items containing sugar. For instance, if an item is priced at 1 euro, the actual amount paid might be 1.7 euros due to the sugar charge. This charge is applied at the price level.
One suggestion put forward was to have the price at the item level, establishing a direct association between the item and its price. However, after further deliberation, the decision was made to maintain the price at the line level while establishing a reference between the line and the item.

In PEPPOL the price is specified based on the location, and the order reflects the price based on quantities. There are two types of discounts: line-level discounts and price-level discounts. Line-level discounts can be defined as a specific amount per line, such as a discount of 100 euros per line. Price-level discounts, on the other hand, are expressed as a certain amount per unit, such as cents per orange.
As a result of the discussion, it was decided to remove the epo-ord:PriceDiscountInformation element and introduce new associations for enhanced clarity and consistency. The new associations are epo-ord:hasPriceDiscountInformation between epo-cat:Price and epo-ord:isSpecificToOrderLine, as well epo:hasPriceSurchargeInformation between epo-cat:Price and epo-cat:ChargeInformation.

The participants agreed to replace the relation adms:identifier with epo:hasBatchID to improv clarity and consistency. The epo: hasCatalogueItemID is replaced by epo:hasSellerItemID
As part of the discussion, it was agreed to add definitions for all epo:Item and epo:Batch IDs:

To illustrate these concepts, an example was discussed: when purchasing a new mobile phone, the seller ID and the manufacturer ID may differ, but a generic buyer ID would be used.
Organisation and Person Certificates
It was agreed upon by the participants to introduce the epo:hasCertification relation between epo:Certificate and epo:Organization, epo:Person, and epo:Item. This new relation allows for the association of certifications with these entities.
Furthermore, the definitions for the following concepts were updated as follows:

During the working group meeting, it was agreed by the participants to rename the entity epo-ord:DeliveryTerm to epo-ord:DeliveryAgreement. By changing the name of the concept there is no conflict with the Term hierarchy of the ontology and the original modelling can be reused. The update was made directly in the meeting.
.

The participants revised the definitions with respect to the concepts that were discussed during the meeting.

Action Points:

GH 431

In the context of concession contracts, the award of procedure actually means procedure. So the “scheduled date for start of award of procedure” is the start of the procedure. We should look into the Directive 2014/24/EU for a better understanding.

The term procedure has been conflated.
Question: What is a procedure?
Answer: A description of steps taken by someone, a plan.
This plan acts as a general plan for multiple Lots. There are specific plans per each Lot, but the general plan should be fine-tuned in order to cover all the Lots.

Within a procurement project we can have a procedure type. Each lot should be executed once or multiple times according to the procedure type.

There are procedural things that are open to all Lots. We can think about it as a procurement procedure.

Some actions/events are reusable within a procedure:

The negotiation action can be part of the competition.

Also, WG discussed re-usable process fragments:

eAuction and mini competitions are subsets of closed competition.

Some important examples of procedure types are discussed:

The competition is related to award criteria and the qualification is related to exclusion grounds and selection criteria. All the process fragments should take into consideration the criteria and the appropriate objects.

A differentiation between a plan and an execution is discussed.

We can have procedure-executions per Lot. For a lot, there may be one or multiple executions.

There is one execution for the whole procedure.

Procurement purpose is split into Lots, and NOT the procedure that is split into lots.

Section III.1.* of F21 refers to Selection criteria.

In the eForms they are at the Lot level, but in the standard forms they are at the Procedure level? They are in fact “criteria summaries” for Procedure level

Question: Does SelectioncriteriaSummary inherit from SelectionCriterien?

The property epo:hasLotAwardLimit has been deleted.

epo:hasMaximumNumberOfLotsToBeAwarded is kept.

Example 1

Example 2

Definition for cv:LegalEntity:
A self-empoyed person, company, or organization that has legal rights and obligations.

Definition for epo:Business:
A private law company registered in a national registry.

Any comments on the documentation?

Click here to let us know