PEPPOL is an EU co-funded project CIP-ICT PSP-2007 No TICC PoACC Joint meeting

Agenda  Roll call – joint High level Status and overview (ANKI / SVR) Information about election of CC leaders (SVR) Presentation of the new candidate for PoACC – Sören Pedersen, ESV (SE) Transfer of SML service to DG-DIGIT (SVR) TIA Revision Project (SVR) Message Level Response (MLR) overview (ANKI) AOB Page 2

Roll call – Name and Organization Page 3

High level overview – TICC/PoACC Page 4 PoACC: Yellow pages (TICC) Status: initiated Validation & Quality Assurance (TICC) Status: ongoing LCM & Governance Status: standstill E-Invoicing DSI collaboration – CEF Status: ongoing PC 434 (EN on e-Invoicing) Liaison established, ongoing TICC: SML Service Transfer to DG DIGIT Status: ongoing TIA Revision (PoACC) Status: ongoing E-Delivery DSI collaboration – CEF Status: ongoing

Election of CC leaders Page 5  Appointment of CC Leaders to Managing Committee in accordance with OpenPEPPOL Statutes  Term of 2 years  Written procedure for candidacy/elections to be executed in February 2015 with support from the OpenPEPPOL Operating Office  Status TICC  Current Leader: Sven Rasmussen (DIGST)  Available for the next term  Status PoACC  Current Leader: Anders Kingstedt (ESV)  ESV proposes Sören Pedersen for the next term

Transfer of SML service to DG-DIGIT Page 6 Migration of Services from BRZ to DG DIGIT New DNS Domains: OperatorSML domain nameSMK domain name BRZ (old)sml.peppolcentral.orgsmk.peppolcentral.org DG DIGIT (new)edelivery.tech.ec.europa.euacc.edelivery.tech.ec.europa.eu Process Agreements, SLA and test – Ongoing Notification and information initiated Software Update (Ex. CIPA ver ) Updated schedule for transfer: April, week 17 (tbc) Strategy Transfer of PEPPOL e-Delivery to joint CEF e-Delivery Governance and Operations Sharing e-Delivery deployment in multiple domains Benefits from CEF funding and resources Securing support for OpenPEPPOL stakeholder requirements including use of AS2, PKI etc.

TIA Revision Project Page 7 Revision of PEPPOL TIA Agreed in Bruxelles GA 2014 Objective to resolve issues identified such as: Legal concerns related to liability Specification of penalties Revision and operationalization of “Mandatory BIS requirement” Distinction between e-Delivery (Network) and Payload (Domain) governance Formalization of validation requirement Improved Service Level Requirements Update of Annexes Project established and progressing work Ties into Validation & QA-project Revised TIA for review Q1 2015

Validation & Quality Assurance - MLR Page 8 Overview - Status -Overall – the Validation & QA has been slowed down by the MLR issue -Release management of Validation Artifact (VA) outstanding issue -Versioning policy for VA and PEPPOL BIS still not implemented

Scope – validation / verification and quality assurance AP Content Quality Handling reference information * Ensuring Well formedness (XML) Valid XML Scheme (UBL XSD) Business rules (Schematron / XSLT – PEPPOL BIS) Validation & Notification Notification & receipts -Technical -Message (payload) -Business * Message Level Response (MLR) Rules for handling / rejecting / accepting messages * - currently out of scope for OpenPEPPOL / PEPPOL General considerations Relation to TIA Policies and general rules Publication & management Tool support Responsibilities -End to end -AP to AP Ensuring technical / infrastructure stability Storing / logging / audit trail …

Message Level Response Three issues in particular have been discussed: 1.Addressing issue 2.Policy for mandating negative MLRs 3.Use of positive MLR

MLR - Addressing issue Problem statement: Endpoint for MLR can only be registered in one AP. If a participant is using more than one AP for sending messages (such as invoices and orders) then they have to choose one AP for receiving MLRs. Solution 1: Unique MLR Document ID for each BIS/Document-type Requires pre-approval of Document Ids Can be managed for PEPPOL BIS but hardly for all other document type Solution 2: Use SMP ProcessID to register different endpoints depending on process Might not solve the issue to 100% (restrictions: will not work if using a single profile/BIS consists of several messages and where different APs are used for different messages – not very likely however) Does not require any pre-approved Document Ids and also works for non-BIS

MLR – Policy for negative MLR’s Proposed Policy for mandating negative MLR’s The suggestion is to mandate that any sender (participant) of A PEPPOL BIS MUST publish the capability for receiving MLRs. Consequences: All participants therefore need to be registered in SML/SMP All APs need to have the capability to receive (and process) negative MLRs A receiver MAY send a negative MLR if validation errors occur

Suggestion for Positive MLR: A positive MLRs MUST only be send when REQUESTED by the sender An indicator in SBDH is used to request a positive MLR A receiver of a business document MUST send a MLR (positive or negative) if requested MLR – Use of positive MLR

Handling acknowledgements (draft) The above flow is illustrative; the actual flow of events might not be executed in the order presented. In scope Out of scope

Not a perfect mapping, but could work

Validation & QA Policy - Current status Introduction Mission Statement Scope/applicability Goals and non-goals Terminology Layout of the document Roles and Responsibilities Legal requirements Enforcement Quality Assurance Artefact Lifecycle management Change management Release management Release schedule Release versioning Structure of artefacts Validation process Validation business processes overview Sender side validation process Receiver side validation process Validation process error codes Use of the MLR How to validate a document Identify validation artefact Inform sender of validation result Annex 1: List of Validation Artefacts Annex 2: Concepts and definitions Annex 3: Further tasks

Time table and next steps Next steps 1.Policy document for the MLR to be created and circulated for review and approval 2.Comment resolution 3.When/if necessary: technical development and update of the MLR BIS and SBDH spec 4.Migration to new MLR policy Tentative Time Table Page 17 Policy & BIS development – by Q Review and comment resolution Acceptance Migration Voluntary use Q2 – Q Mandatory use Q1 2016

PEPPOL is owned by OpenPEPPOL AISBL Join the OpenPEPPOL community! For more information: Web addresswww.peppol.euwww.peppol.eu