One level of usage is a structuring of the customer according to his “business language”. Think about a hospital with different departments, each of them is using certain expensive equipments.  So you may do an Ibase for the hospital with subnodes (text type) for the different departments. You may also do different Ibases for them or even use objects from type functional locations for this)

•    The second level is collecting all the items, which belong to an department. This means you put all of them on the same level, as the items are physically independent. E.g. a machine/computer to analyze blood is independent from a machine to make a picture of bones
  

•    The third level is a – is part of – collection in physical sense. It covers which part is build in.  Any time the main object is moved, also the parts in it are moving also.
  

For the first and second level text components, ibases or functional location objects can be used as header. The difference is now on level 3.
One scenario are structured objects, may be even several levels, with a rather stable structure. E.g. elevators, traffic lights, buildings in general. Here is the use of ibasetyp 01 appropiate, as the leading object itself is rather complex/broad structured, but the user starts mainly with the top object. The one visible Ibase is not a problem. (actually the lot of empty ibases during data transfer and building up the structure, might be an issue, but I haven’t heard complains about this).
The other scenario are mass objects, with a limited structure. Actually the structure is mostly one level, as everybody knows where the subparts are. E.g. a vehicle with it’s motor, a cellphone with the sim card. For those the ibase type 03 was designed. The maintenance of such ibases is integrated in the CRM-UI for objects.

We had constellations, where removing and adding parts in ibase type 01 could result in illogical structures. But I have to search for this document. Nevertheless the maintenance of the Object structure 03 in the object maintenance ensures a certain overview with the one level. For example is it hard to add a second engine on the second level, which might easily happen in a ibase of type 01.

Sent: Friday, September 05, 2014 8:07 PM

we still stick to category 03 for the object structure.

There are several reasons for that:

1.       If you use different installation categories for the customer installation and the object structure you are able to hide 03 from the installation search (customizing). From our perspective this is mandatory because the installation with category 03 is only a technical installation for linking two objects to each other. If you use 01 for linking the objects this is no longer possible.
   

2.       An object structure is displayed in the object’s ‘Components’ and ‘Object Structure’ Assignment Block whereas in your case the is no longer possible.
   

3.       User handling is different.
   

The installation plays an important role for us because the customer wants to have a comprehensive overview of the customer’s installation. The installation contains more than just the objects. It also contains the information where it is installed. The following is planned:
Installation XY à there is one for each ship-to party
Text Component ‘blue room’ à describes the room where the equipment is installed
Object component à contains the connection to the parent object
Text component called ‘not yet assigned’ à contains the objects that belong to the ship-to but it is not known where it is installed
This information is used in Interaction Center and is needed to identify the objects. Usually the customer that calls in does not know the serial number but talks about ‘the chair in the blue room’. We talk about dental assistants that call in. They are not familiar with the technical information of a chair. So they don’t know where the SN is.

So the call center agent gets the information ‘chair in the blue room’. He/ she goes through the installation and once the installation is up-to-date he/ she will find the right object. On the other hand we have contract determination in use. Here it is possible to cover the whole installation instead of a single object. Furthermore there are reports based on installation.

Next think is partner determination in a service order which bases on the installation. We maintain partners in the installation header as well as the address and we use the inheritance of partner and address information. As long as we use the object component in a service order the system will be able to determine the installation and the object. So we have everything we need in the service order. The customer is maintained in the object, too. We read the ship-to from the equipment (parent) that is downloaded to CRM and try to find a corresponding installation. If there is an installation the new equipment will be assigned to text component ‘not yet assigned’. The technician on site will tell us where the Equipment is installed. Then it will be moved to an appropriate text component.
Since HENRY SCHEIN isn’t the only service provider. So there can be parts in a chair that weren’t installed by HENRY SCHEIN but HENRY SCHEIN wants to offer a service for it. That’s the situation a new object has to be created manually in CRM.