Loading
Feature Disruption - Service Cloud VoiceRead More
Feature degradation | Gmail Email delivery failureRead More
Industries Order Management
Table of Contents
Select Filters

          No results
          No results
          Here are some search tips

          Check the spelling of your keywords.
          Use more general search terms.
          Select fewer filters to broaden your search.

          Search all of Salesforce Help
          Parent-Child Relationships in Decomposition with Top Order Item Scope

          Parent-Child Relationships in Decomposition with Top Order Item Scope

          For parent-child relationships to exist among technical products in decomposition, there must be a clear relationship in the catalog between the two technical products. There must also be a clear decomposition relationship between the commercial and technical products.

          When thinking about parent and child relationships in decomposition, there are two main concepts to think about:

          • Technical products that are supposed to have parents must be modeled in the catalog to have those parents.

          • Source (parent) products and decomposition relationships must be organized in a way that clearly identifies the parent of the technical product. (More on that later.)

          So why do you need BOTH concepts, instead of just one? Or, put a different way, if you've already set up a technical product to have a parent, then why do you have to worry about any other organization? Can't OM assign a parent based on that information?

          Well, it's not that easy, because you can model a product to have many parents. For example, let's say that we have a technical product X, which has been modeled so that it could have a parent A or a parent B. Then there's an order with both A and B in it. What happens? Which one becomes the parent of X?

          Industries OM looks to see whether the product that decomposed into X also decomposes into one of the possible parents of X. In this case, that's either A or B, because X is modeled to have either A or B as a parent.

          • If the source product (that is, the one that decomposes into X) also decomposes into A, then A becomes the parent of X. If the source product decomposes into B, then B becomes the parent of X.

          • If the source product doesn't decompose into any of the possible parents, then OM makes the same check with the parent of the source product. And ITS parent. And ITS parent, looking for whether any of them decompose into either A or B. If so, then it can assign either A or B as the parent of X.

          • If neither the source product, nor any of its parents up the hierarchy, decompose into either A or B, then X does not have a parent. It's just an independent item.

          In the following image, the source product that decomposes into X is S1.1. So OM checks whether S1.1 or any of its parents (S1, Offer, and so on) decompose into A or B.

          S1.1 doesn't decompose to either A or B. Neither does its parent. But the parent of its parent (Offer) does decompose into A. So A becomes the parent of X.A chart shwing decomposition as described in the text: S1.1 decomposes to X, and A becomes the parent of X.

          Here's another image. In this one, neither S1.1, nor any of its parents, decompose to either A or B. So X is independent.

          A chart showing what's described in the text: Neither S1.1, nor any of its parents, decompose to A or B, so X is independent.

          And one last image. In this one, the item that decomposes into X also decomposes into A. So there's no need to look further: A is the parent.

          A chart showing what the text describes: One commercial product decomposes to both A and X. Therefore A is the parent of X.

           
          Loading
          Salesforce Help | Article