Open APIs

Hi

We are seeking to represent in a ProductOrder resource (TMF622) the nature of the order - in particular the following two properties :-

journeyType - the broad characterisation of what what the order is attempting to achieve - eg. provision, modification, cessation

journeySubType - the more narrow characterisation of what the order is attempting to achieve - eg. (for journeyType modification) Speed Upgrade, Equipment Replacement, Service Relocation etc.

There does not appear to be any attribute like this like this on this resource or any related resource. I am raising this as the recipient of of the request seeks to demonstrate these on customer communicated emails and other files

Thanks, Darren

Hi Darren

The productOrderItem->action attribute tells whether the product to-be added, modified, terminated. The downstream system reads this field to take the action. Is there any additional requirement to mention the journey in addition? There is a Note->text attribute , which may be used to mention the journey.  

Hi

We are seeking to represent in a ProductOrder resource (TMF622) the nature of the order - in particular the following two properties :-

journeyType - the broad characterisation of what what the order is attempting to achieve - eg. provision, modification, cessation

journeySubType - the more narrow characterisation of what the order is attempting to achieve - eg. (for journeyType modification) Speed Upgrade, Equipment Replacement, Service Relocation etc.

There does not appear to be any attribute like this like this on this resource or any related resource. I am raising this as the recipient of of the request seeks to demonstrate these on customer communicated emails and other files

Thanks, Darren

I suspect Darren is looking for something more structured.

It is bit like the US MACD ( move, add, change, delete) where a move is distinct from any other change. But it is more nuanced than that.

So one could be saying "Oh you asked for me to provide an FTTP(H) product at these premises but I notice there is already an inactive port on an ONT present there so I am going to achieve this "provide" order as a remote activation of a spare port". Or once could be saying "I see that the ONT port you have identified to provide a product on already has a working product provided by another retailer I am presuming you are asking me to transfer this to your new chosen provider".

It is important to identify these scenarios explicitly as they can have an impact on the cost and leadtime provide the working product.

Hi Darren

The productOrderItem->action attribute tells whether the product to-be added, modified, terminated. The downstream system reads this field to take the action. Is there any additional requirement to mention the journey in addition? There is a Note->text attribute , which may be used to mention the journey.  

Hi

We are seeking to represent in a ProductOrder resource (TMF622) the nature of the order - in particular the following two properties :-

journeyType - the broad characterisation of what what the order is attempting to achieve - eg. provision, modification, cessation

journeySubType - the more narrow characterisation of what the order is attempting to achieve - eg. (for journeyType modification) Speed Upgrade, Equipment Replacement, Service Relocation etc.

There does not appear to be any attribute like this like this on this resource or any related resource. I am raising this as the recipient of of the request seeks to demonstrate these on customer communicated emails and other files

Thanks, Darren

Hi Derrick

if we consider the provider change scenario you mentioned, I assume you are referring to port-in request? in such scenario , in the product specification , the last provider name, old customer id , etc can be provided as characteristics, which can be provided during product order.   

I suspect Darren is looking for something more structured.

It is bit like the US MACD ( move, add, change, delete) where a move is distinct from any other change. But it is more nuanced than that.

So one could be saying "Oh you asked for me to provide an FTTP(H) product at these premises but I notice there is already an inactive port on an ONT present there so I am going to achieve this "provide" order as a remote activation of a spare port". Or once could be saying "I see that the ONT port you have identified to provide a product on already has a working product provided by another retailer I am presuming you are asking me to transfer this to your new chosen provider".

It is important to identify these scenarios explicitly as they can have an impact on the cost and leadtime provide the working product.

Hi Darren

The productOrderItem->action attribute tells whether the product to-be added, modified, terminated. The downstream system reads this field to take the action. Is there any additional requirement to mention the journey in addition? There is a Note->text attribute , which may be used to mention the journey.  

Hi

We are seeking to represent in a ProductOrder resource (TMF622) the nature of the order - in particular the following two properties :-

journeyType - the broad characterisation of what what the order is attempting to achieve - eg. provision, modification, cessation

journeySubType - the more narrow characterisation of what the order is attempting to achieve - eg. (for journeyType modification) Speed Upgrade, Equipment Replacement, Service Relocation etc.

There does not appear to be any attribute like this like this on this resource or any related resource. I am raising this as the recipient of of the request seeks to demonstrate these on customer communicated emails and other files

Thanks, Darren

Hi

We are seeking to represent in a ProductOrder resource (TMF622) the nature of the order - in particular the following two properties :-

journeyType - the broad characterisation of what what the order is attempting to achieve - eg. provision, modification, cessation

journeySubType - the more narrow characterisation of what the order is attempting to achieve - eg. (for journeyType modification) Speed Upgrade, Equipment Replacement, Service Relocation etc.

There does not appear to be any attribute like this like this on this resource or any related resource. I am raising this as the recipient of of the request seeks to demonstrate these on customer communicated emails and other files

Thanks, Darren

I wonder if this is even achievable. we tried in the past but it's just too difficult when a single order simulatenously contains:

• terminate of a product
• modify of a product
• add a product offering
  
  • all of the above may even be called differently depending on whether you're doing it inside a bundle or with stand-alone products
• suspend a product

Move (to a new location), transfer (to another customer account or another billing account) tend to be done as separate orders, though, which makes taxonomical classification easier.

Hi

We are seeking to represent in a ProductOrder resource (TMF622) the nature of the order - in particular the following two properties :-

journeyType - the broad characterisation of what what the order is attempting to achieve - eg. provision, modification, cessation

journeySubType - the more narrow characterisation of what the order is attempting to achieve - eg. (for journeyType modification) Speed Upgrade, Equipment Replacement, Service Relocation etc.

There does not appear to be any attribute like this like this on this resource or any related resource. I am raising this as the recipient of of the request seeks to demonstrate these on customer communicated emails and other files

Thanks, Darren

Agree. We also do separate orders for take over and move journey..

I wonder if this is even achievable. we tried in the past but it's just too difficult when a single order simulatenously contains:

• terminate of a product
• modify of a product
• add a product offering
  
  • all of the above may even be called differently depending on whether you're doing it inside a bundle or with stand-alone products
• suspend a product

Move (to a new location), transfer (to another customer account or another billing account) tend to be done as separate orders, though, which makes taxonomical classification easier.

Hi

We are seeking to represent in a ProductOrder resource (TMF622) the nature of the order - in particular the following two properties :-

journeyType - the broad characterisation of what what the order is attempting to achieve - eg. provision, modification, cessation

journeySubType - the more narrow characterisation of what the order is attempting to achieve - eg. (for journeyType modification) Speed Upgrade, Equipment Replacement, Service Relocation etc.

There does not appear to be any attribute like this like this on this resource or any related resource. I am raising this as the recipient of of the request seeks to demonstrate these on customer communicated emails and other files

Thanks, Darren

Hello All 

So I do not think the notion is to orchestrate several things at once (although I might be misunderstanding the original question).

Rather it is to subdivide the notion of a provide or a modify or a cease of a service into different scenarios and call out which one is in play for a particular order?

So (as an example) in the Wholesale part of BT Group you can say "provide VDSL at this location on this line" and the provider will evaluate what is on the line and what has been asked for and then tell you in return what subtype of order that will be (as a justification for the price and the lead time).

That subtype could say anything from

"There is VDSL on that line already sold through another retailer so we are moving that service to you"

to

"There is ADSL on that line provided to you and so we are upgrading that service to you"

to

"There is no  broadband on that line at the moment so we a providing that as a new service".

Similarly a modify (change)  and be either 

"Change the speed"

OR

"Move the Network Termination Point"

OR

"Change this from VDSL to FTTP and cease the copper line that hosted the VDSL after you have provided the FTTP service ".

But I think we can agree that for one instance of the service doing the several things in one would be a tricky thing to orchestrate.

Indeed the more things you change in one go the more it looks like "provide a new service" as one order and "remove/cease/disconnect this service" as another.

Agree. We also do separate orders for take over and move journey..

I wonder if this is even achievable. we tried in the past but it's just too difficult when a single order simulatenously contains:

• terminate of a product
• modify of a product
• add a product offering
  
  • all of the above may even be called differently depending on whether you're doing it inside a bundle or with stand-alone products
• suspend a product

Move (to a new location), transfer (to another customer account or another billing account) tend to be done as separate orders, though, which makes taxonomical classification easier.

Hi

We are seeking to represent in a ProductOrder resource (TMF622) the nature of the order - in particular the following two properties :-

journeyType - the broad characterisation of what what the order is attempting to achieve - eg. provision, modification, cessation

journeySubType - the more narrow characterisation of what the order is attempting to achieve - eg. (for journeyType modification) Speed Upgrade, Equipment Replacement, Service Relocation etc.

There does not appear to be any attribute like this like this on this resource or any related resource. I am raising this as the recipient of of the request seeks to demonstrate these on customer communicated emails and other files

Thanks, Darren

Hi,

the product order syntax is actually much richer than any journey type and subtype could express.

A product order has several order items each with their action: add, modify, delete & no_change.

On top of that there are orderItem relationships and product relationships that can be used to express bundling, dependencies.

The combination of this rich syntax and the use of atomic products allows you to express a move as an add of a new accessline in a new location and a delete of the old accessline while not changing the internet, SD-WAN or VOIP services that run on the accessline. With the relationships, make before break or break before make scenarios can be expressed. Similarly CPE replacements or speed upgrades can easily be expressed using this syntax.

The syntax introduces exactness of the operations to be performed that is only expressed more vaguely with journey types.

regards

Hello All 

So I do not think the notion is to orchestrate several things at once (although I might be misunderstanding the original question).

Rather it is to subdivide the notion of a provide or a modify or a cease of a service into different scenarios and call out which one is in play for a particular order?

So (as an example) in the Wholesale part of BT Group you can say "provide VDSL at this location on this line" and the provider will evaluate what is on the line and what has been asked for and then tell you in return what subtype of order that will be (as a justification for the price and the lead time).

That subtype could say anything from

"There is VDSL on that line already sold through another retailer so we are moving that service to you"

to

"There is ADSL on that line provided to you and so we are upgrading that service to you"

to

"There is no  broadband on that line at the moment so we a providing that as a new service".

Similarly a modify (change)  and be either 

"Change the speed"

OR

"Move the Network Termination Point"

OR

"Change this from VDSL to FTTP and cease the copper line that hosted the VDSL after you have provided the FTTP service ".

But I think we can agree that for one instance of the service doing the several things in one would be a tricky thing to orchestrate.

Indeed the more things you change in one go the more it looks like "provide a new service" as one order and "remove/cease/disconnect this service" as another.

Agree. We also do separate orders for take over and move journey..

I wonder if this is even achievable. we tried in the past but it's just too difficult when a single order simulatenously contains:

• terminate of a product
• modify of a product
• add a product offering
  
  • all of the above may even be called differently depending on whether you're doing it inside a bundle or with stand-alone products
• suspend a product

Move (to a new location), transfer (to another customer account or another billing account) tend to be done as separate orders, though, which makes taxonomical classification easier.

Hi

We are seeking to represent in a ProductOrder resource (TMF622) the nature of the order - in particular the following two properties :-

journeyType - the broad characterisation of what what the order is attempting to achieve - eg. provision, modification, cessation

journeySubType - the more narrow characterisation of what the order is attempting to achieve - eg. (for journeyType modification) Speed Upgrade, Equipment Replacement, Service Relocation etc.

There does not appear to be any attribute like this like this on this resource or any related resource. I am raising this as the recipient of of the request seeks to demonstrate these on customer communicated emails and other files

Thanks, Darren