Friday, February 8, 2013

Error in AX 2012 for Retail POS: 'Cannot select a record in Catch weight setup (PdsCatchWeightItem)'

Error:

In the POS for AX 2012 for Retail, we were seeing the error "Cannot select a record in Catch weight setup (PdsCatchWeightItem). The SQL database has issued an error. Cannot execute the required database operation. The SQL database has issued an error. Cannot execute a data definition language command on (). The SQL database has issued an error." (Figure 1 below). This error can also be something like 'LedgerJournalTrans'

Figure 1 - Error from the POS

Solution:

Those familiar with AX will recognize this error as a table sync error (except usually in AX, not the POS). There are no issues in AX though. Even more curious, we weren't even using catch weights for items. The table is actually synced correctly in AX but it seems that there is something in the RTS or AOS that makes the POS not happy...

While this may not be the solution to all scenarios where this is encountered, the solution to this can be a few things:
  1. sync the table in the first error (PdsCatchWeightItem in this example)
  2. restart the retail transaction service (RTS)
  3. If still needed: restart the AOS where you are seeing this issue. 
Not entirely sure what the root problem was but the above will fix the issue. Hope this helps out!

Thursday, February 7, 2013

AX 2009 security profiler tool

I know this post is outdated but then again there are still people out there running AX 3.0. I still think its worth throwing out there so here it is.

Security is always a pain point in ERP applications. Its one area that greys the line between functional and technical. AX security in versions 2009 and before pretty much required the configuring users to be somewhat technical and know their way around the AOT fairly well. In AX 2012, security has changed to role-based and is significantly different. I'd say it still helps quite a bit to be technical in this new security model but its not as necessary as the previous versions

Anyways, for AX versions 2009 and before, the hardest part was finding out the name of the AX objects and tying them to a security key for access permissions. This could be very time consuming. There is a person over at Microsoft AX Support who wrote an AX utility (Security Profiler Project 2009) to help speed this process along and make it easier for functional people to configure security. She's always been awesome to work with and it's a very useful tool. I've used it before and liked it a lot but find that I can do it on my own faster (but I've also logged over 1200 hours of security configuration and support work). For most people, this tool will be a fantastic and all previous clients I've had use it love it.

Some things to note is that this utility only records menu items that are not calling classes or menu items within classes. These issues shouldn't be too crazy for someone using this application as a starting point or not getting too granular with restricting access.

Note for this tool: The existing AX class we hook into gets used every time a form or report is opened in AX so the tool will slow performance down – so don’t load this in a production environment.

As a reminder for AX security, always start with full privileges and then take away. There are some issues if starting with nothing in a group and adding to it.

http://blogs.msdn.com/b/emeadaxsupport/archive/2010/05/25/ax-2009-securityprofiler-tool.aspx

Sunday, February 3, 2013

Remove marked for settlement open transactions through X++ code

Due to the interesting way that AX settles marked transactions (see previous post: http://daxdude.blogspot.com/2010/11/ax-2009-settlement-of-invoice-and.html), it can be required to unmark all currently marked open transactions before marking a new set of transactions and doing an auto-settlement process. If this un-marking of transactions did not occur, certain credits or debits could be settled against unintended transactions because of a true lacking of 3-way matching functionality. Yes we can mod the system to do this (and I have...) but this post has nothing to do with that. But I digress...

In order to un-mark transactions that were previously marked via X++, use the code below:

CustVendOpenTransManager manager;
Common                   originator;

// Set the originator code from a record. 
originator = element.args().record(); 

manager = CustVendOpenTransManager::construct(originator); 

// If there are marked transactions, clear them
if (manager.getSpecTransCount() > 0)
   manager.resetMarkedTrans(); 

Obviously the code above shows some flexibility using the common and loading the framework from different forms. If you just want to clear out a customer's marked transactions in a quick way, you can use the code below and simple replace the customer number with the one you are interested in clearing out. Easy enough.

static void unmarkAllTransByCustomer(Args _args)
{    
    CustTable                custTable = CustTable::find('C00023567');
    CustVendOpenTransManager manager = CustVendOpenTransManager::construct(custTable);
    
    if (manager.getSpecTransCount() > 0)
        manager.resetMarkedTrans(); 
} 

Saturday, February 2, 2013

'Next-Gen RMS' aka Retail SMB unveiled by Microsoft

UPDATE 2/14/2014: Microsoft is releasing 'Retail Essentials'. While it is not replacing RMS, it is truly the next-Gen of a POS due to the large enhancements to the retail experience. It is AX as headquarters and the enterprise POS (ePOS) and mobile POS (mPOS) with a simplified AX retail architecture. The future is bright for the SMB market. I will publish several posts about this in detail in the near future. I have seen it and it is the future!

<ORIGINAL POST BELOW>
Exciting news in the Dynamics Retail realm. Microsoft is going to finally release an RMS and AX 'light' solution. The below is some information released about it from a few different locations (not sure how many are rumors but here is a collection of info):
  • Designed to give small- and medium-sized businesses (SMBs) the advantages of Microsoft Dynamics AX, but without the unnecessary features. 1
  • The new RMS product is going under the working title of "next-gen RMS," will be released near the end of this year according to Michael Griffiths.1 
  • The upgraded RMS product is also being referred to as "Retail SMB.1
  • Microsoft will continue to build on RMS as they are committed to their SMB retail customers and partners.1
  • Microsoft Dynamics AX for Retail, a.k.a., Microsoft Dynamics for Retail, which provides the building blocks of the new SMB retail offering.  3
  • "The vision of omnichannel is showing that all these channels are powered by AX, and now are powered by one commerce engine, the commerce runtime," explained Melissa Stern, senior industry analyst for retail, Microsoft Dynamics. 3  Note: Heavy RTS dependence?
    • 'Line-busting' will be a focus. This a mobile POS which can be used to dampen the effects of things like excessive holiday lines that exceed normal 'peak' capacities.
    • "When we talk about mobility - whether it's phone, or its slate, or a kiosk somewhere in the store, or a thin-web client -- (There are) lots of different platforms, lots of different form factors, the retail server is one way to provide that experience without having to write all the individual one-off solutions."  ~Jeff Blucher, Microsoft program manager
    • Consistency throughout all the channels; one set of rules used consistently throughout all the channels
    • Back end will dictate pricing, discounts and tax calculations like AX for Retail does today
  • Microsoft is intending to release the new version of RMS in 2013. 4
  • New product will effectively supersede both Dynamics RMS 2.0 and POS 2009 4
  • Will be built on a flexible and advanced business software platform shared with Dynamics AX 4 
  • Customers current on the Service Plan will be able to upgrade to the next generation RMS for no additional license costs. 4
  • The following features will be focused on in this new version:
    • Store management control;
    • Role-based, touch optimized, customizable POS user-interface;
    • Merchandising enhancements for loyalty, pricing, and promotion;
    • Replenishment, assortment management;
    • Alerts and monitoring for hardware, user-interface profiles, and data flows;
    • Multi-channel capabilities:
    • Catalog management, cross channel workflows,
    • Integrated sales channel management,
    • Social commerce;
    • Services (payments, commerce, sites);
    • Microsoft stack integration for Visual Studio, Office, and SharePoint;
    • Localization for individual countries.
  • 'Unnecessary features' like HR and CRM will not be in the AX light version but can be added to the solution if needed 5 Note: This makes me think it will be same code base as full version of AX
Background:
In the Microsoft Dynamics Retail realm, there are several tiers of retail software that a business could choose depending on their size and business needs: POS 2009, RMS 2.0, and AX for Retail. These point of sale solutions will allow tendering at the point of sale as well as integrations to the following Dynamic ERP solutions: Nav, GP and AX. To note, AX is the flagship ERP in the Dynamics product family with the most functionality and flexibility.

POS 2009 is good for very small businesses with only one or two stores. Usually outside consultants are not needed to implement this and the back end ERP is usually something like QuickBooks. RMS is good for small/medium businesses with a few brick and mortar locations. Usually this requires a consultant but not complex enough to keep one busy year round. Mainly just support during things like inventory counts and connection issues to HQ. AX for Retail usually fits in with the rest of the business models and requires a team of consultants to deploy but is robust with the AX back end and very scalable. Just to note, its primarily a cash and carry style POS but in AX 2012, you can create AX Sales Orders from within AX with it so the sky can really be the limit.

My thoughts:
RMS fits in with the majority of companies but there was a big issue with integrations with AX. While there are a few solutions out there to integrate these two, there was never an 'official' one. From what I've seen in a variety of industries, a company rarely lines up software-size wise between ERP and POS needs. It's pretty common that  a company is too small to use AX for Retail but is too big for GP/NAV/QuickBooks. The common consensus was to leverage AX in a limited capacity but alas we never saw anything. AX can fit with almost any business because of its readily customizable features and out of the box (OOTB) functionality. All business models have their quirks and AX is the best in the Microsoft ERP family to accommodate these when they are fairly large.

This new approach from Microsoft looks promising but I'm really interested to figure out what AX 'light' means. Is it going to use the same AX code base and program but be restricted to just certain functionality? Indication from what I've read so far is yes. There has always been 'rumors' that this would happen as it seemed like a natural progression so its good to see it actually coming to fruition. This is fantastic because it will give Microsoft the niche market of proving a single solution that runs RMS but needs very advanced, integrated functionality like HR or production.

Important
As an important take away, make sure your customers are current on their service plan so they will be able to upgrade to the next generation RMS for no additional license costs. 4

Sources:
  1. Microsoft Unveils Dynamics AX-based “Next-Gen RMS” at Retail Realm in Vegas
  2. community.dynamics.com - Microsoft Unveils Dynamics AX-based 'Next-Gen RMS' at Retail Realm in Vegas 
  3. MSDynamicsWorld.com - Understanding Microsoft's Next Gen RMS Begins with a Closer Look at Dynamics AX for Retail’s POS, Mobile, Omnichannel Capabilities  
  4. Retail Hero: RMS "New Version" 
  5. Mohamed Aamer - The Identity of Microsofts 'Next-Gen RMS' Will Be Deeper Than Its Dynamics AX Origins  

Friday, February 1, 2013

1099 tax form issues in AX 2012

It's that time of the year again that everyone loves: Tax Time! [smiley face with party hat]

That being said, it always is an interesting time as an ERP consultant. While everyone gets wrapped up in new mods and hitting deadlines for new functionality after go lives, companies often overlook running the 1099 tax forms in their new ERP until the very last second. This creates some problems as there may be issues with the form for the way the company is using it or due to certain mods.

To establish the basics: What is a 1099? A 1099 tax document is a document containing the income given to an independent contractor as received from a particular business. 1099's variations can also be used for other sources of income, such as dividends, interest, debt cancellation, real estate sale proceeds, etc. These are especially important to all the freelance consultants out there.

These documents must be furnished to the appropriate people by the paying company no later than January 31st. There are penalties assessed to the company for not providing them by this date as well as send out 1099s that are incorrect (~$100 penatly per 1099 returned so it adds up!) Check out the IRS website for more detailed info: http://www.irs.gov/instructions/i1099gi/ar02.html#d0e1927 

Waiting till the last second to test and run these puts a ton of heat on the consultants and IT staff if there are issues and things are done at the last second. If this is the first tax season in a new AX version, test before hand! I hit a 1099 last second scramble issue almost every year with various clients. I try to bring it up to be proactive but I don't always remember to due to workload.

To help out with known issues, below are the list of all AX 2012 1099 related hotfixes as of 2/1/2013. Maybe your issue is in the list. Get it from PartnerSource/CustomerSource or raise a support ticket and ask for it by number to see if its the same issue.
  • 2800289 - Pre payments on PO vendor invoices never show up on the 1099
  • 2800067 - 1099 amounts are understated when you apply a prepayment to a PO vendor invoice or overstated if you run the 1099 update 
  • 2723005 - Tax 1099 not calculated or Debug assertion failed with a stack trace error while creating an invoice for the Received purchase order.
  • 2648973 - Unable to edit the Settled Federal 1099 amount for 1099 transactions. You were able to perform this task in Microsoft Dynamics AX 2009. In addition, the HELP file indicates that you can perform this task.
  • 2714546 - Printing the 1099 report throws an "Invalid Range" exception.
  • 2715927 - 1099 amounts for debit memos do not update VendSettlementTax1099 and 1099 Update with Recalculate does not re-calculate them.
  • 2704309 cu3 - 1099 MISC Vendors print in incorrect boxes or not at depending on what MISC value you set the vendor up as
  • 2703177 cu3 - If you do Centralized Payments for 1099 vendors you can't report on the 1099 amounts in the Paying Company 
  • 2681423 - Tax 1099 duplicate taxpayer Identification report returns invalid results as it always returns every vendor set up to print tax 1099 and has a ID number -- it should be only displaying duplicates
  • 2682717 - Update 1099 includes the tax for the AP Invoice but NOT for the PO Invoice when it writes to the VendSettlementTax1099 table
  • 2648973 - Unable to edit the Settled Federal 1099 amount for 1099 transactions

Thursday, January 24, 2013

AX for Retail Store RetailLog table not logging all RTS XMLs

In an earlier blog post about retail logging, I discuss how you can adjust the RetailLog to capture details about processes in the POS with the highest level of detail (http://daxdude.blogspot.com/2013/01/ax-2012-for-retail-retail-transaction.html). We later encountered a situation where there were issues with only certain tasks or nothing at all were being logged. The biggest thing we were trying to do was capture an XML from RTS so that we could retest in AX without the need for the POS.

After some digging, it was determined that someone with admin-like privileges on that POS machine was able to log these missing calls. I'm not sure if it was something set within the database or the POS machine but the culprit was definitely security privileges. These same differences in security were what made error handling in the POS crash instead of present the user friendly AX message for why the process failed.  Unfortunately we never nailed this down but its definitely an issue.

In summary: Not having proper privileges in the AX 2012 for Retail POS can cause the following problems:
  • POS will crash for error handling
  • RetailLog table in Store DB will not log proper calls
Not too much detail in here and I apologize but thought it was worth sharing since there isn't much out there in the way of this. If you have more specifics in your experiences, please share below.

Friday, January 18, 2013

Create New Purchase Requisition is disabled AX 2012

In AX 2012, when attempting to create a new purchase requisition record, the button can be disabled (greyed out) and the user is unable to create any new records (Figure 1 below). Alternately in one of the purchase requisition list pages, the user can click on 'Edit in Grid', then New Purchase Requisition (it will actually be enabled even though it should not be), enter a name, and be met with the error 'Field 'Preparer' must be filled in' halting any further progress (Figure 2 below).  

SOLUTION: These two issues are due to one and the same configuration issue. See below Figure 2 for the solution.

 Figure 1 - Create New Purchase Requisition button is greyed out (disabled)

Figure 2 - The error 'Field 'Preparer' must be filled in.

The solution to this is just a setup issue involving the actual user who is encountering the issue. The user logging into the system must be linked to an AX worker. 

AX has the concept of 'Workers' and actual AX users. AX users are directly linked with Active Directory accounts and Workers are just setup in AX. A user can be both, an AX user and not be a worker, and a worker and not an AX user. If the user will never log into AX, why make them an AX user? The reason that these users are split up is that there will be many users doing things where they will never access AX but still need to be labeled in transactions (e.g. creating orders in AX for Retail POS or through external applications).

Here is how to fix the issue:
  1. Navigate to the System Administration -> Common -> Users -> 'Users' form  (Figure 3)
  2. Highlight the AX user who is having this problem and click on 'Relations' in the ribbon. This must be the user that is hitting the issue as their AX user needs to be linked to a worker. (Figure 4)
  3. Select the HRM Worker setup for that user in AX in the field 'Person'. The 'User Id' field will already be populated with the user selected in the AX user list. Make sure the 'Effective dates are for before today's date and sometime in the future. If the dates don't encompass the current date, the user won't be able to create purchase requisitions. (Figure 5)
Step 3 above populates the DirPerson and DirPersonUser tables.  After these steps are done, you should be in the clear! Note: If the HRM worker of interest in Step 3 can't be seen in the 'Person' field drop down, the user will need to have a worker setup for them or make sure they are not assigned to another user. I won't go into creating an HRM worker as that is a whole other process... Plenty of stuff out there about how to do that...

 Figure 3 - Navigate to the System administration 'Users' form

Figure 4 - The 'Relations' setup in the AX ribbon

Figure 5 - Setup the link between the HRM Worker and the selected AX user