search

GSMA-CPAS / BWRP-UI

Apache License 2.0
1 stars 0 forks source link

MVP review version 0.5.3 #78

Closed fhomberg closed 3 years ago

fhomberg commented 3 years ago

Contract ID: 88a8687f72875859fb834ffa57ceab41f957890b0382345b9e9dacfbc0b464fa

Simple contract with linear rates for MoC local, back home & international; flat rate "0" for MTC and threshold model with 2 thresholds & linear rates for GPRS.

Observations:

Problems:

20210420 FH Test V2 (2).zip

tomSkrzekOvoo commented 3 years ago

The problem was with contract JSON. There was no TADIG codes in discountModels.serviceGroups section. Issue fixed. It works now 20210426 FH Test V4.zip

fhomberg commented 3 years ago

Thank you @tomSkrzekOvoo I confirm that it works now! The only thing is:

Deal commitment: 7.000.000€ Total discounted charges: 6.198.969€

The delta of -801.031€ should either be distributed linearly amongst the different services - or - you would take the deal commitment into account for the settlement report rather than the total discounted charges

ldudzinski01 commented 3 years ago

Hi Federico, we'll check this. I will keep you informed. Thanks.

fhomberg commented 3 years ago

Generated a new dataset, much larger, much more TADIG codes. No error messages, usage reports on both sides look good, HOWEVER:

What I saw: "min" is spelled with small letters in the discrepancy report. But in the dataset & the contract, it spelled "Min". @ldudzinski01 Could this be the issue??

20210427 - 2020 TEF Dataset DT V0.zip

ldudzinski01 commented 3 years ago

Hi Federico,

Yes, for now we support "SMS", "MB" and "min". We changed "Min" to "min" in your dataset and it works i.e. we don't receive zero usages.

If it is important we can turn this issue into requirement. As you wish.

fhomberg commented 3 years ago

Settlement calculation not correct: Volumes are good - but revenues/cost/net positions are not correct. Small differences:

image

ldudzinski01 commented 3 years ago

"MOC Satellite" is missing completely" I checked this and in fact I forgot to support this kind of traffic. Sorry about that. Maybe it is also the reason for wrong calculations.

Pad-135 commented 3 years ago

Hi Federico, I had the same issue (shared in the issue). This is in my opinion due to round up issues. The computation surely makes the PXQ for each month, and then performing the sum at the end or any intermediate steps. (To be confirmed)

It highlights the benefits of having a common (robust) calculator agreed by all members.

Pad-135 commented 3 years ago

Oups, MOC Satellites was also in my agreement.

ldudzinski01 commented 3 years ago

Hi Guys,

Pascal, we left a comment in https://github.com/GSMA-CPAS/BWRP-UI/issues/75 - we were able to get expected results.

Federico, in case of your dataset we get correct usages but still we don't get expected calculations. The problem might be related to calculation engine or/and discrepancy service that's way we need to check settlements coming from calculation engine service. We will keep you informed.

sudo-tilakvardhan commented 3 years ago

The current calculation engine is built on the rule that if a condition is not met (could be contract revenue commitment or deal revenue commitment) there is no deal and the calculation engine returns no dealValues.

So essentially the calculator is just a discount calculator. It was designed assuming that the caller of this API would just use the commitment value directly if no deal value is returned from the calc engine.

andswk commented 3 years ago

@sudo-tilakvardhan is it possible to update the calculation engine in a way that it works in line as Federico has described above?

Deal commitment: 7.000.000€ Total discounted charges: 6.198.969€ The delta of -801.031€ should either be distributed linearly amongst the different services - or - you would take the deal commitment into account for the settlement report rather than the total discounted charges

sudo-tilakvardhan commented 3 years ago

@andswk - For that to happen, I have some queries as it has a few unknowns.

For ex. In the cases where commitment are not met, I can think of two options -

  1. We distribute the delta equally as Fedrico asked, then

    • Should we add delta amount in the field "dealValue" of each service? OR
    • Should we add a new field in each usage like "shortFromCommitment". UI would need to add this to dealValue then. But it would give a clear picture.

  2. We do not return deal with service wise dealValue from the calculator, instead we just return a response with a structure having deal commitment value, as there might not be any reason to show discounted charges since they become irrelevant.

fhomberg commented 3 years ago

My opinion: 1b in the proposal from @sudo-tilakvardhan above: Calculate the value "ShortofCommitment" and add this to the deal value, deal value being the calculated discounted charges of a party. In addition, distribute the "ShortofCommitment" value over the discounted charges by service (pre commitment). You could also call the discounted charges: Pre commitment charges or post commitment charges. Then it should be indeed clear. Any other views?

One more thing: It would not be a "usage" field but a monetary value ;-)

eliraklosi commented 3 years ago

I would also go with 1b and I like Federico's idea of denoting the charges as Pre-commitment and Post-commitment, so it's clear to the user.

Pad-135 commented 3 years ago

I would also go with 1b and I like Federico's idea of denoting the charges as Pre-commitment and Post-commitment, so it's clear to the user.

Fully aligned.

sudo-tilakvardhan commented 3 years ago

Added changes to calculator engine under branch - shortofcommitment-fix. This will require regression testing with all rating plans before merging into master branch.

ldudzinski01 commented 3 years ago

Done