Open APIs

 View Only
Expand all | Collapse all

TMF629 vs TMF666 - Should household/family relationships between subscribers be stored on Customer.relatedParty[] or BillingAccount.accountRelationship[]?

  • 1.  TMF629 vs TMF666 - Should household/family relationships between subscribers be stored on Customer.relatedParty[] or BillingAccount.accountRelationship[]?

    Posted 6 days ago
    Edited by Ajay Saini 5 days ago

    Hi, We are working on a capability for a telecom operator where Primary subscriber (John) can add othes subscribers (Smith, Adam) to his household and assign a relationship label to each - spouse, parent, child, sibling.

    The managed connections (Smith, Adam) may be prepaid, postpaid, broadband, or DTH subscribers. They do not necessarily share a billing account with John. The relationship is purely a personal/household identity label - it does not affect billing, provisioning, or commercial terms.

    The Question:
    Should this relationship be stored at:

    Option A - Customer level (TMF629)
    On the primary subscriber's Customer.relatedParty[] with role = "managedAccount" and a characteristic[relationshipType = "friend"]:

    "relatedParty": [
      {
        "id": "REL-UUID",
        "role": "managedAccount",
        "characteristic": [
          { "name": "msisdn",           "value": "xxxxxxx" },
          { "name": "relationshipType", "value": "friend" }
        ]
      }
    ]



    ------------------------------
    Ajay
    ------------------------------



  • 2.  RE: TMF629 vs TMF666 - Should household/family relationships between subscribers be stored on Customer.relatedParty[] or BillingAccount.accountRelationship[]?

    Posted 45 minutes ago

    Constraint you stated 

    1. Smith & Adam may not share a billing account with John
    2. Relationship must not affect billing
    3. Prepaid / Postpaid / Broadband / DTH mix

    Putting a "spouse / parent / child" label on an Account would overload a commercial object with identity semantics - a classic anti-pattern that leaks into billing extracts, revenue reports, and dunning logic.

    Why TMF629 (Customer) is correct ??

    TMF629 represents the party engaged in a business relationship with the operator - i.e., the person/identity view, independent of what they buy or how they pay.

    Household, family, and personal relationships are attributes of IDENTITY. They persist even if John churns a service, switches from postpaid to prepaid, or closes a billing account.

    In TMF629 we can model this via the relatedParty construct (or, more purely, delegate to TMF632 Party Management which owns PartyRelationship)

    // On John's Customer resource
    {
      "id": "cust-john-001",
      "name": "John",
      "relatedParty": [
        {
          "id": "cust-smith-044",
          "name": "Smith",
          "role": "spouse",          // household label
          "@referredType": "Customer"
        },
        {
          "id": "cust-adam-088",
          "name": "Adam",
          "role": "child",
          "@referredType": "Customer"
        }
      ]
    }



    ------------------------------
    Nitin Srivastava
    Jio Platforms Limited
    ------------------------------