Government measures have eased and people are returning to work, shops, offices, simply to public places. However, lowering measures brings many conditions that we must observe. How do you know if employees or customers are following the recommended distance, and are actually wearing the recommended face masks in the work place or in the store? This is where artificial intelligence helps.
Simply said, artificial intelligence (AI) is a set of machines and systems that efficiently perform tasks and make people's jobs easier.
Artificial intelligence methods use advanced data analysis and connect large amounts of data, between which they search for links and connections. Based on the learning process, these complex algorithms generate accurate results, and classify reality.
Thanks to the data analysis, the system can learn almost anything, such as recognizing faces or certain behaviors. Artificial intelligence surrounds us more and more. Karel Pecl helps to understand the term artificial intelligence in our blog article from February. Read more here.
At the time of the coronavirus, when we are slowly returning to work, the eMotion Counter can help us. Thanks to industrial cameras, compliance with preventive measures in connection with the fight against coronavirus can be easily checked and monitored during store operation.
When thermal cameras are connected, artificial intelligence helps to identify sick people, their movement, and contacts within the area.
EMotion Counter technology receives data using the RTSP protocol, which is standard for commonly used security cameras.
With the help of the eMotion Counter, we simply ensure compliance with the recommended distance between people in queues, within the operation of the factory or in office buildings.
The system can also continuously monitor the number of people, and quickly evaluate the maximum number of people present, for example in a shopping center. If the permitted number of people is reached, the system automatically informs the operator. Employees can be excluded from the census system, so you always have an overview of the actual number of customers in the store.
If you want one-way traffic in the store, walking through alleys in only one direction, the system also monitors the compliance with this rule and immediately informs the operator in the event of a breach.
Artificial intelligence provides an effective tool to ensure compliance with the rule of wearing face masks. Machine learning methods can analyze recordings from security cameras and point out a non-compliance with the regulation of wearing a face mask.
Thanks to the eMotion Counter, you can easily track the entry of a person who is out of the age limit. This can be useful when only certain age groups of customers are allowed to enter. Thermal cameras also detect people with a high temperature.
By combining security and thermal cameras, artificial intelligence can detect and point out people with a high temperature. Fast and automatic identification of a potentially infected person can effectively help reduce the risk of the coronavirus infection.
In the case of a confirmed infection, the system can track and reproduce the movement of the infected person during store operation. Thanks to the face recognition function, it is possible to accurately identify people who have been in close contact with the infected person. The data is processed from all cameras in the building and archived in the SQL server database.
The use of artificial intelligence is wide. In today's difficult times, full of restrictions, eMotion Counter can help in shops, car dealerships, shopping malls, also in public administration, hospitals, large companies, hotels and office buildings.
Ensure greater safety for your employees and customers. Reduce the risk of spreading the disease with modern technology. Contact us.
More informations about eMotion Counter.
Last months I was in charge of developing customizations of Enterprise POS (Windows Forms version of POS) for Microsoft Dynamics AX 2012 R3 (CU9). Among others, our customer required cross-sell functionality at POS. While there is a support for cross-sell in Call center module of Dynamics AX, the POS application does not contain it in its standard.
Development of cross-sell functionality in AX Retail POS is a real-life developer’s story.As I was new to the POS development, I started by googling for some hints. Indeed, there are nice articles describing particular development tasks. However, I was missing a more complex example putting all things together. Especially, after some reading I knew how to create a new form for cross-sell items and how to link it to a new POS operation (which I named CrossUpSell, using the so called BlankOperations). I also learnt that I will have to modify the ItemTriggers assembly to be able to invoke the CrossUpSell operation. However, I did not get any trace of how the invocation can be implemented. And there is more – changes must be done at AX and Commerce Data Exchange too. Therefore, after successfully implementing the up-sell functionality I decided to write down my notes and share them.
The expected audience of this paper are Dynamics AX developers seeking for guidance on performing POS customizations.
Many useful links to information on POS developmentI suppose Dynamics AX 2012 and .NET programming skills and also understanding of the Dynamics AX Retail architecture. Throughout the article, you will find links to numerous sources of information on various aspects of POS development.
Let me start by shortly explaining the desired functionality. In AX, you can define the so called cross-sell items for the main product. These cross-sell items are displayed to a user when a sales line with the main product is created. The user can then make a selection of cross-sell items to be added to the sales order together with the main product. For example, if a PC mouse is being sold then battery pack would be offered. The screenshot below shows the new POS dialog screen that automatically pops up after scanning barcode for product 0003. The user can mark several lines with cross-sell items and after clicking on the OK button new lines will be added to the order.
In AX, cross-sell items are defined in the Up-sell/cross-sell items form which can be opened from the Product information management > Common > Released products by clicking the Up-sell/cross-sell setup button on the Setup tab (up-sell is used for scenarios, when the item replaces the original main product; it is not used in our scenario). In the simplest case the cross-sell definition consists just of one piece of information – the ItemId of the cross-sell item. While there are more parameters for the setup of cross-sell items (Priority, Rules, Scripts), I will not cover them in this article to keep things simpler. For more details on Up-sell/cross-sell functionality, see Technet
Before developing customizations at the POS side, the cross-sell setup table must be added to the store database and to the Commerce Data Exchange infrastructure. The following steps are fully explained in the Implementation guide for Commerce Data Exchange PDF document , chapter Customize Synch Service.
In AX, the cross-sell setup data is stored in MCRUpSellItem table. To add this table to the synchronization schema, the following steps must be taken in AX:
Now the AX part is finished, we have to add MCRUPSELLITEM table to the channel database’s ax schema. The create SQL script will look like this (the script has been created :
Note that except the table itself we also create indices and grant permissions to DataSyncUsersRole. You might wonder how one comes up to the script implementation – I had a look at the DatabaseScript.txt file within CreateDatabase project in Services solution (which I will talk more at the end of this paper) to see how Microsoft does it.
For this moment, it is pretty OK to run the script from within SQL Server Management Studio during development phase. The proper way of deploying channel database changes is to modify the applications responsible for channel database creation / updates. This is described later in this article.
It is time to test the synchronization now. Make sure there are some records in the Up-sell/cross-sell setup table in AX and launch the synchronization job. Open the Retail > Periodic > Data distribution > Distribution schedule form, navigate to the 1040 (Products) record and click on the Run now button. After confirmation the data transfer is launched. If everything goes OK, cross-sell setup data will appear in the ax.MCRUPSELLITEM table in the corresponding channel database. To troubleshoot issues, start in AX in the Retail > Inquiries > Commerce Data Exchange > Download sessions form. Clicking on the Process status messages button you will update the status in the Status field in the form. Another good place to look for some troubleshooting hints is the Event Viewer both at the Async Server and Async Client environments.
Finally, we need to develop customizations at the POS side. To this end we will already need the Visual Studio and Retail SDK installed, see Technet for details on this.
In the following sections I will show how to:
- Create a new CrossUpSell project containing definition of the new frmCrossUpSell windows which implements the cross-sell dialog window
- Use BlankOperations functionality to open this form
- Launch the BlankOperations operation in reaction to adding an item to the sales order at POS’s main window using triggers
We will start the development in the Services solution which a part of Retail SDK (.\Retail SDK CU9\POS Plug-ins\Services). We will create a brand new project called CrossUpSell. This project will contain most of the source code needed for implementing the cross-sell functionality in POS. I was mostly guided by the existing frmItemSearch form in the WinFormsTouch subfolder of the Dialog project. The resulting frmCrossUpSell has almost 1000 lines of source code. Therefore, I am not going to explain every piece of code here. Instead, I will only point out the important part.
First of all, when creating new CrossUpSell project in Visual Studio (of class library type), do not forget to setup the project itself. Namely, it is wise to set the output path of the project to the ..\..\POS\bin\Debug\ (..\..\POS\bin\Release\) folder to simplify the deployment. Second, as we will add icons to the dialog, we need resources file. To this end, I created a Resources subfolder in the CrossUpSell folder (do it from File Explorer, not from Visual Studio). Then I copied all resource files from Dialog\Resources folder to CrossUpsell\Resources folder. Finally, in Visual Studio drag&drop Resources.resx file from Dialog\Properties folder to CrossUpSell\Properties folder.
As a next step create new class called LineSelection which will hold information about the selected item. The Quantity property is not used throughout this paper; it is for future use only. Also note that the class should be serializable.
Now it is time to add a new Windows Form item to the CrossUpSell project. To keep things as similar to the standard frmItemSearch form as possible I decided to throw away the auto-generated Windows Form designer code and put everything into one frmCrossUpSell.cs file (and thus the corresponding frmCrossUpSell class needs not to be defined as partial).
To keep aligned with the look and feel and common behavior (like exceptions treatment) of the POS application it is important to inherit the form from the frmTouchBase class in the LSRetailPosis.POSProcesses namespace:
At this point, do all the usual windows form development stuff – add all necessary windows forms controls to the form – define private variables for them and create control instances in the private InitializeComponent method called from within the constructor. Moreover, add member variables keeping the form’s status:
The public interface to this form consists of two properties. MainItemId property enables the caller to enter the ItemId of the main product for which cross-sell products should be displayed. The SelectedLines property contains list of selected items that were marked by the user working with the dialog.
Further, override the OnLoad method to initialize the form. Among others, call code for getting initial data for the grid. Namely, call the SearchItems method, which in turn calls the GetItemList method.
Inside the GetItemList method the data is obtained from the channel database to populate the grid control. Its implementation is as follows:
You will notice the use of PRODUCTFINDCROSSUPSELL SQL Server stored procedure in GetItemList method. I created this stored procedure as an analogy to the existing PRODUCTSEARCH stored procedure in the standard Retail Channel Database. It takes the ItemId of the main product (and some other auxiliary parameters) and returns all cross-sell records:
As you can see, internally it calls another stored procedure called GETUPSELLITEMS which does the actual cross-sell item data search:
The rest of the PRODUCTFINDCROSSUPSELL takes care of sorting and rules out the products that are not assorted.
Going back to the frmCrossUpSellItem form, we need a way to communicate the result (the selected cross-sell items) back to the caller. This is done in the SelectItems method which is called when the OK button is pressed:
The method simply enumerates all selected rows (the indices of which are stored in the selectedRowIndices member variable), takes their ItemIds and stores them in the selectedLines member variable which is accessible via SelectedLines public property.
As Enterprise POS is not fully open source solution, we cannot add a new operation for cross-sell directly. Instead, we use the BlankOperations functionality. For introduction to BlankOperations see Technet . There is also a nice article about BlankOperations by Erstad Shane.
To implement BlankOperations in our solution we start by creating a new BlankOperationsCrossUpSell class in the CrossUpSell project. This class must implement the IBlankOperations interface and it must be decorated by the Export attribute. The latter is important for the POS application to identify this class as a plug-in implementing the IBlankOperations interface. For details how this works in .NET, see Managed Extensibility Framework (MEF) articles on MSDN .
The IBlankOperations interface from the Retail SDK declares BlankOperation method, which is implemented in BlankOperationsCrossUpSell type as follows:
Basically, this method only treats blank operations with operation ID equal to CrossUpSell. After some sanity checks, it creates a new instance of our frmCrossUpSell form with MainItemId set to the ItemId obtained from the currently running sales transaction. It then calls the POSFormsManager’s ShowPOSForm method to display the form. After the selection has been made and confirmed in the form, the selected lines are obtained from the form’s SelectedLines public property. The selected lines are then enumerated and added to the current sales transaction by invoking the ItemSale operation with the appropriate ItemId. If everything goes OK, the blank operation is marked as handled – this prevents other implementations of this interface from handling this operation too.
You have probably noticed the lines testing and manipulating the insideCrossUpSell static property of Boolean type.
This is a safeguard that prevents us from displaying the cross-sell dialog window recursively. This has been disabled by design as our customer does not require such a functionality; if cross-sell items for cross-sell items (and further levels) were allowed, then we would have to think of a more user friendly solution, somehow flattening all possible cross-sell products of the root product.
The way how our BlankOperation method uses static property for managing recursive invocation is far from being perfect – at least it is not written in a thread-safe way. It would be a better solution to narrow the scope of the insideCrossUpSell Boolean variable to the sales transaction. It can be done with the use of transaction’s PartnerData property – this technique is described in Erstad Shane’s blog , step 5.
There is one more task in connection with blank operations – we have to modify the standard Retail SDK “implementation” of the IBlankOperations interface which can be found in the BlankOperations class of the BlankOperations project – just make sure that there will be no message box displayed for the CrossUpSell BlankOperations operation. This is important as we cannot predict which of the IBlankOperations implementations will be executed first.
Now that we have a new dialog form and a new CrossUpSell blank operation, we need to decide when and how to invoke it. In our solution, we do not need to bind a button to the blank operation, as the cross-sell functionality will be triggered by adding a main item line to the sales order. The good place for this is the PostSales method in the ItemTriggers class. This class is located in the ItemTriggers project of the Triggers solution.
The implementation is quite simple, yet a little bit tricky:
The only thing we need to do in the PostSale method is to invoke the CrossUpSell blank operation. To this end, we need an instance of a type implementing the IApplication interface to call its RunOperation method. Here MEF comes into game again – this time we are importing the IApplication interface implementation and store the result into public Application property. This is done automatically when the POS application starts – in other words, during the POS startup the setter is called passing in the actual IApplication implementation instance.
When calling the IApplication’s RunOperation method, we need to pass in the required operation ID (CrossUpSell in our case). This can be done by sending a string parameter consisting of two substrings delimited by semicolon. The first substring represents the operation ID, the second substring represents extra info value. These two substring correspond to the Operation number and Blank operation param fields in the Configure button form in AX, which you can open from the screen layout designer. In our case, we only use the operation ID substring.
Thanks to the MEF support in the standard POS application, it is quite easy to deploy and test the POS changes. Just locate the Extensions subfolder of the POS installation main folder (usually C:\Program Files (x86)\Microsoft Dynamics AX\60\Retail POS, but it is a good idea to make a local copy of the POS installation before deploying any customizations for testing) and place all needed assembly files. Note that you can only debug your customizations if you compile them with the Debug configuration in Visual Studio and deploy the PDB files together with assembly files.
As mentioned earlier, there is a way how to package and deploy channel database upgrade scripts. In Services solution, there is a CreateDatabase project, that contains artifacts for including the scripts. Namely, in the Upgrades subfolder, create a new file (in our case, Upgrade188.8.131.52.sql), that contains all SQL scripts needed for cross-sell functionality. In the POSISUPGRADES.xml, register the new file
and build the CreateDatabase project. Finally, copy the resulting assembly file (CreateDatabase.dll) into two places – the Retail Channel Configuration Utility installation folder (C:\Program Files (x86)\Microsoft Dynamics AX\60\Retail Database Utility\Services) and the Retail Channel Database installation folder (C:\Program Files (x86)\Microsoft Dynamics AX\60\Retail Channel Database\Tools). The former is used by Retail Channel Configuration Utility, which is the standalone tool for creating/upgrading channel databases:
The latter is the tool used by the Dynamics AX installation program when installing the channel database:
Note that neither of the tools supports MEF plug-ins. That’s why it is necessary to replace the original CreateDatabase.dll files (of course, after making a backup of them). For more information on the Retail Channel Database Utility see Technet .
In this article an example of a more complex Enterprise POS customization was given. It comes from a real life scenario – implementation of cross-sell functionality at Enterprise POS was required. The example illustrates all activities needed for its implementation – changes in AX, in Commerce Data Exchange and in POS application. It contains links to the documentation on particular topics as well as troubleshooting hints.
Ondřej Liberda works as a Dynamics AX Developer/Architect in the company Blue Dynamic and has extensive experience with Dynamics AX development.
Do you often struggle with sharing objects within one project in Microsoft Dynamics AX environment?
Is the amount of time and of energy spent on building and organizing new release builds and their deployment to target customer’s environment unacceptable to you anymore?
Do you and your customer often run into disagreements about ambiguities and bugs once the build is deployed?
If the answer is yes to any of these questions, then I have a number of tips based on my experience on how such situations can be avoided.
When dealing with smaller-scale projects, with fewer developers involved and a lower likelihood that they will need to work on the same objects at the same time, you can use one shared development environment.
For larger projects use the model of distributed development environment in combination with Team Foundation Server.On the other hand for larger projects, you should use model of distributed development environments, in which each developer works on his own development platform that is regularly synchronized with the central repository (see below). Conversely, the developers also periodically submit their code to the central repository (usually on completion of a particular development task).
Using version management on DEV environment brings a lot of advantages:
Dynamics AX environment offers several possibilities of keeping track of development versions.
For each project, use at least two test environments. One of the main development branch, the other for hotfixes.When it comes to the model of shared development environment, it is advisable to use version management that is integrated directly within AX (MorphX VCS).
In this case the developer checks out an object upon starting his work, which makes it temporarily impossible for other developers to access this object for changes. Object only becomes available again after the prior developer checks in changes made to the object to the version management repository.
On the other hand, with the distributed model of development environment it is necessary to synchronize objects on developer’s local environment with the global repository. This allows the developers to work on the same object simultaneously. Conflicts may occur during the submission to the global repository, although for the most part these are automatically resolved. However, when an automatic solution is not possible, the developer has to resolve the pertinent conflicts manually.
For the global repository it is advisable to use Microsoft Team Foundation Server (TFS) that has, among other features, an integrated ticketing system, which allows managers to a see direct relations between the development changes and customer requests.
Release management (RM) significantly raises work effectivity during the creation of a build that should be deployed first to TEST and finally to PROD environment. Apart from quick and smooth release creation, it also provides a clear overview of the detailed history of release build, as well as the list of the requests which were included in it.
From the outset it is clearly defined in the TS which tickets should be included in the build. Release creation process may subsequently proceed as follows:
When it is not possible to fully automate the process of build deployment, then the entire process of release creation and release deployment should not be left to a sole person. Due to the fact that deployment often takes place late at night, you will alleviate the risk of errors by distributing key roles between different team members.
The best way for release build creation is to engage one of the developers working on the project. He should be able to clarify many of the uncertainties related to submitted code and also comprehensibly and cumulatively hand over any required additional technical information related to the deployment (e.g. necessity to launch initialization jobs after release deployment, performance of changes in setup of planned jobs on Batch server, etc.).
The person in charge of the deployment does not necessarily need to be a developer, instead it can be another trained and reliable member of the Operations team.
Model of used environments is also associated with the release deployment process.
Besides the development environment (DEV), build creation environment (BUILD) and target production environment (PROD), it is also necessary to use a testing environment (TEST) before handing the final build over to the customer.
It is ideal to have at least two test environments. One allocated for testing of releases planned in TS in advance and second e.g. for the deployment of hotfixes. A second TEST should essentially be a copy of the production environment.
In order to avoid most of the confusion and unnecessary conflicts with the customer immediately after the release is deployed to the production environment (but also to TEST), it is important to set up a process through which the customer (the responsible key-user) is involved in the approval and testing of the requirements (tickets).
This may be achieved by workflow setup in the TS, set up in a way that the release to PROD is greenlit to deploy only after all the included tickets have the status “Tested and confirmed by customer”.
I believe that the above tips will help you to achieve greater customer satisfaction and also to raise the work efficiency of your team.
Vladislav Nový works as a Dynamics AX Developer in the company Blue Dynamic and has extensive experience with Dynamics AX development.
Each new version of Dynamics AX includes many attractive functionalities, which you may be missing out on because of your concerns about efficiency of the upgrade process. In this article we want to describe how you can minimize the time and costs required for the upgrade from AX 2009 to AX 2012.
There are two approaches to upgrade from AX 2012:
The goal of the entire process of Dynamics AX upgrade is a quick Dynamics AX implementation without unnecessary costs and risks, so that it could be as transparent as possible for the users. Thus, the user could end its work on Friday in the current version of Dynamics AX and on Monday continue to work on a new version of Dynamics AX. In this new version user settings and data will be unchanged.
A successful upgrade to Dynamics AX can be achieved by two approaches: In-place – Upgrade, that takes place in a single background that changes from Dynamics AX 2009 to Dynamics AX 2012 (this one Microsoft does not recommend for major upgrades) and the Source-to-target – The copy of the Dynamics AX 2009 background will be prepared for the upgrade, also Dynamics AX 2012 will be installed and the transfer of the code and data will be done.
Theoretical approach to the upgrade proceeds as follows:
Practical experience is an advantage
Upgrade can be done in two days
Clever tools can help
Setting will be retained
Microsoft’s documentation for the code transfer is not complete and therefore a successful upgrade can be performed only by an experienced contractor.After the transfer of the code data need to be transferred too. In the ideal case, the data transfer will take place automatically. However, in reality, the tool cannot cope with the inconsistencies in the database, incorrect settings and other irregularities in the data. Some of these errors can be solved by the programmers, others need to be consulted with the customer (business data). Unlike the code, the data transfer cannot be done in advance and it is only necessary to test „in a trial version“. The entire process cannot begin until the customer shuts down the system.
You will face many challenges during the upgrade, for example:
In the near future it will become an important issue to upgrade to Dynamics AX 7. Although the ERP system Dynamics AX 7 has not been issued yet, it’s likely (according to information from the Microsoft community web site) that a direct upgrade from Dynamics AX 2009 (and earlier versions) to Dynamics AX 7 won’t be supported. Upgrade of any older version to Dynamics AX 7 will probably be possible only by upgrading to Dynamics AX 2012 R3, which is the only version from which it will be possible to upgrade to the latest version. We know the first step, the second one we will learn when Dynamics AX 7 will be released.