Daisy Channing?

Hello there

Does Daisy Channing refer to referencing a calculated line item in a different module only or it also applies to referencing a calculated line item in the same module as well?

Case 1: Referencing a calculated line item in another module

Module A

Line Item A.1 = ITEM(List)

Module B

Line Item B.1 = Parent(Module A.Line Item A.1)

Case 2: Referencing a calculated line item in the same module

Module A

Line item A.1 = Item(List)

Line item A.2 = Parent(Line item A.1)

Accepted answers

nathan_rudman

I confirm that for the engine, modules don't exist.

Ideally, what you have highlighted in yellow is wrong, but START() being a very simple and efficient formula it might be better than creating a reference to a line item.

I don't know if this one has been tested before.

Misbah

@einas.ibrahim

What I meant by that was "Calculations that happen in SYS modules" including START()

Here is my POV of the below set of formulae as to how these should have been written. First three green and last two red for me. If the calculations have already been performed by the engine I will never repeat it

First Day of Month = START()

Last Day of Month = END()

Current Period Start = CURRENTPERIODSTART()

CurrentPeriod? => Current Period Start = First Day of Month

Actual Period = First Day of Month < Current Period Start

DavidSmith

@Misbah

Since you named dropped!!

@einas.ibrahim We are re-working Planual to iron out any ambiguities, and yes, the wording here could lead to some confusion but hopefully this will clarify things

Rule 2.02-03 actually says "No Repeated Expressions", and really applies repeated elements within a formula, and in a lot of cases repeated expressions solely contained within the same module. As outlined above if the formula is using the same constructs so something like START(CURRENTPERIODSTART()), or Sales[SUM:Store Details.Category], these shouldn't repeated time and time again for the same dimensionality. We often we similar line items with almost identical formulae, especially in nested IFs. It is better to split out the relevant line construct to a separate line item (as per 2.02-18)

Don't daisy chain (2.02-19), really applies to when the same initial data point is being referenced by a module, then another module points directly at that line item, and then another line item points to that line item. It is more efficient to point all line item to the ultimate source line item(to allow parallel processing)

So, yes, there is an element of "it depends", as with most of the rules, but I do think the rules can co-exist and both have their place

I hope that helps, and thanks for the engagement

David

All comments

Misbah

@einas.ibrahim

I don’t think engine understands the diff between inter module or intra module daisy chaining. Wherever it is in the model, if the engine is doing the job more than once it will fall under the daisy chaining. That’s my understanding of it.

einas.ibrahim

Hi @Misbah

Thanks for the response. I did think so as well until I found a pattern within examples in the training material that made me question that.

Look at this screenshot for example:

The Line Item Actual Period? is dependant on the Line Item Current Period Start (Blue Highlight)
At the same time if we don't reference an already calculated Line Item, then we are writing a formula more than once (yellow highlight), which means taxing the engine as well.

So which way is it? This made me feel that I may not be fully understanding Daisy Chaining.

Any thoughts?

Misbah

@einas.ibrahim

I think when it comes to any calculation without data or simply SYS module calculations we do it once and then refer it multiple times within a model (Calculate once refer many times- Zen of the Planual). Basically an expression should not get repeated.

On the other hand Daisy chaining would mean when one line item with data in it gets referenced in subsequent/further line items creating dependencies and any change in the source line item has a ripple effect on dependent line items. This does not allow engine to run calcs in parallel which may degrade performance.

Planual Explained Article on Daisy chaining:

https://community.anaplan.com/t5/Anaplan-Platform/Planual-Explained-Day-23/m-p/73436#M14862

Hope I didn’t confuse you more

einas.ibrahim

Hey @Misbah

Thanks again.

What do you mean by "calculation without data" ? do you mean something like START() in the screenshot I provided?

If that's the case, then according to your answer, If I need to reference the start date of a period in a CALC module, I would use the following formula?

1. Line Item = START()

instead of
2. Line Item = SYS Module.First Day of the month ??

Wouldn't #1 mean we are repeating the formula?

I don't think we are disagreeing on the theory, my question is just a bit nuanced and perhaps I'm not clarifying enough.

How about this... let's just focus on the difference between the 2 ways of writing a formula on the screenshot below. What's the difference (pros/cons) between writing the formulas as highlighted in yellow and that which is highlighted in blue?

I have a couple of theories but I'm looking for a confirmed answer

nathan_rudman

I confirm that for the engine, modules don't exist.

Ideally, what you have highlighted in yellow is wrong, but START() being a very simple and efficient formula it might be better than creating a reference to a line item.

I don't know if this one has been tested before.

Misbah

@einas.ibrahim

What I meant by that was "Calculations that happen in SYS modules" including START()

First Day of Month = START()

Last Day of Month = END()

Current Period Start = CURRENTPERIODSTART()

CurrentPeriod? => Current Period Start = First Day of Month

Actual Period = First Day of Month < Current Period Start

einas.ibrahim

@nathan_rudman

Thank you, I agree.
I also believe the Best Practice are guidelines and following one or the other highly depends on many other factors like -as you said- the complexity of the formula, the size of the model, the number of list items involved in the calculations ..... etc

I asked the question just out of curiosity and to make sure I am not missing a concept.

I just feel that the 2 concepts (Best Practices) :

1. Don't Daisy Chain and 2. Don't repeat a formula
Can't exist together for every case, because by definition "Don't Daisy Chain" means to write the root formula again. Can we at least agree on this?

In the language of Management Consulting, this is not MECE 😁 [Mutually Exclusive Collectively Exhaustive]

Einas

einas.ibrahim

@Misbah

Thank you very much.
I appreciate your engagement and thinking about this with me.

As I said in my reply to Nathan, I think to Not Daisy Chain or Not Repeat the Formula are one of these "it depends" cases.

If I find more clarifying information, I'll make sure to come back and post it. 🙂

Misbah

@einas.ibrahim

Can't exist together for every case, because by definition "Don't Daisy Chain" means to write the root formula again. Can we at least agree on this?

I disagree. "Don't daisy chain" doesn't mean to write the formula again. It means to go back to the ultimate source and not the intermediate source. For example If I have data flow of A->B->C->D->E, this is an example of daisy chain. Rule says you should do below

A->B

A->C

A->D

A->E

On the other hand we have Rule which says Calculate once reference many times. We all agree to that point and there is no debate or discussion on that. But these two rules can co-exist. That's my opinion on these two rules. How I miss @DavidSmith & @rob_marshall expert advice here

DavidSmith

@Misbah

Since you named dropped!!

@einas.ibrahim We are re-working Planual to iron out any ambiguities, and yes, the wording here could lead to some confusion but hopefully this will clarify things

So, yes, there is an element of "it depends", as with most of the rules, but I do think the rules can co-exist and both have their place

I hope that helps, and thanks for the engagement

David

einas.ibrahim

@DavidSmith

Thank you very much for your response and clarification. I look forward to the new Planual. 🙂

DavidSmith

Planual 2.0 for the digital world - It's going to be great 😁

Misbah

@DavidSmith

Thanks for dropping by and clarifying.

Quick Links

Can you help?

Unanswered questions

OData Rest API for
Hi, Does anyone know how to get an outbound OData Rest API, (OAuth2) to establish a connection between SAP and Anaplan. Thanks Khaled
Looking for Anaplan End-Users to take a short survey!
We are looking for Anaplan end-users to provide feedback on their experiences with the Excel add-in. Interested individuals will respond to this 5-minute survey to help us understand personal needs and behavior when using the add-in. The feedback provided by survey takers is essential to the roadmap of Anaplan's products.…
CERTIFICATION BADGES - ANNOUNCEMENT
Anaplan Champions! The Community team just posted this announcement that certification badges may not be showing up on your profile probably until next year. Rest assured, you will get credit once you complete and pass the exams. https://community.anaplan.com/t5/Blog/Badges-Back-Soon/ba-p/123385