Hi there,
I hope that everybody is having a great week. It’s almost Friday and I’m sure we are all looking forward for a restful and fun weekend.
On this post I would like to focus a bit more on a functional portion of AX 2012 Retail. This week I was working on some customization in AX 2012 Retail that required the posting of POS transactions from AX 2012 Retail.
However, before posting the POS transactional data in AX 2012 retail, we need to create a Statement. The Statement records will be stored in the RETAILSTATEMENTTABLE, and the statement data will be used during the posting process.
In order to have transactional data in AX 2012 Retail we need to run a Job that does this for us. You can find the job in Retail/Periodic/Retail Scheduler/Distribution Schedule.
When you click the menu item, the Distribution Schedule form opens. On the left side you will see the list of jobs available for us to run. In the AX 2012 Retail Demo this jobs is called P-0001 (POS Transactions). We can run this job from this window by clicking the Run Directly button.
When the transactional data is in AX 2012 Retail we need to create a statement. For this go to Retail/Journals/Open Statements
Choose your store
Click New Statement
Click the Edit button to add a new Terminal under Setup. (NOTE: in the picture follow the number sequence to execute the operations in the correct order)
Click the Calculate Statement button.
When the statement is calculated, click the Post Statement button to post the transactions.
That’s all for now folks. Keep checking my blog for much more to come on AX 2012 Retail. I’m working on something really cool right now and I need some time to write about Blank Operations, but I will and very soon.
Have a great and safe weekend!
Hi there,
I hope everybody had a great week and that you are ready for a well-deserved long and restful weekend.
As you already know, I will be working on a series of articles related to the Microsoft Dynamics AX 2012 POS application. Last week I wrote an article called AX 2012 POS Development - Application Triggers. Please check it out if you haven’t already done so.
In the course of this week I have been gathering a lot of information about the AX 2012 POS application, and the more I work with it, the more sense it makes to me. There are many different layers to this application, but this will be covered in future articles.
Anyway, this week I was working on a new instance of the AX 2012 POS application. To run it from Visual Studio, I followed the steps outlined in my last article AX 2012 POS Development - Application Triggers.
When all the setup steps were completed, I started the solution, keyed my user name and password and all of the sudden I got the following error:
This was odd as I went back to the demo instance I have and after following the same steps, I did not get this error. Luckily, there is LOG table called RETAILLOG in the AX 2012 POS application that can tell you what’s going on, and for my surprise, I was missing the Microsoft.Dynamics.Retail.EventTraceParser.dll as depicted in the following picture (from a working application).
The solution was easy; I just placed the missing dll to my AX 2012 POS application root folder. So, the Event Trace Parser enables rapid analysis of traces to find the longest running code, longest running SQL query, highest call count and other metrics useful in debugging a performance problem.
The Microsoft.Dynamics.Retail.EventTraceParser.dll is installed when installing AX 2012 for Retail and you can find it in your AX 2012 client folder.
The Walk through major features of Microsoft Dynamics AX 2012 article will give you a good introduction to its basic concepts.
That’s it for now folks. I hope you have a wonderful weekend. And stay tune for more to come on AX 2012 POS development. Next week I will post about how to use the AX 2012 POS System.Settings dynamics library and its in-memory functions.
Also, the following week I will write about Blank Operations by going through a really cool simple project.
Take Care!
