Hello Stephen,
I'm not sure if I get the idea. I was thinking of a scenario where a Party has multiple BillingAccounts. In that situation it would be good to have like a default or fallback on the party level for certain attributes like the BillStructure and specify them for a BillingAccount only if they differ. That's why I was wondering if PartyAccount could be a solution so I could define a structure like:
Party
|- PartyAccount (with "default/fallback" BillStructure)
|- BillingAccount A (with optional "differing" BillStructure settings)
|- BillingAccount B (with optional "differing" BillStructure settings)
Not sure if that's what "PartyAccount" was intended for in the first place as I keep reading that it's more like a base class and that it might be more common to just use Billing Account as a specialization instead.
Best regards,
------------------------------
Fabian Dankof
1&1 Versatel GmbH
------------------------------
Original Message:
Sent: Aug 19, 2025 04:35
From: Stephen Harrop
Subject: TMF666 - PartyAccount usage
Hi Fabian,
I think you are "warm" - but I would probably start with a BillingAccount (another resource/sub-class under TMF666-Account), which has an optional "BillStructure", that itself has a "BillFormatRefOrValue". There is nothing much to this BillFormat (id, href, name, description), but perhaps you could extend/sub-class it to accommodate your needs?
There is also TMF678-Customer Bill, which you'd think would also have the same BillFormat - but I don't see it in v4.
------------------------------
Stephen Harrop
Principal Integration Architect
Vodafone Group
Original Message:
Sent: Aug 18, 2025 10:33
From: Fabian Dankof
Subject: TMF666 - PartyAccount usage
Hi,
is it valid to use a PartyAccount instance as sort of a "default configuration" regarding bill structure/format for a Party or is there a different usage intended?
Best regards,
------------------------------
Fabian Dankof
1&1 Versatel GmbH
------------------------------