Participants and absents

Chair

Pedersen, Sören <soren.pedersen@esv.se> as PoACC Community Leader

Elected members (with voting right)

Maroe, Jan <jan.andre.maroe@difi.no> (Difi)

Helger, Philip <philip.helger@brz.gv.at>, BRZ Austria

Allikas, Ahti <ahti.allikas@opuscapita.com>, OpusCapita

Ciciriello, Carmen <carmen.ciciriello@celeris-group.eu>, Celeris-Group

Observers (without voting right)

~~Rapisarda Isabella <isabella.rapisarda@consip.it> as Pre-award CC Leader~~

~~Berg, Hans <hans.berg@tickstar.com> as eDelivery Community Leader~~

Previous meeting minutes

2018

Agenda

Present:
- Sören Pedersen, soren.pedersen@esv.se
- Hoddevik, André <andre.hoddevik@difi.no>
- Hans Berg, hans.berg@tickstar.com
Absent:
- Isabella Rapisarda, isabella.rapisarda@consip.it

Summary of previous meeting (4th May)
1. André and Hans continued to discuss the pros and cons of TVR and or escalation to PA.
2. Action Item (Hans+Sören): André would like to see TICC and POACC to suggest routines on how to increase the quality in the network. Who is responsibility of corner 1 and what should courner 2 do to enforce corner 1 to live up.
3. Action Item (Sören+André): Read TVR document especially page 7.
4. Action Item (Hans): Inform TICC of the process.
5. Action Item (Hans): Send background and decision document to MC (first a dialogue between André and Hans)
6. Action Item (MC): Take a decision on TVR.
AOB

Outstanding and new issues:

Meeting minutes from meeting 4^th of May:
- PURPOSE WITH MEETING:
  - André summarized the current organisational situation and how it affects the current situation
- TODAY’S SITUATION
  - Marcus added that C3 could mistakenly validate using old version of schematron.
  - André pointed out that C3 do not have any responsibility of doing validation but should only forward message.
  - Philip states that if somebody is in breach with TIA somebody needs to follow up. TVR = alarm system.
  - Ahti states cost is in C3 (receivers side). Simple way to tell sender that message is not validated.
  - Ahti states that IT systems always have bugs.
  - Georg what are the main causes of C1 creating problems.
  - Ahti states that we only have assumptions about why C1 is causing problems (sending invalid messages).
  - Assumptions why invalid messages are send:
  - Make authorities aware of their responsibility
  - Marcus states that service providers would like to solve these problems themselves before escalating to a PA. Doubt that PA can handle this responsibility. Also the costs will become an issue in the long term.
  - Carmen states that we need to increase maturity in a structured way.
  - Even if there is a clause in the TIA it is clear that there is no consensus about the AP role in the network. Some AP:s see their role only as a postman.
- IDEAS FOR PART-RESOLUTION
  - Marcus agrees that it is good to have something about contract between C1 and C2 in the TIA.
  - Ahti states that PEPPOL should not interfere with commercial agreements between C1 and C2.
  - André and Ahti agrees that PEPPOL could provide guidance.
  - E-delivery needs to be able to handle other scenarios like e.g. the ones we see in pre-award.
  - The cost for increased quality should be looked into comparing different solution comparing technical solution and PA police functions
  - Georg mentions, that the resolution could be separated in “error preventing” and “error handling”. “Error prevention” takes mostly place in C1/C2.
  - Prioritization of measures is needed, in the context of markets.
  - Georgs assumption: adopting PEPPOL increases maturity of markets.
  - Andre states, that TVR is a possible solution, after the other measures in preventing errors are executed
  - Philip states, that 10 years of PEPPOL was a long time to create preventive measures, but still errors occur and need to be handled
  - Andre thinks that the costs of establishing a TVR in the whole network would be to high. Even though Norway initiated the MLR 3-4 years ago, they matured and don’t need it anymore today.
  - Ahti wants to establish something between “prevention” and “punishment” - the “notification” aka TVR
  - Georg asks, if the “network ack” can be used to to propagate validation responses. Markus declines this - because validation is not always possible synchronously (especially on large files) and may happen in C3 or C4.
  - Markus explains that the TVR must be asynchronously.
  - Andre states that the TVR is neither technical transport level nor business level. Philip states that the validation on sender side falls into the same gap. => a definition of the level between “technical transport” and “business level” is needed
  - Andre mentions IRM (Invoice Response) to fill a gap, and may also contain validation errors. Philip claims that the costs for introducing IMR is comparable to the ones of MLR. Andre states that IMR has a business level value and TVR has not. Philip doesn’t agree. Ahti states, that IMR creates a business value for C1 and C2, TVR creates a business value for C3.
  - It is not a big effort for DIFI to inform AP:s about incorrect messages. DIFI has an efficient process for notifying AP:s with exact information needed for problem resolution.
  - It should not be the goal to threaten APs with revocation of certificates. Happened <= 5 times so far.
  - Based on Difi knowledge
  - Ahti to disagrees, that this is more cost effective. Sending emails is inefficient.
  - Andre thinks a cost-benefit-analysis is needed before putting something like TVR in place
- AOB

Information items

-

Decisions

-

Action items

-

-- EoD

Attachments

	File	Modified

No files shared here yet.

Post-Award Community (PoAC)

Cross community TVR follow up meeting