As I stated in one of my previous posts, the AX for Retail solution is highly customizable. There is not a lot out there on the web about it but there should be. While I am not so much of a technical person anymore (just by title...), I will still do a bunch of mods in this solution to make sure I know my stuff.
A functional consultant that knows the technical aspects of things is an extremely valuable resource and I can assure you that I will stay current with tech to keep that badge.
I'll post some stuff on here as I do it to keep people informed of my adventures.
Here is one great blog post about retail POS development that I've found helpful. I hope you will, too. I hope to come out with one that is equally as helpful that people will come to as well...
http://blog.rahulsharma.in/2011/09/dynamics-ax-for-retail-pos-development.html
Monday, November 14, 2011
AX 2012 for Retail history summary and how it got to where it is today
Microsoft had two primary Point of Sale (POS) solutions in their Dynamics software stack: Retail Management System (RMS) and POS 2009. These solutions were great for cash and carry retail operations that had a few locations and could handle a fair amount of volume without a problem. They handled all of their backoffice functionality in smaller accounting solutions like Quickbooks and PeachTree to name a few.
For larger companies, Microsoft's Dynamics AX (Axapta) solution was the obvious choice for their backoffice applications as these smaller accounting solutions were not capabale of sustaining their operations. The issue with these POS products and larger corporations is that they were developed for smaller operations out of the box (OOTB). The major selling point of large scale ERP's are their abilites to centralize managment of all operations into a single location. These products had to be adapted for larger companies via third party integrations like ToIncrease's Retail Chain Management (RCM) or Blue Horseshoe's Retail Operations Bridge (ROB) interfaces (for example) in order to integrate RMS to the AX system.
There were two issues with this solution: 1) Not a OOTB integration with a lot of effort in upgrading and 2) RMS was not a flexible application to allow major customizations like AX was able to.
As many in the AX industry know, AX is VERY customizable. With this customization power comes great customization responsibility. As an observation, the larger a corporation was, the more unique requirements their business contained. This created an obvious limitation of using these solutions as they were not very customizable. To note, they did not need to be and they did their job extremely well.
In order to bridge these two gaps, Microsoft purchased LS Retail POS and ToIncrease's RCM in order to develope their own, highly integrated, highly customizable POS end-to-end solution for their larger clients. From this came AX 2009 for Retail. This was a great product and everyone instantly saw that every implementation had customizations. I have yet to hear of a single solution that was 100% OOTB. This was by design as one size does not fit all.
Microsoft will soon release in the third quarter of 2012 (tentative), the AX 2012 for Retail feature pack. This is currently in the TAP process at the moment.
This is obviously just a high level history of how AX for Retail came to be. I left some stuff out and may have been too broad in some areas so please comment below if you can help add to this. I'm always interested to learn the background of stuff...
For larger companies, Microsoft's Dynamics AX (Axapta) solution was the obvious choice for their backoffice applications as these smaller accounting solutions were not capabale of sustaining their operations. The issue with these POS products and larger corporations is that they were developed for smaller operations out of the box (OOTB). The major selling point of large scale ERP's are their abilites to centralize managment of all operations into a single location. These products had to be adapted for larger companies via third party integrations like ToIncrease's Retail Chain Management (RCM) or Blue Horseshoe's Retail Operations Bridge (ROB) interfaces (for example) in order to integrate RMS to the AX system.
There were two issues with this solution: 1) Not a OOTB integration with a lot of effort in upgrading and 2) RMS was not a flexible application to allow major customizations like AX was able to.
As many in the AX industry know, AX is VERY customizable. With this customization power comes great customization responsibility. As an observation, the larger a corporation was, the more unique requirements their business contained. This created an obvious limitation of using these solutions as they were not very customizable. To note, they did not need to be and they did their job extremely well.
In order to bridge these two gaps, Microsoft purchased LS Retail POS and ToIncrease's RCM in order to develope their own, highly integrated, highly customizable POS end-to-end solution for their larger clients. From this came AX 2009 for Retail. This was a great product and everyone instantly saw that every implementation had customizations. I have yet to hear of a single solution that was 100% OOTB. This was by design as one size does not fit all.
Microsoft will soon release in the third quarter of 2012 (tentative), the AX 2012 for Retail feature pack. This is currently in the TAP process at the moment.
This is obviously just a high level history of how AX for Retail came to be. I left some stuff out and may have been too broad in some areas so please comment below if you can help add to this. I'm always interested to learn the background of stuff...
Tuesday, November 8, 2011
Allow a single user name to log into a server without taking over a session
The following should be used very carefully. I thought I would write about it since it helped me out of a tight situation a few times.
An example of where I used this: There is a third party application running at a client site and it doesn't seem to work for any other user except for the administrator account on that machine. The client wants to get in there and start using the program but the vendor is unavailable to assist at the moment. By allowing multiple people to log into the single administrator account, it helps progress move forward. THIS IS NOT IDEAL FOR A LIVE ENVIRONMENT.
A note to people making config changes: PLEASE TEST YOUR CHANGES. DO NOT ASSUME THIS WILL JUST WORK SINCE I SAID SO. This is a VERY important step and seperates the posers experts and the real experts that know better.
The following is for Remote Desktop Services (RDS). Microsoft (MS) rebranded Terminal Services (TS) as RDS. This process can be done with any user that has privileges to do this and it affects all users logging into that server.
Step 1 - Navigate to 'Remote Desktop Session Host Configuration'
To get here, go to: Start -> Administrative Tools -> Remote Desktop Services -> 'Remote Desktop Session Host Configuration' (See Figure 1 below)
Step 2 - Uncheck the 'Restrict each user to a single session' box.
Once in Remote Desktop Session Host Configuration, under the 'Edit Settings' section, look at the options in the General option. The third one down should read 'Yes' if you log into the server and immediately take over an active session. Double click on this option and you will see the form in Figure 2 pop up. Uncheck the 'Restrict each user to a single session' box and click Apply.
Step 3 - Validate the changed setting
While keeping your current session open, open a new RDP session and log in as your current user. If the new window opens a fresh instance on the server, you're all set!
Hope this helps!
An example of where I used this: There is a third party application running at a client site and it doesn't seem to work for any other user except for the administrator account on that machine. The client wants to get in there and start using the program but the vendor is unavailable to assist at the moment. By allowing multiple people to log into the single administrator account, it helps progress move forward. THIS IS NOT IDEAL FOR A LIVE ENVIRONMENT.
A note to people making config changes: PLEASE TEST YOUR CHANGES. DO NOT ASSUME THIS WILL JUST WORK SINCE I SAID SO. This is a VERY important step and seperates the posers experts and the real experts that know better.
The following is for Remote Desktop Services (RDS). Microsoft (MS) rebranded Terminal Services (TS) as RDS. This process can be done with any user that has privileges to do this and it affects all users logging into that server.
Step 1 - Navigate to 'Remote Desktop Session Host Configuration'
To get here, go to: Start -> Administrative Tools -> Remote Desktop Services -> 'Remote Desktop Session Host Configuration' (See Figure 1 below)
Step 2 - Uncheck the 'Restrict each user to a single session' box.
Once in Remote Desktop Session Host Configuration, under the 'Edit Settings' section, look at the options in the General option. The third one down should read 'Yes' if you log into the server and immediately take over an active session. Double click on this option and you will see the form in Figure 2 pop up. Uncheck the 'Restrict each user to a single session' box and click Apply.
Step 3 - Validate the changed setting
While keeping your current session open, open a new RDP session and log in as your current user. If the new window opens a fresh instance on the server, you're all set!
Hope this helps!
Figure 1 - Navigate to 'Remote Desktop Session Host Configuration'
Figure 2 - Uncheck the 'Restrict each user to a single session
Subscribe to:
Posts (Atom)