I have not used the TMF764 Cost Management API but I have guided implementations where costs are really important (FTTH Build). TMF764 is still immature and I feel an integration of Cost into Work and Resource just like Price is part of Product is more appropriate.
From my experience I learned costs are linked to several sources:
- Direct costs
- tangible resources (stuff you buy)
- work or activities (people doing something)
- Indirect costs
- amortisation ( a statistical model to assign sunk costs to other entities like services)
- usage
Direct costs
Focusing on modelling direct costs this means that you need for costs a similar model to ProductPrice and ProductOfferingPrice.
I solved this by extending Resource with resourceCost and ResourceCandidate with resourceCandidateCost. I also extended Work with workCost and WorkCandidate with workCandidateCost. Each of these are array of Cost so that different costs with their costType: one-time, recurring, usage can be modelled.
Compared with TMF764 resourceCandidateCost & workCandidateCost map to projectedCost; resourceCost and workCost map to actualCost.
The duality ProductSpecification / ProductOffering is widely accepted in TM Forum. The same duality for ResourceSpecification (e.g. Smartphone) and ResourceCandidate (iPhone 16e) is however still contested. The duality WorkSpecification (dig a trench) and WorkCandidate (digging by Contractor A) isn't accepted either in TM-Forum. I found them however extremely usefull in several customer projects and found the concepts actually implemented in several vendor products.
Indirect Cost
A similar model for Usage / UsageSpecification / UsageCandidate with usageCost and usageCandidateCost (e.g. voice minutes from CSP A) could be considered and would be usefull for Interconnect Billing.
Ammortisation cost is a difficult one. It is the spreading of sunk costs over individual intangible services. The ammortisation rules are heavily dependent on duration of ammortisation and the number of expected services. Probably this is also not required in the operational models and can be left to the General Ledger experts.
I hope this contrarian view helps you in solving your issue.
------------------------------
Koen Peeters
Ciminko SA
------------------------------
Original Message:
Sent: Aug 04, 2025 17:19
From: Jiri Smekal
Subject: Unit cost origin for TMF764 Cost Management
Dear all,
the recently published TMF764 Cost Management API introduces support for managing both ProjectedCost and ActualCost associated with various entity instances in proceses like service ordering, such as:
service: "E-line connectivity service"
resource: "Fiber Optic Cable"
resourceUsage: "Electricity and Power Consumption"
workOrder: "Maintenance and support"
In the sample of the fiber optic cable, the TMF764 User Guide contains for example:
"costItemAmount": { "quantity": { "amount": 10, "units": "km" }, "amount": { "unit": "AUD", "value": 50000 }}
This suggests a unit cost of 5000 AUD / km – although in real scenarios the pricing logic may be more complex (e.g. tiered rates).
Our question is:
When constructing a CostItem, where should this unit cost information come from?
Should it be defined within each respective catalog (e.g. Product / Service / Resource / WorkOrder / ...)?
Or would a dedicated Cost Catalog be more appropriate, defining reusable cost item specifications linked to the relevant entity specifications?
We'd appreciate any insights on this topic.
Thank you in advance for sharing your experience or views on this direction within the TM Forum.
------------------------------
Kind regards
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------