Move serial object between IFS companies

  • 23 October 2020
  • 8 replies

Userlevel 7
Badge +18

We are bringing a new Chinese company online in IFS in a couple of weeks and have discovered that there are a dozen or so serial objects that were created in our UK company even though the machine was installed in China and is serviced by our China company.  We need to move the serial objects from one company to the other, but the move serial object function is intersite within the same company.  Copy serial object would be a fine alternative, but it isn’t allowed because it sees the object as a duplicate.  We can’t create the equipment with new serial object IDs because the serial number on the system doesn’t physically change, it is just connected to the wrong functional object.

I’ve tried:

  • Move serial object
  • Copy serial object
  • Delete object from functional object (not allowed due to connected work orders)
  • Create Component Repair Order in an attempt to return the system from one customer site and into inventory, then issue to the new customer but in a different company (this didn’t go very far without issues)

I’m stuck as to where I can go from here and wonder if anyone else has ran into this issue.  I realize it won’t be a common occurrence.


8 replies

Userlevel 4
Badge +9

Hi Shaun ( @ShawnBerk ),

I have a sledgehammer suggestion for you - could you raise a (zero value) Purchase Order from Chinese to UK company (they would be the supplier) and transfer the serial items inter-company like this?



Userlevel 7
Badge +18

Hi Shaun ( @ShawnBerk ),

I have a sledgehammer suggestion for you - could you raise a (zero value) Purchase Order from Chinese to UK company (they would be the supplier) and transfer the serial items inter-company like this?



@pwlm Thanks Pete, I’m willing to use a sledgehammer at this point, but could you please elaborate on that suggestion a bit?  The serial object is currently connected to a functional object which represents the service site, I would need to get it back to stock so it could be supplied on the corresponding customer order that would like to the purchase order.  That would all work, but I haven’t figured out how to get it disconnected from the functional object and into inventory.  That was my intent with the CRO, but that got stuck at the disconnect point also.

Badge +4

Good afternoon,

I’m wondering whether this solution eventually resolved your issue, I have a very similar request and am trying to understand the best route forward. Getting the Serial object into stock to be used with the CO does seem to be my problem also.

Any advice you can impart would be most welcome.

Many thanks,


Userlevel 7
Badge +18


No, actually none of the suggestions has worked and we even went so far as to attempt to have a Db admin change the data at the table level - to no avail.  There is no way we’ve found that works to transfer serial objects between companies.  In the end, we chose the very inelegant solution to require our China office to recreate the serial object with an additional character or space so it shows different to IFS, but is still the same object ID visually.  Time was against us to come to a solution as work needed to be recorded against some of the items that needed moved.

Userlevel 4
Badge +8

Hi @ShawnBerk 

It’s good that you could sort-out this with a workaround.

Just to add some inputs into this discussion, the requirement to create new serial object in new Site/Company, it can be done using customer order for a new part serial No. Please refer following link.

But IFS application is incapable of handling moving of a serial object between sites/companies while maintaining same object ID/serial No. There are some limitations to overcome when delivering a solution for this issue such as,

  • Since the site is a crucial part of the key for an object and its ownership, changing it might loss the tracking information of a serial object.
  • Changing the site may affect functional flows and analysis data such as financial transactions, material transactions, PM actions, WO and Historical WO.

Source : Case G2129368

Userlevel 7
Badge +18

Yes, unfortunately, it doesn’t account for the fact that some of our customers buy our equipment, set it up in one country and we do work orders against it in that site and company.  Then later, the customer decides to move that exact same machine to another country where from our perspective it is a different IFS company.  So a real world situation that IFS doesn’t handle or account for.  I wouldn’t even call our solution a work around.  It is a fabrication that requires someone remembering that they have to look up the connected Serial Object from a connected Functional Object, the admin person can’t type in the serial object ID from the field paperwork because the extra character only exists in the new object.  It isn’t real.  It is not a good solution, but given it is about 12 objects out of over 10000, it was not worth pursuing further.  We just live with the fact that at times, there is an error that the serial object doesn’t exist if it was typed in, when it is plainly found on a lookup because the user can’t know it is different.

Userlevel 4
Badge +6

In addition to all those solutions and ideas, I’d suggest that to raise this matter to the RnD Idea Wall. They might consider this as a new feture or keep this as a limitation. 

Userlevel 3
Badge +6


As many other Customers we have the exact same issue. I can’t find the RnD Idea wall, but if I could, I would want to post something like this. If someone has access, please be inspired by below.


As IFS is often branding itself on their capabilities within service and maintenance and as an enabler for global growth, it is peculiar, that basic multi-site/multi-company functionality are retaining a major architectural flaw, namely that Serial Objects are forever linked to the site & company in which they were originally created. (From here, assume sites are in different companies)

While a Part Serial can be naturally moved from site A to site B, the Serial Object remains connected to site A subsequently to this move.

Let’s reflect upon the consequences of this:

  • Users in site B will after the A->B move of the part serial, not be able to see/edit the subordinate structure of the serial object and related documents etc. without full access to site A. 
  • Users in site B will not be able to create work orders on the moved object or its subordinate objects. That is,  they will not be able to conduct preventive or corrective maintenance without access to the site of origin.
  • As the Serial Object is linked to the site of origin even after being sold to a customer, service and maintenance on that object are only possible for users with access to said site of origin. This means that service engineers must have access to all production sites in order to perform their daily job. As the Serial objects after a sale are no longer owned by the selling company and can be moved around in the world as the customer desires, there are no reason that the Serial Object should be associated with as it is (even though a “softer” connection to the “site of origin” could make sense)

The Site field on Serial Objects are obsolete as the Object ID in itself is sufficient unique identifier for the object. As Serial Objects by definition are something which can be moved around between sites, should the Site relations on a Serial Object naturally follow the Part Serial in order to keep logistic - and Service/maintenance dimensions aligned.