Jump to content

Contract Types - more than 2 levels


Martyn Houghton

Recommended Posts

@Martyn Houghton

It would be possibly to expand these, but I purposefully limited it to two levels we could create a usable UI in terms of filtering, two levels seemed to be a good choice.  Also my experience with SM, the more levels of profiling you have the more unusable the data put into the profile codes becomes, people generally struggle with creating good quality hierarchal data models - just look at anyones shared network drive for an example :) . Changing this would be quite complicated but I fear would also make it more user unfriendly for customers who do not need more levels so I am wondering if there are alternative ways of solving the problem you are trying to solve?   Perhaps we need to add the notion of a "Division" to the data model for example.  Maybe you could describe your data needs in more detail so we can explore other possibilities?

 

Gerry

Link to comment
Share on other sites

@Gerry

In terms of the UI, I was wondering why a different presentation/selection method was used compared to the tree component used elsewhere where profiles are used?

We have number of different part so the organisations (Divisions as you term them) using a common instance, with more coming on board.

Each Division will have a number of different products, which will be expressed as one or more Services depending on the licensing options chosen.

Each product will potentially have  one or more contract types, i.e. On-Prem, Hosted, Rental, Capital, or even custom site specific ones etc

Hence why we where looking at a more deeper level breakdown.

My ultimate aim is to have all our support contracts within Hornbill with the appropriate linked service subscriptions and said service subscriptions status is dictated by the status/validity of the assoicated contract. Some of which is covered in my earlier post below.

Cheers

Martyn

Link to comment
Share on other sites

@Martyn Houghton


 

Quote

In terms of the UI, I was wondering why a different presentation/selection method was used compared to the tree component used elsewhere where profiles are used?


Ok I think I see what you are saying. The problem here is stemming from the fact that when we designed the contracts data model we did not every have an intention of expanding the type/sub-type, we used the profile codes as a "convenience" to reduce the need to build a separate administration interface for managing types and sub-types, its was never intended to create a multi-level hierarchical filtering/organisational scheme for contracts.  The fact we have used the profile codes I can see has led you think we done something different, what we done was took a short-cut for implementing the administration of types and sub-types. 

Internally we sub-divide further using the contract name and have a naming convention to support that.  It feels instinctively wrong to use profile code scheme to encode things like divisions, products and so on.  This is why we refer to the filter options as "type" and "sub-type" rather than profile code or any such other term. 

How many levels do you envisage you would use? would not not be better to add an "organisation" filed which maps to the organisations, then your types and sub-types map to products and contract types?

I am very hesitant to introduce a variable unstructured hierarchy here for the same reasons its always been a mess in profile codes relating to tickets

Gerry

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...