As for the existing functionality its not possible to change the site of a functional object through “Move Functional Object”. Please refer to the comment in
Maybe you can add this as an idea to be considered by the product management
Regards,
Asitha
Thank you Asitha,
think that that the copy Functional Object is a not acceptable feature since it creates multiple objects with the same name in many sites. My customer is now facing administrative challenges and this will not make their job easier setting objects out of operation etc.
I have reached out to R&D with this matter and am keeping my fingers crossed for a solution.
Regards,
Johanna
I fully agree with @Asitha Rajapaksha on creating an idea here. By the way, what is the use case for your customer? How frequently do they move functional objects between sites, and what are the reasons for these moves?
We would appreciate a detailed explanation to better understand this.
@jopsse
If you can find a good triggering point (when the parent machine code, or parent equipment object sequence changes), perhaps you can get what you want using a custom event plus an event action or workflow? In a workflow you can even ask the user for the new site.
And, as others have said, please create an idea for this here on IFS Community, where you explain as much details as you can on why this is needed, for what, used by who, etc.
Good luck!
I fully agree with @Asitha Rajapaksha on creating an idea here. By the way, what is the use case for your customer? How frequently do they move functional objects between sites, and what are the reasons for these moves?
We would appreciate a detailed explanation to better understand this.
Hi Mayura and thank you for reply!
My customer will use sites to figure as a geographical district where Functional Objects will work as locations;
(Superior) Geographical District → Station District → Individual Station → Employee
Below each Individual Station we will create Functional Objects that will figure as a employee.
Each employee will then have serial objects connected to them (operational gear, materials that needs to be tracked). The object structure has a large importance to be able to mobilize employees with certain capabilities (will use Object Type) and specific operational gear connected to them.
Since the Functional Objects are employees - they can move around within the site or other sites. Some operational gear (serial objects) might follow in the move, some will be moved to inventory.
The operational gear will have PM Actions connected to them since they have different cycles of service (3 year functionality check etc).
Hope my explanation is clear enough to be comprehended.
Regards,
Johanna
@jopsse
If you can find a good triggering point (when the parent machine code, or parent equipment object sequence changes), perhaps you can get what you want using a custom event plus an event action or workflow? In a workflow you can even ask the user for the new site.
And, as others have said, please create an idea for this here on IFS Community, where you explain as much details as you can on why this is needed, for what, used by who, etc.
Good luck!
Hi Mathias and thank you!
This can be a solution since my customer will have central resources that are going to maintain the application on a more superior level. The customer does not have enough resources or competence throughout the whole organization so if the Move Functional Object functionality would work the same as Move Serial Object - then I think the admin work would be accepted and understood.
Have a happy monday!
Regards, Johanna
I fully agree with @Asitha Rajapaksha on creating an idea here. By the way, what is the use case for your customer? How frequently do they move functional objects between sites, and what are the reasons for these moves?
We would appreciate a detailed explanation to better understand this.
Hi Mayura and thank you for reply!
My customer will use sites to figure as a geographical district where Functional Objects will work as locations;
(Superior) Geographical District → Station District → Individual Station → Employee
Below each Individual Station we will create Functional Objects that will figure as a employee.
Each employee will then have serial objects connected to them (operational gear, materials that needs to be tracked). The object structure has a large importance to be able to mobilize employees with certain capabilities (will use Object Type) and specific operational gear connected to them.
Since the Functional Objects are employees - they can move around within the site or other sites. Some operational gear (serial objects) might follow in the move, some will be moved to inventory.
The operational gear will have PM Actions connected to them since they have different cycles of service (3 year functionality check etc).
Hope my explanation is clear enough to be comprehended.
Regards,
Johanna
Thank you for the explanation, @jopsse. This seems to be a rather uncommon way of mapping objects. 
However, what is the purpose of maintaining the Employee as a Functional Object in this context? Can an Employee also be treated as a Serial Object with Child Serials, such as operational gear or materials that need to be tracked?
I fully agree with @Asitha Rajapaksha on creating an idea here. By the way, what is the use case for your customer? How frequently do they move functional objects between sites, and what are the reasons for these moves?
We would appreciate a detailed explanation to better understand this.
Hi Mayura and thank you for reply!
My customer will use sites to figure as a geographical district where Functional Objects will work as locations;
(Superior) Geographical District → Station District → Individual Station → Employee
Below each Individual Station we will create Functional Objects that will figure as a employee.
Each employee will then have serial objects connected to them (operational gear, materials that needs to be tracked). The object structure has a large importance to be able to mobilize employees with certain capabilities (will use Object Type) and specific operational gear connected to them.
Since the Functional Objects are employees - they can move around within the site or other sites. Some operational gear (serial objects) might follow in the move, some will be moved to inventory.
The operational gear will have PM Actions connected to them since they have different cycles of service (3 year functionality check etc).
Hope my explanation is clear enough to be comprehended.
Regards,
Johanna
Thank you for the explanation, @jopsse. This seems to be a rather uncommon way of mapping objects. However, what is the purpose of maintaining the Employee as a Functional Object in this context? Can an Employee also be treated as a Serial Object with Child Serials, such as operational gear or materials that need to be tracked?
You are quite correct there Mayura, this customer is quite rare of its kind and are sprung out of that they have upgraded from App 10 to Cloud. They have only been using the Supply Chain module and Customer Order but are now taking on several functional areas of the application in use (such as Finance, B2B, HR, Asset & Maintenance, Call Center...)
The employee will be customer, object and employee, and not all of them will be placed in an object structure. The object structure will mirror the organizational structure and function both as place holder for serial objects but also as a quick way to find resources when mobilizing task force for crises, planned events etc. So not all employees will be created as an object.
We chose to create Functional Objects with connected serial objects because its more comprehensible to the customer and that we dont need to create a dummy article for them. The customer is confused enough 
We might reconsider this, but for now this is our working theory.
Even if they are unique, I think that the function for moving a Functional Object could be adjusted and work the same way as for moving a serial one :)
Regards,
Johanna
Yes, we need to align movement behavior where necessary. However, it's important to understand that Functional Objects and Serial Objects are two distinct concepts, each with its own characteristics. Therefore, behaviors may differ between them.
