Featured Post

Dynamics GP 2018 is now Released

It is officially published that Microsoft Dynamics GP 2018 is available, the download link is provided below: Product download page ...

Thursday, August 6, 2015

Considerations for Sales Person and Territory


There has been a recent question on the Dynamics GP community discussing the objectives of using sales person and territory. The concern was primarily about how to use them, and how they actually work. The concept is to be comprehensively illustrated in this post, along with suggestions made on MSConnect by MVP Leslie Vail for a better functionality.

Master Details - Setup 
Initially, it is important to understand the setup cycle of sales persons, territory and their relationship with the customer card. 

The sales person is configured from Cards > Sales > SalesPerson. 
 
Sales Person Setup Window
When configuring a sales person card, the territory field is a required field that should be filled, you cannot save a sales person unless it is linked or assigned to a specific territory. It is a one-to-one relationship which implies that one sales person can not be assigned to multiple territories on the setup level.
Setup - Sales Person and Territory relationship 

On the other hand, Sales Territory is defined from Cards > Sales > Sales Territory. 
Setup - Sales Territory
It must be noted that the sales territory can have a territory manager, while the assignment of the territory-salesperson is defined on the sales person level.On the customer card, there are two fields to setup the salesperson and territory, by default, these values are inherited from the sales person card, which can be modified on the customer card level.


Sales Transaction Entry - Default values for Sales Person and Sales Territory

When entering a sales transaction, and picking the customer from the predefined customer list, the default sales person and territory filled on the customer card will be automatically inherited into both the header and details of the transactions (technically speaking, SOP10100 and SOP10200)

In order to check the sales person and territory assigned to the header level, click on the arrow next to the customer number field, in order to open the Sales customer Detail entry window. Technically speaking, this is stored in SOP10100. On the other hand, to check which the same details for each line item, click on the arrow next to the item number field to open the sales item detail entry window which shows the sales person and sales territory assigned to this line item.
Sales Transaction Entry Window

In this essence, it is a important to visualize all these details in one diagram that shows how setup and transaction are designed in terms of inheritance and default values. The diagram below summarizes all these details accordingly
 
Sales Person and Territory - Default Values Diagram
Issues and Suggestions:
In a previous post, I have illustrated a critical issue which occurred when integrating sales invoices through eConnect, the sales person and territory were only imported into the header table (SOP10100) not the detail (SOP10200), the resolution was provided through SQL code to make sure that there is consistent data stored in these two tables.

Another issue which was brought up by MVP Leslie Vail on the community, is not to update the sales territory field when changing the sales person field, the system automatically brings the default territory assigned to the sales person on the card level. The suggestion made implies to provide some sort of configuration or setup which controls the ability to either inherit the master data or not. The suggestions can be found on Stop changing my Territory when I change Salespersons on an Invoice - MSConnect Suggestion.

Furthermore, I have found another critical issue which needs a look from Microsoft Support team, the issue is that the sales transaction window allows you to change the sales person and territory on the header level, and these changes are not rolled down to the line items which already exists on the transaction. I am adding this to the suggestion made by Leslie above, in order to be taken into consideration.
Here are the details of the posted invoice with inconsistent salesperson and territory details,the solution provided above can solve this issue on the database level.
Sales Header and Details - Territory is not inherited

Your vote matters 
Best Regards, 

3 comments:

  1. Excellent post, Mahmoud. This functionality in Dynamics GP is often misunderstood and so your explanation is very much needed and appreciated. If I may, I’d like to add one additional piece of information to your post. As you have outlined, a single salesperson can be automatically assigned to sales transactions using Dynamics GP functionality. For instances where more than one salesperson receives commission, your options become limited. For example, it is very common for a Territory Manager to be assigned to a Territory; an experienced sales professional who supports one or more salespeople on increasing sales in a particular geographical area. Companies who have Territory Managers have a need to default more than one Salesperson to sales transactions. Third party products, like EthoTech Commission Plan, can assist with this requirement, allowing for automation of multiple salesperson assignments per sales transaction and even per sales transaction line item. Thanks again for your insights!

    ReplyDelete
    Replies
    1. Thanks John for the valuable information, the power of such third party products can definitely enhance the functionality of Dynamics GP and provide more powerful capabilities and features.

      Delete
  2. Hi,

    I need to do Salesperson (GP) to ERP System User (CRM) integration by using scribe.
    But while connecting with scribe not getting Salesperson data object,could you please help me here .

    Thanks

    ReplyDelete