... you still can for the first DDC event in 2011 (and the second ever ).

As we communicated before, this time we will have 2 sequential sessions and contrary to our first event this will NOT be a purely technical happening.

The first session will be performed by Arne de Booij, Senior UX Researcher at Microsoft for the Dynamics product family. In this session Arne will shed light on the background of the role-based thinking and,based on the results of a survey among more than 15 companies in multiple countries, illustrates how Role Based client of Microsoft Dynamics is used in day-to-day business.

You can still subscribe to the 2nd Event

Send us a e-mail: events@dutchdynamics.net with the following details:

1. Full Name
2. Name of the Company you work for/at.
3. Status of the Company: partner/klant/zzp

When was your last time facing this screen?

Mine was last week. And then I took the screen shot and decided to write a blog on it. Or actually, I had even decided on that way-before as this "feedback" screen keeps on appearing every now and then. Even those days-after every time I dutifully did "help".

I guess I can cope with that Usability Sciences stalker. I can cope with the fact that for every search I do on PartnerSource I have to relearn how to find what I am looking for. Fortunately I am using it daily. Also fortunately for my colleagues who often refer to me when they have to use PartnerSource.

So when I give feedback I can positively answer all questions as I do find what I am looking for; and, yes, I am using it frequently; and, yes, it makes sense to use it; and, .... And PartnerSource stays as it was.

I have no proof, but it seems to me PartnerSource hasn't changed since it started as PartnerGuide. Probably it has, but not much. At least is doesn't make me happy.

It's all so inefficient, counter-intuitive, so opposite to the user experience of MS product.

Create a Support Request

Just a small example. Ever created a support request? If you select Support > New Support Request you get to a screen with this section:

So I push the blue (NAV) button. And on the next page I will push this button:

Which lead me to the start of my new support request.

I select the company and click next.

Didn't I select NAV already?

Epilogue

Am I wrong assuming that all I am writing about PartnerSource also applies to CustomerSource?

Update 2011-01-30

Want to share your experiences, judgements and suggestions: write them below, MS seems interested; they contacted me on this!

Update 2011-06-16

The above example still hasn't been improved.

Update 2011-10-11

The above example still hasn't been improved.

MS seemed interested though.

Update 2012-10-14

More than 1 year passed and still the above example hasn't been improved.

.. not a "normal" release ... beware!, Waldo informed us on his blog almost 2 weeks ago.

This post is just to add some info on the things I encountered today. No big issues (so far), but some minor, mainly translation matters.

Comparing R2 NL with NAV 2009 SP1 NL showed me that:

• For what ever reason the ENU term No. Series has now been wrongly translated to NLD Nr.-reeksen after ages of right translation; i.e. Nr.-reeks
  
  This affects the following table objects:
  
   

  TAB17	TAB210	TAB5621	TAB5994
  TAB18	TAB232	TAB5625	TAB7309
  TAB21	TAB233	TAB5628	TAB7310
  TAB23	TAB234	TAB5050	TAB7311
  TAB25	TAB236	TAB5107	TAB7312
  TAB27	TAB237	TAB5109	TAB7316
  TAB32	TAB246	TAB5619	TAB7320
  TAB37	TAB270	TAB5620	TAB7322
  TAB38	TAB277	TAB5629	TAB7331
  TAB77	TAB281	TAB5633	TAB7333
  TAB81	TAB295	TAB5634	TAB7340
  TAB82	TAB297	TAB5635	TAB7342
  TAB83	TAB302	TAB6650	TAB11307
  TAB88	TAB304	TAB6660	TAB11400
  TAB89	TAB308	TAB5718	TAB11401
  TAB110	TAB370	TAB5740	TAB11000000
  TAB112	TAB382	TAB5744	TAB99000754
  TAB114	TAB751	TAB5746	TAB99000758
  TAB120	TAB753	TAB5772	TAB99000763
  TAB122	TAB5071	TAB5900	TAB99000771
  TAB124	TAB5076	TAB5913	TAB99000779
  TAB156	TAB5080	TAB5940	TAB99000786
  TAB167	TAB5092	TAB5943	TAB99008504
  TAB169	TAB5097	TAB5965	TAB99008500
  TAB203	TAB5200	TAB5968	TAB99008502
  TAB206	TAB5405	TAB5970	TAB99008505
  TAB207	TAB5600	TAB5990	TAB99008508
  TAB209	TAB5601	TAB5992

  
  .., and next to that MEN10 and MEN1010.
   
• Same applies with respect to the ENU noun View. Until R2 this rightly translated to the NLD noun Weergave. With R2 this has been wrongly  translated to the NLD verb Weergeven.
   

  FOR521	PAG11407	PAG11000000	PAG11000016
  FOR8710	PAG11412	PAG11000002	PAG11000017
  PAG521	PAG11413	PAG11000004
  PAG8710	PAG11415	PAG11000006
  PAG11406	PAG11418	PAG11000012

  
  BTW: This reminds of the first translation we got after the MS take over of Navision, when all of a sudden the ENU adjective Open was translated to the NLD verb Openen instead of the NLD adjective Open.
   
• In Report 5606 the ENU term Total is no longer translated to NLD Totaal, but seems to have been copied straight from the ENU caption: Total. Yes, we have Total fuel stations, but apart from that total is non NLD.
   
• For another obscure reason the following objects have an updated object Date, i.e. it has been set to 11-12-10 (dd-mm-yy), without any other changes to these objects:
   

  COD11402	FOR11000000	TAB11407	TAB2000000072
  COD11000004	FOR11000002	TAB11411	TAB2000000073
  COD11000007	FOR11000004	TAB11000005	TAB2000000074
  COD11000008	FOR11000006	TAB11000008	TAB2000000075
  COD11000009	FOR11000012	TAB11000009	TAB2000000076
  FOR11406	FOR11000016	TAB2000000065	TAB2000000078
  FOR11407	FOR11000017	TAB2000000066	TAB2000000079
  FOR11412	MEN10	TAB2000000067	TAB2000000080
  FOR11413	MEN1010	TAB2000000068	TAB2000000203
  FOR11415	REP11000003	TAB2000000069
  FOR11418	TAB11405	TAB2000000071

Next to these two errors I stumbled over two other issues:

• In Reports 11401 and 11402 the ENU term parcel(s) used to be translated  to NLD collo/colli.With R2 this has simplified to Colli.
• In Codeunits 5813, 5814, 5815, 5816 and 5818 a grammatical error was fixed: ENU undo was erroneously translated as NLD ongendaan and should have been ongedaan. This has been corrected.
  
  But ... I am not sure if I do understand the translation of the full text constant:
  
       ENU=Undo quantity posting...-> NLD=Aantal boeken ongedaan maken...'
  
  ... as NLD Aantal boeken seems to me wrong.

This altogether makes me wonder if other local version suffer from the same kind of issues.

Update 2011-01-27

•  Have a look at COD5056: both Date and Version List have been updated, but only one empty line has been removed for code!

• And what to think about COD99008517. This does not makes sense to me:

•  Another 'nice' one: PAG64 (note that the Version List has not been changed):

Update 2011-01-28

• Another very useful (but not) caption change in TAB277:

•  And TAB7701 (Dutch caption have now turned into English - similar issue on TAB7700):

... unless your have a good reason for it!

Already a year ago I wrote my Validating Data series. And only a couple of weeks ago me and my colleague were investigating one of our solutions that had a performance issue and were faced with code that wasn't quite SMART with respect to using VALIDATEs. If you're not sure what I am referring to (re)read this post: Validating Data #4: Assignment and VALIDATE.

Rule-of-Thumb vs. Rule-of-Thumb

And there we were sitting.  Me wondering how an intelligent developer could have done this. My colleague (not his code; not mine either) wondering what actually was wrong about it. As became clear we both were looking from a very different perspective at these lines of code where a number of fields were populated and validated at the same time.

My perspective based on the rule-of-thumb saying: Never use VALIDATE ... unless you have a (very) good reason for it. Or, quoting Marq in my post, "... to avoid the validate statement when populating records ...".

My colleagues rule-of-thumb: always validate a field when assigning a value, because you're never sure validation code is behind it.

I (still) think I could make my point and could clarify that his rule-of-thumb is definitely not a good enough reason to use VALIDATEs. So I would like to stress to you all again:

Never use VALIDATE ...

... unless you have a good reason for it.

If you're not sure what I mean or disagree. Read my Validating Data series and challenge me below.

BTW ...

... dimishing the number of VALIDATE statement in our code did help, but (unfortunately) wasn't the main problem.

Update 2011-01-30

After you did read this post be sure to read the comments below as I wrote it because of the discussion. And of course, if you did not read my Validating Data series yet take your time for it.

With this BaIS sequel I am going to create a collection of findings and thoughts on the various things we are coming across within Imtech ICT during our quest in building international solutions. Findings and thoughts not always logically ordered, but worth sharing with and getting comments on from the Dynamics community. So be invited to comment on them.

Possibly this might lead to some sort of white paper on BaIS and Dynamics NAV, who knows.

BaIS #1: Source Control, Branching and Merging

Building international solutions with multiple developers for multiple countries places us for the challenge how to manage/control our code. This is not only about how we secure the code and the change history, but also about how to propagate changes from the international code to local code, i.e. from our w1 to, let's say, to a UK version. Or even from our horizontal solution into various vertical solutions. Altogether we need a source control system that:

1. secures our code
2. enables us to
   • branch code
   • merge changes from one branch to the other
   • revert to a previous version
3. allows parallel development
4. and maybe even let us automatically create builds

Code in .txt Format

As Dynamics NAV does not have an on-board source control system and no NAV-aware source control system seems to exist that can cover our need, we had to do it with existing systems. First of all this forces us to store our code (objects) in .txt format. Not a big problem as such, but of course no standard tool now that can check the syntax of my code. But OK, I can live with that. I have done it at MS for many years already.

No Captions

No captions should be stored in the code objects. For a number of reasons:

1. Developers should only focus on the code and not on language matters, so they will only be occupied with naming objects and defining ENU texts (for messages, etc.)
2. Object captions can automatically be created during the translation process (see one of the following posts on BaIS), so no need for developers to spend time on that. OK some exceptions:
   1. ENU caption of Text Constant
   2. ENU caption of unbounded controls (on Forms/Reports/Pages)
3. Captions (and especially local captions) pollute the .txt code objects in the sense that comparing w1 code objects with localized objects for code development purposes will show many irrelevant differences (see screen shot)

Source Control System

As might have concluded from a number of my other posts we decided to take Visual Studio Team Foundation Server as our source control system. We are working with it and the same time still investigating. Too early to share things on that so one of the upcoming BaIS posts will probably be dedicated to that.