Open APIs

Hi all,

there should be clear two-way mapping between TMF622 ProductOrderItem and TMF637 Product as product inventory must be updated based on the order items and order items are initiated based on the product inventory (for "asset based ordering").

The similar mapping should be between TMF760 and TMF622 as product configuration shall be transformed to order items. 

It seems that resources ProductConfiguration and ProductOrderItem are not fully aligned (e.g. attribute ProductConfiguration.isSelected seems quite strange for product modification use cases and ProductConfiguration.configurationAction should be sufficient).

Is there any description of this mapping between ProductConfiguration and ProductOrderItem?

Hi,

ProductConfiguration plays a role mostly in context of bundles(CPQ process) involving more than one product and customer as part of change request might be asking for new products, change in existing product configuration and also terminating few existing products. During the negotiation phase sales rep or customer might work on this across multiple sessions and will save their work to work on it later. isSelected is a flag to indicate if an optional product in a bundle has been selected by customer/salesrep and doesn't directly map to TMF622, ProductConfiguration.configurationAction maps to action in 622.

This my understanding based on my work for past couple of monthly in this area and not an expert, so above is more an opinion based on my current knowledge, happy to be corrected.

Hi all,

there should be clear two-way mapping between TMF622 ProductOrderItem and TMF637 Product as product inventory must be updated based on the order items and order items are initiated based on the product inventory (for "asset based ordering").

The similar mapping should be between TMF760 and TMF622 as product configuration shall be transformed to order items. 

It seems that resources ProductConfiguration and ProductOrderItem are not fully aligned (e.g. attribute ProductConfiguration.isSelected seems quite strange for product modification use cases and ProductConfiguration.configurationAction should be sufficient).

Is there any description of this mapping between ProductConfiguration and ProductOrderItem?

Thanks a lot.

You are probably right in most of you say. It seems there are some "hidden" assumptions behind design of this API:

• TMF760 ProductConfiguration model is used in two totally different contexts - (A) for communication with configurator UIs and (B) for mapping to/from order.
• UI is typically specifying required to-be state (i.e. what customer will have after change). This is purpose of flag "isSelected". It is just for (A).
• But sometimes you need also specify configurationAction (as "move") during product configuration.
• TMF622 order needs to get "deltas" - which order item is added, removed, changed.

The key question is which component should calculate order "deltas" (difference between required to-be state and as-is state):

1) If Product configurator then attribute "action" is used for (A) and (B) for the different purposes (quite misleading). But your mapping is correct. 

2) If OCV then mapping between ProductConfiguration.configurationAction and action in 622 is not so straightforward.

Hi,

ProductConfiguration plays a role mostly in context of bundles(CPQ process) involving more than one product and customer as part of change request might be asking for new products, change in existing product configuration and also terminating few existing products. During the negotiation phase sales rep or customer might work on this across multiple sessions and will save their work to work on it later. isSelected is a flag to indicate if an optional product in a bundle has been selected by customer/salesrep and doesn't directly map to TMF622, ProductConfiguration.configurationAction maps to action in 622.

This my understanding based on my work for past couple of monthly in this area and not an expert, so above is more an opinion based on my current knowledge, happy to be corrected.

Hi all,

there should be clear two-way mapping between TMF622 ProductOrderItem and TMF637 Product as product inventory must be updated based on the order items and order items are initiated based on the product inventory (for "asset based ordering").

The similar mapping should be between TMF760 and TMF622 as product configuration shall be transformed to order items. 

It seems that resources ProductConfiguration and ProductOrderItem are not fully aligned (e.g. attribute ProductConfiguration.isSelected seems quite strange for product modification use cases and ProductConfiguration.configurationAction should be sufficient).

Is there any description of this mapping between ProductConfiguration and ProductOrderItem?

Nice conversation, thank you.

Does TMF622 really needs to get the Delta or can it work based on to-be state.

Current state is in Product Inventory(TMF637), can POCV receiving to-be state in TMF622 derive the delta using current. This simplify the channels and bring in lot of the complex logic to a single place serving all the channels.

Does it make sense?

Thanks a lot.

You are probably right in most of you say. It seems there are some "hidden" assumptions behind design of this API:

• TMF760 ProductConfiguration model is used in two totally different contexts - (A) for communication with configurator UIs and (B) for mapping to/from order.
• UI is typically specifying required to-be state (i.e. what customer will have after change). This is purpose of flag "isSelected". It is just for (A).
• But sometimes you need also specify configurationAction (as "move") during product configuration.
• TMF622 order needs to get "deltas" - which order item is added, removed, changed.

The key question is which component should calculate order "deltas" (difference between required to-be state and as-is state):

1) If Product configurator then attribute "action" is used for (A) and (B) for the different purposes (quite misleading). But your mapping is correct. 

2) If OCV then mapping between ProductConfiguration.configurationAction and action in 622 is not so straightforward.

Hi,

ProductConfiguration plays a role mostly in context of bundles(CPQ process) involving more than one product and customer as part of change request might be asking for new products, change in existing product configuration and also terminating few existing products. During the negotiation phase sales rep or customer might work on this across multiple sessions and will save their work to work on it later. isSelected is a flag to indicate if an optional product in a bundle has been selected by customer/salesrep and doesn't directly map to TMF622, ProductConfiguration.configurationAction maps to action in 622.

This my understanding based on my work for past couple of monthly in this area and not an expert, so above is more an opinion based on my current knowledge, happy to be corrected.

Hi all,

there should be clear two-way mapping between TMF622 ProductOrderItem and TMF637 Product as product inventory must be updated based on the order items and order items are initiated based on the product inventory (for "asset based ordering").

The similar mapping should be between TMF760 and TMF622 as product configuration shall be transformed to order items. 

It seems that resources ProductConfiguration and ProductOrderItem are not fully aligned (e.g. attribute ProductConfiguration.isSelected seems quite strange for product modification use cases and ProductConfiguration.configurationAction should be sufficient).

Is there any description of this mapping between ProductConfiguration and ProductOrderItem?

Thanks again, it was really helpful for me.

I am happy with TMF760 API now :)

Just to summary my understanding based on your inputs:

• ProductConfiguration describes customer's intent as TO-BE state (i.e. not what is needed to be changed). ConfigurationAction helps to specify this intent (as Move)..
• OCV is responsible for mapping this intent to the required change. Order item action defines this required change. 
• Mapping between ProductConfiguration and ProductOrderItem is internal OCV functionality and depends on the multiple factors (asset based ordering vs delta ordering, configurationAction semantics, etc.)

Nice conversation, thank you.

Does TMF622 really needs to get the Delta or can it work based on to-be state.

Current state is in Product Inventory(TMF637), can POCV receiving to-be state in TMF622 derive the delta using current. This simplify the channels and bring in lot of the complex logic to a single place serving all the channels.

Does it make sense?

Thanks a lot.

You are probably right in most of you say. It seems there are some "hidden" assumptions behind design of this API:

• TMF760 ProductConfiguration model is used in two totally different contexts - (A) for communication with configurator UIs and (B) for mapping to/from order.
• UI is typically specifying required to-be state (i.e. what customer will have after change). This is purpose of flag "isSelected". It is just for (A).
• But sometimes you need also specify configurationAction (as "move") during product configuration.
• TMF622 order needs to get "deltas" - which order item is added, removed, changed.

The key question is which component should calculate order "deltas" (difference between required to-be state and as-is state):

1) If Product configurator then attribute "action" is used for (A) and (B) for the different purposes (quite misleading). But your mapping is correct. 

2) If OCV then mapping between ProductConfiguration.configurationAction and action in 622 is not so straightforward.

Hi,

ProductConfiguration plays a role mostly in context of bundles(CPQ process) involving more than one product and customer as part of change request might be asking for new products, change in existing product configuration and also terminating few existing products. During the negotiation phase sales rep or customer might work on this across multiple sessions and will save their work to work on it later. isSelected is a flag to indicate if an optional product in a bundle has been selected by customer/salesrep and doesn't directly map to TMF622, ProductConfiguration.configurationAction maps to action in 622.

This my understanding based on my work for past couple of monthly in this area and not an expert, so above is more an opinion based on my current knowledge, happy to be corrected.

Hi all,

there should be clear two-way mapping between TMF622 ProductOrderItem and TMF637 Product as product inventory must be updated based on the order items and order items are initiated based on the product inventory (for "asset based ordering").

The similar mapping should be between TMF760 and TMF622 as product configuration shall be transformed to order items. 

It seems that resources ProductConfiguration and ProductOrderItem are not fully aligned (e.g. attribute ProductConfiguration.isSelected seems quite strange for product modification use cases and ProductConfiguration.configurationAction should be sufficient).

Is there any description of this mapping between ProductConfiguration and ProductOrderItem?

Thank you for the collaboration.

3rd Bullet may not be right, please refer to TMF760 user guide(version 5.0.0) page 7. Engagement Management BFF has the responsibility to map ProductConfiguration to ProductOrder(intent).

Thanks again, it was really helpful for me.

I am happy with TMF760 API now :)

Just to summary my understanding based on your inputs:

• ProductConfiguration describes customer's intent as TO-BE state (i.e. not what is needed to be changed). ConfigurationAction helps to specify this intent (as Move)..
• OCV is responsible for mapping this intent to the required change. Order item action defines this required change. 
• Mapping between ProductConfiguration and ProductOrderItem is internal OCV functionality and depends on the multiple factors (asset based ordering vs delta ordering, configurationAction semantics, etc.)

Nice conversation, thank you.

Does TMF622 really needs to get the Delta or can it work based on to-be state.

Current state is in Product Inventory(TMF637), can POCV receiving to-be state in TMF622 derive the delta using current. This simplify the channels and bring in lot of the complex logic to a single place serving all the channels.

Does it make sense?

Thanks a lot.

You are probably right in most of you say. It seems there are some "hidden" assumptions behind design of this API:

• TMF760 ProductConfiguration model is used in two totally different contexts - (A) for communication with configurator UIs and (B) for mapping to/from order.
• UI is typically specifying required to-be state (i.e. what customer will have after change). This is purpose of flag "isSelected". It is just for (A).
• But sometimes you need also specify configurationAction (as "move") during product configuration.
• TMF622 order needs to get "deltas" - which order item is added, removed, changed.

The key question is which component should calculate order "deltas" (difference between required to-be state and as-is state):

1) If Product configurator then attribute "action" is used for (A) and (B) for the different purposes (quite misleading). But your mapping is correct. 

2) If OCV then mapping between ProductConfiguration.configurationAction and action in 622 is not so straightforward.

Hi,

ProductConfiguration plays a role mostly in context of bundles(CPQ process) involving more than one product and customer as part of change request might be asking for new products, change in existing product configuration and also terminating few existing products. During the negotiation phase sales rep or customer might work on this across multiple sessions and will save their work to work on it later. isSelected is a flag to indicate if an optional product in a bundle has been selected by customer/salesrep and doesn't directly map to TMF622, ProductConfiguration.configurationAction maps to action in 622.

This my understanding based on my work for past couple of monthly in this area and not an expert, so above is more an opinion based on my current knowledge, happy to be corrected.

Hi all,

there should be clear two-way mapping between TMF622 ProductOrderItem and TMF637 Product as product inventory must be updated based on the order items and order items are initiated based on the product inventory (for "asset based ordering").

The similar mapping should be between TMF760 and TMF622 as product configuration shall be transformed to order items. 

It seems that resources ProductConfiguration and ProductOrderItem are not fully aligned (e.g. attribute ProductConfiguration.isSelected seems quite strange for product modification use cases and ProductConfiguration.configurationAction should be sufficient).

Is there any description of this mapping between ProductConfiguration and ProductOrderItem?

Hmm, it is quite strange.

IG1228, TMFS003: Use Case: Order Capture - Fiber Contract v9.0.0 describes it in the different way.

ProductConfiguration is sent to POCV as part of process API. I prefer to perform such mapping in channel independent way (i.e. not in BFF) as specified in IG1228.

Thank you for the collaboration.

3rd Bullet may not be right, please refer to TMF760 user guide(version 5.0.0) page 7. Engagement Management BFF has the responsibility to map ProductConfiguration to ProductOrder(intent).

Thanks again, it was really helpful for me.

I am happy with TMF760 API now :)

Just to summary my understanding based on your inputs:

• ProductConfiguration describes customer's intent as TO-BE state (i.e. not what is needed to be changed). ConfigurationAction helps to specify this intent (as Move)..
• OCV is responsible for mapping this intent to the required change. Order item action defines this required change. 
• Mapping between ProductConfiguration and ProductOrderItem is internal OCV functionality and depends on the multiple factors (asset based ordering vs delta ordering, configurationAction semantics, etc.)

Nice conversation, thank you.

Does TMF622 really needs to get the Delta or can it work based on to-be state.

Current state is in Product Inventory(TMF637), can POCV receiving to-be state in TMF622 derive the delta using current. This simplify the channels and bring in lot of the complex logic to a single place serving all the channels.

Does it make sense?

Thanks a lot.

You are probably right in most of you say. It seems there are some "hidden" assumptions behind design of this API:

• TMF760 ProductConfiguration model is used in two totally different contexts - (A) for communication with configurator UIs and (B) for mapping to/from order.
• UI is typically specifying required to-be state (i.e. what customer will have after change). This is purpose of flag "isSelected". It is just for (A).
• But sometimes you need also specify configurationAction (as "move") during product configuration.
• TMF622 order needs to get "deltas" - which order item is added, removed, changed.

The key question is which component should calculate order "deltas" (difference between required to-be state and as-is state):

1) If Product configurator then attribute "action" is used for (A) and (B) for the different purposes (quite misleading). But your mapping is correct. 

2) If OCV then mapping between ProductConfiguration.configurationAction and action in 622 is not so straightforward.

Hi,

ProductConfiguration plays a role mostly in context of bundles(CPQ process) involving more than one product and customer as part of change request might be asking for new products, change in existing product configuration and also terminating few existing products. During the negotiation phase sales rep or customer might work on this across multiple sessions and will save their work to work on it later. isSelected is a flag to indicate if an optional product in a bundle has been selected by customer/salesrep and doesn't directly map to TMF622, ProductConfiguration.configurationAction maps to action in 622.

This my understanding based on my work for past couple of monthly in this area and not an expert, so above is more an opinion based on my current knowledge, happy to be corrected.

Hi all,

there should be clear two-way mapping between TMF622 ProductOrderItem and TMF637 Product as product inventory must be updated based on the order items and order items are initiated based on the product inventory (for "asset based ordering").

The similar mapping should be between TMF760 and TMF622 as product configuration shall be transformed to order items. 

It seems that resources ProductConfiguration and ProductOrderItem are not fully aligned (e.g. attribute ProductConfiguration.isSelected seems quite strange for product modification use cases and ProductConfiguration.configurationAction should be sufficient).

Is there any description of this mapping between ProductConfiguration and ProductOrderItem?

Hmm, it is quite strange.

IG1228, TMFS003: Use Case: Order Capture - Fiber Contract v9.0.0 describes it in the different way.

ProductConfiguration is sent to POCV as part of process API. I prefer to perform such mapping in channel independent way (i.e. not in BFF) as specified in IG1228.

Thank you for the collaboration.

3rd Bullet may not be right, please refer to TMF760 user guide(version 5.0.0) page 7. Engagement Management BFF has the responsibility to map ProductConfiguration to ProductOrder(intent).

Thanks again, it was really helpful for me.

I am happy with TMF760 API now :)

Just to summary my understanding based on your inputs:

• ProductConfiguration describes customer's intent as TO-BE state (i.e. not what is needed to be changed). ConfigurationAction helps to specify this intent (as Move)..
• OCV is responsible for mapping this intent to the required change. Order item action defines this required change. 
• Mapping between ProductConfiguration and ProductOrderItem is internal OCV functionality and depends on the multiple factors (asset based ordering vs delta ordering, configurationAction semantics, etc.)

Nice conversation, thank you.

Does TMF622 really needs to get the Delta or can it work based on to-be state.

Current state is in Product Inventory(TMF637), can POCV receiving to-be state in TMF622 derive the delta using current. This simplify the channels and bring in lot of the complex logic to a single place serving all the channels.

Does it make sense?

Thanks a lot.

You are probably right in most of you say. It seems there are some "hidden" assumptions behind design of this API:

• TMF760 ProductConfiguration model is used in two totally different contexts - (A) for communication with configurator UIs and (B) for mapping to/from order.
• UI is typically specifying required to-be state (i.e. what customer will have after change). This is purpose of flag "isSelected". It is just for (A).
• But sometimes you need also specify configurationAction (as "move") during product configuration.
• TMF622 order needs to get "deltas" - which order item is added, removed, changed.

The key question is which component should calculate order "deltas" (difference between required to-be state and as-is state):

1) If Product configurator then attribute "action" is used for (A) and (B) for the different purposes (quite misleading). But your mapping is correct. 

2) If OCV then mapping between ProductConfiguration.configurationAction and action in 622 is not so straightforward.

Hi,

ProductConfiguration plays a role mostly in context of bundles(CPQ process) involving more than one product and customer as part of change request might be asking for new products, change in existing product configuration and also terminating few existing products. During the negotiation phase sales rep or customer might work on this across multiple sessions and will save their work to work on it later. isSelected is a flag to indicate if an optional product in a bundle has been selected by customer/salesrep and doesn't directly map to TMF622, ProductConfiguration.configurationAction maps to action in 622.

This my understanding based on my work for past couple of monthly in this area and not an expert, so above is more an opinion based on my current knowledge, happy to be corrected.

Hi all,

there should be clear two-way mapping between TMF622 ProductOrderItem and TMF637 Product as product inventory must be updated based on the order items and order items are initiated based on the product inventory (for "asset based ordering").

The similar mapping should be between TMF760 and TMF622 as product configuration shall be transformed to order items. 

It seems that resources ProductConfiguration and ProductOrderItem are not fully aligned (e.g. attribute ProductConfiguration.isSelected seems quite strange for product modification use cases and ProductConfiguration.configurationAction should be sufficient).

Is there any description of this mapping between ProductConfiguration and ProductOrderItem?

Hi,

ProductConfiguration plays a role mostly in context of bundles(CPQ process) involving more than one product and customer as part of change request might be asking for new products, change in existing product configuration and also terminating few existing products. During the negotiation phase sales rep or customer might work on this across multiple sessions and will save their work to work on it later. isSelected is a flag to indicate if an optional product in a bundle has been selected by customer/salesrep and doesn't directly map to TMF622, ProductConfiguration.configurationAction maps to action in 622.

This my understanding based on my work for past couple of monthly in this area and not an expert, so above is more an opinion based on my current knowledge, happy to be corrected.

Hi all,

there should be clear two-way mapping between TMF622 ProductOrderItem and TMF637 Product as product inventory must be updated based on the order items and order items are initiated based on the product inventory (for "asset based ordering").

The similar mapping should be between TMF760 and TMF622 as product configuration shall be transformed to order items. 

It seems that resources ProductConfiguration and ProductOrderItem are not fully aligned (e.g. attribute ProductConfiguration.isSelected seems quite strange for product modification use cases and ProductConfiguration.configurationAction should be sufficient).

Is there any description of this mapping between ProductConfiguration and ProductOrderItem?

Hi all,

there should be clear two-way mapping between TMF622 ProductOrderItem and TMF637 Product as product inventory must be updated based on the order items and order items are initiated based on the product inventory (for "asset based ordering").

The similar mapping should be between TMF760 and TMF622 as product configuration shall be transformed to order items. 

It seems that resources ProductConfiguration and ProductOrderItem are not fully aligned (e.g. attribute ProductConfiguration.isSelected seems quite strange for product modification use cases and ProductConfiguration.configurationAction should be sufficient).

Is there any description of this mapping between ProductConfiguration and ProductOrderItem?

------------------------------
Peter Rajsky
CGI Information Systems and Management Consultants Inc.
------------------------------