Microsoft Dynamics 365 Blog


The payment of commission for services or products sold is a common way to reward sales people.

The purpose of this blog post is to provide some guidance and inspiration as to how one might go about customizing the Retail POS to link different POS transactions to different sales people in order for these to earn commission.

It is important to note that any code suggestion or samples included in this post adhere to the following disclaimer:

“Microsoft provides programming examples for illustration only, without warranty either expressed or implied, including, but not limited to, the implied warranties of merchantability or fitness for a particular purpose. This article assumes that you are familiar with the programming language that is being demonstrated and the tools that are used to create and debug procedures.”


What is included in Standard Retail POS?

First, it is important to know that in standard Retail POS there is no “set salesperson” operation. There is a “Clear salesperson” operation but this is currently of little use, according to the following TechNet article:

The article refers to a table that lists the operations that a staff member can perform in Retail POS. Below is a snap shot of said table:



This somewhat limits the possibilities of action and forces you to customize a bit if you wish to have added functionality within this area.

Adding functionality

In the Retail POS plug-ins, you will find several interesting artifacts to use in order to create this functionality:

  •  In the C# classes, you can use the salesperson properties of the retailTransaction (header of the transaction) and the saleItems (lines of the sales transaction) objects
    •   If the salespersonId is set for example, it will be saved in the Store database (and that’s interesting)



  •  In the Store database, you have in the RetailTransactionSalesTrans table a column which defines the salesperson (column name is Staff)
    •   Note that for Staff and StaffId, it’s basically: StaffId is for the operator (the one who takes your payment) and Staff is for the salesperson (the one who shows you what clothes are cool on you)
    •   This field Staff will be populated if you’ve set the SalesPersonID property on the sale items as I mentioned before:



  •  In Retail POS plug-ins projects, you can find a form (called LSRetailPosIs.POSProcesses.frmSalesPerson) which shows the staff of the store and which can be used to get the salespersonId




Therefore, in order to support the “changing salesperson” functionality, what you have to do is:

  •   Create a blank operation which will show the staff form
  •   Affect the salespersonID of the salesperson which was selected to the retailTransaction and the saleItems of the retailTransaction
  •   Customize the ItemTriggers to make sure that you update every new item added to the transaction


Note that if you want to be able to do it before a transaction is started, you have to create a temporary object, which will be used as a reference every time a sale item is added.

In the end, when you run the P-* Job, you will get the salespersonID in the sale lines of the transactions and be able to analyze that.


A big thanks goes to Christopher Lim – Associate Consultant, Center of Excellence – for providing the content for this article.


Thank you for your attention!

Eric Vester
Support Engineer
Microsoft Dynamics AX, SCM


We're always looking for feedback and would like to hear from you. Please head to the Dynamics 365 Community to start a discussion, ask questions, and tell us what you think!