By "same names", I suppose you meant "same codes". As the catalog entities (nodes/entries) are identified by codes, so the code must be unique across catalogs. If you have a node with code "Hello" in catalog A, but you are importing catalog B, and there is a node with code also "Hello", then the new node will override the old one, and that would mess up with the relations. 

How come Catalog Management UI doesn't mess up the existing nodes?

Can you confirm it's same codes as I supposed? They both use the same APIs internally, so it should be the same. However ServiceAPI support upload chunks and that can cause some different.

If possible can you post screenshots of how do you catalog structure look like, in (supposedly) working and faulty case?

Yes, I was thinking about the codes. Tax-free is the existing one and Netthandel is the new one.

Here is the Catalog Management UI result on dropbox.

Here is the Postman Service API result on the same node, but if I navigate to parent node of the new one I get this result. You can see that all the products and nodes are just pilled up without the structure.

That's strange. ServiceAPI will always overwrite duplicates, while you might not select "overwrite" in Commerce Manager. So I think the results must be the way around ...

That means I have no good explanation for the issue - you should contact the developer support service. 

You, are correct. In Catalog Manager I did not select to overwrite nodes. Postman version just pile up products and variants.. Thanks. I will contact them.

I talked a bit with my colleague Steve (I assume you have been in contact with him) - and it does make senses now. In Commerce 11, we introduced the concept of IsPrimary concept, so you can specify the "primary" node for an entry. 

• When you upgrade to Commerce 11+, the "current" parent will be selected primary.
• When you import via ServiceAPI, because the default option is to overwrite, and because you didn't specify the primary node in your catalog import file, it will clear out current primary nodes. Entries without primary nodes will end up in catalog.
• When you import via Commerce Manager, because you didn't select overwrite, the existing nodes are left untouched, and therefore all the node-entry relations remain. 

The fix in this case is to update your import file (inRiver?) to add IsPrimary = true to the NodeEntryRelation. 

EDIT: this is an example of why you should include the version in the question. The behaviors might change over versions, and having a version number will remain us on those changes, and you'll get faster, more accurate answers.

Okay.. I see that there should exist IsPrimary set to true in the NodeEntryRelation.

Scenario is like this: For every product there is exactly one variation below it. Relations are defined as follows:

<NodeEntryRelation>
     <EntryCode>11901</EntryCode>
     <NodeCode>Champagne</NodeCode>
     <SortOrder>0</SortOrder>
</NodeEntryRelation>
<NodeEntryRelation>
     <EntryCode>734599116056</EntryCode>
     <NodeCode>Champagne</NodeCode>
     <SortOrder>0</SortOrder>
</NodeEntryRelation>

This sets both product and its variation so they belong to Champagne node. 

Next piece of code:

<EntryRelation>
     <ParentEntryCode>11901</ParentEntryCode>
     <ChildEntryCode>734599116056</ChildEntryCode>
     <RelationType>ProductVariation</RelationType>
     <SortOrder>1</SortOrder>
</EntryRelation>

defines that variation is bound to that product. 

Where exactly should IsPrimary be set to true? In the first NodeEntryRelation element? The one that defines actual product entry?

In this case both NodeEntryRelation can be IsPrimary (and actually, they should, you want the product and the variant to be in same category, don't you). IsPrimary is unique per entry, not per node. 

Just to verify some things:

When using service API you are using the import/catalog endpoint? No CRUD operations involved?

Did you try to do the same import in the UI with overwrite enabled? What result did you get then?

Yes, I was using that endpoint without any CRUD involved. I can't give you the answer right now regarding the 'overwrite' option because there were some breaking changes in our model. I will get back soon.

So,

the original idea was to have a new catalog imported from inRiver next to the old one. Having the same products so that editor could manualy move newly added products to the existing product. New decision is to have it overwritten during the import in case there is any change in PIM,

I have added IsPrimary to all the <NodeEntryRelation> tags and it still behaves funky on first import - when there is no catalog imported at all. Using the Postman and Service API I get mangled up catalog and using the Catalog Manager UI catalog imports nice. I did contact develop support and provided them with catalog.zip. They are working on it.

I would suggest you to contact our developer support service and file a support case. If we can have a direct look at the catalog import file and your database, it should be much quicker to identify (and even fix) the problem.