Sales

Get Involved. Join the Conversation.

Topic

    Martin Cryer
    Is Geography data essential for including geography as a...Answered
    Topic posted August 5, 2014 by Martin CryerBlue Ribbon: 750+ Points, tagged Configuration, Sales Performance Mgmt 
    253 Views, 14 Comments
    Title:
    Is Geography data essential for including geography as a territory dimension?
    Summary:
    There doesn't seem to be any benefit of importing geography data, other than enabling that dimension for territories
    Content:

    We are defining territory based on ZIP in the United States, on Territory (Manitoba, etc.) in Canada; and on Country in the rest of the world.

    I am not very concerned about correct address entry.

    United States and Canada Nokia geography data  has been imported, but do I have to import geography data for EVERY country in the world?

    Thanks for any help you can give,

    Martin Cryer

    Best Comment

    Francis Chang

    Hi Martin,

    Before you go too far down, I'd like to provide you with some best practice guidance.

    It is important for you to understand, conceptually, the difference between what we call the Master Geographies hierarchy and the Territory Geography hierarchy.  Master geographies are the geography elements that are standardize, such as zip codes, counties, states, countries, etc.  Territory geography hierarchy is a hierarchical structure of the geography data that is maintain strictly for the purpose of defining territories.  Territory geography hierarchy is typically a smaller subset of the overall master geographies hierarchy and has the ability for you to create non-standard geography elements (for example, Regions for the US such as Northwest, Southeast, etc...are non-standard since different companies can define them differently) - this is the Zone geography that you mentioned below.

    Some best practice guidance:

    1. Keep your territory geography hierarchy as simple as possible.  This is to minimize the data maintenance as well as to improve the user experience for users that are defining territories through the UI.  Customers typically should only include geography elements in the Territory Geography hierarchy to those levels by which they want to define territories.  For example, even though for the US, the master geographies contain Zip - City - County - State, if you only define territories at the Zip Code level and never at the City of County levels, you don't need to include City and County in your territory geography hierarchy.  Just go directly from Zip Code -> State -> Country (US).  I'd keep the State level so that the data is easier to navigate through the UI.  With Oracle Sales Cloud, you can define territories using zip code ranges.

    2. Set up territory "Zone" geography only if it's necessary for your business.  Keep things simple.

    3. As a best practice, always consider aligning your territories at the higher level of the geography structure.  It is much easier to maintain your territories using 52 different state codes as opposed to 40,000+ postal codes. 

    Good Luck.

     

     

     

     

    Comment

     

    • Raphael Weber

      Yes you need to import the master geographies/nokia data for each country in which you want to assign your accounts on a zip code basis. The alternative is to enter or import the geographical master data manually (on a zip code level that is one *** of a job). If you're fine with country level assignment (as states in your question) then it's sufficient for "the rest of the world" to just enter/import the country into the master geographies. then the accounts will get assigned to the country-level territories provided that each sell-to address of your account has the correct country set correctly.

       

      Raphael

    • Martin Cryer

      Thank you for your comment. That is very good news for 'the rest of the world'. What steps do I need to follow, please, to enter or import the countries we do business in to the master geographies?

      Martin

    • Raphael Weber

      Could you check Setup Task "Manage Geographies" and search for the countries. If your lucky your instance may have seeded the country data already.

       

      Raphael

    • Martin Cryer

      OK, yes they are already there,, that is a blessing:) Thank you!

      Martin

    • Francis Chang

      Hi Martin,

      Geography data is required primarily for two reasons

      1. Use as Geography dimension in Territory definition
      2. Enable LOV and validate geographical elements in address e.g. state, city, postal code

      If both of these are not requirements for certain countries you do business in, there is no need to import geography data for those countries.

      Please let me know if you have any further questions.

    • Martin Cryer

      Hi Francis,

      I'm not too worried about LOV or validation.

      The real issue is the Geography dimension. I do want to use the Geography dimension in Territory definition. In the United Sates, it will be by ZIP (postal) code. In Canada it will be by Territory (Quebec, etc.). For both of those countries I've imported the Nokia geography data so there is no problem.

      However, for the rest of the world, our territories will be defined by country. The country names already appear to be seeded (see posts above). I don't need more geographical detail than that. But, the question I have is: can I go ahead and still use teh geography dimension if that is all that is entered for those countries?

      Rapael's post above indicates that I do not need to import additional geographical data for those countries and I can still use the geography dimension for territories.

      Martin

    • Raphael Weber

      Hi,

      actually it is a little more complicated. Master data is one thing. Having the master data alone won't enable you to select these values in the geography dimension. Other setup tasks and a load/activation of dimension members is necessary in order to do that. And than you might have to deal with so called "zones" which are different from master geographies. For the LOVs it may be necessary to activate them (along with validation) if you want the assignment manager to properly assign your sales accounts.

      Please keep in mind that Territory Management setup involves some critical choices and quite some setup that in some cases may be irreversible. For instance, once (Nokia) master data is imported and being used there is no way to do a proper import for the same country again.

      In case you have never setup territory management in Fusion before, I would highly recommend that you seek professional advise before you setup a companywide territory hierarchy.

       

      Thanks,

      Raphael

    • Francis Chang

      Hi Martin,

      Yes, we have confirmed that territory assignment at the country level will work without having to load the geography data for those countries.

      As Raphael pointed out above, you still need to ensure that all the necessary setup steps are performed to get the proper geography values into Territory Management, in particular all the countries that you want to enable territory assignment must be included in the territory geographies setup (which is separate from the master geographies).

      Francis

       

    • Martin Cryer

      Hi Francis and Raphael, thanks for your guidance.

      I am following the Oracle Sales Cloud - Getting Started with Your Implementation - Release 8 - April 2014 guide, so hopefully that guide will take me through the other required steps.

      Thank you for the advice to get professional help, Raphael. I do have a contract with Oracle Consulting Services, but I have not used them yet. My Managing Director prefers me to do teh implementation myself as much as possible. Although I took the 'Implementation' and 'Extensibility' Oracle University classes, this is proving to be extremely difficult.

      The good news is that I am using the TEST environment to learn, and that it is completely disconnected from the production environment.

      At this moment, I am thinking I will perform the implementation in TEST, and then ask Oracle Consulting Services to review it and make any recommended changes for the production implementation.

      Martin

    • Stephen Barkley

      We thought about zip-code based assignment for the US but did not go through with it. There were a few reasons why: 

       

      1. Zip codes change all the time 

      2. Zip codes do not represent an geographic area, they represent a group of addresses. That means they can overlap, and span other geographic elements which brings me to point ....

      3. Since (last I checked) all the geography is in an hierarchical format, zip codes ARE NOT. They span cities, counties and in a few cases states. I have no idea how you would do this accurately in Fusion. 

       

      $0.02

    • Martin Cryer

      Hi Stephen,

      Points taken. However I need to do this as our real-life territories are based on zip codes in the United States.

      I believe I will need to create what are called 'zones'. I believe these are groupings of master geographies that can be insrted into the territory hierarchy.

      Martin

    • Francis Chang

      Hi Martin,

      Before you go too far down, I'd like to provide you with some best practice guidance.

      It is important for you to understand, conceptually, the difference between what we call the Master Geographies hierarchy and the Territory Geography hierarchy.  Master geographies are the geography elements that are standardize, such as zip codes, counties, states, countries, etc.  Territory geography hierarchy is a hierarchical structure of the geography data that is maintain strictly for the purpose of defining territories.  Territory geography hierarchy is typically a smaller subset of the overall master geographies hierarchy and has the ability for you to create non-standard geography elements (for example, Regions for the US such as Northwest, Southeast, etc...are non-standard since different companies can define them differently) - this is the Zone geography that you mentioned below.

      Some best practice guidance:

      1. Keep your territory geography hierarchy as simple as possible.  This is to minimize the data maintenance as well as to improve the user experience for users that are defining territories through the UI.  Customers typically should only include geography elements in the Territory Geography hierarchy to those levels by which they want to define territories.  For example, even though for the US, the master geographies contain Zip - City - County - State, if you only define territories at the Zip Code level and never at the City of County levels, you don't need to include City and County in your territory geography hierarchy.  Just go directly from Zip Code -> State -> Country (US).  I'd keep the State level so that the data is easier to navigate through the UI.  With Oracle Sales Cloud, you can define territories using zip code ranges.

      2. Set up territory "Zone" geography only if it's necessary for your business.  Keep things simple.

      3. As a best practice, always consider aligning your territories at the higher level of the geography structure.  It is much easier to maintain your territories using 52 different state codes as opposed to 40,000+ postal codes. 

      Good Luck.

       

       

       

       

    • Martin Cryer

      Hi Francis,

      thank you for your advice! I am new to this and appreciate everyone's help.

      Your tip that it is possible to define territories with zip code ranges is huge, thank you! That eliminates the need for zones. I'm all for simple!

      As far as keeping the states is concerned, if we do keep this level, i.e. zip code > State > Country (US), what happens in those cases that Stephen mentioned above (about 300 zip codes) that span across state boundaries? (This occurs mainly in Cincinnati and El Paso.)

      I will be the one adjusting territories per the managers' requests; so I am inclined to leave states out to avoid any problems with that.

      Martin

    • Raphael Weber

      The topic you brought up is an interesting one.

      If your leaf-level territories of your sales reps are defined based on zip code level then you have to ensure that the geography of each parent territories includes all geographies of the child territories. This means if there is a leaf-level territory that has a zip code that spans across different states the parent territory must include both the states. Otherwise you will get invalid territories because the dimensional coverage of the child territories is larger than the coverage of its parent. This in turn leads to another problem, because on the level of the parent territories you will find peer territories having the same states assigned, which will be considered as an overlap.

      As I mentioned earlier, territory management can get very complicated and is not only about completing setup tasks. It is about critical decisions and the structure of your data you enter.

       

      Thanks,

      Raphael