Inconsistent Behavior of the Description in Part and Serial Object screens

I think you are asking for a setting to control what should happen in this case, or a more clever business logic and a field where we store information about that the serial object description was changed manually and should not be overwritten if the part description changes. It's in the gray zone between being a bug and an enhancement request in my view. How about creating an idea in the Ideas section here on IFS Community to get this looked into?

Hi @Buddhika Kurera ,

General idea is that Serial object which is basically a maintenance aware part serial should always be consistent with its respective serial part. Therefore the description of the Serial object should always be the description of the part. As you correctly pointed out if the corresponding part description is changed, its part serials and serial object descriptions are changed. 

However the description of the serial object/part serial should not allowed to be changed to have this consistency across. Because if the serial object description is changed(which essentially is changing the description of its part) then descriptions all of the serial objects/ part serials created with this part should be changed.  Currently in IFS Cloud due to a defect in our system its allowed to change the serial object description in some of our pages(In APPS10 IEE serial object descriptions are not allowed to change) . 

 We can consider this as a defect and fix it to go back to the correct behaviour(not allowing to edit the serial object descriptions) but that might not help with the customers requirement 😀.

Regards,
Asitha 

@Asitha Rajapaksha Thanks for looking into this, I ll send a task. If we can freeze the Description field in the Serial Object page then it is also a solution. As you correctly mentioned that is how APP10 works.

in addition to my above comment,

if there is a requirement to differentiate between serial objects created from the same part, it’ll be better to use a data field other than description to indicate the differentiation. (Notes, technical data or any other general field depending on the nature of the differentiation) 

From what I can see after a recent update, changing the description of individual serial objects is no longer possible. I can’t help but disagree with the reasoning behind it. In my opinion it worked the way it was supposed to and the latest change is currently causing big issues in our use case.

When several practically identical objects are created they may be based on the same master part. During the creation process they are differentiated by a serial number and their individual object ID. The initial description is imported from the master part but in case of the original behaviour the description of each individual object could have been changed later. Personally I believe description is definitely a place where each individual serial object should be differentiated, therefore the old behaviour was correct.

Description is one of most basic fields that is present in pretty much all screens, which is very handy. Trying to tell apart serial objects by some additional field is really inconvenient, impossible in a lot of screens and would require implementing that new field in those screens individually, which is not always so simple. For example the screen for reporting a problem has very few fields available when expanding the search window and description is one of them. Since object description is present in most places, using it to differentiate objects allows You to always easily distinguish them. Having well thought out descriptions telling You all the frequently needed information is much more convenient than having it scattered across all sorts of different fields which are not even always readily available.

You may have 3 identical roller conveyors manufactured by ABC of XYZ model. You can create a master part named “Roller conveyor ABC XYZ” and then further differentiate them by adding something like a number or other descriptor. As a result You end up with something like “Roller conveyor ABC XYZ 1”, “Roller conveyor ABC XYZ 2” and “Roller conveyor ABC XYZ 3” which makes it much easier to identify specific object that You want to report a problem on. You may even have the same conveyors used in different production lines and may want to add some indicator of which line they are a part of or any other kind of information that You may frequently need across all screens. In current version You will end up with 3 different objects with identical descriptions and no easy way of telling them apart other than knowing their exact object IDs or looking it up on different screens containing extra information.

Another argument in favour of the old solution is that it is possible to achieve the current functionality by simply blocking the ability to edit those fields in respective screens, making it impossible to change individual descriptions if that is ever an issue in your organisation. Furthermore if any inconsistency appeared, fixing it is as simple as just changing the description of the master part which overwrites all object descriptions. You can’t achieve the old behaviour right now in any way because it is disabled on some deeper level. In our case we relied on the ability to modify the descriptions of each object and the recent patch really is just a huge hindrance for us at the moment.

I do not consider the old behaviour a bug and I think changing such an important functionality just to solve a problem for some of clients, which could have been solved in a much simpler way without changing anything in the program is wrong, especially if it causes much bigger issues for others which can’t be fixed so easily. If possible I would appreciate reverting back to the old behaviour and simply informing users of how to block the ability to edit certain fields if it is a problem for them.