Improving Profitability and Increasing Efficiency...

You need solutions. And you need someone who isn’t going to back down from the challenges your business faces. From consulting, to building and implementing SCEM, ERP, WMS, and TMS, we work with you every step of the way to analyze your business processes and technology, and apply practical and economical solutions.
Our experience is real. Our knowledge is strong, and we are ready to help you use tried and true technology to proactively increase profitability. So what are you waiting for?
Contact us and let’s get started today.
contact blue horseshoe solutions blue horseshoe on linkedinblue horseshoe on facebookblue horseshoe on twitter

AX 2012 R3: The new warehouse (WHS) module and deprecated WM2 functionality. What it means to you!

With the newest release of AX 2012 R3, users will notice the addition of significant functionality around the warehousing (WHS) and transportation (TMS) capabilities. The features are so large they now have their own modules within Dynamics AX. Its exciting to see these make it into an ERP out of the box as historically, they are reserved for software which does them exclusively dubbed ‘best in breed’. Because Microsoft has declared these as the way of the future for AX, the functionality and concepts will become key to future implementations of AX.

I wanted to write a brief post highlighting a few things in regards to WM2 being deprecated. We think these points are important so we want to do all we can to make sure the information gets out there in the AX community.

The big point: While AX 2012 R3 will support WM2 and WHS, they are not going to be supported in conjunction with each other. Make sure that only either WM2 or the WHS modules are checked, NOT BOTH. Microsoft is not supporting both enabled in a single environment. They were designed in R3 to be mutually exclusive.

Why was the Warehouse Management II (WM2) functionality deprecated in AX 2012 R3?
Making reference to Microsoft’s official document for deprecated and new features “New, changed, and Deprecated Features for Microsoft Dynamics AX 2012” document, on page 750, the functionality duplicates what is in the new WHS functionality. The capabilities will not be 1:1 to features in WM2 as the concepts and ideas behind accomplishing certain tasks have changed. You should be able to accomplish everything you were able to do and more in WM2. It may take some time to learn the new functionality but, when executed correctly, will take implementations so much further with fewer customizations.

Why didn’t Microsoft just add advanced features to the existing functionality?
It’s not so much a question of “What features can be added to a module” as it is “If the module was designed for the features to be added to it”. Any system can technically have any feature added to it; it’s only a question of time and money (and sanity!). Adding new features to existing functionality on a framework that wasn’t designed for them is what can lead to ‘spaghetti code’ and a large bug sheet.

When Blue Horseshoe wrote the Warehousing for AX (WAX) and Transportation for AX (TRAX) modules, the functionality was designed with best in breed features in mind. We designed for the future but implemented for today. People now have a significantly more robust framework for adding advanced concepts of warehousing than were previously able to do on WM2. Some say “The functionality is too much for what we do”, but the reality is, when implemented correctly, there isn’t an organization small enough for this to not be the path to take.

What does this mean for upgrading?
According to Microsoft, no upgrade impact has been announced. Additionally, neither migration tools nor documentation have not been announced as of the date of posting. In my opinion, this is not a big deal. A very large majority of AX implementations are either integrating to a best of breed or have a heavily modified environment to accommodate for the functionality now included in the R3 code. This makes the upgrade path a topic that will require analysis on a case by case basis to find the best path forward. Purely ‘technical’ upgrades aren’t really possible. Also, remember that WM2 is just deprecated, not eliminated in R3. The functionality can still be used. There is still time here. Deprecation means intention to discontinue, not pull the table cloth out as fast as possible and hope the dishes don’t move.

Blue Horseshoe has had the distinct advantage of having written the original code as well as working very closely with the Microsoft development team to write the code for R3. With this, we’ve been able to analyze and plan for upgrade paths successfully. We’ve also been able to see what various levels of upgrading will take in some of the most complex AX instances out there. When Switching to the new WHS/TMS functionality in R3, it becomes vitally important to ask the right questions in planning the upgrade in order to take your organization to the next level of success.

Innovations in technology and systems are inevitable. How you design and implement you system today will determine a company’s ability to adapt to the innovations of tomorrow.

For additional information, contact Blue Horseshoe Solutions, Inc by clicking here


Removing Persistent SSRS Parameters in Dynamics AX 2012 Reports

(This is specific to reports using a Report Data Provider)
I built an SSRS report to retrieve a list of all prices from specific vendors. In this report, there are a number of parameters: Item Status, Prices to display, Inventory On Hand, and of course Vendor Account.

A system user selects various parameters to run this report. As is customary in these SSRS reports, the next time that the user opens this form to run the report, all of the parameters that they selected for the prior report run are pre-selected by default. However, it is possible to default these values to your choosing.

In my case, my users simply wanted all the parameters to be cleared when they open the form. This can be achieved by calling the parmLoadFromSysLastValue method (extended from the SrsReportRunController class) with a false parameter in the RDP Controller class.

After this is compiles, all of your report parameters will be defaulted to blank regardless to what was entered previously by the user.

In a more complicated scenario, you might want one or more of these parameters to either be checked by default while the others are blank. In this case, you can make use of the prePromptModifyContract method in the RDP Controller class.

Here, you will need to reference your contract class where your various parameters are defined and then specify your values. If I want to default the “Status A” to be automatically checked while the rest are blank, I can use the following code:

My result when the report is opened:

I should note that the Display Inventory and Prices to Display parameters are not part of my Report Data Provider. Those were implemented and deployed entirely from Visual Studio so they cannot be referenced in the RDP Controller class like the Item Status and Vendor Account parameters can be. Although the first method to remove all previous values (parmLoadFromSysLastValue) will work to clear out all parameters, if you want to specify values for the non-RDP parameters, you will need to do that in Visual Studio or convert them to RDP parameters in your Contract class.


Dynamics AX – Illusion of missing check numbers gap explained

Audits can be difficult and stressful times for any organization. During a recent audit of one of our clients, a gap in the check number sequence was brought to our attention. This can turn out to be a red flag during audits for obvious reasons (you don’t want blank checks just floating around). What made this particular scenario interesting is when you checked the check’s status within Dynamics, those numbers were listed as blank checks. Because of this, we had to investigate several options and make several attempts at duplicating the issue.

After several troubleshooting attempts, it was determined that this was not an issue with AX or the setup within AX. What was actually occurring was that the journal that the check was in had several invoice lines. This meant that all those lines could not fit on just one check page, and it spilled over onto a second. This is what caused the blank check entry within AX. This is good news as it means that there weren’t any missing blank checks wandering around and there was not an issue with Dynamics.


Create!Forms Reports in Microsoft Dynamics AX 2012

Create!Forms software has not changed significantly from the versions created prior to Microsoft Dynamics AX 2012. However, the structure within AX to generate the XMLs for the reports has changed. The XMLs in AX 2012 are now built from a temporary table that is populated by a data provider class. Adding fields to reports is different now because of this new structure.

Example: Add Delivery Mode to the Sales Invoice header.

1. Add the new field to the temporary table.

Note: The temporary tables will end in ‘Tmp’ and typically begin with the title of the report.

2. Populate the field on the data provider class on the ‘insertIntoTmpTable’ method.

Note: This step can be complicated if the field being added is not directly related to a table already being used to populate the temporary table. If a new table needs to be added; declare the new table on the Class Declaration, read through the ‘Process Report’, and join the new table appropriately.

The data provider classes end in ‘DP’ and typically begin with the title of the report.

3. Add the testing parameter onto the report at System Adminitrator > Setup > Bottomline > Enabled Reports on the Setup tab Run the report to get a new XML with the additional field.

This newly structured XML changes the way sections are organized when brought into Create!Forms. Instead of having many sections per report in the 2009 format, the XML will only have a section for the temporary table. If there are multiple transactions or lines, the temporary table will be repeated. This format will slightly alter the strategy to design a report within the Create!Form Designer, but all of the tools are the same.


Planning and Designing a Chart of Accounts for Dynamics AX or Any ERP

Many people, especially those outside of finance, may question why proper planning regarding a chart of accounts is an important task. The chart of accounts needs to be structured in such a way that historical, short-term, and long-term needs can be met. The structure should be conducive to analyzing data in an easily digestible manner. In a word, it should be “future-proof” and capable of easily handling growth. A streamlined chart of accounts allows users to instantly recognize what an account is (based on its placement in the chart), it simplifies the coding and approval process, and eases maintenance. To put it differently, a poorly structured chart of accounts costs a company money, even when they are not aware of it, causes inefficiency, and limits growth.

Many companies allow the past to tie them down. Keep in mind that if changes are desired or needed then they shouldn’t be shied away from; there is never a better time to hit refresh on a clunky and outdated chart of accounts than during an ERP implementation. It’s important to realize that planning for a chart of accounts cannot take a one-size-fits-all approach. However, the implementation team should try to adhere to a certain concept of proper placement, using industry standards as a template, and build the structure from there. For instance, account numbering can usually be accommodated with 4 digits although some companies with a more detailed oriented chart may make use of 5 digits. Generally speaking, if 5 digits seem necessary consider that you may not be using certain functionality such as advanced rules and financial dimensions to their fullest potential. For most companies, the high-level organization of a chart may appear something like the table below:

Account Range Account Type
1000-1999 ASSETS
3000-3999 EQUITY
4000-4999 REVENUE
6000-6999 EXPENSES

Typically a company needs nowhere near one thousand equity accounts. However, in order to have appropriate segregation of key account groups, this is generally the preferred structure. Keep in mind that the chart needs to be flexible and adaptive. Furthermore, be sure that industry and business practices are taken into consideration during development. Most fluctuation usually takes place from the 6000s and up. For instance, a company with a heavy focus on employee benefits and carries quite a few employee related expenses may want to have the 6000s as Payroll Expenses, 7000s as Operating Expenses, and the 8000s as Other Expenses/Revenue. Some companies with numerous activities outside of their regular business operations may want to separate Other Expenses and Other Revenues into separate blocks (i.e. 7000s and 8000s) and others may want to use the 9000s for taxes or even minor operations that are run out of the same entity. Frequently, the last grouping is left open for potential growth. The important part is that the structure is logical, consistent, and leaves plenty of room for growth.

Once the broad structure is determined, further groupings of accounts should be considered. At this level of the account structure, there is typically still a common progression of account groups but a far higher degree of customization. For instance, almost all charts will start with the current assets beginning with Cash utilizing the 1000s, usually followed by AR in the 1100s, and then possibly seguing into Prepaid Expenses or perhaps Inventory. Allowing plenty of room for growth is key to this process. If you feel that you are within 50-75% capacity in a number range already and there is any chance of further expansion, consider raising the range to accommodate. An example format for assets and liabilities is below:

1000-1099 CASH
1400-1499 INVENTORY
1800-1899 UNASSIGNED
1900-1999 OTHER ASSETS
2000-2099 UNASSIGNED
2400-2499 UNASSIGNED
2500-2599 UNASSIGNED
2800-2899 UNASSIGNED

Be sure to consider the business needs as well as how the financial statements are structured. What accounts are grouped together in the balance sheet? On a basic level, the company should function and track information the way that it is reported. This obviously doesn’t mean that the chart should be an exact mirror of all of your financials or even mirror the balance sheet but this is merely a note that it should be taken strongly into consideration. Note how there was also a goal to achieve symmetry in the chart. The 11##s are AR while the 21##s are AP, the 15##s and 25##s are both associated with related parties, and the17##s and 27#ss correspond to Notes Receivable and Notes Payable, respectively. Even greater relationships can be established, if desired. For example, 1601 may be Due from company XYZ while 2601 may be Due to company XYZ. Additionally $USD cash accounts may utilize the 1000-1049 range while international bank accounts ($MXD or €EUR) may occupy the 1050-1099 range. The possibilities of accommodating both customization and organization are expansive. Whenever possible, a greater level of structure and organization creates a logical progression, eases report writing and maintenance, reduces time for users to acclimate to the chart, and increases overall process efficiency across a breadth of areas and employees (coding/clerks, approval/managers, audit, etc.).

Although we’ve discussed extraneously some of the benefits of having a carefully planned and designed account structure, let’s examine a few examples in more detail. Whenever creating financial statements, such as the excerpt from the Management Reporter 2012 balance sheet row definition below, single accounts in conjunction with account ranges are specified when rolling up to the reportable groupings. While it’s certainly common and understandable for there to be a few accounts that have to be added out of sequence and possibly subtracted from other ranges (especially depending on the report being created), the goal should be to limit that as much as possible through the creation of a logical progressing and organized chart of accounts. As the Link to Financial Dimensions field begins to grow in length as numerous values get added or subtracted, it becomes increasingly difficult to determine whether an account has been excluded from the financials without running diagnostic tools or possibly discovering the error later in incorrect reports. However, the benefits aren’t limited to report creation.

Since we have created the chart with growth in mind, the above range for CASH 1002:1099 very likely doesn’t have actual accounts assigned to all of those values. Instead, we have merely assigned the range that we know cash to occupy and if someone adds an account in the future, for example 1025, it is already included in our cash accounts rollup. No further work is necessary aside from adding the account in the source system. The importance of something like this cannot be underestimated. Imagine a certain P&L account utilized in 5 different reports that may have slightly different row structures (Actual vs. Budget, Actual by Department, Current Year vs. Prior Year, etc.). Now consider the maintenance component of having to consider every report that the account may be associated with each time a new account is created and having to go to each of those reports and manually update it. A well-planned chart of accounts will save time creating reports and maintaining reports as well as decreasing the likelihood user error.

Furthermore, a similar benefit can be derived within the Dynamics AX account structure from having an organized chart of accounts. The account structure within AX is a tree-based validation system which indicates what financial dimensions are relevant and what financial dimension values are valid for a particular section of the account string. In the below example, inventory adjustments have been assigned from account 5200 to the end of the Cost of Goods Sold section, 5998. Because the chart of accounts was structured in logical and planned way, we can easily assign what financial dimensions we want to be valid for this section of the chart (in this case the custom dimensions of Commodity and Sub-commodity) and within sections of those trees we can dictate what specific values may be valid for each account or range of accounts. We can also easily determine at a glance whether any accounts have been left off. By reviewing the chart alongside the structure we could easily determine whether or not the structure we have assigned will be valid for the entire range. The same logic could be applied if certain ranges of P&L accounts only received postings from certain departments/cost centers.

When the chart of account’s overall structure is only considered as an afterthought and deemed unimportant or insignificant, attempting to ascertain if new accounts need additional setup within Dynamics AX 2012 becomes an extremely difficult and cumbersome task. Not only would a user be potentially confused about what “range” to place the new account in, they would then have to research if the assigned financial dimensions and allowed financial dimension values make sense for that newly added account. Obviously report writing and maintenance, as explained above, becomes exponentially more difficult as well. This results in an error prone and inefficient process for valuable employees whose time would be better served in other tasks.

Designing and implementing a carefully planned chart of accounts is like pouring a level and solid foundation for a house. You could certainly build on it either way but it may not be structurally sound or stand the test of time without the proper foundation. Spending time researching where to create an account, validating and maintaining related reports and rule structures, sinking time into research for coding and approving transactions due to a high learning curve, etc. are processes that the modern company cannot afford. Either directly or indirectly, the chart is utilized at virtually every level of the company and as such deserves appropriate consideration when developing. An efficient and flexible chart of accounts with potential for growth allows for an efficient and flexible company with the potential for growth.

Blue Horseshoe is the best in the business at selecting and implementing the right software solutions for your company. We have created some of the most successful and efficient processes for your industry and we work together with you to create any custom applications you require.

Learn more about solutions for your industry>
• Food and Beverage • Manufacturing
• 3PL: Third Party Logistics
• Wholesale Distribution
• Healthcare (Providers & Distribution)
• Retail • Automotive • Publishing
What our clients say...

“Blue Horseshoe was able to quickly understand our supply chain business and proposed its Vendor Portal system as a solution to significant challenges we were experiencing. Our efficiencies in shipping, receiving, warehouse and tracking our international orders has improved with Blue Horseshoe’s solution and we look forward to our next steps with Blue Horseshoe to further enhance our operations.”

Daniel Dugan, IT director of Application Services
Batteries Plus