RSMUS.comOverview
One of the biggest benefits of using Dynamics AX in a retail environment is the ability to work on a central, headquarters based inventory management system. This design, however, has some inherent challenges. Specifically, because of the store personnel are operating in the same “back office”, they have the ability to view and edit transactions that don’t necessarily belong in the store.
This was typically handled by using Dynamics AX XDS model to limit the information available to the store users. In this latest AX2012R3 release, Microsoft has implemented several new XDS policies that can be used right out of the box.
These views will limit the information that a store user can view based upon the warehouse that is assigned to the store. The following areas are affected by these new XDS policies:
- Purchase Order lines
- Transfer Order Lines
- Inventory Journals
- POS Terminals
- Sites
- Warehouses
- Workers
Setup
To enable these policies, the AX login will need the RetailStoreManager role. In addition, the ax user will need to be associated with a worker.
Note: the XDS policy can be overridden if the user is provided a higher level role, such as system administrator. Remove all roles except System User and RetailStoreManager. If you want store personnel to create inventory journals, then also add the RetailOperationsManager role.
Once this is completed, the final connection is made between the “employee address book” on the store and the “address book” on the worker records.
Worker assigned to address books as follows:
Employee address books assigned to store as follows:
Filtering
Filtering works very well. The user will not be aware that there is a filter applied. This worked on sites, warehouses, workers, POS registers, purchase orders, purchase lines, transfer orders, and inventory journals.
Data Entry
Because the filtered tables includes warehouses and sites, the user can only select the warehouses and sites from the list of stores for which they have access. This works very well when creating purchase orders, purchase lines, inventory journals and inventory journal lines.
Unable to Create Transfer Orders
This has a side effect for transfer orders. The filter is on both the “from warehouse” and “to warehouse” and applies to new records. This means that if the user can only select from and to warehouses for which they are assigned, they will not be able to create transfer orders to other stores. However, they will be able to see transfer orders that are from or to their store.
Journal Lines are Unfiltered
Lines within a journal are unfiltered. Although this is partially addressed by having a warehouse filter that limits what a store user can enter, it does not prevent a store user from viewing and posting data for that does not match what is in their store. This is something we have to re-address on every implementation. If the user goes to the trouble of entering the site and warehouse on the journal, these values should be defaulted on the lines to the exclusion of any other site and warehouse.
Hiring New Workers Requires Corporate Intervention
The filters allow the user to go into the worker list and complete some basic maintenance such as resetting a POS password or assigning a POS Permission Group change. However, hiring and terminating workers is still a corporate function. This would include creating new jobs and positions for the workers.
Conclusions
This functionality is definitely helpful but will require some additional work to make it fully functional in some scenarios. Specifically, the creation of transfer orders is a common requirement that will need to be addressed. Given the current functionality, the system pre-supposes that someone at Corporate with enough privilege would create the transfer order header for the stores on an as needed basis.
