Open APIs

Hi,

to disambiguate the semantic around "payment plan", I propose 2 different terms:

• Payment Plan Template
• Payment Plan Schedule

Managing Payment Plan Templates is a design time activity. it defines how the the payments will be calculated, (interest rate, number of instalment, Escalation formula, rounding rules etc). in essence, a payment plan is a payment option.

Managing Payment Plan Schedule is a run-time activity. it defines the list of payments payer must settle, each payment is an amount and a date. Further activities are involved when payment is collected, unpaid etc.

To answer your question: I don't know  any TMF guide about Payment Plan Template, only for Payment Plan Schedule.

Here are some options to consider:

1. manage them outside the catalogue in a dedicated application. TMF Catalogue has no support for Settlement option, payment method etc.
2. you could compromise with policyRef (with polymorphism) in the catalogue, under the relevant product offer
3. you could also compromise with ProductTerm, but the datamodel is weak, you would have to extend the API or maybe use the @schemalocation to "define additional attributes and relationships."
4. Another approach, if you're open minded, is to consider the Payment plan as a product offering. Considering that this settlement option is a product offering typically sold by banks (loans etc), I think it's legitimate that CSP can do the same. Modelling it as a PO offers multiple advantages:

product relationships, bundling, eligibility rules are easy to model, and the icing on the cake is that all the calculation parameters can be very easily modelled as product characteristic, some of them may even be selectable by end-user for instance to let customer choose the number of instalments.

Furthermore, you mention "charges", "amounts" ($100 for month and an increase) in your post. That suggests a pregnant confusion between prices and payments.

Let's take the opportunity to remind us that a payment or an instalment is not a price. I see this confusion is very pregnant.

• A Payment Plan Template is not a productOfferingPrice
• A Payment Plan Schedule is not an array of productPrices

amounts should be computed at runtime based on rules not stored in the catalogue.

here is an basic example of a Payment Plan Template. I added your geometric escalation rule. This is something you could store under ProductTerm

{  "planId": "PHONEONLY_10X_DP15_ZURICH",  "description": "15 % down payment at purchase, then 10 monthly instalments that rise 5 % each time; nominal annual interest 10 % only for phone sold with post-paid mobile subscription",  "downPayment": {    "rate": 0.15,                    // 15 % of product price    "dueTiming": "atPurchase",       // settled immediately (same day as sale)    "appliesTo": "principal"         // reduces the financed principal; no interest charged  },  "installmentRule": {    "count": 10,    "frequency": "monthly",    "escalation": {      "method": "geometric",      "increment": 0.05,      "base": "previous"    },    "principalBase": "netPrice * (1 - downPayment.rate)",  // financed 85 % of price    "amountAllocation": "pro-rata",       // geometric weights normalised to the financed base    "rounding": {      "mode": "halfEven",      "scale": 2    }  },  "financeTerms": {    "nominalAnnualRate": 0.10,    "compounding": "monthly",    "dayCountConvention": "ACT/365F"  },  "constraints": {    "gracePeriodAllowed": false,    "earlyRepaymentAllowed": true,    "penaltyRate": 0.02  },  "engineHints": {    "weightFormula": "w(n) = (1 + increment)^(n-1)",    "normaliseWeights": true  },  "schemaVersion": "1.0"}

💡Payment plans are mentioned in customer/party API and the payment API. Those are not for Payment Plan Template, but maybe they give some insights on how the templates are managed. there could be more to search in TMF confluence website.

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------

Hello Matthieu, All, 

Thanks for your reply.

Thanks for bringing in clarity as to the capabilities that should be/NOT be managed in the product catalog, agree with the installment payment schedule being not managed in the product catalog. We can also infer that penalties for termination of the above scenario be also only "defined" in the catalog with the actual charging happening in the customer bill API/component. The product order could only reflect the terminate order, with the appropriate termination definition?

Would appreciate to have your opinions on this?

Regards, 

Hi,

to disambiguate the semantic around "payment plan", I propose 2 different terms:

• Payment Plan Template
• Payment Plan Schedule

Managing Payment Plan Templates is a design time activity. it defines how the the payments will be calculated, (interest rate, number of instalment, Escalation formula, rounding rules etc). in essence, a payment plan is a payment option.

Managing Payment Plan Schedule is a run-time activity. it defines the list of payments payer must settle, each payment is an amount and a date. Further activities are involved when payment is collected, unpaid etc.

To answer your question: I don't know  any TMF guide about Payment Plan Template, only for Payment Plan Schedule.

Here are some options to consider:

1. manage them outside the catalogue in a dedicated application. TMF Catalogue has no support for Settlement option, payment method etc.
2. you could compromise with policyRef (with polymorphism) in the catalogue, under the relevant product offer
3. you could also compromise with ProductTerm, but the datamodel is weak, you would have to extend the API or maybe use the @schemalocation to "define additional attributes and relationships."
4. Another approach, if you're open minded, is to consider the Payment plan as a product offering. Considering that this settlement option is a product offering typically sold by banks (loans etc), I think it's legitimate that CSP can do the same. Modelling it as a PO offers multiple advantages:

product relationships, bundling, eligibility rules are easy to model, and the icing on the cake is that all the calculation parameters can be very easily modelled as product characteristic, some of them may even be selectable by end-user for instance to let customer choose the number of instalments.

Furthermore, you mention "charges", "amounts" ($100 for month and an increase) in your post. That suggests a pregnant confusion between prices and payments.

Let's take the opportunity to remind us that a payment or an instalment is not a price. I see this confusion is very pregnant.

• A Payment Plan Template is not a productOfferingPrice
• A Payment Plan Schedule is not an array of productPrices

amounts should be computed at runtime based on rules not stored in the catalogue.

here is an basic example of a Payment Plan Template. I added your geometric escalation rule. This is something you could store under ProductTerm

{  "planId": "PHONEONLY_10X_DP15_ZURICH",  "description": "15 % down payment at purchase, then 10 monthly instalments that rise 5 % each time; nominal annual interest 10 % only for phone sold with post-paid mobile subscription",  "downPayment": {    "rate": 0.15,                    // 15 % of product price    "dueTiming": "atPurchase",       // settled immediately (same day as sale)    "appliesTo": "principal"         // reduces the financed principal; no interest charged  },  "installmentRule": {    "count": 10,    "frequency": "monthly",    "escalation": {      "method": "geometric",      "increment": 0.05,      "base": "previous"    },    "principalBase": "netPrice * (1 - downPayment.rate)",  // financed 85 % of price    "amountAllocation": "pro-rata",       // geometric weights normalised to the financed base    "rounding": {      "mode": "halfEven",      "scale": 2    }  },  "financeTerms": {    "nominalAnnualRate": 0.10,    "compounding": "monthly",    "dayCountConvention": "ACT/365F"  },  "constraints": {    "gracePeriodAllowed": false,    "earlyRepaymentAllowed": true,    "penaltyRate": 0.02  },  "engineHints": {    "weightFormula": "w(n) = (1 + increment)^(n-1)",    "normaliseWeights": true  },  "schemaVersion": "1.0"}

💡Payment plans are mentioned in customer/party API and the payment API. Those are not for Payment Plan Template, but maybe they give some insights on how the templates are managed. there could be more to search in TMF confluence website.

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Hello Matthieu, All, 

Thanks for your reply.

Thanks for bringing in clarity as to the capabilities that should be/NOT be managed in the product catalog, agree with the installment payment schedule being not managed in the product catalog. We can also infer that penalties for termination of the above scenario be also only "defined" in the catalog with the actual charging happening in the customer bill API/component. The product order could only reflect the terminate order, with the appropriate termination definition?

Would appreciate to have your opinions on this?

Regards, 

Hi,

to disambiguate the semantic around "payment plan", I propose 2 different terms:

• Payment Plan Template
• Payment Plan Schedule

Managing Payment Plan Templates is a design time activity. it defines how the the payments will be calculated, (interest rate, number of instalment, Escalation formula, rounding rules etc). in essence, a payment plan is a payment option.

Managing Payment Plan Schedule is a run-time activity. it defines the list of payments payer must settle, each payment is an amount and a date. Further activities are involved when payment is collected, unpaid etc.

To answer your question: I don't know  any TMF guide about Payment Plan Template, only for Payment Plan Schedule.

Here are some options to consider:

1. manage them outside the catalogue in a dedicated application. TMF Catalogue has no support for Settlement option, payment method etc.
2. you could compromise with policyRef (with polymorphism) in the catalogue, under the relevant product offer
3. you could also compromise with ProductTerm, but the datamodel is weak, you would have to extend the API or maybe use the @schemalocation to "define additional attributes and relationships."
4. Another approach, if you're open minded, is to consider the Payment plan as a product offering. Considering that this settlement option is a product offering typically sold by banks (loans etc), I think it's legitimate that CSP can do the same. Modelling it as a PO offers multiple advantages:

product relationships, bundling, eligibility rules are easy to model, and the icing on the cake is that all the calculation parameters can be very easily modelled as product characteristic, some of them may even be selectable by end-user for instance to let customer choose the number of instalments.

Furthermore, you mention "charges", "amounts" ($100 for month and an increase) in your post. That suggests a pregnant confusion between prices and payments.

Let's take the opportunity to remind us that a payment or an instalment is not a price. I see this confusion is very pregnant.

• A Payment Plan Template is not a productOfferingPrice
• A Payment Plan Schedule is not an array of productPrices

amounts should be computed at runtime based on rules not stored in the catalogue.

here is an basic example of a Payment Plan Template. I added your geometric escalation rule. This is something you could store under ProductTerm

{  "planId": "PHONEONLY_10X_DP15_ZURICH",  "description": "15 % down payment at purchase, then 10 monthly instalments that rise 5 % each time; nominal annual interest 10 % only for phone sold with post-paid mobile subscription",  "downPayment": {    "rate": 0.15,                    // 15 % of product price    "dueTiming": "atPurchase",       // settled immediately (same day as sale)    "appliesTo": "principal"         // reduces the financed principal; no interest charged  },  "installmentRule": {    "count": 10,    "frequency": "monthly",    "escalation": {      "method": "geometric",      "increment": 0.05,      "base": "previous"    },    "principalBase": "netPrice * (1 - downPayment.rate)",  // financed 85 % of price    "amountAllocation": "pro-rata",       // geometric weights normalised to the financed base    "rounding": {      "mode": "halfEven",      "scale": 2    }  },  "financeTerms": {    "nominalAnnualRate": 0.10,    "compounding": "monthly",    "dayCountConvention": "ACT/365F"  },  "constraints": {    "gracePeriodAllowed": false,    "earlyRepaymentAllowed": true,    "penaltyRate": 0.02  },  "engineHints": {    "weightFormula": "w(n) = (1 + increment)^(n-1)",    "normaliseWeights": true  },  "schemaVersion": "1.0"}

💡Payment plans are mentioned in customer/party API and the payment API. Those are not for Payment Plan Template, but maybe they give some insights on how the templates are managed. there could be more to search in TMF confluence website.

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Hi,

to disambiguate the semantic around "payment plan", I propose 2 different terms:

• Payment Plan Template
• Payment Plan Schedule

Managing Payment Plan Templates is a design time activity. it defines how the the payments will be calculated, (interest rate, number of instalment, Escalation formula, rounding rules etc). in essence, a payment plan is a payment option.

Managing Payment Plan Schedule is a run-time activity. it defines the list of payments payer must settle, each payment is an amount and a date. Further activities are involved when payment is collected, unpaid etc.

To answer your question: I don't know  any TMF guide about Payment Plan Template, only for Payment Plan Schedule.

Here are some options to consider:

1. manage them outside the catalogue in a dedicated application. TMF Catalogue has no support for Settlement option, payment method etc.
2. you could compromise with policyRef (with polymorphism) in the catalogue, under the relevant product offer
3. you could also compromise with ProductTerm, but the datamodel is weak, you would have to extend the API or maybe use the @schemalocation to "define additional attributes and relationships."
4. Another approach, if you're open minded, is to consider the Payment plan as a product offering. Considering that this settlement option is a product offering typically sold by banks (loans etc), I think it's legitimate that CSP can do the same. Modelling it as a PO offers multiple advantages:

product relationships, bundling, eligibility rules are easy to model, and the icing on the cake is that all the calculation parameters can be very easily modelled as product characteristic, some of them may even be selectable by end-user for instance to let customer choose the number of instalments.

Furthermore, you mention "charges", "amounts" ($100 for month and an increase) in your post. That suggests a pregnant confusion between prices and payments.

Let's take the opportunity to remind us that a payment or an instalment is not a price. I see this confusion is very pregnant.

• A Payment Plan Template is not a productOfferingPrice
• A Payment Plan Schedule is not an array of productPrices

amounts should be computed at runtime based on rules not stored in the catalogue.

here is an basic example of a Payment Plan Template. I added your geometric escalation rule. This is something you could store under ProductTerm

{  "planId": "PHONEONLY_10X_DP15_ZURICH",  "description": "15 % down payment at purchase, then 10 monthly instalments that rise 5 % each time; nominal annual interest 10 % only for phone sold with post-paid mobile subscription",  "downPayment": {    "rate": 0.15,                    // 15 % of product price    "dueTiming": "atPurchase",       // settled immediately (same day as sale)    "appliesTo": "principal"         // reduces the financed principal; no interest charged  },  "installmentRule": {    "count": 10,    "frequency": "monthly",    "escalation": {      "method": "geometric",      "increment": 0.05,      "base": "previous"    },    "principalBase": "netPrice * (1 - downPayment.rate)",  // financed 85 % of price    "amountAllocation": "pro-rata",       // geometric weights normalised to the financed base    "rounding": {      "mode": "halfEven",      "scale": 2    }  },  "financeTerms": {    "nominalAnnualRate": 0.10,    "compounding": "monthly",    "dayCountConvention": "ACT/365F"  },  "constraints": {    "gracePeriodAllowed": false,    "earlyRepaymentAllowed": true,    "penaltyRate": 0.02  },  "engineHints": {    "weightFormula": "w(n) = (1 + increment)^(n-1)",    "normaliseWeights": true  },  "schemaVersion": "1.0"}

💡Payment plans are mentioned in customer/party API and the payment API. Those are not for Payment Plan Template, but maybe they give some insights on how the templates are managed. there could be more to search in TMF confluence website.

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------