Short answer: In blueprint view, change any List (under the Applies To column), Time, or Versions for your line item so they are different from the overall settings for the entire module.
A module is a cube defined by dimensions such as Lists, Time, and Version. I don't like the term "subsidiary view" and find it confusing or, at best, not very descriptive. When I teach the 102 class, I tell students to think of it as a "cube within a cube" ... the line item has its own set of dimensions that may or may not match those of the module that contains it.
Thank you for the quick reply! I have a list called Territory and i want this line item to be of Territory North America which is in my list. When I change the "Applies to" to List -> Territory, it gives me this error and I can't figure out why.
But let's also understand the error message. You have a bunch of Line Items with formulas that are doing a Lookup on the Territory line item. Your module is dimensioned by Strategic Customer (not by Territory). Switching Territory (line item) to "Applies to: Territory (list)" is confusing the poor thing.
I assume you've got a Territory-to-Strategic Customer assignment mapped somewhere in you model (in a list property or in a module line item). If so, you probably want a formula that will figure out what the assigned Territory is for each Strategic Customer. If that is the case, leave this poor line item's Applies To alone and use a formula such as Strategic Customer.Assigned Territory to go find the information you desire.
Why do you need to make it a subsidiary view? We see this a lot, creating subsidiary views in multiple modules which leads to the same formula being kicked off from multiple modules. I assume you have a composite list with accounts rolling up to an owner, and those end up rolling up to a Territory, and so on. What I would recommend is havign a properties module at the lowest level (Account) with different line items for different parts of the hierarchy (Account Owner, Territory, Region, etc). That way, the formula is only kicked off one time, but many other modules can share that formula. Also, when other module builders need some information, instead of re-creating the same line item multiple times, they can very easily link to that properties module.
So, long story short, but it would be very helpful to see/understand the list structure to help you further.
You are exactly correct. I have a list of accounts that roll up to an owner and this module i pictured holds the accounts quotas. THe module is currently all zero and if i make the Territory line item a subsidiary view, i think it might populate the quota numbers. I have another module with the same logic and the Territory as a subsidiary view and the numbers are populated. I've attached picture of my list (CaptureList.PNG) that the module is built on.
Ok, I think I know what you are attempting to do, but in order to accomplish this, it depends on your codes within the Territory hiearchy. Do you know who you manufactured them, how the account is tied to the Territory? Hopefully, you guys used the Territory "_" Account code (the NAxxxx) code. If so, you don't need to do a lookup, but rather a sum after you create a line item (at the Account rolling up to the Territory hierarchy) that links back to your Strategic Accounts.
So, the key difference between Lookup's and Sum's: Sum's allow you "sum" over line items from a module as long as you sum over a list formatted line item where that list formatted line item correpsonds to your target module. A Lookup, on the other hand, only allows you to lookup information where that data is on the outside of the "house" (think rows, columns, or Page Axis). So, I can do 'Module1'.data[lookup:Territory] IF module 1 is dimensionalized by Terrority.
I'm not sure if this is working because they are already on Sum. For ex, I have these line items with Weight % and it looks up by Territory. They are displaying 0. In another module, they display numbers with the Territory subsidiary view.