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.

sanjeev

Hi Peter,

Thanks for your reply. I'm trying to build out the hierarchy using views as you suggested. Not been completely successful there. 

One question though. If a child item is going to be used in multiple Parent item, how do I load the hierarchy so that it goes and sits in all parents as a child list item.

peter_mcanena

So a child can have multiple parents? That complicates things.

Is there a maximum number of parents (say, up to five) or do you need to support an arbitrary number of parents? Also, can a material have multiple children as well as multiple parents? That would make it a many-to-many relationship, which can't be modelled in a hierarchy.

sanjeev

Well. Its a Bill of Material. So a parent can have multiple children. And each children can have multiple children underneath. So multiple Finished Goods/Semi Finsihed Goods can have the same child ingredient. 

In a flat structure it only shows as a single record.
Ex
StartFragment EndFragment

Parent	Child
A	B
A	C
A	D
B	B1
B	D
B	C1
B1	B11
B1	E
C	B1
C	E
C	F
A1	B
A1	C2
A1	F1

As you can notice above, Finished Goods A and A1 both require B. Now, how do I build this hierarchy to ensure that B goes into both A1 and A.

harish_bk

Hi Sanjeev

This looks bit complicated to me too, let me try to see if this should solve it

1) Identify maximum number of processes required to manufacture a material
2) Based on number of processes required group the materials accordingly into subsets
3) Then create The material mix modules for each level of process and call only those materials which are part of that process
4) Have a numbered list in those modules and line items BOM, Materials requried
5) Let BOM be the End product (List formatted with that particulare level), Material required to produce (Total materials list formatted)
6) Cost of the materials : Let this be a look up of the previous level processes modules
7) Have final cost module to do a sum if of all the materials from all the material mix modules

This is very lengthy process but would surely work.

peter_mcanena

In that case I'd use a numbered list to define the relationships, which the user would enter, and then I'd have your Material Hierarchy as a second numbered list. So you end up with these three lists:

• Material
  
• Material Relationships (numbered list with two Material properties called Parent and Child, plus any additional information about the relationship, such as how much of the child material goes into the parent material)
  
• Material Hierarchy (similar to the Material Hierarchy I talked about yesterday, but as a numbered list, permitting a child material to appear under multiple parent materials)
  

The action to populate Material Hierarchy should now run off a module dimensioned by Material Relationships, and you should clear out the Material Hierarchy list before each import. And you may also need a separate action to insert materials that don't appear in the relationships list.

Everything else should work as I described before.

Good luck!