Hi @perchristianb ,

Have you looked at using the Copy Part functionality under the Part Master Data?

You’re able to copy a lot of information from an existing part to another part.

Regards,

William Klotz

This is an excellent use case for replication jobs! 

hi @perchristianb 

You mention “IFS Data Migration”, but are you familiar with the specific type of jobs procedure name = Replication, which are intended for exactly this?

The copy part functionality is good when you copy a few parts, but in my case it’s over a hundred. Also I have to consider potential changes to existing parts later and then I think the replication functionality could be better. 

Thanks for all answers! I will now investigate more around Replication. 

This is what Assortments can be used for.

=====================================================================

Assortments and Site Clusters

The possibility to mass create parts for many sites dramatically facilitates for companies that have many parts, many sites, and short product life cycles. It reduces the amount of work required for part creation to a minimum. It provides a possibility to centralize the initial setup of parts. In addition, it reduces the risk of inconsistent data between sites, since the data is initialized from one single source.

Assortments and site clusters form the foundation for a successful mass creation of parts. Remember, assortment in this context is your company's assortment, and should not be confused with the assortment of your supplier.

Assortments and site clusters are two different types of structures. These structures consist of nodes; ordinary nodes as well as part or site nodes. Ordinary nodes are not connected to a part or a site; they are mainly building blocks for building the structure. A part node is a node connected to a part catalog part while a site node is a node connected to one of your user-allowed sites. A part or a site node is always the lowest level in a structure. This means that a part node or a site node cannot be a parent to other nodes. Within one specific assortment or site cluster, each node has a unique identity. This means that the same node identity can exist several times in the database but only once in the same assortment or the same site cluster. Consequently, a part can only exist once in the same assortment and a site only once in the same site cluster. You can create as many assortments and as many site clusters as you want. Furthermore, you can create extensive structures with as many nodes as you want in each structure.

You start to define your assortment and your site cluster and build your structures. Remember that it is optional to create a site cluster; i.e., it is possible to eventually create many parts for many sites without having a site cluster defined. At the bottom of the assortment, you connect part catalog parts. When you do this, so called part nodes are automatically created; one part node per part. You can choose to either connect already existing part catalog parts, or create and connect new part catalog parts. If you choose the latter, it means that you automatically create a new part in part catalog. At the bottom of the site cluster, you connect user-allowed sites. When you do this, so called site nodes are automatically created; one site node per site.

To facilitate the use of the structures, it is important to enter levels. The assortment levels and site cluster levels are shown in several places in the application. The level makes it easier for you to understand the hierarchy and to orient yourself when working with the assortments and the site clusters. All nodes will be automatically assigned to the correct level when the nodes are created or when the nodes are moved. This means that you do not connect nodes to levels; it happens automatically.

Before creating parts per site, you need to enter defaults. Defaults can be entered on any assortment node; ordinary nodes as well as part nodes. Defaults entered for a parent node are also valid for all sub-nodes in the whole branch below. However, defaults can be overridden by defaults entered further down in the branch. To facilitate the entering of defaults, you will see all defaults entered for a parent node when you are working with a sub-node. You can only enter inventory part characteristic defaults if a node or a parent node in the assortment is connected to a characteristic template. The template strictly defines for which characteristics you are allowed to enter defaults. All defaults are entered per site, site cluster node, company, country, or a combination. Site has the highest priority and can never be combined with the other three. The priority between the four fields is: site, site cluster node, company, and country. The company is the company connected to the site; the site for which the background job will try to create parts. The country is the country defined on the delivery address connected to the site; the site for which the background job will try to create parts.
 

Hi Steve, this sounds very interesting to me, we are looking for a solution like this. Is there more information with any examples? Or a video or other information?

Thank you for your feedback!

Regards Martina 

Reading the documentation I was able to progress:

Connecting parts is possible from right mouse menue in the node.

After 2 hours I was able to create at least inventory parts and purchase parts...

Great approach, this distribution! Thank you for your hint, Steve :-)

Regards Martina

Create a migration job of type ‘Replication’ and set the trigger to your original part loading site, and destination to all other sites you want. You will have to create replication type mig jobs for Purchase Part, Supplier for Purchase Part, Inventory Part etc.

I’ve blurred the To Value List for privacy..

I was looking for Community resources to address a development I am thinking of , then I came across this useful thread, thank you all. When we have Incoming Customer Orders through internal sites sometimes let’s say the Sales Part is not present in the receiving site. To Address that I thought we’d use any of the suggestions @william.klotz, @Steve_IFS and @malik.sally suggested. Let’s say my Technical colleague comes up with an event in IFS to copy inventory part first from the sending site, then create a Sales part when the Incoming CO is approved. Please let me know if you think this is a stupid idea :) 

@EnzoFerrari I believe you would want to use a custom event for this. You would want to check a number of conditions on the incoming order. Inventory part, sales part, sales part cross reference, what about pricing? 

Yes @Steve_IFS , I meant a custom event to be triggered at the time of approval. Inventory Part and Sales Part of course. With regards to Sales Part Cross Reference, the Customer’s Part No will be the same as newly creating Inventory / Sales Part No due to our internal standard to maintain same part IDs. Do you think that’s going to cause an issue? 

With regards to the price, we do have an object property defined whereby the PO’s Price / Base value will be 5% less than what’s filled in the ‘Cost’ column of the external CO. So the same price from the PO will go to Sales Price of the newly creating Sales Part. That’ll do right? :)

@EnzoFerrari just wondering what is stopping you’ll from proactively replicating the sales parts, rather than wait for a customer order to kick in and create the sales part. Is it simply because of the volume of data that you’ll are going to end up with?

@malik.sally , nope we do have a cost advantage when sourcing through the headquarters. And the demand site has unforeseen external demands, meaning they may create sales parts all of a sudden, inventory part creation is not centralized, hence they might not create them in all sites. So this has been identified as a need