Open APIs

In our setting we differentiate several types of ProductOrders, e.g. to distinguish a change of a Product from a relocation (change of address). We call this the "Business Use Case".
In one order, several such use cases may be contained, so that it is a property of an OrderItem rather than of the Order as a whole.
Obviously, the actual processing of the modification highly depends on the kind of change.

So far, both cases would have OrderItem.action=modify, and to find out if it is the place that changes, one needs to evaluate the reference to the place; and references to other objects to identify further kinds of changes. This implicit differentiation needs to be made explicit to simplify the processing.

How could this be modelled in the TMF ProductOrder API?

• additional attribute of OrderItem?
• additional values of OrderItem.action?
• any other idea?

Thank you,

Lutz

Place where a Product currently exists is know in the Product Inventory. If the Provider system processing the order can derive what has changed based on what is in the order and what is in the Product Inventory then we would not need this additional qualifier in the order. However is we want the consumer to indicate the use-case would suggest "additional attribute of OrderItem".

In our setting we differentiate several types of ProductOrders, e.g. to distinguish a change of a Product from a relocation (change of address). We call this the "Business Use Case".
In one order, several such use cases may be contained, so that it is a property of an OrderItem rather than of the Order as a whole.
Obviously, the actual processing of the modification highly depends on the kind of change.

So far, both cases would have OrderItem.action=modify, and to find out if it is the place that changes, one needs to evaluate the reference to the place; and references to other objects to identify further kinds of changes. This implicit differentiation needs to be made explicit to simplify the processing.

How could this be modelled in the TMF ProductOrder API?

• additional attribute of OrderItem?
• additional values of OrderItem.action?
• any other idea?

Thank you,

Lutz

Hi Lutz,

I have had the same issue with some other German service providers as well as in the German wholesales standardisation working group (AKS&P). 

The approach we implemented is:

• use  productOrder.category to document the "business use case " / "Geschäftsfall"
• extend productOrderItem.action

Actually, with the combination of category and action, we barely had to add new actions. 

Hope this helps, Iwan

Place where a Product currently exists is know in the Product Inventory. If the Provider system processing the order can derive what has changed based on what is in the order and what is in the Product Inventory then we would not need this additional qualifier in the order. However is we want the consumer to indicate the use-case would suggest "additional attribute of OrderItem".

In our setting we differentiate several types of ProductOrders, e.g. to distinguish a change of a Product from a relocation (change of address). We call this the "Business Use Case".
In one order, several such use cases may be contained, so that it is a property of an OrderItem rather than of the Order as a whole.
Obviously, the actual processing of the modification highly depends on the kind of change.

So far, both cases would have OrderItem.action=modify, and to find out if it is the place that changes, one needs to evaluate the reference to the place; and references to other objects to identify further kinds of changes. This implicit differentiation needs to be made explicit to simplify the processing.

How could this be modelled in the TMF ProductOrder API?

• additional attribute of OrderItem?
• additional values of OrderItem.action?
• any other idea?

Thank you,

Lutz

Hi Iwan,

good idea, matches the definition of category "Used to categorize the order from a business perspective that can be useful for the OM system". That is exactly the intension, to be used by the OM system.

Problem: The Order does not only contain one "Geschäftsfall", but several ones, like moving and new purchase, so the "category" would be needed on Item level, but I think that is not the best idea. So the people introduced a new object "BusinessCase" which is "between" the order and the OrderItem; a better - TMF compliant - solution would probably be to use separate Orders (then your proposal can be used) which are linked by an OrderRelationship, or maybe be related to the same Agreement that then acts as an "envelope" for the orders.

Hi Lutz,

I have had the same issue with some other German service providers as well as in the German wholesales standardisation working group (AKS&P). 

The approach we implemented is:

• use  productOrder.category to document the "business use case " / "Geschäftsfall"
• extend productOrderItem.action

Actually, with the combination of category and action, we barely had to add new actions. 

Hope this helps, Iwan

Place where a Product currently exists is know in the Product Inventory. If the Provider system processing the order can derive what has changed based on what is in the order and what is in the Product Inventory then we would not need this additional qualifier in the order. However is we want the consumer to indicate the use-case would suggest "additional attribute of OrderItem".

In our setting we differentiate several types of ProductOrders, e.g. to distinguish a change of a Product from a relocation (change of address). We call this the "Business Use Case".
In one order, several such use cases may be contained, so that it is a property of an OrderItem rather than of the Order as a whole.
Obviously, the actual processing of the modification highly depends on the kind of change.

So far, both cases would have OrderItem.action=modify, and to find out if it is the place that changes, one needs to evaluate the reference to the place; and references to other objects to identify further kinds of changes. This implicit differentiation needs to be made explicit to simplify the processing.

How could this be modelled in the TMF ProductOrder API?

• additional attribute of OrderItem?
• additional values of OrderItem.action?
• any other idea?

Thank you,

Lutz

In our setting we differentiate several types of ProductOrders, e.g. to distinguish a change of a Product from a relocation (change of address). We call this the "Business Use Case".
In one order, several such use cases may be contained, so that it is a property of an OrderItem rather than of the Order as a whole.
Obviously, the actual processing of the modification highly depends on the kind of change.

So far, both cases would have OrderItem.action=modify, and to find out if it is the place that changes, one needs to evaluate the reference to the place; and references to other objects to identify further kinds of changes. This implicit differentiation needs to be made explicit to simplify the processing.

How could this be modelled in the TMF ProductOrder API?

• additional attribute of OrderItem?
• additional values of OrderItem.action?
• any other idea?

Thank you,

Lutz

When I worked at Siebel, around 25 years ago, Deutsche Telekom AG, which was using Siebel CRM as a BSS, has asked us the same question, not in the context of TMF order API but Siebel Order interface. Maybe you remember it.
the answer we gave you then was to construct your sales order with 2 root Order line items (OLI). Note: Each root could have child OLIs in case of bundle
Root OLI 1 has fields action code = move, sub-action code = out and service address Id = Id of the current place/termination point.
Root OLI 2 has fields  action code = move, sub-action code = in and  service address Id would have the Id of the new place/termination point.
exact same logic applies with mobile subscription except it's the account triumvirat that change: owner account, service account and billing account 

This was a vanilla functionality in siebel under the MACD process flow.

I don't see why this approach would not be different in 2025 with another API provider like TMF.

In our setting we differentiate several types of ProductOrders, e.g. to distinguish a change of a Product from a relocation (change of address). We call this the "Business Use Case".
In one order, several such use cases may be contained, so that it is a property of an OrderItem rather than of the Order as a whole.
Obviously, the actual processing of the modification highly depends on the kind of change.

So far, both cases would have OrderItem.action=modify, and to find out if it is the place that changes, one needs to evaluate the reference to the place; and references to other objects to identify further kinds of changes. This implicit differentiation needs to be made explicit to simplify the processing.

How could this be modelled in the TMF ProductOrder API?

• additional attribute of OrderItem?
• additional values of OrderItem.action?
• any other idea?

Thank you,

Lutz

Yes, this is still the same background; unfortunately, the action attribute of the OrderItem has fixed enum values, so that means we need to extend that enumeration to cover "move", and also introduce a further attribute sub-action, or use action "move-out" and "move-in".

So there is no other choice than to enhance the API by enum values and/or another attribute.

Would such an extension be of general use so that it should be considered for the next version of the TMF622 Product Ordering API?

When I worked at Siebel, around 25 years ago, Deutsche Telekom AG, which was using Siebel CRM as a BSS, has asked us the same question, not in the context of TMF order API but Siebel Order interface. Maybe you remember it.
the answer we gave you then was to construct your sales order with 2 root Order line items (OLI). Note: Each root could have child OLIs in case of bundle
Root OLI 1 has fields action code = move, sub-action code = out and service address Id = Id of the current place/termination point.
Root OLI 2 has fields  action code = move, sub-action code = in and  service address Id would have the Id of the new place/termination point.
exact same logic applies with mobile subscription except it's the account triumvirat that change: owner account, service account and billing account 

This was a vanilla functionality in siebel under the MACD process flow.

I don't see why this approach would not be different in 2025 with another API provider like TMF.

In our setting we differentiate several types of ProductOrders, e.g. to distinguish a change of a Product from a relocation (change of address). We call this the "Business Use Case".
In one order, several such use cases may be contained, so that it is a property of an OrderItem rather than of the Order as a whole.
Obviously, the actual processing of the modification highly depends on the kind of change.

So far, both cases would have OrderItem.action=modify, and to find out if it is the place that changes, one needs to evaluate the reference to the place; and references to other objects to identify further kinds of changes. This implicit differentiation needs to be made explicit to simplify the processing.

How could this be modelled in the TMF ProductOrder API?

• additional attribute of OrderItem?
• additional values of OrderItem.action?
• any other idea?

Thank you,

Lutz

I'm not sure what you mean by "OrderItem has fixed enum values".

if you think of the values provided by TM Forum, you know that these are only provided for illustration purposes. Every BSS vendor supporting TMF APIs has its own set of values and CSP typically introduce their own values and often work in different languages requiring even more enum values.

your question is valid, but as you have probably noticed, TMF API/etom/SID/etc project owners very rarely engage with the TMF communities. We are on our own here. I think you have to submit your suggestion it in their regular TMF API meetings. There has been a lot of great questions and recommendations shared in TMF communities that are lost because there is little communications between TMF project members and the community members.

Yes, this is still the same background; unfortunately, the action attribute of the OrderItem has fixed enum values, so that means we need to extend that enumeration to cover "move", and also introduce a further attribute sub-action, or use action "move-out" and "move-in".

So there is no other choice than to enhance the API by enum values and/or another attribute.

Would such an extension be of general use so that it should be considered for the next version of the TMF622 Product Ordering API?

When I worked at Siebel, around 25 years ago, Deutsche Telekom AG, which was using Siebel CRM as a BSS, has asked us the same question, not in the context of TMF order API but Siebel Order interface. Maybe you remember it.
the answer we gave you then was to construct your sales order with 2 root Order line items (OLI). Note: Each root could have child OLIs in case of bundle
Root OLI 1 has fields action code = move, sub-action code = out and service address Id = Id of the current place/termination point.
Root OLI 2 has fields  action code = move, sub-action code = in and  service address Id would have the Id of the new place/termination point.
exact same logic applies with mobile subscription except it's the account triumvirat that change: owner account, service account and billing account 

This was a vanilla functionality in siebel under the MACD process flow.

I don't see why this approach would not be different in 2025 with another API provider like TMF.

In our setting we differentiate several types of ProductOrders, e.g. to distinguish a change of a Product from a relocation (change of address). We call this the "Business Use Case".
In one order, several such use cases may be contained, so that it is a property of an OrderItem rather than of the Order as a whole.
Obviously, the actual processing of the modification highly depends on the kind of change.

So far, both cases would have OrderItem.action=modify, and to find out if it is the place that changes, one needs to evaluate the reference to the place; and references to other objects to identify further kinds of changes. This implicit differentiation needs to be made explicit to simplify the processing.

How could this be modelled in the TMF ProductOrder API?

• additional attribute of OrderItem?
• additional values of OrderItem.action?
• any other idea?

Thank you,

Lutz

Lutz is referring to the API schema which defines the action as an enum rather than a string.  Other fields have been defined only as a string with example values instead, e.g. 

               "action": {
                    "type": "string",
                    "description": "Action to be performed on this order item (add, modify, move, delete, noChange)",
                    "examples": [
                      "add",
                      "modify",
                      "move",
                      "delete",
                      "noChange"
                }

I'm not sure what you mean by "OrderItem has fixed enum values".

if you think of the values provided by TM Forum, you know that these are only provided for illustration purposes. Every BSS vendor supporting TMF APIs has its own set of values and CSP typically introduce their own values and often work in different languages requiring even more enum values.

your question is valid, but as you have probably noticed, TMF API/etom/SID/etc project owners very rarely engage with the TMF communities. We are on our own here. I think you have to submit your suggestion it in their regular TMF API meetings. There has been a lot of great questions and recommendations shared in TMF communities that are lost because there is little communications between TMF project members and the community members.

Yes, this is still the same background; unfortunately, the action attribute of the OrderItem has fixed enum values, so that means we need to extend that enumeration to cover "move", and also introduce a further attribute sub-action, or use action "move-out" and "move-in".

So there is no other choice than to enhance the API by enum values and/or another attribute.

Would such an extension be of general use so that it should be considered for the next version of the TMF622 Product Ordering API?

When I worked at Siebel, around 25 years ago, Deutsche Telekom AG, which was using Siebel CRM as a BSS, has asked us the same question, not in the context of TMF order API but Siebel Order interface. Maybe you remember it.
the answer we gave you then was to construct your sales order with 2 root Order line items (OLI). Note: Each root could have child OLIs in case of bundle
Root OLI 1 has fields action code = move, sub-action code = out and service address Id = Id of the current place/termination point.
Root OLI 2 has fields  action code = move, sub-action code = in and  service address Id would have the Id of the new place/termination point.
exact same logic applies with mobile subscription except it's the account triumvirat that change: owner account, service account and billing account 

This was a vanilla functionality in siebel under the MACD process flow.

I don't see why this approach would not be different in 2025 with another API provider like TMF.

In our setting we differentiate several types of ProductOrders, e.g. to distinguish a change of a Product from a relocation (change of address). We call this the "Business Use Case".
In one order, several such use cases may be contained, so that it is a property of an OrderItem rather than of the Order as a whole.
Obviously, the actual processing of the modification highly depends on the kind of change.

So far, both cases would have OrderItem.action=modify, and to find out if it is the place that changes, one needs to evaluate the reference to the place; and references to other objects to identify further kinds of changes. This implicit differentiation needs to be made explicit to simplify the processing.

How could this be modelled in the TMF ProductOrder API?

• additional attribute of OrderItem?
• additional values of OrderItem.action?
• any other idea?

Thank you,

Lutz

I understand but using string or enum is irrelevant in defining your own list of action values. enum just requires updating the API schema.

Can you explain why it is "unfortunate" to have enum instead of string?

we didn't face any "challenge" in translating/changing any "enum" list of values in our TMF APIs.

Lutz is referring to the API schema which defines the action as an enum rather than a string.  Other fields have been defined only as a string with example values instead, e.g. 

               "action": {
                    "type": "string",
                    "description": "Action to be performed on this order item (add, modify, move, delete, noChange)",
                    "examples": [
                      "add",
                      "modify",
                      "move",
                      "delete",
                      "noChange"
                }

I'm not sure what you mean by "OrderItem has fixed enum values".

if you think of the values provided by TM Forum, you know that these are only provided for illustration purposes. Every BSS vendor supporting TMF APIs has its own set of values and CSP typically introduce their own values and often work in different languages requiring even more enum values.

your question is valid, but as you have probably noticed, TMF API/etom/SID/etc project owners very rarely engage with the TMF communities. We are on our own here. I think you have to submit your suggestion it in their regular TMF API meetings. There has been a lot of great questions and recommendations shared in TMF communities that are lost because there is little communications between TMF project members and the community members.

Yes, this is still the same background; unfortunately, the action attribute of the OrderItem has fixed enum values, so that means we need to extend that enumeration to cover "move", and also introduce a further attribute sub-action, or use action "move-out" and "move-in".

So there is no other choice than to enhance the API by enum values and/or another attribute.

Would such an extension be of general use so that it should be considered for the next version of the TMF622 Product Ordering API?

When I worked at Siebel, around 25 years ago, Deutsche Telekom AG, which was using Siebel CRM as a BSS, has asked us the same question, not in the context of TMF order API but Siebel Order interface. Maybe you remember it.
the answer we gave you then was to construct your sales order with 2 root Order line items (OLI). Note: Each root could have child OLIs in case of bundle
Root OLI 1 has fields action code = move, sub-action code = out and service address Id = Id of the current place/termination point.
Root OLI 2 has fields  action code = move, sub-action code = in and  service address Id would have the Id of the new place/termination point.
exact same logic applies with mobile subscription except it's the account triumvirat that change: owner account, service account and billing account 

This was a vanilla functionality in siebel under the MACD process flow.

I don't see why this approach would not be different in 2025 with another API provider like TMF.

In our setting we differentiate several types of ProductOrders, e.g. to distinguish a change of a Product from a relocation (change of address). We call this the "Business Use Case".
In one order, several such use cases may be contained, so that it is a property of an OrderItem rather than of the Order as a whole.
Obviously, the actual processing of the modification highly depends on the kind of change.

So far, both cases would have OrderItem.action=modify, and to find out if it is the place that changes, one needs to evaluate the reference to the place; and references to other objects to identify further kinds of changes. This implicit differentiation needs to be made explicit to simplify the processing.

How could this be modelled in the TMF ProductOrder API?

• additional attribute of OrderItem?
• additional values of OrderItem.action?
• any other idea?

Thank you,

Lutz

I'm not sure what you mean by "OrderItem has fixed enum values".

if you think of the values provided by TM Forum, you know that these are only provided for illustration purposes. Every BSS vendor supporting TMF APIs has its own set of values and CSP typically introduce their own values and often work in different languages requiring even more enum values.

your question is valid, but as you have probably noticed, TMF API/etom/SID/etc project owners very rarely engage with the TMF communities. We are on our own here. I think you have to submit your suggestion it in their regular TMF API meetings. There has been a lot of great questions and recommendations shared in TMF communities that are lost because there is little communications between TMF project members and the community members.

Yes, this is still the same background; unfortunately, the action attribute of the OrderItem has fixed enum values, so that means we need to extend that enumeration to cover "move", and also introduce a further attribute sub-action, or use action "move-out" and "move-in".

So there is no other choice than to enhance the API by enum values and/or another attribute.

Would such an extension be of general use so that it should be considered for the next version of the TMF622 Product Ordering API?

When I worked at Siebel, around 25 years ago, Deutsche Telekom AG, which was using Siebel CRM as a BSS, has asked us the same question, not in the context of TMF order API but Siebel Order interface. Maybe you remember it.
the answer we gave you then was to construct your sales order with 2 root Order line items (OLI). Note: Each root could have child OLIs in case of bundle
Root OLI 1 has fields action code = move, sub-action code = out and service address Id = Id of the current place/termination point.
Root OLI 2 has fields  action code = move, sub-action code = in and  service address Id would have the Id of the new place/termination point.
exact same logic applies with mobile subscription except it's the account triumvirat that change: owner account, service account and billing account 

This was a vanilla functionality in siebel under the MACD process flow.

I don't see why this approach would not be different in 2025 with another API provider like TMF.

In our setting we differentiate several types of ProductOrders, e.g. to distinguish a change of a Product from a relocation (change of address). We call this the "Business Use Case".
In one order, several such use cases may be contained, so that it is a property of an OrderItem rather than of the Order as a whole.
Obviously, the actual processing of the modification highly depends on the kind of change.

So far, both cases would have OrderItem.action=modify, and to find out if it is the place that changes, one needs to evaluate the reference to the place; and references to other objects to identify further kinds of changes. This implicit differentiation needs to be made explicit to simplify the processing.

How could this be modelled in the TMF ProductOrder API?

• additional attribute of OrderItem?
• additional values of OrderItem.action?
• any other idea?

Thank you,

Lutz

Hi Matthieu,

you are right, this is not the way to post a request for extension/change to the API Design team, but that was not my intension with the question; being a member of the API team myself, I just wanted to find out if the described problem is DT specific (so we need to find a "local" solution) or if there is a broader interest in this so that it makes sense to propose a solution to the team.

But with Iwan's idea I think we do not need that ;-)

Cheers,

Lutz

I'm not sure what you mean by "OrderItem has fixed enum values".

if you think of the values provided by TM Forum, you know that these are only provided for illustration purposes. Every BSS vendor supporting TMF APIs has its own set of values and CSP typically introduce their own values and often work in different languages requiring even more enum values.

your question is valid, but as you have probably noticed, TMF API/etom/SID/etc project owners very rarely engage with the TMF communities. We are on our own here. I think you have to submit your suggestion it in their regular TMF API meetings. There has been a lot of great questions and recommendations shared in TMF communities that are lost because there is little communications between TMF project members and the community members.

Yes, this is still the same background; unfortunately, the action attribute of the OrderItem has fixed enum values, so that means we need to extend that enumeration to cover "move", and also introduce a further attribute sub-action, or use action "move-out" and "move-in".

So there is no other choice than to enhance the API by enum values and/or another attribute.

Would such an extension be of general use so that it should be considered for the next version of the TMF622 Product Ordering API?

When I worked at Siebel, around 25 years ago, Deutsche Telekom AG, which was using Siebel CRM as a BSS, has asked us the same question, not in the context of TMF order API but Siebel Order interface. Maybe you remember it.
the answer we gave you then was to construct your sales order with 2 root Order line items (OLI). Note: Each root could have child OLIs in case of bundle
Root OLI 1 has fields action code = move, sub-action code = out and service address Id = Id of the current place/termination point.
Root OLI 2 has fields  action code = move, sub-action code = in and  service address Id would have the Id of the new place/termination point.
exact same logic applies with mobile subscription except it's the account triumvirat that change: owner account, service account and billing account 

This was a vanilla functionality in siebel under the MACD process flow.

I don't see why this approach would not be different in 2025 with another API provider like TMF.

In our setting we differentiate several types of ProductOrders, e.g. to distinguish a change of a Product from a relocation (change of address). We call this the "Business Use Case".
In one order, several such use cases may be contained, so that it is a property of an OrderItem rather than of the Order as a whole.
Obviously, the actual processing of the modification highly depends on the kind of change.

So far, both cases would have OrderItem.action=modify, and to find out if it is the place that changes, one needs to evaluate the reference to the place; and references to other objects to identify further kinds of changes. This implicit differentiation needs to be made explicit to simplify the processing.

How could this be modelled in the TMF ProductOrder API?

• additional attribute of OrderItem?
• additional values of OrderItem.action?
• any other idea?

Thank you,

Lutz