Dynamics AX for Retail is a retail software that integrates point of sale (POS), retail store management, and ERP all in one solution. I am assuming you all understand how it works (atleast from functional point of view). It’s implementation includes four separate applications.
1) Dynamics AX for Retail Headquarters is managed and implemented in AX. It is designed to run at the head office. It has three modules in AX.
- Retail Headquarters module is used to configure and manage stores, terminals, staff, retail items, promotions, gift cards, retail sales transactions and other records.
- Retail Scheduler module is used to synchronize data between head office (AX) and stores / terminals.
- Retail Store Inventory is used to send store inventory documents to stores to use for receiving inventory for a purchase order, picking or receiving inventory for a transfer order, or counting stock for a count order.
2) Dynamics AX for Retail POS is a .Net touch screen application having its own local database to work offline during network interruptions. This can be fully customized for any type of business and store procedures. This is what we are going to cover in this article.
3) Dynamics AX for Retail Store Connect is a windows service that sends data between the head office, stores and individual POS terminals.
4) Dynamics AX for Retail Transaction Service is again a windows service that is also a part of communication mechanism of Dynamics AX for Retail. For example; this service is used to authenticate the cashier logon credentials etc.
Customize Retail POS: After going through this article you should be able to modify or extend existing POS functionality.
|Plug-ins folder structure.|
When you download plug-ins you will get C# source code for services and triggers as well as the required documentation. Download also comes with a some .Net tutorials and a developer’s guide to customization.
Services: Services are actually .Net assemblies. POS implements many of the features as services using interfaces and can be modified using Visual Studio 2008. POS loads these services at run time by calling the interfaces. So whenever you modify or extend the standard service keep the assembly name same as original so that POS can recognize it and call it at run time.
Each service provides a specific feature in POS. There is a special service called Blank service. This service can be used to implement custom operations and can be invoked using the Blank operation.
NOTE: You can modify or develop new business logic or new touch screen forms when talking about customizing the POS. Logic is written in C# and should not be a big thing for a C# developer. In order to create touch screens Microsoft uses third party controls from DevExpress. You need buys a license of a specific version (126.96.36.199) of DXperience WinForms for Retail April Refresh R2.
Triggers: Triggers are called before and after the operations. There are two types of triggers, Pre-triggers and Post-triggers. Pre-triggers provide a way of validation before a certain operation is executed. Post-triggers are used to respond to an operation after it has finished. You can modify the triggers same way as services.
Below are the tasks we going to perform in this session to customize POS.
- Create a new table in POS that already exists in AX. POS database is actually a slimmed down version of AX database. All the POS tables also exists in AX as well.
Create the required table in AX first then just open the SQL Server Management Studio and copy the Create SQL Script for this table. Now, go to your POS database (AxRetailPOS) and run this script to get the exact schema as your AX table. We need to keep table schema same at both side for data synch.
- Write AX Retail Scheduler job to synch data between AX and POS database.
You will use AX Retail Scheduler module to setup data synchronize jobs. AX uses these jobs to synch data between POS terminal and AX headquarters.
- Create an operation and POS button in Button Grid (Tasks) in AX. Attach your operation with the button.
You define your custom operation in AX which is then linked to a POS button. All custom operations are handled through the Blank operation.
AX > Retail Headquarters > Setup Define a button on button grip. Set operation id to Blank Operation. Right click to set button attributes. Define properties you will see in BlankOperations.dll
When you click on this blank operation bound POS button, at run time POS calls Blank operations service (BlankOperations.dll). You can modify this service and check if it’s been called with operation attributes you provided in AX.
Blank operations service (BlankOperations.dll) can be modified from the “Retail POS Plug-insServicesBlankOperations” folder. For this, create a .Net C# Class Library project for this folder and do required modification for your custom operation. This Blank operation service only contains one class called BlankOperations. This class only has one method,
public void BlankOperation(ref BlankOperationInfo operationInfo, ref PosTransaction posTransaction)
operationInfo provides operation details like OperationId (Operation number), Parameter (Blank operation param) etc. posTransaction is your current retail transaction.
After you are done compile your project and replace original BlankOperations.dll in all POS installations (Services folder) with your modified BlankOperations.dll.
- Create a new POS plugin to show touch form to fill data. This plugin will be called from the button you added above.
By now you know that plug-ins are .Net assemblies. You can create one for your custom functionality and put it in the Services folder. You can then call it from the BlankOperations.dll and check if this service is called by your custom button. To create touch forms you need DXperience WinForms (188.8.131.52) license and knowledge of .Net windows form development.
That’s it for now. Do let me know if I missed something or you want me to add more things specific to POS development?