The email notifications that are sent between users according to the document approvals setup are based on email templates defining which fields and text to show in the notification.
The email template is an HTML file that you can export from Microsoft Dynamics NAV, edit in Word, for example, and then import back to the program where it then defines the content of approval notifications sent between users in the database.
The following default notification email template is shipped with the standard product:
The parameters represent the following variables when used for sales approval notifications:
The parameters represent the following variables when used for purchase approval notifications:
A sales approval notification based on the default template looks approximately as follows:
Note: The program automatically inserts variables in the notification according to the approval action and document type that it notifies about.
If the default mail template for approval notifications does not fit your needs, you can export, edit, and import it as described in the following procedure.
To Set Up a Mail Template for Document Approval Notifications
Begin by exporting the default mail template to a folder on your computer.
1. From the navigation pane, click Administration, and then click Application Setup
2. Click Document Approval, and then click Approval Setup.
3. In the Approval Setup window, click Mail Templates, point to Approval Mail Template, and then click Export.
4. Give the HTML file a name, such as “notification mail.htm”, and save it in any folder.
Proceed to edit the template to define which fields to include in approval notifications in your company.
1. Locate the exported template file.
2. Right-click on the file, point to Open with, and then click Word (or Note Pad).
3. Edit the template by adding, changing, or removing variables to define the notification content you want.
4. Save and close the HTML file.
Finish by importing the changed template.
3. In the Approval Setup window, click Mail Templates, point to Approval Mail Template, and then click Import.
4. Select the HTML file you edited in the previous steps, and then click OK.
5. Click Yes to overwrite the existing mail template in the database.
Overdue Mail Template
To define the content of reminder emails to users concerning overdue approval actions, follow the same procedure as for notification mails, but begin by clicking Mail Templates, and then point to Overdue Mail Template in the Approvals Setup window.
- Soren Groes-Petersen
We support the following versions of Microsoft Dynamics NAV with Microsoft Windows Server 2008 R2 and Microsoft Windows 7: Microsoft Dynamics NAV 2009 SP1. Please note though that tests are currently taking place on the compatibility of Microsoft Dynamics NAV 5.0 SP1 with Microsoft Windows 7 and Microsoft Windows Server 2008 R2. Furthermore, the compatibility for Microsoft Windows Server 2008 R2 does not cover Business Notification for Microsoft Dynamics NAV and Commerce Gateway.
For more information about requirements, please go to http://msdn.microsoft.com/en-us/library/dd301054.aspx.
Did find an interesting tool developed by Kine yesterday about managing multiple service in NAV 2009. So what can this tool do?
Kine's post about the tool: HereZip: NAV2009_NST_Management_1_0_0_debug.zipSource code: http://github.com/kine/NAV_NST_Management
If you're going to blog as infrequently as I have, it's a good policy to make sure that when you do, you focus on very important subjects. Since this is my first post since last fall's "Microsoft Dynamics NAV 2009 Ships!" entry, I'm happy to say I'm following my own policy. Today, we are releasing Microsoft Dynamics NAV 2009 SP1 to customers and partners, and my enthusiasm for what we've done for you, with you, is just as immense as it was when we shipped Microsoft Dynamics NAV 2009. Of course this time, I'm excited about different things.
Let's rewind for a moment to set the stage: Last November, we released what I called a landmark release of Microsoft Dynamics NAV 2009. We transformed the user experience, revolutionizing and modernizing the rich client with a RoleTailored approach to design. We also significantly refactored the product's architecture introducing three tiers, Web services, a .NET runtime, and RDL reports for SQL. It was a mountain of a release, and we hit the summit.
Microsoft Dynamics NAV 2009 was a release of courage. We made big bets. We wanted nothing short of transformation. And we accomplished our goal, shipping what is arguably the most significant release in Microsoft Dynamics NAV history.
Microsoft Dynamics NAV 2009 SP1, by contrast, is a release of precision. We listened and collaborated with you, our partners and customers. We refined. We executed predictably. And, less than 12 months after the release of Microsoft Dynamics NAV 2009, we are giving you a service pack that extends the value of Microsoft Dynamics NAV 2009 and meets our joint goal of making Microsoft Dynamics NAV simply the most productive middle-market ERP product on the planet. In this way, it is as just as big as the release it is built upon.
Here's how we did it and what we're giving you.
When Microsoft Dynamics NAV 2009 shipped, we had a number of customers in our Technical Adoption Program (TAP) already live on the product. These customers and the partners providing them solutions together gave us a tremendous amount of feedback on the product. Much of this feedback influenced what we shipped in Microsoft Dynamics NAV 2009. But we couldn't respond to all of the feedback in our timeline for shipping. In addition, we wanted to add productivity improvements for both customers and partners, and features that took advantage of our new client architecture. So we decided to release this service pack and invest a fair bit in it.
The features we have added to increase customer productivity follow the six dimensions of productivity I discussed originally in my Microsoft Dynamics NAV 2009 blog - usability, familiarity, flexibility, transactional efficiency, business insight, and collaboration. For example, the new Search box will be instantly familiar to users of Internet Explorer and will reduce the time it takes to find list places not already available in one's Role Center. In addition, users can now persist filtered views of list places, filter-as-you-type columns, and the default number of lines in a document page grid. We have provided transactional efficiency increases with some refactored matrix forms, a large increase in keyboard enablement, and the addition of many Classic client keyboard combinations. Reporting drill-down enhancements further improve business insight, and the Online Connect part gives users access to communities, knowledge base articles, and learning directly from the Role Center, and promotes collaboration with the Microsoft Dynamics NAV community.
The features we have added to increase partner productivity are equally extensive. We improved the efficiency of page design by adding a page wizard and providing edit-and-run capabilities for pages directly from within the C/SIDE environment. We added data zoom (About This Page) to pages, which provides helpful page information and is similar to how partners have historically worked with forms. We added fixed IDs to page transformation, which should help ISVs manage their implementations better. Finally, we increased our documentation for partners, for example, adding walkthroughs for installation.
But probably the most intriguing feature we have added for partners is client extensibility. We have exposed the client API and provided a very simple model for adding managed code controls to pages from C/SIDE, so that partners can now develop custom user experience parts that take advantage of powerful Microsoft technologies like Microsoft Silverlight, Windows Presentation Foundation (WPF), and Windows Forms. The opportunity for partners to differentiate their solutions from the competition through user experience innovation is limitless, and builds on the thought leadership we've provided in Microsoft Dynamics NAV 2009. We're looking forward to an explosion of creativity!
None of this would have been possible without the unmatched support we've received from our partners and customers, especially through (but certainly not limited to) our TAP and ISV Beta Access Program (BAP).Whether through surveys, group meetings, informal e-mails, or short conversations at events, we've received a tremendous amount of feedback on Microsoft Dynamics NAV 2009.We've taken this feedback, incorporated it, worked with our TAP customers and partners to evaluate the results of this service pack, and now we're shipping it. Thanks many times over for your incredible support, devotion, and passion for Microsoft Dynamics NAV. Together, we've made a great product even greater.
Before I finish this blog post, I want to mention something I ended my Microsoft Dynamics NAV 2009 Ships blog entry with: quality. At that time, I said, "Perhaps the thing I'm most proud about in this release is that we've substantially improved quality." That's true again with Microsoft Dynamics NAV 2009 SP1.We've continued to increase the bar on quality. In our customer satisfaction surveys, the reliability of Microsoft Dynamics NAV has always received high marks. And we're making it better and better. I simply can't emphasize enough how important quality is to us. And we know it's important to you.
I hope you're as excited about Microsoft Dynamics NAV 2009 SP1 as I am. Download a copy from CustomerSource or PartnerSource, or try out the Microsoft Dynamics NAV 2009 SP1 VPC and let us know what you think!
P.S. A final thought: For those of you who are intrigued by Microsoft codenames, Microsoft Dynamics NAV 2009 was once called Corsica. Indeed, the mountains of Corsica are tall, and the highest summit is Monte Cinto at 2700 meters, or just shy of 9000 feet. The view from this summit is unique because the mountain's island location in the Mediterranean gives it a wide panorama and views of other mountains that are quite distant. As we said when we released Microsoft Dynamics NAV 2009, "The view from the top rocks!"
The usual rule for specifying a key in NAV is, that it will chose the first key that matches all the fields specified by SETCURRENTKEY, RunformLink, etc.
Example:Table 21 "Cust. Ledger Entry" has the following keys (not all of them listed): - Entry No. - Customer No.,Posting Date,Currency Code - Customer No.,Open,Positive,Due Date,Currency Code - Customer No.,Applies-to ID,Open,Positive,Due Date You have code like this:CustLedgEntry.SETCURRENTKEY("Customer No.");CustLedgEntry.FINDFIRST; You will get a query with this ORDER BY:ORDER BY "Customer No_","Posting Date","Currency Code","Entry No_" So far, all works as expected: NAV finds the first key that matches the sorting, and uses that. This changes if you change the SQLIndex property on the key. If we design table 21 and set SQLIndex = "Customer No." on the key used above, then NAV will skip this key and use the next matching one, and the code above will now generate this ORDER BY:ORDER BY "Customer No_","Open","Positive","Due Date","Currency Code","Entry No_" So now, even if we want to sort by "Customer No.", and we have a SQL Index which is exactly that, NAV chooses a different index. And it no longer follows the rule of choosing the first key available which satisfies the requested sorting. So specifying SQLIndex on a key makes this key less likely to be chosen by NAV. Of course, this does not affect which index SQL Server actually decides on when it makes its query plan. It only afects the ORDER BY clause.
The reason for this is:
Above is mentioned that we want to sort on "Customer No.". This is not the whole truth. NAV always adds the primay key, so actually we want to sort on "Customer No.", "Entry No.". The primary key fields are used for specifying a sorting (ORDER BY) that is deterministic and they are also used to construct SQL for calls to Record.NEXT(), which might be needed to reposition itself in the database. This happens a lot from the UI but also from C/AL code.
So the short story is: When SQLIndex is used, they key will by definition not match the ORDER BY which is based on the NAV key, and the index is likely to not be unique, so NAV will give the key a lower priority when there are other similar keys which do not have SQLIndex specified.
Only when a SQL index is NOT specified, NAV automatically adds the primary key field(s) when it creates the index on SQL server. When we do add SQLIndex, this does not happen - the SQL Index will be exactly what you specify in this property. In this example where we set SQLIndex to "Customer No.", the SQL Index will just be just that - "Customer No_", so it will not be unique and it will not satisfy an ORDER BY on “Customer No.,Posting Date,Currency Code, Entry No.” and it will not satisfy calls to Record.Next(). So when SQLIndex is specified, NAV will continue down the list of keys, looking for the next key that matches the chosen sorting (and does not have SQLIndex specified) and use that instead. It’s recommended to use the SQLIndex property with great caution. Also see previous blog posts:Beware the SQL Index property on NAV 5.0 SP1 SQLIndex property If you do use it, then also be aware of the changes in behaviour described here
Microsoft Dynamics UK
Microsoft Customer Service and Support (CSS) EMEA
We have now released Service Pack 1 for Microsoft Dynamics NAV. So you will now all be able to use the new Reporting features in this Service Pack. Previously I have described all new reporting features in this Service Pack. Please find all these features described here: What is new in Dynamics NAV 2009 SP1 for Reporting.
Thanks, Claus Lundstrøm, Program Manager, Microsoft Dynamics NAV
Today I found a really good and interesting blog about general troubleshooting of multi-machine scenarios in NAV 2009. Most of the blog is checking SPN settings, delegations settings and different problems with those.
IntroThe NAV 2009 documentation walkthroughs provide step-by-step instructions for installing NAV 2009 on 2 or 3 machines. However, we have found that some of the same configuration issues come up time after time after installation.When on calls with partners and customers, it seemed to me that this information was spread out all over the place, so I wanted to organize it in a different way for troubleshooting purposes so that I would have most everything in one place. Hopefully this will be helpful to others as well.The intention of this post is to provide a checklist of sorts for troubleshooting some of the areas where we frequently find errors or omissions in configuration after NAV 2009 has been installed.
Find the whole blog here: http://blogs.msdn.com/nav_developer/archive/2009/08/17/troubleshooting-multi-machine-installations-of-nav-2009.aspx
We have released the source files for Dynamics NAV 2009 SP1 Help to PartnerSource. This release includes 8 different languages across 16 countries/regions, approximately 1 million files, and about 2.5 GB of content. If it were in book format, that would stack up to about 10 meters of books. That's a lot of help for a lot of users!
With these source files and the previously released Help Toolkit for SP1 (also on PartnerSource), you can modify the Help files to match customizations that you create. Go ahead, add to the stack of content and customize the Help that you provide to your users!
And as always, let us know what you think about the Help, the customization process, the tools, what's missing, and what would be more helpful.
When doing an upgrade running Microsoft Dynamics NAV CSIDE client on the same machine as your SQL server, please run the CSIDE client with full administrator rights (Run as administrator).
The reason why this is important is because, when connecting locally from a Vista/Windows 2008 server to SQL Server, it will strip down the Windows token from, among other things, honoring builtin\Administrator membership, unless connecting from an elevated command (run as administrator).
This is especially important when doing upgrades for NAV 2009 SP1.
This should not be needed if you connect from a remote workstation to SQL server.
After Microsoft Dynamics NAV 2009 SP1 released, more and more developers started using it and trying to adopt existing solutions for new 3tier environment.Most workload comes from trying to adopt current forms to new object - pages.Particularly transformation could be done by using TransformationTools (http://msdn.microsoft.com/en-us/library/dd338789.aspx), however it is not "best ever" and partners reporting problems and require to fix it...
But it isn't so easy...
This tool is delivered to us from dev team and it helps us to make transformation faster, but it is supplementary tool - we can use NAV without this tool and we can "convert " our solutions without it - do it manually.So "big thanks" to dev team for this tool, however we can't expect that dev team will fix all problems in tool with the same priority as base products (Microsoft Dynamics NAV).
And we can't expect fixes for problems related to incorrect transformed statements - after transformation pages can't be compiled...Problem is in tool simplicity: it searches for text and convert it to another text. Converting rules are described in file CodeRules.txt (http://msdn.microsoft.com/en-us/library/dd338843.aspx).But simplicity is as strength as weakness of this tool - only text described in CodeRules.txt file will be converted, if there are any differences in text - transformation will be incorrect.For example:In form code we have statement:CurrForm.Number.UPDATEFONTBOLD(Number);Then after transformation on page will be created new variable NumberEmphasizeAnd statement will be converted to:NumberEmphasize := Number;It is because UPDATEFONTBOLD is not used in pages and must be removed.
So far so good.Tranformation will be done correct for statements:CurrForm.Number.UPDATEFONTBOLD(Number1=Number);CurrForm.Number.UPDATEFONTBOLD(Number1>Number);and etc. because transformation rules are described in CodeRules.txt
But transformation tool is looking for direct text fit to rules and will not transform text which is not described in Coderules.txt. If code becomes little more complicated (not described the same syntax as CodeRules) - transformation tool capitulates.For example next code will not be transformed:CurrForm.Number.UPDATEFONTBOLD(Number1<Number);CurrForm.Number.UPDATEFONTBOLD(Number1=xRec.Number);CurrForm.Number.UPDATEFONTBOLD(xRec.Number1=Number);CurrForm.Number.UPDATEFONTBOLD(Number1=Number2=Number3);CurrForm.Number.UPDATEFONTBOLD(Number1=(Number+100));...Yes... We can make rules for these statements too (dev team delivered rules file), but we will never describe everything what could be written by happy-creative developpers around the world...Maybe some rules could be never used? Who knows..?
I can collect all requirements for CodeRules.txt and periodically release new one (fixed). Do you want to order me do it, let me know in comment to current post :) ...
These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.
Gedas Busniauskas (gediminb)
Microsoft LithuaniaMicrosoft Customer Service and Support (CSS) EMEA