MLA WG Proposal Review (Aug 2023)
This is a recording of the MLA (now MLS) WG Proposal Review from Fri 25 August 2023
Chat Messages
00:03:07.946,00:03:10.946
Philip Helger: MLS is cool, because "S" comes after "R" in the alphabet, so its a logical successor ;-) Similar to SMK and SML :D
00:04:11.908,00:04:14.908
Sebastian Boklund: :D
00:11:21.165,00:11:24.165
Martin Forsberg: Why not include the suffix possibility from start?
00:11:48.626,00:11:51.626
Markus G: When MLS becomes mandatory, is there really any need to for registering an MLS in the SMP?
00:11:51.203,00:11:54.203
Philip Helger: @Martin this is a discussion for oo and not here.
00:12:33.172,00:12:36.172
Philip Helger: @Markus: Registration will be needed - so that MLS is a regular transmission.
00:13:56.117,00:13:59.117
Markus G: @Philip will it still be open for discussion?
00:14:38.835,00:14:41.835
Philip Helger: @Markus G: Don't think so. SMP registration is even needed for Reporting. So there is no good reason why this shouldn't be the case for MLS.
00:14:39.835,00:14:42.835
Sander Fieten (Chasquis): I believe that the timing of the suffix should be decided by members, not oo
00:14:40.456,00:14:43.456
manjeet yadav: If that is the case then rejected can be changed to Undelivered
00:14:55.411,00:14:58.411
manjeet yadav: or something similar
00:15:04.181,00:15:07.181
manjeet yadav: Rejected gives a completed different message
00:15:11.303,00:15:14.303
Philip Helger: @Sander: it depends on the specific semantics of the Suffix :)
00:15:26.699,00:15:29.699
Martin Forsberg: The business reasons seems to be something that only the business can cause. So who is rejecting?
00:16:05.466,00:16:08.466
Jelte: registration in an smp is necessary because there is no information about the sending access point's URL in the current transport
00:17:30.742,00:17:33.742
Markus G: @Philip I think this is a totally different case. If it is mandatory and always required to send, it is redundant and becomes less of a complexity (and more robust) since you simply send the response and if C2 rejects it with "not supported messag" it is a violation of the Peppol agreement.
00:17:33.878,00:17:36.878
Martin Forsberg: Will there be an obligation on C2 to feed the status back to C1?
00:18:35.153,00:18:38.153
Philip Helger: @Markus: the receiver of the MLS will be C2, so C2 needs a registration. The old MLR is targeted towards C1. To make sure that data is correct, an SMP registration is needed.
00:18:39.451,00:18:42.451
Martin Forsberg: What about the business reason rejections?
00:18:54.633,00:18:57.633
Sander Fieten (Chasquis): For the last causes, I agree with Martin that it is more a business reason rejection that should have a business response
00:19:03.533,00:19:06.533
manjeet yadav: Acting on behalf of C4 for rejecting due to certain reasons should be part of Invoice responses still
00:19:07.006,00:19:10.006
manjeet yadav: in my opinion
00:20:04.568,00:20:07.568
Jelte: i would like to limit 'business reason rejection' to the cases where a business response can't be sent
00:21:30.666,00:21:33.666
Martin Forsberg: I think you should update the slide accordingly. It now looks like a business reason if an order referendum is missing
00:21:44.485,00:21:47.485
Risto Collanus: Ultimately it remains to be seen in court system if C3 on behalf of C4 can reject, incoming invoice based on Business Rule violation.
00:21:54.634,00:21:57.634
Simon Foster: @martin will do. The BIS itself has a clearer explanation
00:22:32.450,00:22:35.450
manjeet yadav: IMHO, it doesn't make sense for C2 to know something is rejected by C3 without a reason being communicated, it doesn't solve the problem of i don't want to pick up the phone! It adds extra communication requirements
00:22:52.670,00:22:55.670
Arne Johan Larsen: Agree with Wim
00:23:03.003,00:23:06.003
Sander Fieten (Chasquis): But isn't it a bad idea to mix these purposes? If you want to have business responses, make the business response mandatory
00:24:18.628,00:24:21.628
Sander Fieten (Chasquis): It also looks that these are additional rules beyond the ones in the Peppol spec. That to me looks a problem between C1 and C4
00:24:43.829,00:24:46.829
Hans Berg: I have to admit that I have not come across C1s or C4s (or even C2/C3) that has had the issues we are now trying to resolve. I am also concerned about the mix of business level /non-business level context of these messages since this may increase complexity for involved parties. Happy to discuss this further.
00:24:49.065,00:24:52.065
Sander Fieten (Chasquis): And like others said, if you don't get additional details, you will still need to pick up the phone.
00:25:19.706,00:25:22.706
Sander Fieten (Chasquis): I agree with Hans, is this a real problem?
00:26:08.509,00:26:11.509
Arne Johan Larsen: Yes, this is a real problem (responds as as a business user with a high volume over Pepppol)
00:27:46.535,00:27:49.535
Sander Fieten (Chasquis): But there already is a solution by the business response. If this is a problem in exchanges between certain C1s an C4s they should agree to implement the BLS
00:28:08.201,00:28:11.201
Katharina Koch: I think in the business process it is different, e.g. if the order reference is missing, this can be checked independently of the recipient by C3 and thus also rejected if the process ID expects an order response. If the order reference is not correct, then in my view it is a case for the order response.
00:30:35.025,00:30:38.025
Martin Forsberg: But if there is no obligation from C2 to feed the status/rejection to C1, the I think this will only cause uncertainty
00:30:44.154,00:30:47.154
manjeet yadav: I agree with Sander here!
00:31:29.556,00:31:32.556
manjeet yadav: Agree with Hans comment above!
00:32:09.240,00:32:12.240
manjeet yadav: +1 Martin!
00:32:11.348,00:32:14.348
Hans Berg: do we have any hard data (statistics) for the number of failed transactions due causes we're trying to resolve by introducing this new message?
00:32:57.684,00:33:00.684
Sander Fieten (Chasquis): +1 Hans
00:33:07.347,00:33:10.347
manjeet yadav: +1 Hans!
00:34:05.046,00:34:08.046
Jelte: i know that in a specific country document format they want to mandate the email address of the sender, so that they can send error emails due to the lack of response message support (both mlr and ir)
00:34:11.486,00:34:14.486
Hans Berg: it is cruicial that we make decisions based on facts rather on hearsay.
00:35:27.070,00:35:30.070
manjeet yadav: @Jelte that is covered with a separate onboarding and mandate in Belgium!
00:36:25.494,00:36:28.494
manjeet yadav: I think we need to bring in chain of trust here which is part of Peppol governance
00:36:51.757,00:36:54.757
manjeet yadav: There is a chain of trust between C3 and C4, the same should be used for confirming the delivery
00:36:59.824,00:37:02.824
Sander Fieten (Chasquis): +1 Hans
00:37:09.819,00:37:12.819
manjeet yadav: Irrespective of how many parties are in between
00:37:56.915,00:37:59.915
Markus G: if "delivered WITHOUT confirmation" is sent, can "delivered WITH confirmaton" be sent later, even 2-3 days later? Would it be useful?
00:38:09.186,00:38:12.186
Ahti Allikas: Just FYI from OpusCapita perspective I can say average error rate of incoming messages has been around 0,07%. It has its peaks mainly with 2 triggers - peppol release and new service providers joining.
Main issues: attachment, schematron rules.
00:39:29.575,00:39:32.575
Hans Berg: Thanks Ahti! :)
00:42:14.294,00:42:17.294
Jelte: should we perhaps not say 'business' reasons but make the reason 'could not deliver, and could not send business response' with a free-form failure message?
00:42:26.092,00:42:29.092
manjeet yadav: Thanks Ahti! that's exactly my point with respect to rejecting due to Schematron errors, in my experience too, the issues happen generally with new Peppol releases, currently the assumption is that C2 makes a mistake by using older version of schematron too late or new schematron too early causing these messages however same can be done by C3, it is disputed non-comformace case which should be dealt outside automatic rejections! Automation here cas cause more issues than fixing!
00:44:28.280,00:44:31.280
Philip Helger: OO thinks that Scenario 1 is not the necessary step forward that is needed. Scenario 2 is seen a more feasible aproach to fulfil the basic requirements
00:47:19.354,00:47:22.354
Ahti Allikas: Manjeet - here I dare to disagree with you. I am fully for the automation of the feedback. Today it adds unnecessary workload to C3 to pickup the phone or send an email despite of the fact that C3 is not quilty at all.
00:47:42.417,00:47:45.417
Jelte: one thing to keep in mind in these scenarios is 'what happens if the MLS message fails' (and how often would that happen in each scenario)
00:48:09.371,00:48:12.371
manjeet yadav: Ahti- IMHO, the problem i foresee here is that we are not solving the problem, we are just shifting the problem from C3 to C2
00:48:17.563,00:48:20.563
Martin Forsberg: Does any of these statuses have legal implications between C4 and C1? Example, C1 sends an invoice which is rejected. But since the message is informative without obligation to pass on to C1. Can C1 charge interests/fees to C4 when the invoice isnt paid? Or is C2 taking a risk?
00:48:26.802,00:48:29.802
manjeet yadav: with an overhead on nboth C2 and C3 to support new BIS
00:48:59.615,00:49:02.615
manjeet yadav: Good question Martin!
00:50:39.263,00:50:42.263
Simon Foster: Peppol can only contract with C2 and C3. Contractual issues between APs and their customers are up to each AP to handle. Also - this is very much jurisdictional.
00:50:49.722,00:50:52.722
Katharina Koch: I confirm with Moritz
00:51:52.275,00:51:55.275
Katharina Koch: Scenario 2 is in my opionion the best solution
00:52:21.076,00:52:24.076
Arne Johan Larsen: Numbers from Equinor (C1/C4) from the last 12 months approx 2,5 % of all incoming invoices had fatal schematron validation errors (that would had been returned by C3 to C2 with a mandatory MLS). In addition we got approx ,1 % with incorrect attachments (like supposed PDF is not a proper bas64 encoded PDF) - bit this is for our business response.
00:52:21.476,00:52:24.476
Jelte: How often would we think that we'll need to pick up the phone because the message was delivered to C4 successfully but the MLS Success response to C2 failed?
00:52:57.516,00:53:00.516
Jelte: (again, this would not be an issue with universal deployment of business responses)
00:53:28.709,00:53:31.709
Ahti Allikas: I see that there is for sure no legal responsibility in it.
It is about C2 providing as much feedback as possible Nothing new compared to today's solution - if today C2 gets an email from C3 that message has been rejected then depending on the content it either fixes the message itself or if necessary, informs C1 in it
00:54:30.784,00:54:33.784
manjeet yadav: In my view as a service provider, we are creating a big overhead to SPs here without really solving the problem rather shifting the problem. We should assume that a +ve as4 ack means successful completion of obligation from C2 and C3/C4 are happy to send business responses if there are any and we should look how the non-compliance cases e.g. technically invalid docs can be reported and resolved smoothly!
00:54:53.162,00:54:56.162
Hans Berg: Thanks Arne Johan! Is there a pattern of the 2.5% inbound failed docs? Are they sent to you by the same Service Provider? Would be interesting to see a distribution...My experience is that immature service providers fail more often than immature ones. Also failures are more common a few days after new validation rules have been published.
00:55:21.642,00:55:24.642
Philip Helger: Maybe a quick poll. Would you prefer S2 or S3?
00:55:27.698,00:55:30.698
Moritz Plˆfll | Traffiqx: no
00:55:29.150,00:55:32.150
Sander Fieten (Chasquis): No
00:56:19.249,00:56:22.249
Ahti Allikas: Scenario2 with common agreement on the network on timilimit when MLS should be delivered
00:56:20.607,00:56:23.607
Katharina Koch: S2
00:56:42.354,00:56:45.354
Arne Johan Larsen: @Hans, typically immature Srvice Providers + a couple of "standard suspect" (e.g. should have been a mature SP, but very often poor qualioty)
00:56:51.578,00:56:54.578
Ahti Allikas: @Manjeet
Business response - message to exchange business information btw C1 and C4
MLS - network quality message btw C2 and C3
00:57:25.936,00:57:28.936
Hans Berg: Thanks Arne Johan. I think the network is far to kind towards service providers that aren't complying with the rules of the network.
00:58:15.594,00:58:18.594
Arne Johan Larsen: @Hans - agree
00:58:31.621,00:58:34.621
Ahti Allikas: +1 Hans, Arne
00:58:37.956,00:58:40.956
Philip Helger: Lets discuss SBDH - AS4
00:58:42.400,00:58:45.400
Sander Fieten (Chasquis): The OASIS specification that defines the AS4 property:
https://docs.oasis-open.org/bdxr/bdx-as4/v1.0/cs01/bdx-as4-v1.0-cs01.htm
00:59:09.994,00:59:12.994
Sander Fieten (Chasquis): See section 3 about response messages to C2
https://docs.oasis-open.org/bdxr/bdx-as4/v1.0/cs01/bdx-as4-v1.0-cs01.html#_Toc85107779
00:59:26.299,00:59:29.299
Philip Helger: @Sander: thanks
00:59:34.050,00:59:37.050
Simon Foster: We need feedback from Peppol Authorities on the compliance piece and the effort required. I agree 100% that we are too kind on non-compliance; but it is often a very difficult issue to resolve [eg it could be one govt agency communicating with another]
01:00:18.416,01:00:21.416
Risto Collanus: It would be delivered w/o confirmation on most cases in 99,9% of our traffic
01:01:06.580,01:01:09.580
Hans Berg: if non-compliance is never (or very rarely) acted upon by Peppol Authorities we should consider removing non compliant clauses from the SP agreements.
01:01:13.156,01:01:16.156
Philip Helger: The "delayed" message is also good for operational messages
01:01:58.027,01:02:01.027
manjeet yadav: @Simon, @Ahti, @Hans, Arne: I think we should discuss about how to resolve such non-compliance issues smoothly with usual suspects or new SPs, MLS doesn't look like a proper solution to it in my opinion!
01:02:51.495,01:02:54.495
manjeet yadav: Thanks everyone!
01:03:00.516,01:03:03.516
Katharina Koch: thanks everyone