Closed ldudzinski01 closed 3 years ago
csarthou
commented
3 years ago I almost agree with this part: "This exchange is a basis ( a possibility, I would say ) for the usage discrepancies" but not with this part: "and calcluations for the settlements"
The calculation for the settlement do not need an exchange of usage.
csarthou
commented
3 years ago The usage exchange is only used to share this object ( only sent for information ), but do not change the settlement process.
It was the only condition that we imposed on the incorporation of this FEATURE into the MVP, and you are trying to change this.
We can't change MVP content every day, a lot of work is already done in common-adapter.
ldudzinski01
commented
3 years ago Okay, I think I haven't provided enough information and that's way, probably, we have a little misunderstanding. So let me clarify.
First, what should be done in MVP1 scope in the context of the settlements: Definitely, each ORG needs to have two settlements: for own and partner calculations. This is necessary to provide settlement discrepancies feature - https://github.com/GSMA-CPAS/BWRP-UI/issues/58. And it turned out that we can, and in fact we must, generate these settlements only locally using own usage and partner usage, but the partner usage must be sent by the partner beforehand. This is the reason why I stated that the usages exchange is a basis for not only usage discrepancies but for settlements calculations as well.
Any changes to common-adapter?
At first glance, from your perspective, it doesn't change a lot. Still you need to provide the usages exchange functionality(as agreed) and still we are going to use existing comA's REST end-point to generate the settlement - now it will be invoked from the UI. One difference is that we(i.e. settlement UI) must invoke this end-point twice, first time for the own usage and second time for the partner(exchanged) usage. Of course, the generated settlements are still to be preserved in comA database which holds the master copy(as agreed and was also stated in Mom mail I sent you). OVOO_Scope_BWR_Navigation.pptx
What can be considered on a purely technical level?
In my opinion, if we have time, we could consider to generate settlements using only one REST request, instead of invoking the same REST end-point twice. But it's not crucial, I would say.
Please refer to the slides attached, you can find there the full UI design which encapsules the entire process I descrived above, e.g. we have included UI buttons to invoke existing comA REST end-points.
Regards
csarthou
commented
3 years ago A large part of the process that you propose is based on an assumption that seems very risky over time: outgoing and incoming usages of each partners are shared. It is not an obvious thing for me, and all the functional should not be based on it.
And one other point very important for me, if ORG1 has already sent all his usage to ORG2, before ORG2 has created his own usage locally, ORG2 can create his usage with the most intersting values for him: For his cash out, the minimum of the ORG1 values and his values, and will never share what he should have paid more For his cash in, the maximum of the ORG1 values and his values, and will never share what the other ORG should have paid less And then send this usage to ORG1... This process, in its design, accepts data makeup.
and in fact we must, generate these settlements only locally using own usage and partner usage
and this is exactly our point of disagreement If the partner usage is shared ( It's not an obligation! ), no settlement will be generated on it
The partner settlement will be received after a calculation on partner side. And the settlement receiver will compare this received settlement with his generated settlement using own usage data. This allows to keep a confidentiality on the usage data, which can be exchanged in a second time in case of problems with the shared settlements.
ldudzinski01
commented
3 years ago Christophe, I understand your point, and you're right - data makeup during usages exchange process can take place. Thanks for this input, its very interesting because it's completely new to me and good to keep it in mind. But, on the other hand, the same "hack" can be applied to the settlements. Let me explain why.
If the partner usage is shared ( It's not an obligation! ), no settlement will be generated on it
The partner settlement will be received after a calculation on partner side. And the settlement receiver will compare this received settlement with his generated settlement using own usage data.
I think we cannot ensure that the actual settlements exchange can be perfomed then, and only then, when settlements are generated on both sides, in other words, having settlements generated on both sides is not a necessary condition to mutually exchange the settlements using UI and comA. There is no business logic for that. Therefore, it may happen that one side hasn't generated its own settlement yet but received the partner settlement. In such case this side has all the "tools" for data makeup and calculation makeup. Maybe it is a little bit more complicated but it seems to be possible. Correct me if I'm wrong.
Last, but not least, recently we have had several discussions with the commercial team to precisely define business requirements that we need to follow. The attached slides reflects conclusions from those meetings. I understand that you have your perspective and arguments but I'm not sure if it is a good place to analyse them further. Maybe it should be communicated to the commercial team...
Don't get me wrong, but for now OVOO team has to stick to some requirements and those coming from commercial team are effective/obligatory ones, at least for us.
csarthou
commented
3 years ago Therefore, it may happen that one side hasn't generated its own settlement yet but received the partner settlement. In such case this side has all the "tools" for data makeup and calculation makeup. Maybe it is a little bit more complicated but it seems to be possible. Correct me if I'm wrong.
I totally agree with that. It's why, at the start, we only wanted to send in the settlement one filtered usage without useful data for the partner for the calculation of his settlement.
But this filtered usage would not allowed an usage comparison for the MVP, and we imagined that this filtering would be done later.
zkong-gsma
commented
3 years ago hi, I think there is a few points we need some clarification about.
Definitely, each ORG needs to have two settlements: for own and partner calculations. This is necessary to provide settlement discrepancies feature - GSMA-CPAS/BWRP-UI#58.
We agree on this, and the way we see it, on each "Org", you should see a "SENT" and "RECEIVED" settlement.
At first glance, from your perspective, it doesn't change a lot. Still you need to provide the usages exchange functionality(as agreed) and still we are going to use existing comA's REST end-point to generate the settlement - now it will be invoked from the UI. One difference is that we(i.e. settlement UI) must invoke this end-point twice, first time for the own usage and second time for the partner(exchanged) usage. Of course, the generated settlements are still to be preserved in comA database which holds the master copy(as agreed and was also stated in Mom mail I sent you). OVOO_Scope_BWR_Navigation.pptx
Exchanging usage was purely done upon request by you. not the requirement as we do not agree that we will need to exchange usage specifically. As they can be sent together with monthly invoices as well.
I do not understand the reason for below.
first, you asked for "Usage exchange". (lets assume the capability has been delivered) now, you want to "call" generate "Settlement" twice. Once for "Local Own" usage, once of "remote Received" Usage. what is the logic of this? This will result to a "Locally" generated "Settlement of Remote" that will be the exact same copy of the "Settlement report" received from "Remote".
Note. we also assume and agree that in the MVP, there is no "usage" discrepancy, in a sense that the "local" usage and remote will not be exactly the same, so that there will be a "discrepancy" report to be generated but this difference will be within the allowed threshold.
So if "Contract's" discount deal model is "fixed". and the "usages" are fixed. (so is the Settlement Calculator Service) regardless of who executing it will always produce the same result.
Can you kindly explain and justify the reason to
ldudzinski01
commented
3 years ago Exchanging usage was purely done upon request by you.
For us, the commercial team is a source of business requirements, of course we definitely take into acoount other arguments. Personally, I take advantage of the arguments you're presenting and discussion that we have but, as I said, we need to stick to some requirements. And I think there is no huge gap(in technical respect - a lot is in place now) between what is proposed by the commercial team and you, please find details below why.
Note. we also assume and agree that in the MVP, there is no "usage" discrepancy, in a sense that the "local" usage and remote will not be exactly the same, so that there will be a "discrepancy" report to be generated but this difference will be within the allowed threshold.
Kong, I'm sorry, but my point of view is different - I thought we agreed that there is a usage disprepancy(T14) that could be done before actual settlements. That's way there is a need for usages exchange beforehand. When it comes to T14: https://github.com/GSMA-CPAS/BWRP-UI/issues/20 this is only for the view purpose no matter how big a discrepancy is. In addition, we have plan to add flags to indicate how big a particular usage discrepancy is.
Can you kindly explain and justify the reason to
- Receive "remote usage"
- generate a locally generated "remote settlement" using "remote-usage"
- receive a Remote generated settlement. (which will be identical to no 2)
Kong, of course, please find my answers below.
In other words, we would like to do 2(generate a locally generated "remote settlement" using "remote-usage") instead of 3.
Usages exchange shall be added to the Common-Adapter. This exchange is a basis for the usage discrepancies and calcluations for the settlements.