Project Hour Sales Price by Project Contract or Customer Account is Not Implemented

During an AX 4.0 to AX 2012 R2 upgrade, I came across an issue with the Project Hour Sales Price functionality.

This functionality had been implemented in AX 4.0 and AX 2009, removed for AX 2012, and then added back in AX 2012 R2 CU6.

In the Project Hours Sales Price form, you're able to specify pricing based on a variety of criteria as seen in the image below.

Prior to the 2012 R2 CU6 release, the Project contract ID and Customer account fields, both in AX 4.0 and 2009, were not available. With the 2012 R2 CU6 release, these fields were reintroduced to the form. However, the code behind the form for selecting pricing records was not updated appropriately.

The Hours Journal and Project Timesheet forms both call a method, findHourSalesPrice, in the ProjHourSalesPrice table. When we review this method, we see a few interesting things.

1. The code in the findHourSalesPrice method makes no reference to Project contract ID or Customer account. Sections in the method where we would expect to see a Project contract ID or Customer account are replaced with blank strings.
   
2. There is PSA specific code (from 4.0/2009) that is used to determine pricing by Project contract ID and Customer account. However, this code is never called from the Hours Journal or Project Timesheet forms. The code relies on the Price group, Customer account, or Project contract ID being passed from the Hours Journal or Project Timesheet form.
   
3. Price searching is performed differently between the findHourSalesPrice and psaFindHourSalesPrice methods and differently in the psaFindHourSalesPrice based on the valid for value provided.
   
   

   Method: findHourSalesPrice	Method: psaFindHourSalesPrice
   	Valid For: Table	Valid For: Group	Valid For: All
   Project ID + Worker + Category Project ID + Worker Project ID + Category Project ID	Project ID + Worker + Category Project ID + Worker Project ID + Category Project ID Project contract ID Customer account Category + Worker Worker Category	Worker + Category Worker Category	Worker + Category Worker Category

Microsoft has identified this as being an issue and will address it in a future hotfix.

Use of the Corrected Sales Tax Amount/Actual Sales Tax Amount field in AX 2012

Recently, we've encountered an issue with the Corrected Sales Tax Amount(AX 2009)/Actual Sales Tax Amount (AX 2012) field on the Invoice Journal form.

In AX 2009 and prior, you could adjust the sales tax for a given invoice journal line by changing the value in this field. The field could be added to the lines section of the invoice journal and entered quickly.

In AX 2012 using this functionality with the Public Sector and Project configuration keys enabled causes several problems.

1. Automatic sales tax calculations are no longer carried to Actual Sales Tax Amount field after a sales tax adjustment
   
   After performing a sales tax adjustment using the Actual Sales Tax Amount field, the Sales Tax Override field is set for all new records following. With the override field set and no Adjusted Sales Tax Amount specified in the Sales Tax dialog of the Invoice Journal form, the sales tax appears as 0.
   
   To correct this, a user must enter the Sales Tax dialog and reset the sales tax values.
   
   
2. Records are not removed from the TaxUncommitted table
   
   A record for the adjusted sales tax is created in the TaxUncommitted table. If information is to change on the line (sales tax group, invoice, date) with a modification made to the Actual Sales Tax Amount, the record may not be removed. When attempting to post the journal, all records referencing the specific journal in the TaxUncommitted table are used to create the relevant ledger transactions. As there is an additional TaxUncommitted transaction, the voucher will not balance, preventing posting.
   
   Again, the solution to this issue is to open the Sales Tax dialog and reset the tax values.

Our solution has been to disable use of the Actual Sales Tax Amount field on invoice journals and have users open the Sales Tax dialog for adjusting sales tax entries.

Year-End Purchase Order Process and Encumbrance

We've been using the new encumbrance feature provided by DAX 2012 to create commitments at time of purchase order confirmation. It works quite well compared with our previous method, which was to use product receipts to represent commitments. However, we've ran into an issue that has greatly complicated our year-end process.

When closing a fiscal period, the outstanding purchase order encumbrance is relieved from the budget on closing of the current fiscal period and added back on opening of the next fiscal period. Pretty straight forward, right?

Well, when the encumbrance is reversed, the original transaction is reversed as per the reverse transaction functionality in AX. This means that if your account structures have changed throughout the year for whatever reason, you will not be able to reverse the transactions without reverting the account structure. 

So, you perform the year-end process for the purchase orders under the original accounting structure and then the new accounting structure. Everything should be good, right?

But what about purchase orders that were committed under the original accounting structure and then amended and committed under the new accounting structure. You now have two transactions under different accounting structures that are trying to be reversed under a single accounting structure. As expected, the year-end process fails and you're stuck.

Microsoft has released a hotfix (http://support.microsoft.com/kb/2579432) to address similar issues in other areas. With any luck, we'll get something similar for purchase order year-end processing.

More information on the purchase order year-end process can be found at:
http://technet.microsoft.com/en-us/library/hh209300.aspx

Default Date Formats

Date formats in Dynamics AX can be a bit of a challenge. There are a few different locations to manage date formats. Any modifications made to each location can lead to an entirely different result.

• System and user language
  The system language is used to define the default language when creating new records in AX. Examples of records that default from the system language parameter are vendors, customers, organizations and users. Languages define the format that will be used for date, time, and currency in the system and reporting.
  
  When a new user is created, their Language setting (set under the users > user account > options dialog) will default to the value specified in the System language parameter.
  
  As such, if the system language is set to EN-CA (for Canada), a newly created user will see dates as dd/MM/yyyy. By changing the user's language to EN-US (for USA), that same user will now see dates as MM/dd/yyyy.

• Report language
  The report language parameter set in Visual Studio for a given report can be change to alter the display format of date, time, and currency. As with user language, each language is tied to a specific date, time, and currency format.

• Control specific formats
  Controls, such as text boxes, can have specific formats set to display dates as desired. To apply formatting to a given control, right click the field and view the field's properties.

• Using expressions to get exact values
  Expressions can be used to display a field as desired. For example, if you are only concerned with the month of a given field, you can use the expression =Month(fields!transdate.value) to show only the month. Using expressions allows you to do significantly more with date fields.