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."
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.
In the Retail POS plug-ins, you will find several interesting artifacts to use in order to create this functionality:
Therefore, in order to support the “changing salesperson” functionality, what you have to do is:
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 VesterSupport EngineerMicrosoft Dynamics AX, SCMCSS/EMEA
But how to setup up temporary object for referring. am confused in this point.
How can we use the above functionality in AX 2012 R3?
It seems that Staff field is not present in AX2012 R3. Do you know if it was deprecated or moved?
It looks that STAFF column no longer exists in R3. How to fix it?
As Mauro said, "STAFF" column no longer exists in R3.
How to fix it??
There was a bug created on AX 2012 R3 because the thought was that the STAFF and STAFFID columns were redundant, so the decision was made to remove the STAFF column from the RetailTransactionSalesTrans table.
Development did not realize how many customers use this blog to add the Salesperston to POS. A Design Request Change has been created to have Development look at adding the functionality in a future release.
One of the AX Solution Architects found a temporary work-around:
There is a temporary workaround available for demos right now without any Enterprise POS customization. This assumes Sales Person is same for all Lines.
1) Setup a Infocode in the functionality profile for “End of Transaction”. This will be prompted after all payment is done.
a. Staff – The Staff Infocode type can be used. It prompts for a Staff Number to be input. There is no validation on whether it is a valid staff number or not. The input can be marked to be printed on the Receipt along with the prompt. This is put in the comments area of the receipt as per receipt setup in the demo VM.
b. Build a Staff Sub Code List – In order for a selection to be done, a minor customization can be done in AX to periodically fill the Subcode list with Employee’s ID so that one employee can be selected. For the demo, u can fill this up with employee id using a SQL query too.
This modification isn't really needed at all, you can configure it.
There is an operation named "Salesperson" that calls this form by default. It has ID "502". But Microsoft has somehow, before the R3 version, forgotten to classify this as an "User operation" in the default "initialized" installation of AX.
They also have this fun thing when opening "Operations" form in AX that it automatically filters on only "User operations" by defauilt (CTRL + G).
So just tick in that the 502 operation is a user operation and you can add it to your buttongrids and call the form in POS. The staff selected gets added to transaction (retailtransactionsalestrans and field staff) etc and all is well in the world :)
They seem to have "messed" it up again in R3 though by removing the field "Staff" in store database, but that's another issue. Still doesn't seem like it's solved in upgrade package from 20th of march at least.