SID Q&A - Question 8

This is the eight in a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.  

In this Q&A we discuss start to discuss ProductOfferPrice, the mechanism used in Frameworx SID to apply prices to ProductOfferings as well as ProductCatalogue.


So4It:  Now we come to the pricing of our Product Offerings.

As I understand it the ProductSpecificationCost is the cost for the operator to install the product it specifies into their network including maintenance etc.  The ProductOfferingPrice is partly based on it (since the price has to cover the cost of cause) but the ProductOfferingPrice is the end price to the customer, right?  So in practice one can skip ProductSpecificationCost and just have ProductOfferingPrice right? 

 

Andrew:  Correct on all counts. The ProductSpecificationCost is not mandatory and would only be used in situations where you were doing profitability analysis.

So4It:  The ProductOfferingPrice includes all types of price including one-time fee, monthly fee etc so when building a complete system the process of creating a ProductOfferingPrice the creator of the ProductOffering would check all the ProductSpecificationCosts, one-time and re-occurring, and create a ProductOfferingPrice that will cover it plus the profit?

Andrew:  Yes, theoretically – but practically the complete ProductSpecificationCost isn’t known – R&D costs, overhead costs etc may not be known. 

So4It:  I can see in the SID that a ProductSpecCharacteristicValue can affect the product offering price and I want to understand this relationship a bit more since I think we have that case.

"The customer selects mobile telephony with X Free traffic + a iPad mini with either 16 GB memory or 32 GB memory"

So of cause the price will be different and the question here is should we model this as 2 different product offerings or as one with the price depending on what ProductSpecificationCharacteristicValue the customer selected, 16 GB or 32 GB.

Can you please elaborate on how the ProductOfferingPrice would be structured for this case? Would these be 2 different ProductSpecifications or will it be one with a ProductSpecCharacteristicValue that decides if it is 16GB or 32GB?

Andrew:  I would model this as one ProductSpec with a ProductSpecCharacteristic of “MemorySize” with 2 ProductSpecCharacteristicValues of “16GB” and “32GB”.   I would however then create 2 ProductOfferings say “iPadMiniStd” and “iPadMiniDelux” the ProductOfferingProductSpecCharValueUse for “iPadMiniStd” would be associated with “16GB” and for “iPadMiniDelux” it would be associated with “32GB” (in the same way as my example using Widgets had “MonoWidget” associated with “black” and “white” while “RedWidget” was associated with “red”).  Then I would create separate prices for “iPadMiniStd” and “iPadMiniDelux”.  This of course requires the user of the pricing app to apply some common sense and it would be possible to make the “iPadMiniDelux” cheaper than “iPadMiniStd”. 

So4It:  One idea I’ve got since the reference between ProductOfferingPrice and ProductSpecification exists is to have a ProductOffering with a CompositeProductSpecification containing one ProductSpecification for the 16GB and one ProductSpecification for the 32 GB and then when the customer selects one we can use the price that is linked to the selected ProductSpecification seem logical ?

Andrew:  You could go to the extreme of making “iPadMemory32GB” and “iPadMemory16GB” different ProductSpecs each with its own ProductSpecificationCost and then have these linked to the “iPadMini” ProductSpec with a ProductSpecRelationship type of “alternatives” and then to build in pricing rules to ensure that a ProductOffering cannot have a ProductPrice of less than the sum of the ProductSpecificationCosts of the components without some sort of override – but that makes everything complex – but it is possible.

If you want to do what you are describing then I would use ProductOfferings rather than ProductSpecs and add ProductOfferings to a “basket” that has its price increase as you add options which are driven by the ProductOfferingRelationship rather than ProductSpecificationRelationship, rather than changing the price of the ProductOffering.  This would also help where a customer can choose to have multiple sub-component ProductOfferings.  Have you seen how Dell does its p.c. configuration pricing on its website?  It looks very much like this.

So4It:  So a question here is how does the reference between ProductOfferingPrice and ProductSpecification look like? ProductOfferingPrice and ProductSpecificationCharcteristicValue look like?  Will this be a ProdSpecCharValueUse maybe?

Andrew:  As I said above I wouldn’t use the ProductSpecification to drive the ProductOfferingPrice; if anything use the ProductOffering – but remember you are not changing the “price” you are changing the value of the CustomerOrder as the customer adds ProductOfferings to the order.  The unit price of the Product Offerings in the CustomerOrder remains the same (for all customers) but in the CustomerOrder there may be discounts applied as a result of the combination of products in the order or as a result of some sort of negotiated discount.  This is modelled on the CustomerOrder through the BusinessInteractionItemPrice.

So4It:  I mean how do you model this in real classes?

Andrew:  Look at the documentation on ConceptWave’s products and Dell’s and Amazon’s websites for real world examples of how product pricing and configurators work. 

In terms of real classes then I believe you should forget the ProductSpecificationCost – it is a “red herring” or something that is leading you off the correct way of implementing the pricing.  Use low level ProductOfferings “Options” that can be associated with higher level “EntryLevel” ProductOfferings and use the ProductOfferingPrice to accumulate the price on the CustomerOrder.  If discounts are applied then you can use BusinessInteractionItemPrice to record them. 

There is a very complex area of the SID call “Policy” which I am sure can be used to define the rule-base for this, but frankly, I’ve never used it and I think it is overly complex, and I’ve not confidence that it has ever been used in practice.

My advice is “KISS” (keep it simple, stupid).  The SID makes everything very complex to allow for every possible circumstance.  If you are building a specific app for say pricing and configuring end-user products then you can afford to model it in a simpler easier to use manner confident that it would never be used to price complex wholesale network bandwidth pricing products with SLAs and other penalties.

So4It:  Then we come to the GeographicArea and DistributionChannel.  As I see it a ProductCatalog has a SalesChannel and GeographicArea it is sold in and from that the price inherits them correct?

Andrew:  Correct.  See the diagram below

The key thing to notice in this diagram is that the ProductCatalogProductOffer which shows which ProductCatalog a Product Offer appears in is linked to the ProductOfferingPrice (though through a m:m association).  This therefore allows a ProductOffering to appear in multiple ProductCatalogs with different (or the same) prices in each.

So4It:  Why would we then keep these on the ProductOfferingPrice, is it because we might reuse the price in other ProductOfferings?

Andrew:  Yes, see my answer above.

So4It:  When it then comes to instantiating the product in the order manager I guess that the ProductOfferingPrice structure more or less becomes the same in the install base but as a Product Price instead correct?

Andrew:  ProductPrice is the price an individual customer paid, or has agreed to pay in the case of recurring charges or the price for Usage.  This can vary from the ProductOfferingPrice because of negotiated discounts etc.  So, yes, you are correct the installed base price is reflected in ProductPrice while the current “catalogue price” is the ProductOfferingPrice.

SID Q & A - Question 7

This is the seventh in a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.  

In this Q&A we explore more about the use of Characteristics and CharacteristicValues to describe ProductSpecifications and then we move on to Usage and then to Promotions.

So4It:  Can you please explain the entities ProductSpecCharUse and ProdSpecCharValueUse and how they are used?

Andrew:  A ProductSpecCharacteristic defines a generic characteristic that can be used by any Product Spec.  In my example there is a ProductSpecCharacteristic called “Colour” and another called “Shape”

                ProductSpecCharacteristic: Colour

                ProductSpecCharacteristic: Shape

The ProductSpec for “Widget” uses “Colour” but not “Shape” while “WidgetInaBox” uses both of these characteristics – (“Shape” is not relevant to “Widget”)

The ProductSpecCharacteristic “Colour” has 4 valid values as defined by ProductSpecCharValue:

                Black, White, Red and Green

But Green is only relevant to “WidgetinaBox” while the other colours are used by both Widget and WidgetinaBox as shown by the data in ProductSpecCharValueProductSpecCharUse.  Thus the value in ProductSpecCharValueProductSpecCharUse tells which of the ProductSpecCharValues apply to a given ProductSpec.

So4It:  We are now thinking about how to specify usage for a product. The UsageSpecification specifies how usage should be applied to usage of for example a product.

I have a lot of questions on how the UsageSpecification and the ProductSpecification are connected.  When a customer chooses a produce offering we send the order to the order manager and we provision the necessary entities in the network.  The usage data starts coming in and we store it on the product and/or service it refers to, but is this where the usage specification comes into the picture?  We will create usage entries using the usage specification and in that case how do we know what usage specification to use for a certain product/service the usage is referring to?

Andrew:  Usage is a relatively new part of the SID and probably not as rigorously defined as the other areas.  Generally in telecoms companies the usage information in provided as UDRs (CDRs (Call Detail Records) for voice usage and IPDRs for data usage (internet Data Records)).  The process of applying the correct charges to these usage records is performed in a set of specialised processes known as Mediation, Guiding and Rating.  These processes do not work on data as shown in the SID as they have to process millions and millions of records a minute and the SID’s highly generic and normalised structures would prevent that throughput from happening.

To quote the SID documentation on usage:

“Normally, when a usage event occurs, it is stored in a network element, for instance in a switch, router, gateway or in an application system.  Resources (applications, network and computing capabilities) usually store usage data in proprietary formats that are not understood by external systems such as billing systems.  Depending on the polling strategy, a mediation engine connects to resources, collects usage data and formats them into a format understood by the billing system.  Outputs of a mediation engine are Usage Detail Records (UDRs).  Examples of UDRs are call Data Records (CDRs – used to describe usage details of voice call services and Internet Protocol Detail Records (IPDRS – used to describe usage details of Internet Protocol based services).  In ...... we will use the Usage abstract business entity to describe any resource- service- or product-based usage that the external system can read update and process.”

The diagram below shows how the UsageSpecification is “theoretically” linked to ProductSpecification:

I say “theoretically” because the SIDs view of the process does not reflect what goes on in reality.  In reality the Rating engine processes the UDRs based on Service Usage assigning a cost  for the usage of the given service (making a phone call, receiving a phone call) depending on the time of day, day of week, duration of usage, location of usage, source and destination of usage etc etc.

When the Billing system receives the rated UDRs it then looks at the CustomerAccount and Product (subscriptions) and adjusts the costs applied by rating depending on the discounts and allowances provided by the ProductPrice.

So the mapping of Usage to Product is the last step in the process, not the first in the “real world” because of the volume of data involved and historically it wasn’t feasible to do the full Rating and allocating the allowances and discounts in near-real time.

The UsageSpec is a SID specific way of linking the Product Usage to the Service and Resource Usages and it does not reflect the real-world.

I think you should follow the industry standard of mapping the usage to the Service used (Rating) and then apply the allowances and discounts for usage (Billing).

So4It:  We are thinking about how to assign cost to a product.  As I understand it the ProductOfferingPrice should specify all the costs related to the product for the customer. In that case the product offering has implicit knowledge of what product specification exists in it.

For example if the product offering has "1 modem", "1 mobile telephony" etc the product offering price might be "A one-time fee off 40€ for the modem", "A reoccurring fee of 12€ / hour for the mobile telephony" etc.  But shouldn’t we link this to the product specification somehow?

As I understand it from the SID is that the ProductSpecificationCost is the cost for creating and maintaining the product and not the price for the end customer.  Which is logical since if we set it on the product specification it will be the same for every product offering using it.

Andrew:  You are quite right – there should be some way of linking the price for usage to the usage element of a ProductSpec.  In your definition of the product you have decided to put the usage in a separate ProductSpec; this is perfectly acceptable and 100% what SID allows.  My personal preference is to align usage to ServiceUsage as it is the services that are getting used not the product.  SID has been very vague here; I guess because there are so many different ways of defining the price and so many different organisations have done it differently that the definition had to be vague.  This however allows you to implement pricing any way you like.

So4It:  In the SID the SalesChannels is relate in a many-to-many relationship with the product offering; is that correct?  Somehow I thought it would be on the ProductCatalogProductOffering entity that is the many-to-many class that relates product catalogue to product offering?

Can you please elaborate a bit on the sales channel and marking parts of the SID.  We will have “invite” campaigns where the inviter earns credits when he/she gets us new customers.  So I am thinking we will have a sales channel that has a marketing campaign we call InviteMarketingCampaign.  In some cases we also have existing customers that gets credits from sending invites to friends.  We need to record these invites and I was thinking about storing them on the customer account.  So do you have any input on how to implement invites in the SID?

Andrew:   Product Catalogue is another new area that is evolving; there are working groups meeting every week to discuss it and I guess it will change in the next release.  There is definitely some sort of linkage between the Catalogue and the SalesChannel, but it hasn’t been defined yet.  The Sale&Marketing Domain has been very under developed for a long time and the relationship between ProductOffering and SalesChannel was defined back in the early days of SID before any work was done on ProductCatalogue.   I think you are correct and you can model a linkage between ProductCatalogue to SalesChannel rather than from ProductOffering to SalesChannel.

The Invites are “promotions” and as such are in fact ProductOfferings.  When you give someone an Invite you are provisioning a Product on their CustomerAccount if they are an existing Customer or will provision it when they become a Customer if they are not yet a customer.

This promotional Product will add Allowances or Discounts that will be applied during billing.

The modelling of the Campaign area of SID is not good – I did some work in this area a few years ago but it was not submitted to the TMForum, and so is not part of SID.

SID Q&A - Question 6

This is the sixth of a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.

This is a long and complex post in which So4It asks some very good questions that get to the heart of using the SID in the real world.

So4It:  Looking at the SID model of CustomerOrder I see the following:

1. A CustomerOrder is compromisedOf CustomerOrderItems
2. A CustomerOrderItem is-a BusinessInteractionItem
3. 0..N BusinessInteractionItem involves 0..1 ProductOffering
4. 0..N BusinessInteractionItem involves 0..1 Products

This means that we somehow are associating a ProductOffering or a Product with the BusinessInteractionItem e.g. CustomerOrderItem.

So let’s review how a CustomerOrder comes to be:  a CustomerOrder is created when a customer decides he/she wishes to purchase a product from our web page.  He/she then chooses a ProductOffering and places the order.  A ProductOffering will have 0..N ProductSpecifications and with each ProductSpecification there will be 0..N ProductSpecificationsCharacteristic(s) associated.  Right so far?

Andrew:  Remember Business Interaction Item is a multipurpose class – Product could be referenced on a Problem report.  Additionally a Customer Order can alter the state of a Product (subscription).

So far as a ProductOffering is concerned, No a ProductOffering will have 0..1 ProductSpecifications and a ProductSpecification has 0..N ProductOfferings.  A ProductOffering is the commercial representation of one and only ProductSpec and a ProductSpec can be sold as one or more ProductOfferings

So4It:  Q1: A CustomerOrderItem represents what, aProductOffering?  If so it must also hold all the ProductSpecificationCharacteristicValue(s) for all the ProductSpecificationCharacteristic for all the ProductSpecification(s) involved in the ProductOffering.  The question is then how do I know which one belongs to which ProductSpecification.

I can see that there are a couple of choices:

1. In the ProductSpecificationCharacteristicValue I place and id to the ProductSpecificationCharacteristic it belongs to and to the ProductSpecification it belongs to.  I am assuming here that 2 or more ProductSpecification might have the same ProductSpecificationCharacteristic so I cannot just assume there is a single ProductSpecification in the CustomerOrderItem
2. A ProductSpecification and for each ProductSpecification we have the selected ProductSpecificationCharacteristicValue in each CustomerOrderItem.

My question is where does the ProductOffering belong in this hierarchy?

1. In the CustomerOrderItem, and if so explain how you solve the point 1) above
2. In the CustomerOrder, what do we then do if it is a BundledProductOffering does it become multiple orders…I know that cannot be the case.

In summary to continue I need to understand how to build the CutomerOrder -->; CustomerOrderItem relationship.  And with that I mean what do I place in each of them.  I guess there will be a number of sub-classes to CustomerOrderItem.

I can even see that a CustomerOrder might contain both CustomerOrderItem that represents the ProductOffering and CustomerOrderItems that represents the ProductSpecification.  If so do we not have to keep the structure between them in any way or can we just say all these order items has to go through.

Andrew:  First of all, this diagram is taken from the “standard” SID:

What is showing is that we can say for a given ProductOffering what ProductSpecCharacteristics are being used (shown through the association ProductOfferingDetermines).  Note this is a m:m relationship so it needs to be resolved by an association class ProductOfferingProductSpecCharUse which shows exactly which ProductSpecCharteristic is being used by this ProductOffering.

The actual ProductSpecCharacteristicValues being set by the ProductOffering are not shown in SID.  This is an omission (the SID has a number of “holes” in it).

We need to extend the model

To explain this:  Imagine we have a ProductSpec for a “widget” which can coloured Black, White, or Red.  We create 2 ProductOfferings: 

1. “RedWidget” which is coloured Red, only ,
2. “MonoWidget” which can be Black or White.

So we have the following instances of the classes:

ProductOffering: MonoWidgetBox
ProductOffering: RedWidgetBox

ProductSpec: WidgetinaBox
ProductSpec: Widget
ProductSpec: Box

ProductSpecCharacteristic:  Shape
ProductSpecCharacteristic:  Colour
ProductSpecCharacteristic:  Wrapping

ProductSpecCharValue:  Shape:Round
ProductSpecCharValue:  Shape:Square
ProductSpecCharValue:  Colour:Red
ProductSpecCharValue:  Colour:White
ProductSpecCharValue:  Colour:Black
ProductSpecCharValue: Colour:Green
ProductSpecCharValue:  Wrapping:Paper
ProductSpecCharValue:  Wrapping:Plastic

ProductSpecCharUse:  WidgetinaBox:Colour
ProductSpecCharUse:  WidgetinaBox:Wrapping
ProductSpecCharUse:  Widget:Colour
ProductSpecCharUse:  Box:Shape

ProductSpecCharValueProductSpecCharUse: WidgetinaBox:Colour : Colour:Green
ProductSpecCharValueProductSpecCharUse: WidgetinaBox:Colour : Colour:White
ProductSpecCharValueProductSpecCharUse: WidgetinaBox:Wrapping : Wrapping:Paper
ProductSpecCharValueProductSpecCharUse: WidgetinaBox:Wrapping : Wrapping:Plastic
ProductSpecCharValueProductSpecCharUse: Box:Shape : Shape:Round
ProductSpecCharValueProductSpecCharUse: Box:Shape : Shape:Square
ProductSpecCharValueProductSpecCharUse: Widget:Colour : Colour:Red
ProductSpecCharValueProductSpecCharUse: Widget:Colour : Colour:White
ProductSpecCharValueProductSpecCharUse: Widget:Colour : Colour:Black

ProductOfferingProductSpecCharUse: MonoWidgetBox:WidgetinaBox:Wrapping
ProductOfferingProductSpecCharUse: MonoWidgetBox:WidgetinaBox:Colour
ProductOfferingProductSpecCharUse: MonoWidgetBox:Widget:Colour
ProductOfferingProductSpecCharUse: MonoWidgetBox:Box:Shape
ProductOfferingProductSpecCharUse: RedWidgetBox:WidgetinaBox:Wrapping
ProductOfferingProductSpecCharUse: RedWidgetBox:Widget:Colour
ProductOfferingProductSpecCharUse: RedWidgetBox:Box:Shape
ProductOfferingProductSpecCharUse: RedWidgetBox:WidgetinaBox:Colour

ProductOfferingProductSpecCharValueUse:
MonoWidgetBox:WidgetinaBox:Wrapping : WidgetinaBox:Wrapping : Wrapping:Paper
MonoWidgetBox:WidgetinaBox:Wrapping : WidgetinaBox:Wrapping : Wrapping:Plastic
MonoWidgetBox:WidgetinaBox:Colour : WidgetinaBox:Colour : Colour:Green
MonoWidgetBox:WidgetinaBox:Colour : WidgetinaBox:Colour : Colour:White
MonoWidgetBox:Widget:Colour : Widget:Colour : Colour:White
MonoWidgetBox:Widget:Colour : Widget:Colour : Colour:Black
MonoWidgetBox:Box:Shape : Box:Shape : Shape:Round
MonoWidgetBox:Box:Shape : Box:Shape : Shape:Square
RedWidgetBox:WidgetinaBox:Wrapping : WidgetinaBox:Wrapping : Wrapping:Paper
RedWidgetBox:WidgetinaBox:Wrapping : WidgetinaBox:Wrapping : Wrapping:Plastic
RedWidgetBox:Widget:Colour : Widget:Colour : Colour:Red
RedWidgetBox:Box:Shape: Box:Shape : Shape:Round
RedWidgetBox:Box:Shape: Box:Shape : Shape:Square
RedWidgetBox:WidgetinaBox:Colour : WidgetinaBox:Colour : Colour:Green
RedWidgetBox:WidgetinaBox:Colour : WidgetinaBox:Colour : Colour:White

Now how do we record the actually selected value for the product on the order?  For a RedWidget it is easy as there is no customer choice, as all RedWidgets are red.  But for the MonoWidget we need to record that the Customer selected a Black MonoWidget.

There is yet another hole in the SID model.  There is no association between OrderItem (or BusinessInteractionItem) and ProductSpec characteristic in SID – again an omission (see below).

Again we have to extend the model and add an association and association class between CustomerOrderItem and ProductOfferingProductSpecCharValueUse.  However it would probably be sufficient to put the association between CustomerOrderItem and ProductSpecCharValue, in this case “Colour: Black” as the ProductOfferingProductSpecCharValueUse has acted as a rule base to ensure that we know how the ProductSpecCharValue relates to the ProductOffering which is in turn related to the CustomerOrderItem.

This will allow us to show that our customer has ordered a MonoWidget and the characteristic value is “ColourBlack” – the OrderManager can use the rule base we’ve created to determine how “ColourBlack” is related to the ordered ProductOffering.

In my last answer I showed some (bad) XML linking OrderItem to ProductSpecCharValue by just including the required value in the nested XML – the thing about XML is that it isn’t relational – you can just included classes where appropriate without having the associations defined in the model.  Now I’ve extended the model you can just have OrderItem nesting ProductOffering and CustomerOrderItemProductSpecCharValue.

So4It:   Let’s see if I get what you mean.  The BusinessInteractionItem is indeed a multipurpose class and the CustomerOrderItem is a specialization of that.  Can you explain when the CustomerOrder and CustomerOrderItem is used since it seems to be a specialization of the BusinessInteraction and BusinessInteractionItem but it doesn't seem to introduce something new it is just an abstract class to the more specialized classes like ASR, LST, DSR and PSRs?

What I mean is do you create a lot of specialized order and order item classes for different type of orders or do you keep the more general classes like BusinessInteraction and BusinessInteractionItem?

In my API I’m thinking of having method like

 place(CustomerOrder) cancel(CustomerOrderId)

 but maybe it is better to have

place(BusinessInteraction) cancel(BusinessInteractionId)

What do you think?

Andrew:  I would forget the classes below CustomerOrder - these are specialised Orders for the USA.

If you want to create a very generic set of services, then yes you could create a place(BusinessInteraction) service and then specialise it into place(CustomerInteraction) - but it sounds like a lot of hard work, unless you are going to do things like Call-Centre management that would be handling all sorts of BusinessInteractions.  I would stick with Place(CustomerOrder).

So4It:  Looking at the relationship ProductOffering to ProductSpecification what it really is saying is SimpleProductOffering to ProductSpecification, but the problem there is that ProductSpecification can be either a ProductSpecificationAtomic or a ProductSpecificationComposite right?

In that case we get the problem I am saying that we might need multiple ProductSpecificationCharacteristicValue(s) but are you saying

1. That never happens?  What I mean is that you are saying that it always is a SimpleProductOffering always pointing to a ProductSpecificationAtomic  OR
2. Even if it is a SimpleProductOffering pointing to a ProductSpecificationComposite we just store one set of ProductSpecificationCharacteristicValue(s) no matter if 2 of the ProductSpecificationAtomic in the ProductSpecificationComposite has the same ProductSpecificationCharacteristicValue.

I remember you saying something about keep it simple one SimpleProductOffering to a ProductSpecifictionAtomic and I will I am just wondering if the thing I am describing can/will happen.

The ProductSpecificationCharacteristic has a 1..N relationship to the ProductSpecificationCharacteristicValue but it seems to be a uni-directional relationship from ProductSpecificationCharacteristic to ProductSpecificationCharacteristicValue.

This introduces a problem with the list of ProductSpecificationCharacteristicValue I have in the customer order since how do I know which ProductSpecificationCharacteristicValue belongs to which ProductSpecificationCharacteristic when there is no relationship from ProductSpecificationCharacteristicValue to ProductSpecificationCharacteristic.

Or maybe I should introduce the ProductSpecificationCharacteristic id in the ProductSpecificationCharacteristicValue to be able to map them together when I start the provisioning, or?

Andrew:   Yes, if you can keep it simple with a SimpleProductOffering related to a SimpleProductSpec that would be wonderful, but it probably won't work out that way and you will have SimpleProductOfferings for CompositeProductSpecs. But don't worry about the Characteristics.

Extending my example: imagine we have 2 more ProductSpecs - a WidgetinaBox - a composite ProductSpec made up of Widget and a new ProductSpec called Box.  The Box has just one Characteristic Shape which has 2 values "Square" and "Round".  The WidgetinaBox has a Characteristic of Wrapping which has the two values of "paper" or "plastic".

Now we can create our 2 new product offerings of MonoWidgetBox and RedWidgetBox - the customer can choose the shape of the Box and whether the composite WidegetinaBox is wrapped in paper or plastic - the characteristics all work out OK - I think.

Life might get more difficult if you reused the Characteristic Colour for the WidgetinaBox which could be say "white" or "green", but I think it still works...

So4It:  Ok, just to make it clear; this I understand.  What I am trying to figure out now is how I send the selected values with the customer order.

If I look at the ProjectSpecifictionCharacteristicValue it has a "value" attribute and a valueFrom and valueTo.

So if I decide to use a Set of ProjectSpecifictionCharacteristicValue in the CustomerOrder it means the ProjectSpecifictionCharacteristicValue that was "selected" by the user.  But in the case of a ProjectSpecifictionCharacteristicValue that says it is a range value from -to the value won’t be set. Would we then expect the caller to create the ProjectSpecifictionCharacteristicValue keeping the default settings and set the value to what he/she wants it to be.

OR

Do we just allow him/her to set a number of name/values that he/she expect to be used during provisioning.

I’m just very hesitant about to how these values are set and how I map them to the ProjectSpecifictionCharacteristic in the provisioning module if there is no relationship to its owning ProjectSpecifictionCharacteristic.

Andrew:  Let's see if I can make this clearer using the WidgetInaBox example.

In trying to make this clearer I discovered that I need to make a change to the model and moved the association class CustomerOrderItemProductSpecCharValue to link CustomerOrderItem to ProductOfferingProductSpecCharValueUse, but it really doesn't make a difference to the XML describing the Order.

A Customer orders a MonoWidgetBox he selects a Green Paper covering for a Round Box that contains a Black Widget.

So we have:

ProductOffering: MonoWidgetBox
ProductOffering: RedWidgetBox

ProductSpec: WidgetinaBox
ProductSpec: Widget
ProductSpec: Box

ProductSpecCharacteristic:  Shape
ProductSpecCharacteristic:  Colour
ProductSpecCharacteristic:  Wrapping

ProductSpecCharValue:  Shape:Round
ProductSpecCharValue:  Shape:Square
ProductSpecCharValue:  Colour:Red
ProductSpecCharValue:  Colour:White
ProductSpecCharValue:  Colour:Black
ProductSpecCharValue: Colour:Green
ProductSpecCharValue: Wrapping:Paper
ProductSpecCharValue: Wrapping:Plastic

ProductSpecCharUse:  WidgetinaBox:Colour
ProductSpecCharUse:  WidgetinaBox:Wrapping 
ProductSpecCharUse:  Widget:Colour 
ProductSpecCharUse:  Box:Shape

ProductSpecCharValueProductSpecCharUse: WidgetinaBox:Colour : Colour:Green
ProductSpecCharValueProductSpecCharUse: WidgetinaBox:Colour : Colour:White
ProductSpecCharValueProductSpecCharUse: WidgetinaBox:Wrapping : Wrapping:Paper
ProductSpecCharValueProductSpecCharUse: WidgetinaBox:Wrapping : Wrapping:Plastic
ProductSpecCharValueProductSpecCharUse: Box:Shape : Shape:Round
ProductSpecCharValueProductSpecCharUse: Box:Shape : Shape:Square
ProductSpecCharValueProductSpecCharUse: Widget:Colour : Colour:Red
ProductSpecCharValueProductSpecCharUse: Widget:Colour : Colour:White
ProductSpecCharValueProductSpecCharUse: Widget:Colour : Colour:Black

ProductOfferingProductSpecCharUse: MonoWidgetBox:WidgetinaBox:Wrapping
ProductOfferingProductSpecCharUse: MonoWidgetBox:WidgetinaBox:Colour
ProductOfferingProductSpecCharUse: MonoWidgetBox:Widget:Colour
ProductOfferingProductSpecCharUse: MonoWidgetBox:Box:Shape
ProductOfferingProductSpecCharUse: RedWidgetBox:WidgetinaBox:Wrapping
ProductOfferingProductSpecCharUse: RedWidgetBox:Widget:Colour
ProductOfferingProductSpecCharUse: RedWidgetBox:Box:Shape
ProductOfferingProductSpecCharUse: RedWidgetBox:WidgetinaBox:Colour

ProductOfferingProductSpecCharValueUse:
MonoWidgetBox:WidgetinaBox:Wrapping : WidgetinaBox:Wrapping : Wrapping:Paper
MonoWidgetBox:WidgetinaBox:Wrapping : WidgetinaBox:Wrapping : Wrapping:Plastic
MonoWidgetBox:WidgetinaBox:Colour : WidgetinaBox:Colour : Colour:Green
MonoWidgetBox:WidgetinaBox:Colour : WidgetinaBox:Colour : Colour:White
MonoWidgetBox:Widget:Colour : Widget:Colour : Colour:White
MonoWidgetBox:Widget:Colour : Widget:Colour : Colour:Black
MonoWidgetBox:Box:Shape : Box:Shape : Shape:Round
MonoWidgetBox:Box:Shape : Box:Shape : Shape:Square
RedWidgetBox:WidgetinaBox:Wrapping : WidgetinaBox:Wrapping : Wrapping:Paper
RedWidgetBox:WidgetinaBox:Wrapping : WidgetinaBox:Wrapping : Wrapping:Plastic
RedWidgetBox:Widget:Colour : Widget:Colour : Colour:Red
RedWidgetBox:Box:Shape: Box:Shape : Shape:Round
RedWidgetBox:Box:Shape: Box:Shape : Shape:Square
RedWidgetBox:WidgetinaBox:Colour : WidgetinaBox:Colour : Colour:Green
RedWidgetBox:WidgetinaBox:Colour : WidgetinaBox:Colour : Colour:White

A ProductSpecCharacteristic defines a generic characteristic that can be used by any Product Spec.  In my example there is a ProductSpecCharacteristic called “Colour” and another called “Shape”

                ProductSpecCharacteristic:  Colour

                ProductSpecCharacteristic:  Shape

The ProductSpec for “Widget” uses “Colour” but not “Shape” while “WidgetInaBox” uses both of these characteristics – (“Shape” is not relevant to “Widget”)

The ProductSpecCharacteristic “Colour” has 4 valid values as defined by ProductSpecCharValue:

                Black, White, Red and Green

But Green is only relevant to “WidgetinaBox” while the other colours are used by both Widget and WidgetinaBox as shown by the data in ProductSpecCharValueProductSpecCharUse.  Thus the value in ProductSpecCharValueProductSpecCharUse tell which of the ProductSpecCharValues apply to a given ProductSpec.

This is the end of this rather long and complex blog.