Circular Reference

[sanjeev]

Hi, I'm getting circular reference problem in the module. How do I resolve it? Here is the problem List called Material (3 sublist for FG, SFG and RM) #Number list called BOM (has Properties as Parent Material, Child Material and Quantity) Module 1- RM Rate (use RM subset list) and has 1 line item Rate (input field) Module 2 - BOM Calculation (use #BOM) with following line items Parent Material - pulled from #BOM.Parent Material Child Material - pulled form #BOM.Child Material Rate - if Child Material = RM then pulled from Module1.Rate else Module3.Rate[lookup:child material]  ----> This gives circular reference. Qty - pulled from #BOM.Quantity Cost - Rate * Qty Module 3 - SFG Rate (use SFG subset list) and has 1 line item Rate (calculated field) Rate = Module 2.Cost(sum:Parent) How do I solve this issue?

[peter_mcanena]

Hi Sanjeev, The problem is that Module 2, Rate is defined in terms of Module 3.Rate, but Module 3.Rate is itself a sum of Module 2.Cost, which is defined as Rate * Qty. So you're defining Rate in terms of itself, which doesn't make sense. You need to give Anaplan a rate to work with, instead of asking it to calculate it in a circular formula. Could you add an input item Child Material Rate to Module 1 and pick it up from there? Pete

[sanjeev]

Hi Pete, The issue is that I have a rate master for only child materials. And for child materials (which are also parents) the value needs to be derived from the cost of all the child materials of that parent. Ex Product A needs 2 units of Product B Product A needs 3 units of Product C Product B needs 5 units of Product B1 Product B needs 3 units of Proudct B2 Product B1 needs 4 units of Product C1 Product B1 needs 2 units of Product D Now, the rate master is only available for products C, B2, C1 and D as they are the lowest material (and not parents) To get Product A price, we need to get price of B. To get price of B we need to get Price of B1.  Further, the issue is compounded as the customer is not willing to make a hierarchy of products (the rollup of materials). How do we solve this problem then? Regards Sanjeev

[peter_mcanena]

I see. So there isn't really any circularity in your pricing logic because it rolls up in the hierarchy. In that case you need to implement the hierarchy, because otherwise Anaplan will detect a circular reference. You know there won't be any circularity, because you're planning to make sure the prices always resolve to master rates, but Anaplan doesn't know that. A hierarchy is how you guarantee to Anaplan that your calculations are not circular (because the logic always flow up the hierarchy, never down). It sounds as if there is a genuine hierarchy of materials, & this hierarchy is an intrinsic part of your pricing model...so you won't be able to calculate the pricing without the hierarchy. Why does your client want to stop you doing this? Could you build the hierarchy for the purposes of calculating the pricing, but then also have a flat list of materials for the purposes of reporting? You'd need actions to keep the two in synch with each other, and a lookup to get the material prices from the hierarchy into the lists.

[sanjeev]

Thanks Peter for your message. The client has genuine requirements of not loading up the hierarchy. As part of their planning process, they keep changing the parent child relationship on the go to see the impact of the cost roll-up at the top level. A flat structure ensures that the change needs to be done for only 1 record and it impacts all parents which may have this child as part of its hierarchy at any level.  What do you recommend for makign a hierarchy and yet have the flat structure? How will actions help? Look forward to hearing from you. Thanks again for responding. Much appreciated. Regards Sanjeev

[harish_bk]

Hi Sanjeev I guess peter meant this but am not sure 1) Create a hierarchy or materials with base members having prices and parent members having the rates aggregating 2) Create the materials flat list and use it for costing purpose 3) List number two have a property to derive material cost (Property be list formatted and the list be the first hierarchial list and value being the list item) 4) link the cost module to hierarchy list used module and lookup by the property to generate cost of each material 5) This way you would have cost of the materials Hope this is correctly understood

[sanjeev]

Hi Harish, Thanks for the reply. Not sure I have understood this completely. If you have the time, can you please elaborate pls? Thanks

[harish_bk]

Hi Sanjeev First I would like to confirm if my understanding is correct: 1) You have material B12, B1, B2 and B 2) Hierarchy would be as below: List item                             Parent B                                         A B1                                       B B2                                       B B12                                     B1 So to get the cost of materials use the above list and derive cost of each material. 3) Have a flat list with Items A, B, B1, B2, B12 so on and have a property called cost derivation 3a) Have the property list formatted with the hierarchy material being the value 3b) Give the values as below: List Item                                Cost Derivation A                                             A B                                             B B1                                           B1 B2                                           B2 B12                                          B12 3c) Then use this flat list in a module and derive costs from first list and this list using lookup 3d) Then you would have the components required in BOM and derive the total costs Hope this helps. Thanks and Regards Harish B K   

[peter_mcanena]

Hi Sanjeev, First of all, yes, Hamish is thinking of the same solution I am. However, it sounds like you probably want to have the flat list as your main list - so that would be your current Material list. Then you want a second list called something like Material Hierarchy. To populate this list, create an action that copies the data from the main Material list into the Material Hierarchy list, with the parent coming from the Parent Material property (and all the other properties going into matching properties in Material Hierarchy). You'll have to run this action any time the structure of the list changes, or any times are added or removed, or any of the properties change. Once you've got this hierarchical version of the list set up, you can rewrite your modules, Module 1, Module 2 & Module 3, to use Material Hierarchy instead of Material, and then finally your formula for Cost can be taken from these hierarchical modules using a lookup. Keep the names and codes of the two lists exactly the same so your lookups are simplified. One thing to be careful of is that using simple properties to define the structure of a hierarchical list doesn't do any error-checking, so you need to be careful that the user doesn't create loops in the parent-child relationships. For example A's parent is B, B's parent is C and C's parent is A. Secondly, instead of importing directly from Material into Material Hierarchy, you could consider setting up a module based on Material and then defining a view on that module to do your import from. This allows you to have different versions of the import, validations to prevent duplication and so on. It's a bit more work but it's good practice.

[peter_mcanena]

Couple of other things: It looks like the Child property is not in use, or it's just being used to identify when a material has no parent material. You could simplify this by just checking if Parent is blank. Then you won't need the Child property, and you reduce the scope for data errors, which is important given that you're bypassing Anaplan's native hierarchy functionality. Secondly, you may want to use a module to hold the parent & master cost data, if the users are going to be managing that data themselves.