Referencing a table field

This is a little post about the various ways you can address fields from tables.

Here are some examples.

This could be a static methode, declared on the table CustTable. The goal is to retrieve the customer name, based from the account code.

static Name GetCustName(CustAccount _custAccount)

{ CustTable custTable;

;
select firstonly custTable

index hint AccountIdx

where custTable.AccountNum == _custAccount;

return custTable.Name;

}

This is probably the most common way used.

There are some alternatives for this:

static Name GetCustName(CustAccount _custAccount)

{ CustTable custTable;

;
select firstonly custTable

index hint AccountIdx

where custTable.AccountNum == _custAccount;

return custTable.(2);

}

As you can see here, you can get access to the field by using it's fieldid. You can look up the fieldid in the AOT, as it is the first property displayed for a field of a table.

But maybe you don't have the fieldid, and would like to retrieve the value by using the field name instead. As always, Ax has a function that comes in handy. You can use fieldname2id.

static Name GetCustName(CustAccount _custAccount)

{ CustTable custTable;

;
select firstonly custTable

index hint AccountIdx

where custTable.AccountNum == _custAccount;

return custTable.(fieldname2id(tablenum(CustTable),'Name'));

}

Maybe a bit less known: You are not required to declare the CustTable table identifier. You can write code like this as well.

static Name GetCustName(CustAccount _custAccount)

{ ;

return (select firstonly custTable

index hint AccountIdx

where custTable.AccountNum == _custAccount).Name;

}

Make sure you use the brackets before and after the select statement.

So, plenty of options, whichever approach works for you.

Dynamics Ax and security setup

Microsoft Dynamics Ax has a nice security setup. It hasn't changed much in the last few years, coming from Axapta version 3 to the current version Ax 2009. Basically it comes down to this: You put users together in user groups. Users can be members of multiple user groups. Then you assign security rights to these user groups. There is some more information, like domain setup and record level security, but they are optional.




I would like to focus this post on the rights given to user groups.


This information is collected in the table AccessRightsList.





Now although I am a fan of the security system in Ax, I also believe there is always room for improvement. So here is my case, based on two simple examples.

1) The form LedgerTable.

In this form, access to the control AccountBalance is controlled by the security key LedgerMisc. If you want your users to have access to the account balances, the setup for the security key LedgerMisc is required. But by giving access to this key, you also give access to all the child keys. That's now what you want. So you are forced to turn the parent key (LedgerMisc) on, and it's child keys off. Bad practice in my opinion.

2) Another example for the same scenario, the form Purchtotals.

This form displays the totals for a given purch order. It requires access to the table Common. To be able to use this form, the user must have access to the security key 'AdminTables'. This key has lots of child keys. Certainly you don't want your users to have access rights to all these tables from Admin. So you are forced to turn the parent key (AdminTables) on, and it's child keys off. Again, bad practice in my opinion.

My tips for Microsoft:

1) The inheritance principle is nice. Switch the parent key on, and you get all the child keys. But for a security setup, this is not recommended behaviour. But it would be even better not to assign security keys of the parent type to elements in forms.

2) You promote the use of 'roles' in the program heavily. A lot of marketing material uses these roles, these personas in the Contoso company (the CEO, the clerk, the order processor). Why not deliver a security setup for these various roles? Give the customer the data (security groups with permissions) for these various roles, so the customer doesn't have to start from scratch settting up his security?

Convergence EMEA 2009

Earlier this year Microsoft cancelled it's Convergence EMEA 2009 event. It was supposed to take place in November, in the beautiful city of Vienna. Reason for the cancellation according to Microsoft was the economic downturn. But Microsoft vowed it would rework the concept, and come with something new. They kept promise, details for Convergence EMEA 2009 are now slowly becoming available.

Instead of one big event in one city, spanning multiple days, there are now multiple one day events, all over Europe. The idea behind it? Microsoft brings Convergence to you, so you don't have to go to them. More localized content, less travel expenses, shorter duration. All for the benefit of the customers.
The selected cities are London, Vienna, Frankfurt and Rotterdam. It's all taking place end of October, beginning of November. Find out more on the dedicated website.

I got to attend Convergence in Munich a couple of years ago and last year in Copenhagen. Lots of good sessions, lots of information, great quality speakers. I am curious to see if the change in concept has affected the overall quality.

Changing form layout by users

In Ax, users can change the layout of forms without any knowledge of programming. This can be done by any user, without writing a single line of code.
Users can for example hide/unhide predefined fields, change the sequence of fields and so on. All these customizations are user specific.

If for some reason you want to limit this functionality, you have various options.
For example, you can change the settings for a specific form, by changing the properties of the design node of the form. Set the property AllowUserSetup to No, so that no user modification to the layout is allowed.

If a specific user is not able to hide/unhide fields or to make changes to the form setup (of any form), you might want to check security setup. Make sure access to the key Admin \ Misc \ SysFormPersonalization is switched on.

SAP bashing

Wow! It’s SAP bashing time again.
Apparently some disgruntled customer of an SAP vendor feels left out in the cold.
So he decides to turn his anger and frustration into other use and launches a website, http://saphorrorstories.com/

Now if you search Google for “SAP horror stories” you get a 57.300 hits.
Just for fun, look up “Oracle horror stories”. That racks up 147.000 hits!
Now google “Dynamics horror stories”…
Puts things in perspective for all the Microsoft believers, not?

I have never used any of SAP’s products, and I don’t have any experience with the vendor that is so heavily targeted with this site.

But how come the number 1 ERP player in the world (yes, SAP), fails so miserably? After all, the SAP reseller in question claims “it can help run SAP for small and mid-sized companies”.

I can understand that an ERP implementation goes wrong. As these things costs time and money, it will end up with an unhappy customer.
But the site’s designer is more than unhappy, he’s pretty angry.
How could have gotten things this far? I believe there are two sides to every story. And as different parties are involved in an erp migration project, there sure are different sides here.
Every ERP implementation has it’s milestones: Missing deadlines in an early stage of a project is big warning.
What about the match between required functionality according to the customer and the available functionality in the proposed solution? These are things that can be included in the contract between customer and vendor, before the implementation starts. Just like the required training of personnel. Don’t leave anything in the dark, but it in black and white.

With year 2000 projects and the euro conversion well behind us, one would think that the slogan “no such thing as a bad erp implementation” is reality. But as products get more mature and complex, contain more and more functionality, implementation costs rise. And in today’s market, the need for qualified, trained business consultants grows.

Lots of things in nature come with waves: sometimes draught for weeks, then days of pooring rain.
Similar to that I do believe we are on the rise regarding this issue: More ERP projects will fail the next few years, or not meet predefined targets.

So my advice: Make sure you do your homework before you even start looking for an erp suite.