EA Version change to EA 17.

Q4 Roadmap

The eInvoicing release was discussed (ePO 4.2.0) :

Roadmap for Q4 was presented. (see agenda)

An agenda of any upcoming meetings will be posted each Friday.

It was decided that PostAward WGMs will be on Thursdays, and WGM meetings on eEvaluation on Tuesdays.

Next thursday (3/10) we will exceptionally cover ePO github issues.

https://github.com/OP-TED/ePO/issues/153 was discussed, and closed.

Discussion About the new Annex document on implementing Regulation 2023/2884 .

To post an agenda of upcoming weekly meetings each Friday.

For Thursday: Discuss about award decision outcome. Specifically about MiniCompetition. We need to either change the class or its definition.

What was proposed in the meeting :

To discuss about the following Github tickets:

Ticket https://github.com/OP-TED/ePO/issues/599, was moved to the 4.3.0 milestone

Ticket https://github.com/OP-TED/ePO/issues/639, it is a duplicate of issue 617, and was closed.

Ticket https://github.com/OP-TED/ePO/issues/634 was implemented.

https://github.com/OP-TED/ePO/issues/624, was discussed:

Create a ticket: Predicate epo:specifiesSubcontractor should be deleted in ePO 5.0.0

Create a ticket Further Investigate whether we should remove the codelists of epo:Notice , since the values of the codelists are represented as concepts in ePO.

Fill in the ePO mappings on the PEPPOL despatch advice data model.

Carrier is an Organization.

The transport_means_operator is an epo:Person.

It was noted that Delivery information should be mandatory.

Predicate epo-ful:hasDespatchPeriod was added. Definition: "The time period when the Despatcher picks-up the goods to be delivered. WG approval 16/07/2024"

The definition of epo-ful:specifiesPlaceOfDespatch predicate was updated: The time period when the Despatcher picks-up the Goods Items to be delivered.
WG approval 16/07/2024".

It was agreed that in the next eFulfilment meeting we will tackle the despatchLine concept from the despatch advice data model.

Create a ticket: Model Fuel consumption business groups to 4.3.0

Create a ticket to model measurement Dimension as a codelist based on the following: https://docs.peppol.eu/logistics/2024-Q1/codelist/UNCL6313-T120/

Add definitions to eInvoice concepts.

Discuss about tickets with no milestones.

Github Issues 653, and 652 were resolved.

The following definitions were added:

An example of invoice with multiple VAT was presented.

It was mentioned that all the information Classes are specifications of epo-cat:InformationHub

To revisit the model in order to add more epo-inv:PaymentCardInformation attributes if required by the ePO users.

Create ticket: Delete predicate epo-inv:hasTaxCategoryTaxableAmount

To generate the glossary for eInvoicing.

Discuss tickets with the 4.1.0 milestone.

Discuss tickets with the 4.2.0 milestone.

eInvoicing conceptual model evolution.

A short introduction of the eInvoicing module was given.

The concept of Credit Note was discussed: A credit note is a document that corrects an invoice or invoices.

In PEPPOL the invoice always uses the value "Commercial Invoice" for the document type code. In ePO this codelist is at-voc-new:document-type.

It was confirmed that BT-73, eInvoicing period startdate is used for services.

The class epo-inv:PaymentInstructionsInformation on the "eInvoicing" diagram was presented.

The "eInvoicing allowance charge and Tax" diagram was presented.

It was discussed how to model different Taxes. It was decided that there shouldn’t be predicates discriminating between VAT and other taxes.

epo:MonetaryValue epo:hasCurrency should have cardinality of 1, rather than [0..1] (a github issue is foreseen for this).

The total amounts that are present at the level of the invoice diagram were presented in the diagram below.

The invoicing vat breakdown diagram was presented.

Next the roles that take part in eInvoicing were presented

The diagram depicting the invoice-line was presented

The diagram containing the Item concept in relation to eInvoicing was presented.

The epo-cat:hasAttributeType of class epo-cat:ItemProperty should be mandatory. (a github issue is foreseen for that)

UBL to provide a list of different documents that can be linked with the Invoice.

UBL to provide an example for invoice

IInform PEPPOL about the cardinalities of different business terms in the context of a country using more than 1 currencies.

Update the invoicing VATbreakdown diagram in order to include all taxes.

ePO github issues to be created:

Tax-scheme should have a cardinality of 1.

Should these attributes be mandatory or not?

Evolution of the ePO modules

eFulfilment dataModel.

It was decided that the following predicates will be removed from the eFulfilment module of future ePO versions:

It was decided that the following predicates will be added from the eFulfilment module of future ePO versions:

Definitions for the following predicates of the efulfilment module were filled:

Next time the WG will continue adding definitions from the predicate epo-ful:hasPackagingType concept.

epo-ful:hasMainCarriageShipmentStage predicate will stay as it is . We are still expecting a decision from PEPPOL regarding issue 575

In the next WG meeting we will continue discussing concepts from the business group "Direct debit".

Create a github ticket to remove epo-ful:Notifier. We do not need this concept because we have the epo:FreightForwarder responsible . It will be removed in the next major release.

Create a github ticket to remove epo-ful:isHazardousRisk after confirmation from the WG because it is covered at the level of consignment. If it is to be removed. It will be removed in the next major release.

Create a ticket to remove the following attributes from epo-ful:Consignment.

eInvoicing

A draft of the eInvoicing ORSD document was presented and edited by the Working Group.

The natural language statements that will be included in the ORSD were presented.And modified.

It was decided that the terms providing information on the Business Process will not be covered in ePO, because it is out of the Ontology’s scope.

Need to check cardinality for payment instructions in the latest version of the standard, for the Natural Language Statements.

Need to check if the payment terms should be mandatory.

Need to check what is Receiving advice. Is it receipt advice?

Evolution of the ePO modules.

eFulfilment definitions

The definitions of the following ePO core concepts were added/updated:

The definitions of the following ePO concepts specific to the eFulfilment module were added/updated:

Also, It was noted that the property from package to epo-ful:GoodsItem should have cardinality 0..*. So it was changed from 1..*.

Enquire about the validity of the epo-ful:DespatchAdvice concept definition in next eFulfilment meeting.

eInvoicing

Evolution of the ePO modules

eFulfilment data model.

Create a ticket: change the name of epo:VehicleInformation in ePO 5.0.0

Collect requirements of eInvoicing and present them on 16/5/2024.

ePO attributes definitions (standard forms related)

Definitions for the following ePO concepts were added:

Class epo:SecurityClearanceTerm  Attribute epo:hasDeadline definition: "The deadline by which the security clearance must be submitted to the buyer.WG Approval 12/09/2019", *was changed to: *"The time limit by which the security clearance must be submitted to the buyer. WG Approval 02/05/2024."

Class epo-not:PreMarketConsultationNotice definition was added: "Announcement of a pre-market consultation. Additional information: A pre-market consultation is not a call for competition and no procurement documents are available at the time of consultation. A consultation may or may not be followed by a future competition.WG approval 02/05/2024.

It was also discussed that Inheritance connections between Classes should be somehow visible in the glossary (for model2owl).

Create a ticket: The attribute epo:hasOJSIssueNumber should be avoided and use adms:identifier from document instead. Eventually (in ePO 5.0.0) the epo:hasOJSIssueNumber attribute should be removed. Do the same for attribute epo:hasOJSType.

Create a ticket : Harmonize the definitions of deadlines.

Create a ticket: Harmonize the definitions of all notices taking into consideration the codelists.

Strategic procurement predicates definitions (eforms related)

Definitions for the following ePO Classes were added:

Definitions for the following attributes were added:

Create a ticket on a UML/glossary tutorial on ePO

Create a ticket to add Cardinalities to release notes.

Github issue : This concept belongs to the contract module and it should be removed from Core.

Create a ticket: Harmonize all URL Attributes .

Discuss about issue 443

eOrder data model update.

Issue 443 was discussed. It was agreed that PEPOL will come up with a clear solution to the matter.

The Definitions of fields in eOrder data model were discussed and updated.

Map the business terms to the appropriate ePO concepts.

Add definitions on properties

Class: epo:ReviewIrregularitySummary:

Class: epo:ProcurementCriteriaSummary

Class: epo:AwardCriteriaSummary

Class: epo:QualificationCriteriaSummary

Class: ParticipationConditionsSummary

Class: epo:ProfessionalSuitabilitySummary

Class: epo:EconomicStandingSummary

Class: epo:TechnicalAbilitySummary

Class: epo:ExclusionGroundsSummary

Class: epo:MiniCompetitionAwardOutcome

Class: epo:AwardOutcome

Class: epo:ConcessionEstimate

Class: epo:SubcontractingEstimate

Class: epo:SubcontractingEstimate

Class: epo:Contract: “Additional information”’ was deleted from definition.

Class: epo:DirectContract

Class: epo:ElectronicSignature

Class: epo:JuryMember

Class: epo:specificDuration

Class: epo:IndefiniteDuration

Create a Ticket discussion on Alignment about how to deal with Unpublished fields.

Create a ticket on how to deal with epo:indefiniteDuration and specific Duration. Propose for epo:indefiniteDuration to be deprecated and change the structure of epo:Duration.

Github issues 396 and 397

Discuss certain fields on Annex to the second amendment of the eForms Implementing Regulation - 2023/2884.

The github issues 396 and 397 of the ePO repository were discussed, and closed.

The new Annex to the second amendment of the eForms Implementing Regulation - 2023/2884 was discussed. Specifically:

Create a ticket on Github on BT-79 Performing Staff Qualification (under BG-705 Other Requirements). We need to change this property as BT-79 is not a criterion and we need to find where to place it. It could be added on Submission Term (if it goes there it excludes the contract), It could be added to contract terms (since it’s about th*e future contract*). (label it alignment)

Create a discussion in Alignment on Github: "Check all the dates fields from https://docs.ted.europa.eu/eforms-sdk-explorer/. If it is just a date in eforms, we just put a date on ePO. If date and time in the eforms is mandatory, then we have to put both of them.

Create a ticket in the alignment discussions whether ,OPT-110-Lot-FiscalLegis, OPT-111-Lot-FiscalLegis, OPT-120-Lot-EnvironLegis, OPT-112-Lot-EnvironLegis, OPT-130-Lot-EmployLegis, and OPT-113-Lot-EmployLegis should exist in eforms/ePO.

Create a ticket to investigate if there is a problem with BT-748. There is a problem with this field because we instantiate a selection criterion that does not exist.

Property Epo-sub:hasMandate definition was updated:

Property po-sub:hasPowerOfAttorney definition was updated:

Property epo-sub:specifiesResponse definition was updated:

Class epo-sub:Response definition was updated:

Property epo-sub:answersQuestion definition was updated:

Property epo-sub:refersToApplicablePeriod prefix changed to epo since is not used anywhere else in the ontology. Its definition was also updated:

Property Cccev:ConfidentialityLevelType definition was updated:

"Security classification assigned to an Evidence e.g. classified, sensitive, public.Additional Information:Classifications should be defined by an organisation/country as an outcome of a security assessment."

Class cccev:SupportedValue definition was updated:

Attribute cccev:value definition : "Value for the Information Concept that the Evidence supports."

Property cccev:providesValueFor definition : "Information Concept for which the Supported Value provides a value."

Attribute epo-acc:refersToNotice definition : "Reference to a Notice. WG approval 12/03/2024".

Class epo-sub:CertificateInformation definition :

Property epo-sub:summarisesInformationAboutCertificate definition :

Attribute sub:coversAllSelectionCriteria definition :

WG approval 12/03/2024".

Property epo:canProvideTaxAndSocialSecuritiesEvidence definition :

Property epo:canProvideNonDiscriminatoryEvidence definition :

cccev:isDerivedFrom definition:

Include definitions from eli ontology on eAccess concepts.

EFulfilment data model update

The alignment between PEPPOL business term requirements and ePO eFulfilment continued from where it left off in the last working group meeting on the eFulfilment module (see WG meeting). During the meeting the following concepts were covered from the Dispatch advice data model:

Properties on epo-ful:ShipmentStage must change in epo 5.0.0 .

Add missing definitions on the covered fields.

Provide mappings for the covered fields.

The "Environmental Emissions" concept is missing in ePO and needs to be included in a future version.

Add definitions for eSubmission and eAccess.

The diagrams of the eSubmission and eAccess modules that will be pre-released were briefly presented.

The ESPD-EDM Conceptual model and business handbook were consulted in order to update the definitions of the following concepts:

epo-sub:ESPDResponse class:

epo-acc:ESPDRequest class:

epo-sub:NationalPrequalificationData class:

epo-sub:LegalRepresentative class:

epo-sub-Mandate class:

epo-sub-PowerOfAttorney class:

Continue work on remaining OTHER CRITERION models

Present final draft for eAccess module

The meeting started by presenting the instantiation for professional risk insurance selection criteria. Parts from the eAccess instantiation diagram of the same selection criteria were included into the eSubmission instance diagram so that we can show how the link between response and request at the level of information requirements is done. This is the reason why 3 Instance diagrams for the 3 question subgroups of the professional risk insurance selection criteria were created.

It was agreed that the instance diagrams satisfy the needs for the ESPD Response, and no further review is needed for the instantiation of a procurement criterion within eAccess and eSubmission.

The overview diagram for eSubmission (ESPD Response) was presented.

It was noted that the attribute cccev:value for class cccev:SupportedValue was missing, and was added during the meeting.

A quick presentation of the diagrams to be published in eAccess module was given.

Clean up and move diagrams and concepts related to eSubmission from sandbox to eSubmission module.

Continue work on OTHER CRITERION models:

The Roles involved in the ESPD Response on the Economic Operator side were presented in the diagram below.

The predicate epo-sub:LegalRepresentative epo:actsOnBehalfOf epo:OfferingParty was added.

The next diagram presented is comprised of three other criteria found in the ESPD-EDM sheet in the excel file Criterion : OTHER-EO-GROUPS, OTHER-EO-RELIED_ON-ENTITIES, OTHER-EO-NOT_RELIED_ON-ENTITIES.

The diagram that represents "Reduction of the number of qualified candidates" found in the ESPD-EDM sheet in the excel file Criterion under OTHER.EO-REDUCTION-CANDIDATES was presented.

The diagram below was presented and discussed.

Extend the github issue in ESPD-EDM repo to incorporate the following use case: certificate or documentary evidence?

Investigate if cccev:Evidence can be extended by adding a dct:description attribute.

Check adms alignment to cover for the economic operator identifier in a given scheme agency. <cbc:ID schemeID="VAT" schemeAgencyID="ROLECE" schemeAgencyName="Registro Oficial de Licitadores y Empresas Clasificadas del Estado">B82387770</cbc:ID>

Fulfilment data model update

During the meeting the following concepts were covered from the Dispatch advice data model:

Add missing definitions on the covered fields.

Provide mappings for the covered fields.

eSubmission model update.

The diagram that represents the ESPD-EDM OTHER-EO-PQS sheet in the excel file Criterion was presented. OTHER-EO-PQS is about the existence and the proof of economic operators existing in a prequalification system or official list.

At the end of the meeting, the EO-PQS diagram looked like the picture below.

The ESPD team should come with a solution on how the official list and certificate should be disentangled, which could include providing precise information on the two concepts. (page 8-9)

present instance diagram for the Exclusion Ground "Payment of Taxes"

The Exclusion Ground "Payment of Taxes" instance diagram from the eAccess module (using the CCCEV model) was presented.

It was agreed that the CCCEV model is sufficient to cover the ESPD Request requirements.

Regarding which vocabulary to use in the context of confidentiality level, it was decided that ePO should use the access-right codelist, and not the confidentiality-level codelist.

The CCCEV alignment was extended by adding the Evidence Type and Evidence Type List concepts in ePO, resulting in the diagram below.

Refactor eAccess module based on the decision taken today to adopt the CCCEV model for the ESPD Request.

Investigate which codelist should be used in place of the "Evidence type classification code list" in ePO.

Fill in all the empty definitions of concepts in the eAccess module.

Continue the presentation and evolution of the eSubmission conceptual model.

It was noted that the class epo:EconomicOperator was equivalent to epo:OfferingParty therefore there is no need to add it.

A diagram of eSubmission should show only the specialisation roles required for eSubmission.

epo-sub:PreQualificationData should concern an org:Organization.

epo-sub:PreQualificationData should become Epo-sub:NationalPreQualificationData .

The UBL 2.3 qualification response is used as a basis for the ESPD-EDM. The UBL 2.3 qualification response foresees a Qualifying party, however it is not clear if this component is used in the ESPD-EDM.

It was asked how the ESPD-EDM implements the following fragment of the ESPD regulation:

In the ESPD 3.3.0 this is implemented as a Criterion. This should not be a criterion. We need to find an alternative way to model this. Perhaps as an Information Requirement.

It was confirmed that epo:ParticipationCondition is not an epo:QualificationCriterion.

It was noted that there should be a correlation of what is in the ESPD-criterion.xlsx. and the ESPD-EDM Regulation.

In the ESPD-criterion.xlsx. File there are sheets covering "other criterion". However, these "other criterion" are not criterion in the sense of the ePO. They contain Information Requirements that are structured in the ESPD-EDM in the same way as Exclusion Grounds and Selection Criterion. These "other criterion" need to be analysed as to whether they should be modelled as independent concepts, Criterion or Information Requirements (which are not connected to a criterion). This analysis will have an effect on both the ESPD Request and the ESPD Response. The other criterion are listed below:

Create a ticket for the ePO repository: The ESPD uses the Criterion codelist to identify each criterion in the criterion Excel file one of which uses the code "shelt-worksh". eforms uses the reserved-procurement codelist to indicate the same concepts. This possible redundancy needs to be looked into for the alignment of ESPD and eforms using th ePO.

Create a diagram for all "other criterion".

eSubmission model update.

The epo-sub:PreQualificationSystemData class was created to represent the cac:QualifyingParty class from the ESPD-EDM model.

It was noted that in UBL 2.3 cac:QualifyingParty has the following definition: "The party qualifying this economic operator."

It was decided that in ePO we do not model the QualifyingParty as a role but as data that is linked to the EconomicOperator role.

Next we discussed the ePO alignment with the CCCEV model.

It was noted that In ESPD sometimes there is no need to provide evidence, just a response to the question coming from an ESPD request.

The Response and Evidence concepts in the context of eSubmission were presented and aligned to the ESPD-EDM and CCCEV models.

In ePO the Evidence class has as a confidentiality-level type a value from at-voc:confidentiality-level codelist.

It was noted that the EvidenceType concept from CCCEV represents the TemplateEvidence from ESPD-EDM.

In the ESPD-EDM diagram, cac:Evidence is connected to a cac:DocumentReference which seems like a conflation of multiple concepts (Certificate, EvidenceDocument, Mandate, IdentityDocument). In ePO, a Certificate is a subclass of epo:Evidence which is not a document.

It should be discussed which controlled vocabulary among at-voc:access-right and at-voc:confidentiality-level codelists should be used in ePO.

ePO should align with CCCEV on EvidenceType and EvidenceTypeList.

Present first draft of eSubmission model.

Regarding issue #https://github.com/OP-TED/ePO/issues/482[482]: Remove link between Procedure and ExclusionGrounds. The following points were discussed:

Also the natural language statement that the procedure should specify exclusion grounds should be deleted.

There is a need for a definition for epo:hasProcurementScopeDividedIntoLot . Even a different name.

The Submission diagram was presented and modified according to feedback from the WG. The new diagram is the following:

New natural language statement was added to the ORSD: "An ESPD response must refer to only one ESPD request".

It was decided that we do not need an association from the ESPD Response to epo:Procedure.

The Submission economic operator diagram was presented and discussed (see below) .

There was a problem with eo-role-type codelist. Also, epo:otherEntity should be renamed reliedUponEntity.

There is no candidate in the ESPD. However, if the ESPD is to be used for a DPS, then a candidate should be foreseen and not a tenderer.

There will be an alignment project later in the year to align the ESPD and eforms via the EPO.

The issue #https://github.com/OP-TED/ePO/issues/482[482]: should be closed according to the discussion above.

Create a ticket in Github repo: "Find an appropriate definition for epo:hasProcurementScopeDividedIntoLot in ePO 4.1.0, and suggest a new predicate for a new major release if necessary.

Add a ticket to change epo:otherEntinty to reliedUponEntity.

Present eAccess instance diagram using CCCEV model.

eSubmission user stories.

The general yearly turnover and professional risk insurance instance diagrams were presented. The main idea was to see if the CCCEV model could adequately present the concepts required by the ESPD request. It was agreed that the ESPD team should review the two diagrams before the next meeting.

The updated user stories for eSubmission were presented:

It was noted that the ESPD team could send some example queries for eSubmission.

It was stated that It is not obvious how to correlate the data only by the ESPD response. As the ESPD responses are not stored anywhere currently it is difficult to foresee the queries someone could ask. However questions such as "has a given economic operator provided coherent data across different procedures of a given buyer?" are valuable examples to be expressed in case of future implementations. Individual information systems will depend on the implementation that each Buyer provides.

When creating a query one should ask oneself, if all the data concepts represented in the eSubmission module were instantiated in a triplestore, what information would a buyer want to receive from this data?

It was noted that the content in EU vocabularies is not necessarily used by all Member States.

Natural Language statements should be reviewed by the ESPD team.

Create an instance diagram for the Exclusion ground "Payment of Taxes".

The ESPD team should:

Review the eSubmission requirements

Discuss ESPD GitHub issues

2 user stories were presented. One for the Tenderer/Candidate, and one for the Buyer.

A request was made for more user stories and competency questions. It was explained that the user stories should be created in the same vein as per the eAccess module. Although the ESPD response structure reuses the ESPD request structure, we need to know the questions that could be created on the data in the ESPD response.

It was agreed that some user stories from eAccess can be modified to accommodate eSubmission, and examples of these modifications were shown during the meeting.

Translated eSubmission user stories:

In the user story for the subcontractor the data available will depend on whether explicit information was requested in the ESPD request. The need for information on the subcontractor may vary from country to country.

Financial ratio type: It was decided that financial ratio type should be implemented in ePO, even though this codelist is maintained by the ESPD team in their repository.
It was mentioned that ePO could refer to the ESPD’s code list about Financial ratio type, espd:FinancialRatioType.
It was noted that the name of the dependency link from cac:ResponseValue to the espd:FiancialRatioType codelist is missing in the ESPD Response TOV (see diagram below). We will add a ticket to inform the ESPD team although this has no consequence at this stage on ePO.

It was decided that the user stories for Exclusion Grounds can be reused in eSubmission as-is for eAccess module.

It was mentioned that the US-EG-2 user story is not viable for both eSubmission and eAccess because we cannot have a Procedure without Exclusion Ground.

It was noted that the ePO team should Specify when creating issues in the ESPD-EDM github whether the issue is related to the ePO via the label "ePO question".

The following issues were discussed and updated:

Add a ticket to inform the ESPD team about the missing name of the dependency link between cac:ResponseValue and the espd:FiancialRatioType codelist .

The ESPD should check the competency questions before Friday 2/2/2024.

Order data model update

Plan work on Fulfillment data model update

A question was raised about the terminology of Agent rather than Actor in the TC440. CEN BII used the term Actor, however eOrdering is now using Agent to be aligned with the ontology. The choreography document of TC440 eOrdering has undergone formal vote so it seems that it cannot be changed.

There was a discussion on the Buyer name business term description:

After that, there was a discussion on the Seller:

It was decided that the ePO class and property paths and definitions will be provided in a similar manner as in the Order data model update.

It was noted that at times the ontology goes too granular for the data that will be provided when creating ontology conformant data. The ePO should look into how they can help data providers find a solution to this. An example of this is when the legal representative of a Seller can either be a legal person or an organization. Often data sources only consider the party and not whether it is a person or an organization therefore if they want to provide ontology conformant data they need a way of differentiating between the two which, in this situation, they cannot.

Continue collecting eSubmission requirements.

There is a problem with Power of attorney . A person has a power of attorney and it is not a role. The ESPD model appears to conflate Person and PowerOfAttorney. The modeling in UBL was consulted (https://docs.oasis-open.org/ubl/UBL-2.4.html) where the PowerOfAttorney exists, which is a document that has an AgentParty.

Cac::DocumentReference: Is a class to define a reference to a document (Document Reference) A reference to the evidentiary document (Evidence) / A reference to a document relevant to this certificate or an application for this certificate (Certificate). We have this in ePO as a *Certificate *(foaf:Person hasCertification epo:Certificate, etc).

We do not have examples of the xml for mandate document.

It was discussed whether or how cac:Evidence cac:EvidenceSupplied should be implemented in the ePO. In the ePO, we will merge these two terms into one concept.

espd:FinancialRatioType: Is a technical code list that we do not need to implement in the ePO.

For the access-right code list, the ESPD uses only the values "confidential" _or "_public".

By the end of the week we will have the draft of the ORSD document.

Create an issue on how the ESPD models the power of Attorney. We should ask them if there is a conflation between the concept of a person and PowerOfAttorney document.

Create an issue in the ESPD github stating that the link of cac:ResidenceAddress to the at-voc::country is missing in the ESPD document.

Edit Github issue 502. (https://github.com/OP-TED/ePO/issues/502)

Present instance diagram using group and subgroup identifiers instead of the concepts in the eAccess module.

Add definitions to remaining concepts created in the eAccess module.

Discuss GitHub issue Remove link between Procedure and ExclusionGround #482.

An Introduction about the action point in the previous working group meeting on eAccess was presented.

With regard to the action point mentioned above, a new conceptual model that contains group and subgroup identifiers was presented.

At the instance level, part of the general yearly turnover selection criteria was presented:

It was pointed out that this modeling creates a Question instance with no data except of the identifier (to cover the subgroup gathering classes used in the ESPD implementation) so it was suggested to have the identifiers at the Question level resulting in the following diagram:

There were some doubts regarding the new model:

A third solution to simplify the previous version was created in the diagrams below:

It was mentioned that all the existing conceptual diagrams of eAccess can be consulted in the ePO repository on the development branch.

It was stated that in the ePO :

Create new instance diagrams for some ESPD criteria (general yearly turnover, and others) by using the CCCEV model.

Create a high level description about the module(s) to be presented in working group meetings.