OK – can anyone tell me what’s unusual about this image?
Showing posts with label New Features. Show all posts
Showing posts with label New Features. Show all posts
Wednesday, 13 May 2009
Sunday, 18 January 2009
Where is that MenuSuite option in NAV 2009? Part 2.
In my first post on the MenuSuite search, I discovered that in NAV 2009 we can get at the MenuSuite through a blob field on the Object Metadata table.
In this post, I'll go one step further to see if we can start to do something with the blob.
The first thing I wanted to know is: do I need to worry about merging the various MenuSuites? When the MenuSuite is exported as text it contains only the differences that should be applied to the previous MenuSuite. For example 1080 (Partner Level) stores the differences that need to be applied to 1020 (Regional level) which in turn stores the differences that need to be applied to 1010 (Dept – MBS level).
I used a text comparison tool to compare my 1080 XML export to my 1020 XML and I can see that the 1080 is the full combined MenuSuite – perfect! This means I don’t have to worry about merging these files together. If I search for the items I want in the MenuSuite with the highest number, I will be looking at the correct menu structure.
Next I need to know what I am looking for in the XML file. If I take a look through the 1080 file, I can see we are looking for an Actions node with an xsi:type attribute of “ActionDefinition”. This will give me the node that is going to run an option. Within this node I can see there is a CaptionML attribute that I can search to try and match the string I am looking for.
My next programming task is to see if I can get the XML document loaded into an XMLDOM automation control inside NAV. Once again, this was a lot easier than I thought it was going to be. I'm not doing much with the XMLDOM, simply loading it and then saving it again so I can check everythig is working. Here's the code:
In this post, I'll go one step further to see if we can start to do something with the blob.
The first thing I wanted to know is: do I need to worry about merging the various MenuSuites? When the MenuSuite is exported as text it contains only the differences that should be applied to the previous MenuSuite. For example 1080 (Partner Level) stores the differences that need to be applied to 1020 (Regional level) which in turn stores the differences that need to be applied to 1010 (Dept – MBS level).
I used a text comparison tool to compare my 1080 XML export to my 1020 XML and I can see that the 1080 is the full combined MenuSuite – perfect! This means I don’t have to worry about merging these files together. If I search for the items I want in the MenuSuite with the highest number, I will be looking at the correct menu structure.
Next I need to know what I am looking for in the XML file. If I take a look through the 1080 file, I can see we are looking for an Actions node with an xsi:type attribute of “ActionDefinition”. This will give me the node that is going to run an option. Within this node I can see there is a CaptionML attribute that I can search to try and match the string I am looking for.
My next programming task is to see if I can get the XML document loaded into an XMLDOM automation control inside NAV. Once again, this was a lot easier than I thought it was going to be. I'm not doing much with the XMLDOM, simply loading it and then saving it again so I can check everythig is working. Here's the code:
OBJECT Codeunit 91360 Export MenuSuite Objects
{
OBJECT-PROPERTIES
{
Modified=Yes;
Version List=;
}
PROPERTIES
{
OnRun=VAR
l_ObjectMetadata@1000000004 : Record 2000000071;
l_XMLDoc@1000000000 : Automation "{F5078F18-C551-11D3-89B9-0000F81FE221} 4.0:{F6D90F11-9C73-11D3-B32E-00C04F990BB4}:'Microsoft XML, v4.0'.DOMDocument";
l_InStream@1000000001 : InStream;
BEGIN
// MenuSuite items in the RoleTailored client are stored in the range 1000..1999
// They map to the Classic client numbers but with 1000 added to the number.
CREATE(l_XMLDoc, FALSE, FALSE);
l_ObjectMetadata.SETRANGE("Object Type", l_ObjectMetadata."Object Type"::MenuSuite);
l_ObjectMetadata.SETRANGE("Object ID", 1000, 1999);
// The XML document for the highest number contains all nodes not just the changes.
// so we only need to do a FINDLAST
IF NOT l_ObjectMetadata.FINDLAST THEN
ERROR('Something went wrong. There was no Object Metadata for the RoleTailored MenuSuites.\'+
'This sample only works with NAV 2009.');
l_ObjectMetadata.CALCFIELDS(Metadata);
l_ObjectMetadata.Metadata.CREATEINSTREAM(l_InStream);
l_XMLDoc.load(l_InStream);
// Just to check to see if I have my XMLDoc loaded correctly, I'm going to save it and
// then open it in my browser.
l_XMLDoc.save(TEMPORARYPATH+STRSUBSTNO('XMLDOM_%1.xml',l_ObjectMetadata."Object ID"));
HYPERLINK(TEMPORARYPATH+STRSUBSTNO('XMLDOM_%1.xml',l_ObjectMetadata."Object ID"));
END;
}
CODE
{
BEGIN
END.
}
}
Tuesday, 13 January 2009
Where is that menu option in NAV 2009?
Ever since the Outlook-style menu was added to Dynamics NAV, I have struggled to find the options I want. Eventually I got used to where things were in the standard system but as soon as the end users or over-zealous consultants made modifications to the MenuSuite objects, I found I was lost once again.
So what is the solution? Obviously I needed a tool to help me find the option I was looking for. In my dream world, I could type "Payment" into a search box and have the following results presented to me:
Financial Management | Cash Management | Payment Journals
Financial Management | Payables | Payment Journals
Financial Management | Receivables | Documents | Customer Payment
Financial Management | Receivables | Setup | Customer Payment
Etc.
It would be really nice to then be able to click a button to launch the option and hopefully, by seeing where the option is, commit to memory where the item can be found.
Previously building a solution such as this was too hard (for me). This was mainly due to the export formats available to version prior to NAV 2009. You could sort of do this by exporting the MenuSuite objects as text and then write a program to read the text file and use this information to build the menu paths. I didn’t really want to have to figure out the file format of the MenuSuite export, and I didn’t really want to have to write the program to read it in. It never seemed quite worth the effort.
NAV 2009 has changed things and I thought that the ability to export objects as XML would make this task a lot easier. Unfortunately when I tried to export a MenuSuite in XML format, all I got was an empty XML file – not what I was hoping for. Back to the drawing board!
Then, when I was creating some programming samples for my book on Implementing Microsoft Dynamics NAV 2009 (buy it from amazon here), I discovered that the Object Metadata table has a blob field called Metadata that, for MenuSuite objects, contains the MenuSuite in XML format. How cool is that? Not only can I get the data in an easily-accessible format, but I can also do it programmatically by handling the XML document in the blob field.
If you wanted to see the contents of your MenuSuites in NAV 2009 as XML files, you could run the following Codeunit. Now I have the basic tools for the job, I can create a Page in NAV 2009 that will (hopefully) meet my requirements. I will, of course, post the progress here. Stay tuned.
Here's the Codeunit...
So what is the solution? Obviously I needed a tool to help me find the option I was looking for. In my dream world, I could type "Payment" into a search box and have the following results presented to me:
Financial Management | Cash Management | Payment Journals
Financial Management | Payables | Payment Journals
Financial Management | Receivables | Documents | Customer Payment
Financial Management | Receivables | Setup | Customer Payment
Etc.
It would be really nice to then be able to click a button to launch the option and hopefully, by seeing where the option is, commit to memory where the item can be found.
Previously building a solution such as this was too hard (for me). This was mainly due to the export formats available to version prior to NAV 2009. You could sort of do this by exporting the MenuSuite objects as text and then write a program to read the text file and use this information to build the menu paths. I didn’t really want to have to figure out the file format of the MenuSuite export, and I didn’t really want to have to write the program to read it in. It never seemed quite worth the effort.
NAV 2009 has changed things and I thought that the ability to export objects as XML would make this task a lot easier. Unfortunately when I tried to export a MenuSuite in XML format, all I got was an empty XML file – not what I was hoping for. Back to the drawing board!
Then, when I was creating some programming samples for my book on Implementing Microsoft Dynamics NAV 2009 (buy it from amazon here), I discovered that the Object Metadata table has a blob field called Metadata that, for MenuSuite objects, contains the MenuSuite in XML format. How cool is that? Not only can I get the data in an easily-accessible format, but I can also do it programmatically by handling the XML document in the blob field.
If you wanted to see the contents of your MenuSuites in NAV 2009 as XML files, you could run the following Codeunit. Now I have the basic tools for the job, I can create a Page in NAV 2009 that will (hopefully) meet my requirements. I will, of course, post the progress here. Stay tuned.
Here's the Codeunit...
OBJECT Codeunit 91360 Export MenuSuite Objects
{
OBJECT-PROPERTIES
{
Version List=;
}
PROPERTIES
{
OnRun=VAR
l_ObjectMetadata@1000000004 : Record 2000000071;
BEGIN
// MenuSuite items in the RoleTailored client are stored in the range 1000..1999
// They map to the Classic client numbers but with 1000 added to the number.
l_ObjectMetadata.SETRANGE("Object Type", l_ObjectMetadata."Object Type"::MenuSuite);
l_ObjectMetadata.SETRANGE("Object ID", 1000, 1999);
IF NOT l_ObjectMetadata.FINDSET THEN
ERROR('Something went wrong. There was no Object Metadata for the RoleTailored MenuSuites.\'+
'This sample only works with NAV 2009.');
REPEAT
l_ObjectMetadata.CALCFIELDS(Metadata);
l_ObjectMetadata.Metadata.EXPORT(TEMPORARYPATH+STRSUBSTNO('Metadata_%1.xml',l_ObjectMetadata."Object ID"));
HYPERLINK(TEMPORARYPATH+STRSUBSTNO('Metadata_%1.xml',l_ObjectMetadata."Object ID"));
UNTIL l_ObjectMetadata.NEXT = 0;
END;
}
CODE
{
BEGIN
END.
}
}
Sunday, 2 November 2008
NAV 2009 Web Services and InfoPath
I gave an introductory talk at Christchurch CodeCamp 2008 on Dynamics NAV from a Developer's Perspective yesterday but unfortunately ran out of time before being able to show this example of consuming a page web service in an InfoPath form, so I figured I'd make a blog post.
Lars Lohndorf-Larsen has already made a couple of posts on how to expose codeunits and pages as web services using the upcoming NAV 2009 three-tiered architecture and has provided a sample c# program for consuming them.
I'm using the Marketing Beta Release for this so any partner will be able to download the VPC image and repeat this exercise.
First of all, you'll need to expose the Customer Page (Object ID=21) as a web service with a service name of Customer. This is as simple as running form 810 Web Services and inserting a record with Object Type=Page, Object ID =21, Service Name=Customer and ticking the Published field.
If you enter http://localhost:7047/DynamicsNAV/ws/CRONUS_International_Ltd/Page/Customer in your web browser, you should see the WSDL for the page web service. It still amazes me how easy this is.
Now it's time to start up InfoPath. On the Getting Started page, click the Design a Form Template... option on the left hand pane.
In the Design a Form Template dialog, click the Web Service option and click OK.
Select the option to Receive and submit data and click the Next button. Paste the URL for the Customer Web Service into the field that is asking for the location of the data connection web service. If you used the right URL (I just copied it from my browser address bar after I had checked the WSDL for my web service) you should see the following screen when you click Next.
I found this screen a little confusing because I've never used InfoPath before I didn't realise it is wanting me to tell it which method can be used for reading data from the web service. Select the ReadMultiple option and click Next. On the next screen, you get an opportunity to name the data connection. I left mine as the default Main query and clicked Next. The next screen askes for the URL to the web service that will be used when users submit their changes. It defaults to the previous URL so just click Next. On the following screen you are asked to select the operation that will be used for submitting the data. I selected UpdateMultiple and clicked Next.
On this page we need to specify where the Customer comes from so I clicked the Modify button next to the Field or group text box and drilled down until I could select the Customer Node in the XML structure.
You can leave the name for the data connection as Main submit and click the Finish button. If all went to plan, you should now have a new template to drag your fields on to.
Drag the filter group on to the Query fields area of the design surface and select the option to add the groups as a repeating table. This way users will be able to add any filter fields to the read command. You can select the properties of these fields and set a default value - for example, Field defaults to No. and Criteria defaults to *. This will ensure you get some records back. You will also need the setSize parameter since this is mandatory for the ReadMultiple operation. Drag this on to the control surface and give it a default of 100. You should have a query section that looks something like this.
Now expand the dataFields node and drag the Customer node on to the fields area of the design surface and once again select Repeating Table as the option. This puts in every field which is way too much so just right click on the table after you have created it and selec the properties, then click the Change Binding button. You will see a tree that is expanded to show the customer node, that's fine, just click Next and you'll get on to a dialog where you can remove fields. For a quick way to remove all fields, click in the Columns in table list box and hold down Alt+R until there are no fields left - now you can click on the fields you want and add them. I used No, Name, Address and City. You should re-size the fields so they fit the available space and have a larger Name and Address field. Now it's time to run the form and see what happens. Click the Preview button. When prompted, select the option to connect rather than work offline. Hit the Run Query button and accept the dialog box and you should see something similar to the following.
Nice! OK now you can try editing the name of one of the customers and hitting the submit button. If you see a dialog saying "The form was submitted successfully, you've just updated the NAV data!
Lars Lohndorf-Larsen has already made a couple of posts on how to expose codeunits and pages as web services using the upcoming NAV 2009 three-tiered architecture and has provided a sample c# program for consuming them.
I'm using the Marketing Beta Release for this so any partner will be able to download the VPC image and repeat this exercise.
First of all, you'll need to expose the Customer Page (Object ID=21) as a web service with a service name of Customer. This is as simple as running form 810 Web Services and inserting a record with Object Type=Page, Object ID =21, Service Name=Customer and ticking the Published field.
If you enter http://localhost:7047/DynamicsNAV/ws/CRONUS_International_Ltd/Page/Customer in your web browser, you should see the WSDL for the page web service. It still amazes me how easy this is.Now it's time to start up InfoPath. On the Getting Started page, click the Design a Form Template... option on the left hand pane.
In the Design a Form Template dialog, click the Web Service option and click OK.
Select the option to Receive and submit data and click the Next button. Paste the URL for the Customer Web Service into the field that is asking for the location of the data connection web service. If you used the right URL (I just copied it from my browser address bar after I had checked the WSDL for my web service) you should see the following screen when you click Next.
I found this screen a little confusing because I've never used InfoPath before I didn't realise it is wanting me to tell it which method can be used for reading data from the web service. Select the ReadMultiple option and click Next. On the next screen, you get an opportunity to name the data connection. I left mine as the default Main query and clicked Next. The next screen askes for the URL to the web service that will be used when users submit their changes. It defaults to the previous URL so just click Next. On the following screen you are asked to select the operation that will be used for submitting the data. I selected UpdateMultiple and clicked Next.
On this page we need to specify where the Customer comes from so I clicked the Modify button next to the Field or group text box and drilled down until I could select the Customer Node in the XML structure.
You can leave the name for the data connection as Main submit and click the Finish button. If all went to plan, you should now have a new template to drag your fields on to. 
Drag the filter group on to the Query fields area of the design surface and select the option to add the groups as a repeating table. This way users will be able to add any filter fields to the read command. You can select the properties of these fields and set a default value - for example, Field defaults to No. and Criteria defaults to *. This will ensure you get some records back. You will also need the setSize parameter since this is mandatory for the ReadMultiple operation. Drag this on to the control surface and give it a default of 100. You should have a query section that looks something like this.
Now expand the dataFields node and drag the Customer node on to the fields area of the design surface and once again select Repeating Table as the option. This puts in every field which is way too much so just right click on the table after you have created it and selec the properties, then click the Change Binding button. You will see a tree that is expanded to show the customer node, that's fine, just click Next and you'll get on to a dialog where you can remove fields. For a quick way to remove all fields, click in the Columns in table list box and hold down Alt+R until there are no fields left - now you can click on the fields you want and add them. I used No, Name, Address and City. You should re-size the fields so they fit the available space and have a larger Name and Address field. Now it's time to run the form and see what happens. Click the Preview button. When prompted, select the option to connect rather than work offline. Hit the Run Query button and accept the dialog box and you should see something similar to the following.
Nice! OK now you can try editing the name of one of the customers and hitting the submit button. If you see a dialog saying "The form was submitted successfully, you've just updated the NAV data!
Friday, 24 October 2008
NAV 2009 Edit in Excel
At our recent NAV User Group conference, I had the pleasure of seeing some new NAV 2009 functionality demoed by our local Microsoft ERP Expert.
In the demo, Sue set a filter on a list of records (I think it was a vendor list) and then from the Actions command menu selected a new option called "Edit in Excel".
This looked similar to the Send to Excel feature with one difference. There was a new button on a Dynamics NAV tab of the Ribbon that allowed the data to be updated.
In the demo, Sue deliberately set the Responsibility Centre in the spreadsheet to an invalid value and the update returned an error message that the Responsibility Centre was not valid. She then corrected the data in the spreadsheet, hit the update button and the data was updated in NAV.
This was a fantastic demonstration of the new NAV 2009 web services in action. I'm pretty sure this option is not available in the Marketing Beta Release that is available to partners and the image Sue had was based on Windows Server 2008.
It looks like there's definitely more cool stuff coming in the NAV 2009 release and this ability to edit data in Excel is going to prove extremely useful to many users.
In the demo, Sue set a filter on a list of records (I think it was a vendor list) and then from the Actions command menu selected a new option called "Edit in Excel".
This looked similar to the Send to Excel feature with one difference. There was a new button on a Dynamics NAV tab of the Ribbon that allowed the data to be updated.
In the demo, Sue deliberately set the Responsibility Centre in the spreadsheet to an invalid value and the update returned an error message that the Responsibility Centre was not valid. She then corrected the data in the spreadsheet, hit the update button and the data was updated in NAV.
This was a fantastic demonstration of the new NAV 2009 web services in action. I'm pretty sure this option is not available in the Marketing Beta Release that is available to partners and the image Sue had was based on Windows Server 2008.
It looks like there's definitely more cool stuff coming in the NAV 2009 release and this ability to edit data in Excel is going to prove extremely useful to many users.
Tuesday, 30 September 2008
Calling Web Services in the Marketing Beta of NAV 2009
My first experience of using web services in the Marketing Release (CTP4) for Dynamics NAV 2009 resulted in a couple of errors. The first one I experienced was a bit of confusion over the way Visual Studio 2008 handles web services.
If I had read through Lars Lohndorf-Larsen’s blog post on how to consume a web service properly this wouldn’t have been a problem, but basically if you want to add a web service in VS 2008, it’s a little different.
When I went to add my service, there was no add web reference option.
I thought, hey that’s cool they’ve changed the name and updated the user interface, so I just selected this option and put in my address. But when I came to use the web service I got the shock of my life when none of my methods were there. Now I had to go back and read Lars’ post and this time I was determined to follow it step by step to see what I was doing wrong.
Sure enough Lars does say:
2) This step depends a bit on whether you use VS2005 or 2008. In VS2005, just rightclick on "References" in the Solution Explorer, and select "Add Web Reference". In VS2008, to get to the same place, rightclick on "References", then select "Add Service Reference", then click the Advanced button, and then click the "Add Web Reference" button.
So when you see this screen:
Click the Advanced button and then click the Add Web Reference button.
Now we’re back in familiar territory and everything works as it did previously.
Except – my console app didn’t work! I kept getting this error: "Path property must be set before calling the Send method."
I think this problem only happens when you are adding multiple web references to a single project (not uncommon) and I’m really not sure why it happens – maybe someone who knows a bit more about .NET and visual studio 2008 could add a comment as to why this happens.
Even though the URL property is set on the web reference, for some reason the service doesn’t know the URL, so I needed to explicitly set it within the code.
Here’s an example.
SSRef.SystemService SysServ = new SSRef.SystemService();
SysServ.Url = "http://localhost:7047/DynamicsNAV/ws/SystemService";
SysServ.UseDefaultCredentials = true;
I guess this is my first blog post on NAV 2009 although, like many people, I’ve been working with it a lot since the CTP3 release. I have to say that this is an amazing product and I really can’t wait to start using this for real. Nice one Microsoft!
If I had read through Lars Lohndorf-Larsen’s blog post on how to consume a web service properly this wouldn’t have been a problem, but basically if you want to add a web service in VS 2008, it’s a little different.
When I went to add my service, there was no add web reference option.
I thought, hey that’s cool they’ve changed the name and updated the user interface, so I just selected this option and put in my address. But when I came to use the web service I got the shock of my life when none of my methods were there. Now I had to go back and read Lars’ post and this time I was determined to follow it step by step to see what I was doing wrong.
Sure enough Lars does say:
2) This step depends a bit on whether you use VS2005 or 2008. In VS2005, just rightclick on "References" in the Solution Explorer, and select "Add Web Reference". In VS2008, to get to the same place, rightclick on "References", then select "Add Service Reference", then click the Advanced button, and then click the "Add Web Reference" button.
So when you see this screen:
Click the Advanced button and then click the Add Web Reference button.
Now we’re back in familiar territory and everything works as it did previously.
Except – my console app didn’t work! I kept getting this error: "Path property must be set before calling the Send method."
I think this problem only happens when you are adding multiple web references to a single project (not uncommon) and I’m really not sure why it happens – maybe someone who knows a bit more about .NET and visual studio 2008 could add a comment as to why this happens.
Even though the URL property is set on the web reference, for some reason the service doesn’t know the URL, so I needed to explicitly set it within the code.
Here’s an example.
SSRef.SystemService SysServ = new SSRef.SystemService();
SysServ.Url = "http://localhost:7047/DynamicsNAV/ws/SystemService";
SysServ.UseDefaultCredentials = true;
I guess this is my first blog post on NAV 2009 although, like many people, I’ve been working with it a lot since the CTP3 release. I have to say that this is an amazing product and I really can’t wait to start using this for real. Nice one Microsoft!
Sunday, 27 July 2008
What's New in Microsoft Dynamics NAV 2009
There is a new training course available for download from PartnerSource and CustomerSource. I'm not the first to blog about this, but NAV 2009 is definitely a hot topic, and I only came across this today, so if I've missed it, I'm sure there are others out there that will be interested. The upcoming release of Microsoft's ERP solution is much anticipated and accounts for a significant number of hits on this blog from search engines. It's not possible to write much about the product but hopefully that will change when the next release is made in September.
If you have access to PartnerSource, you can view the training course contents and powerpoint at this link. The CustomerSource URL is here.
If you have access to PartnerSource, you can view the training course contents and powerpoint at this link. The CustomerSource URL is here.
Friday, 27 June 2008
I hate TRANSFERFIELDS - Part II
I hate the TRANSFERFIELDS command. The last time I ranted about it I seemed to stir up some strong feelings, so I figured it’s time to bring this one up again.
Last time I commented on how the unsuspecting developer has no way of knowing what is going to happen when they use this command due to the way it copies fields between tables using the field ID to map the tables. Since then I have been tripped up again by this evil function and instead of simply moaning about it, I thought I would suggest an alternative.
So here I am going to introduce the all-new transferfields functionality. Microsoft, please feel free to take this idea and implement it in NAV.
The TRANSFERFIELDS command is programmed the same as now but in order to use it, a field mapping between the two tables must be defined at the table definition level. Let’s say we want to transfer fields from the Purchase Header table and the Purch. Inv. Header tables. You can find an example of this in the Purch.-Post codeunit as follows:
This line takes the fields from the PurchHeader record variable and transfers the fields to the fields with the same field ID in the PurchInvHeader record variable.
If you have not defined a filed mapping between these two tables, the above code will not compile. In order to define the mapping I see it working like this.
Go to edit the Purchase Header table and select View menu and select the Table Mappings option. This will launch a form similar to the following:
On this form, you can insert a new line and enter the To Table ID to identify the table you want to map to. It would probably make sense at this stage for the system to automatically insert mapping between the two tables based upon the matching field IDs of the two tables. In this respect replicating the existing behavior would be pretty easy.
To customize the field mappings for the tables, the user will simply click the assist edit button on the Mapped Fields field and this will show the Field Mapping form.
Here the user can set up the field mapping. There are a couple of great things about this approach, you can ignore fields that you would never want to copy, such as the No. field. You can also map fields with different IDs. The other great thing is that field mappings can be managed by end users without the need to write code. An example would be if the user creates a new custom field on the Purch. Inv. Header table called Original Purchase Order No. The user can then make sure that the purchase order number ends up in this field by just using the mappings.
We could even add some rules on what to do when the fields don’t match in type, i.e. should we truncate the string or throw a run-time error.
Last time I commented on how the unsuspecting developer has no way of knowing what is going to happen when they use this command due to the way it copies fields between tables using the field ID to map the tables. Since then I have been tripped up again by this evil function and instead of simply moaning about it, I thought I would suggest an alternative.
So here I am going to introduce the all-new transferfields functionality. Microsoft, please feel free to take this idea and implement it in NAV.
The TRANSFERFIELDS command is programmed the same as now but in order to use it, a field mapping between the two tables must be defined at the table definition level. Let’s say we want to transfer fields from the Purchase Header table and the Purch. Inv. Header tables. You can find an example of this in the Purch.-Post codeunit as follows:
PurchInvHeader.TRANSFERFIELDS(PurchHeader);
This line takes the fields from the PurchHeader record variable and transfers the fields to the fields with the same field ID in the PurchInvHeader record variable.
If you have not defined a filed mapping between these two tables, the above code will not compile. In order to define the mapping I see it working like this.
Go to edit the Purchase Header table and select View menu and select the Table Mappings option. This will launch a form similar to the following:
On this form, you can insert a new line and enter the To Table ID to identify the table you want to map to. It would probably make sense at this stage for the system to automatically insert mapping between the two tables based upon the matching field IDs of the two tables. In this respect replicating the existing behavior would be pretty easy.
To customize the field mappings for the tables, the user will simply click the assist edit button on the Mapped Fields field and this will show the Field Mapping form.
Here the user can set up the field mapping. There are a couple of great things about this approach, you can ignore fields that you would never want to copy, such as the No. field. You can also map fields with different IDs. The other great thing is that field mappings can be managed by end users without the need to write code. An example would be if the user creates a new custom field on the Purch. Inv. Header table called Original Purchase Order No. The user can then make sure that the purchase order number ends up in this field by just using the mappings.
We could even add some rules on what to do when the fields don’t match in type, i.e. should we truncate the string or throw a run-time error.
Monday, 23 June 2008
Help!
In May I wrote a short piece for MSDynamicsWorld.com on on-line help and offered some thoughts on how it could be improved. In response to this article, I received a question asking how to configure the online help in Dynamics NAV.
In truth I have never done this. I knew I had read a document on how to do it but to be honest, it looked so hard I didn't bother. When I came to reply with the details, I really struggled to find the document I was looking for that described the help creation process. If you're looking for it, it's called NOHG.pdf
One of my points in the article is that we really need an easy-to-use help editor, similar to the one in Dyamics AX. Doh! I can't believe I just admitted something was better in AX!
In truth I have never done this. I knew I had read a document on how to do it but to be honest, it looked so hard I didn't bother. When I came to reply with the details, I really struggled to find the document I was looking for that described the help creation process. If you're looking for it, it's called NOHG.pdf
One of my points in the article is that we really need an easy-to-use help editor, similar to the one in Dyamics AX. Doh! I can't believe I just admitted something was better in AX!
Wednesday, 9 April 2008
Try Catch in Dynamics NAV
This has to be up there on my list of "all time desirable features" for NAV. As you probably know NAV has an ERROR function that is used to, well, throw errors. It will abort the current transaction (and roll back to the point of the last commit) and display the text message that you selected in an error dialogue box.
The thing is, sometimes you don't want it to do the abort and rollback. For example if we are importing a file or maybe a series of files, we may just want to log the error somewhere and carry on with the next file. You can do this in NAV 5.0 using the new GETLASTERRORTEXT function.
Here's an example of how to do it.
First of all, create a simple codeunit that, when run, will throw an error:
When you run this codeunit you get the following error message displayed.
Now create another codeunit that will call the first one and trap the error it generates:
When you run this second codeunit, even though it calls the first codeunit, you don't see the error message. Instead you see this:
You'll need to make a COMMIT before trying to trap the return code from running the codeunit but if you have uncommitted transactions you'll get a run time error telling you this. Unfortunately this only works when you Run a codeunit so you either have to use lots of codeunits or write some kind of clever dispatcher that allows you to set the action on the codeunit first and then run it.
So my most desired feature would require some language additions to C/AL. Introduce a TRY CATCH language construct – it would work similar to an IF ELSE statement. Here is an example:
I have put the BEGIN and END in the CATCH part to illustrate how it work in a similar manner to the IF ELSE construct but it wouldn't be needed. The neat thing about this is you would not need to use a codeunit just to be able to trap the error. The same rules regarding commits, etc. would apply.
I guess I'll just nip over to the Connect site and suggest this little beauty for the product team to ponder over.
The thing is, sometimes you don't want it to do the abort and rollback. For example if we are importing a file or maybe a series of files, we may just want to log the error somewhere and carry on with the next file. You can do this in NAV 5.0 using the new GETLASTERRORTEXT function.
Here's an example of how to do it.
First of all, create a simple codeunit that, when run, will throw an error:
OBJECT Codeunit 50000 ThrowError
{
OBJECT-PROPERTIES
{
Date=09/04/08;
Time=[ 9:34:55 PM];
Modified=Yes;
Version List=;
}
PROPERTIES
{
OnRun=BEGIN
// Call a function that throws an error.
DoSomething();
END;
}
CODE
{
PROCEDURE DoSomething@1000000000();
BEGIN
ERROR('Hey Look I threw an error.');
END;
BEGIN
END.
}
}
When you run this codeunit you get the following error message displayed.
Now create another codeunit that will call the first one and trap the error it generates:
OBJECT Codeunit 50001 Test Throw Error
{
OBJECT-PROPERTIES
{
Date=09/04/08;
Time=[ 9:35:58 PM];
Modified=Yes;
Version List=;
}
PROPERTIES
{
OnRun=VAR
l_ThrowError@1000000000 : Codeunit 50000;
BEGIN
IF NOT l_ThrowError.RUN THEN
MESSAGE(GETLASTERRORTEXT+ ' - or did I?');
END;
}
CODE
{
BEGIN
END.
}
}
When you run this second codeunit, even though it calls the first codeunit, you don't see the error message. Instead you see this:
You'll need to make a COMMIT before trying to trap the return code from running the codeunit but if you have uncommitted transactions you'll get a run time error telling you this. Unfortunately this only works when you Run a codeunit so you either have to use lots of codeunits or write some kind of clever dispatcher that allows you to set the action on the codeunit first and then run it.
So my most desired feature would require some language additions to C/AL. Introduce a TRY CATCH language construct – it would work similar to an IF ELSE statement. Here is an example:
TRY
BEGIN
DoSomething();
DoSomethingElse();
END
CATCH
BEGIN
MESSAGE(GETLASTERRORTEXT);
END;
I have put the BEGIN and END in the CATCH part to illustrate how it work in a similar manner to the IF ELSE construct but it wouldn't be needed. The neat thing about this is you would not need to use a codeunit just to be able to trap the error. The same rules regarding commits, etc. would apply.
I guess I'll just nip over to the Connect site and suggest this little beauty for the product team to ponder over.
Tuesday, 25 March 2008
Dynamics NAV Gets Connected
In my first ever blog post I wrote about a site where ideas for new product features can be posted. Today I came across a news article on PartnerSource that pointed me to a new place for logging feature enhancements, the Connect for Microsoft Dynamics site. You will need to register a Windows Live ID in order to use the site, which site is a big improvement on the old public forum.
Microsoft seems to be committed of late to listening to feedback from partners and customers and this is a very welcome move. Recently they requested feedback on how the online help can be improved through Convergence and some of the public forums. This new listening, caring Microsoft makes me feel warm and fuzzy and I truly believe that we should all be feeding back to Microsoft where we think the product can be improved. Long gone are the days when this was a pointless exercise, so sign up and give it a go!
The site seems to have been active since October 2007 but there are only 7 suggestions for NAV – maybe it hasn't been that well publicised? Well here's a suggestion to get things going. If you want to vote for this suggestion you can register and click the rating. Here is the suggestion:
Every implementation of NAV I have ever been involved with has a test system and a live system. I am assuming this is a universally accepted practice – you don't want to be applying programming modifications to your live system without testing them first. In nearly every implementation of NAV I have been involved with, there have been instances at least one user has been logged in to the live system and thought they were logged in to the test system and they have mistakenly posted entries in their live system. The request I commonly receive is to make it so that it is immediately obvious to the users which system they are in: live or test. This should be immediately visually obvious – to me there is only one way to achieve this and that is to change the colour scheme of the windows. You can change the text in the title bar (via 3rd party utilities or by renaming the company) but this is not immediately visually obvious. Another less common requirement is for users that need to work in more than one company at once and they want to see which company they have open. Again they want something that is instantly obvious and don't want to be reading titles of windows. So my suggestion is: allow the Window Colour and Appearance options to be specified at a Company AND Database level. The Database level is required so that if a user restores their live system over their test system (something they frequently need to do) they do not lose the all important colour settings. At the database level it could be stored in a table similar to the $ndo$srvproperty table in the master database – this would have one record for each NAV database. Restoring a database would not overwrite this value. At the company level, it would be set in a table that is company specific.
Tuesday, 11 December 2007
Test Drive Microsoft Dynamics NAV 5.0
This link came up on my Google Blog Search for Dynamics NAV:
http://www.dynamicsnavtestdrive.com/
By logging onto the test drive environment using your web browser, you will be able to experience Microsoft Dynamics NAV first hand without the need of installing it on your computer. You can explore the product on your own, or follow along guided exercises and demos.
http://www.dynamicsnavtestdrive.com/
By logging onto the test drive environment using your web browser, you will be able to experience Microsoft Dynamics NAV first hand without the need of installing it on your computer. You can explore the product on your own, or follow along guided exercises and demos.
Saturday, 17 November 2007
Microsoft Dynamics NAV "6.0" Video - You have got to see this!
I have just finished watching the video that I downloaded from the link on the NAV 6.0 Technical Preview page, if you don't have access to PartnerSource, you can download it from mibuso. Microsoft, I salute you! The video is stunning - never mind the whitepaper (which is just "interesting") this is amazing stuff.
Some highlights for me are:
Some highlights for me are:
- The interactive date picker that animates zooming in and out between month and day views.
- The Freeze columns feature for sales lines (Very Cool - geddit? Freeze Columns, Cool? - Never mind!)
- Additional fields feature - yes I know we've seen this before but I had forgotten how neat it is.
- The web service demo. Wow! This is so incredible. Microsoft have really got their act together on this. It seems to be everything we could want.
- The SharePoint integration. Wow again! This is just astounding. I am running out of superlatives. Employee Portal is a good idea but a bit of a pig to implement. This is just amazing in its simplicity, beauty and elegance.
Monday, 4 June 2007
Dynamics NAV 5.0 – Send to Application Feature – Part 4
This is the last part of a series of postings on using the new send to application feature in Dynamics NAV 5.0.
In Part 3 I showed you how to use Word to create a seed xml document that can be used to create a transformation template. It was late in the evening when I wrote this and there were a couple of mistakes in the posting. I had implied that you could take the SalespersonName element from the Customer element and move it down to the bottom of the letter. Unfortunately when I worked through my own example this did not work (the XSL does not include the text as expected.) I am sure there is a way to do this but I do not know how. If you are reading this and you know about such things, why not post a comment?
In this post, I will show you how to create the XSLT from the seed document you created in Part 3. The first thing you need to do is download the transform inference tool from the Microsoft downloads site. The download will install the tool: a command-line executable with some documentation. I accepted the default install path so, for me, it was installed in "C:\Program Files\Microsoft Office 2003 Developer Resources\Microsoft Office 2003 WordprocessingML Transform Inference Tool\".
In Part 3 I wrote about creating a seed document. If you have not done that, you will need to go back and follow those steps before being able to use the transform utility. I am assuming that you have a seed document stored as “customer seed.xml”.
Open a command prompt and change directory to the location of the inference tool. Type the following command:
WML2XSLT "c:\customer seed.xml"
Since we have two namespaces in our seed document, you will see a dialogue box asking you to select the namespace you wish to use for the transform.
In Part 3 I showed you how to use Word to create a seed xml document that can be used to create a transformation template. It was late in the evening when I wrote this and there were a couple of mistakes in the posting. I had implied that you could take the SalespersonName element from the Customer element and move it down to the bottom of the letter. Unfortunately when I worked through my own example this did not work (the XSL does not include the text as expected.) I am sure there is a way to do this but I do not know how. If you are reading this and you know about such things, why not post a comment?
In this post, I will show you how to create the XSLT from the seed document you created in Part 3. The first thing you need to do is download the transform inference tool from the Microsoft downloads site. The download will install the tool: a command-line executable with some documentation. I accepted the default install path so, for me, it was installed in "C:\Program Files\Microsoft Office 2003 Developer Resources\Microsoft Office 2003 WordprocessingML Transform Inference Tool\".
In Part 3 I wrote about creating a seed document. If you have not done that, you will need to go back and follow those steps before being able to use the transform utility. I am assuming that you have a seed document stored as “customer seed.xml”.
Open a command prompt and change directory to the location of the inference tool. Type the following command:
WML2XSLT "c:\customer seed.xml"
Since we have two namespaces in our seed document, you will see a dialogue box asking you to select the namespace you wish to use for the transform.
Tick the option for the namespace you put your NAV document in and hit OK.
Now take a look at the location where you stored your seed document. You will see a document with the same name but a with a ".xsl" extension.
The quickest way to test your XSL is to take your raw xml file and edit some of the data (try changing the customer name). Then save the raw xml file and open it in Word. When you open an xml file in Word, it prompts you for a style sheet to apply. Select the style sheet you created from your seed. You should now see a Word document that looks like your seed but with the changed data values from the raw file.
If everything is working properly, you can now import this style sheet for use with the send to application feature. For details on how to do this, go back to Part 1. Note that our transformation uses elements that are only available for the Customer card export, so when you import this style sheet, do it as a style sheet for form 21 only. You should also ensure that the application for the style sheet is Word.
That’s it. I don’t know if this is the best way of creating your XSLTs but it certainly works for me. The nice thing is that I don’t need to know the XSLT language in order to create the transform (which I think will be true for the majority of people that will need to create new templates.) I must stress that this series of postings is made with no warranty or support. If you follow this, you’re on your own. If anyone finds a better way of creating XSLT transforms for use with Dynamics NAV then I would like to know – please post a comment.
Saturday, 26 May 2007
Dynamics NAV 5.1 – Incredible New Features
There is a new version of Dynamics NAV and it has got me pretty excited. Not because of its new features, or technology, or roles-based user interface, but because I have never used it.
There is a magical time in a product’s life when it is perfect, and, for me, Dynamics NAV 5.1 is there. Having never used the product, I can unreliably inform you it is the best version of Dynamics NAV yet. The roles-based client is intuitive and a pleasure to use; the online help has been completely re-written with a focus on the roles within an organisation and the business processes that keep it running.
In a stroke of genius, Microsoft has completely re-engineered the application architecture in order to make all functions available to the NAV developer. Any actions that can be triggered by a user can now be triggered through code. This is probably the one non-feature I find most exciting. NAV developers can now create tools that will dramatically improve the Dynamics experience for re-sellers and end-users alike. The testing tool is a prime example of this. Similar to the Record Macro feature in Microsoft Office, it is now possible to record a series of actions, save them as a script (using your preferred language of C/AL, C# or VB.NET) and finally edit the code to produce testing programs. This will allow new features to be automatically tested to ensure they meet requirements and do not introduce nasty side-effects to other parts of the application. The application comes with a set of pre-defined localised test cases that allow Dynamics NAV resellers to develop their own applications and have total confidence that they have not broken the standard application.
Programming objects within Dynamics NAV can now be exported and imported through code (either using the built-in programming tools or via the web-service interface.) This, coupled with the fact that all programming objects are now stored internally in an open XML format, means that Dynamics NAV is now limited only by the imagination of the business community and the skills of the developers. Being able to hook into events makes it possible to write tools that will revolutionise version control within business applications. One of the sample applications illustrates this feature by waiting for customers to make modifications to their programming objects, and then sending a copy of the change to the Dynamics NAV Partner. No longer will we need to worry about lost, undocumented, or inappropriate programming changes.
These new features are available for a limited time only. Eventually, Microsoft will release Dynamics NAV 5.1 and my fantasy vapourware version will be replaced with the real thing, but until that day, I have the perfect ERP system.
There is a magical time in a product’s life when it is perfect, and, for me, Dynamics NAV 5.1 is there. Having never used the product, I can unreliably inform you it is the best version of Dynamics NAV yet. The roles-based client is intuitive and a pleasure to use; the online help has been completely re-written with a focus on the roles within an organisation and the business processes that keep it running.
In a stroke of genius, Microsoft has completely re-engineered the application architecture in order to make all functions available to the NAV developer. Any actions that can be triggered by a user can now be triggered through code. This is probably the one non-feature I find most exciting. NAV developers can now create tools that will dramatically improve the Dynamics experience for re-sellers and end-users alike. The testing tool is a prime example of this. Similar to the Record Macro feature in Microsoft Office, it is now possible to record a series of actions, save them as a script (using your preferred language of C/AL, C# or VB.NET) and finally edit the code to produce testing programs. This will allow new features to be automatically tested to ensure they meet requirements and do not introduce nasty side-effects to other parts of the application. The application comes with a set of pre-defined localised test cases that allow Dynamics NAV resellers to develop their own applications and have total confidence that they have not broken the standard application.
Programming objects within Dynamics NAV can now be exported and imported through code (either using the built-in programming tools or via the web-service interface.) This, coupled with the fact that all programming objects are now stored internally in an open XML format, means that Dynamics NAV is now limited only by the imagination of the business community and the skills of the developers. Being able to hook into events makes it possible to write tools that will revolutionise version control within business applications. One of the sample applications illustrates this feature by waiting for customers to make modifications to their programming objects, and then sending a copy of the change to the Dynamics NAV Partner. No longer will we need to worry about lost, undocumented, or inappropriate programming changes.
These new features are available for a limited time only. Eventually, Microsoft will release Dynamics NAV 5.1 and my fantasy vapourware version will be replaced with the real thing, but until that day, I have the perfect ERP system.
Sunday, 13 May 2007
Dynamics NAV 5.0 – Send to Application Feature – Part 2
In my previous post on this topic, I looked at the send to application feature in Dynamics NAV 5.0. I explained that you can send data from NAV to Word, Excel or any other application by using an XSLT template to transform the XML data into a format that the target application understands. I also introduced the WordprocessingML language that can be used to create Word documents as XML files – a feature that Microsoft introduced in office 2003.
In this post I am going to show you how to see what NAV is producing as the starting XML file before any transformation is applied. Then we'll look at the WordprocessingML schema and create a simple Word document using Notepad. If you want to see the results of your efforts, you'll need Word 2003 or 2007 installed.
The first thing I wanted to know when I saw this new feature was how it worked. I understood the concepts of XSLT and WordprocessingML and applying transformations to XML files but I had never done it in practice. I didn't know what NAV was giving us to work with. In order to be able to make my own transformations, I needed to first know what my starting point was.
XSLT is a language that can be used to transform an XML file from one format to another. I knew that I could load my own XSLT file as a template for NAV to use but I didn't know what my starting XML file would be. I would like to pretend I am some kind of XSLT guru, but the truth is I just asked some people at work. My question was "what do I need in an XSLT to make my output file a copy of my input file?" The hardest part was convincing people I was not crazy and listening patiently as they explained that there was no point in applying a transformation that would make the output file identical to the input file. I think the answer ultimately came from a Google search – but it helps to know what you are looking for.
Open up Notepad and enter this text:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
</xsl:stylesheet>
Now save the file as "Copy All.xslt".
Since the file is so short, I will give you my expert explanation of its contents. The first line is probably really interesting. All I know is you need it - so put it in there for all of your XSLT files otherwise they won't work. It's something to do with defining this document as being a stylesheet and indicating that anything that starts with xsl: in the document will be defined in the schema that is referenced by the namespace provided. Incidentally, if you paste the http://www.w3.org/1999/XSL/Transform URL into a web browser, you'll see a link to the XSL Transformations specification. If you really want to learn about XSLT this is probably a good starting point.
The second line says find the start of the file you are reading.
The third line says copy everything without changing it.
Lines four and five are the closing tags for lines two and one respectively.
Now we have our transform, let's look at applying it to NAV. First we'll set up a new application to handle our transform. We need something that's good at displaying XML files – so I decided to use Internet Explorer.
Select Administration > IT Administration > General Setup > Launch Applications. The Send-to Programs form is displayed showing two programs: Excel.exe and Winword.exe.
Create a new record and enter IEXPLORE.EXE as the executable and Internet Explorer as the name. Press Esc to close the window.
Now I want to import my new template and tell NAV to use Internet Explorer to launch the resulting XML file.
Select Administration > IT Administration > General Setup > Manage Stylesheets. The Manage Style Sheets form is displayed showing all style sheets that have been set up for the database (oops – maybe that should have been set up as data per company since your templates are likely to contain company logos – as Microsoft would say: "this is a reseller opportunity" meaning: "oops we stuffed it up – you fix it"). In the standard CRONUS company this will mean a default stylesheet for Word and Excel (common to all forms) and a few form-specific templates (Customer Card letter template, Vendor Card letter, etc.)
Before you can create a new template, you need to select either the Style sheets common to all forms or Style sheets for this form only radio button against the Show label. For this example we want to be able to export from any form so click the Style sheets common to all forms radio button.
Maybe you are thinking you can now create a new record in the list of stylesheets – but that would be too easy. Instead, you should select the Import option from the Functions menu button. The system will display the Import Style Sheet form. Use the assist edit button to open the "Copy All.xslt" you saved earlier or type the path and file name into the Style Sheet field. Enter "Copy All to IE" into the Name field. Use the look-up button to select Internet Explorer as the Send-to Program. Click the OK button to import the stylesheet. You should now see a new line in the Manage Style Sheets form and, if all has gone well, we will now be able to test it out.
Open the Customer Card and click the Send Options button. The Program Selection form is displayed. Select our new Internet Explorer program. The Style Sheet field is showing the first style sheet that can be used for the data we are exporting. If it is not the one you want, click on the field and use the look-up button to select a different style sheet – in this example you should have only one stylesheet set up for the Internet Explorer program. Click the Send button.
If all has gone well, you should now see Internet Explorer with a new xml file displaying the information from the Customer card. Take a look at our xml file. You'll notice that the first part just gives us a hierarchy of all the controls on the form starting with Form, then Tab Control, then Tab Page, then a mixture of labels and text boxes. After the controls, we see some other sections for Customer, WorkDate, Salutation, CompanyInfo, etc. This suggests to me that there is something funny going on. How does NAV know that these things are important? We'll look at how you can create your own custom content to the XML file in a later posting.
To wrap things up, let's take a look at a simple WordprocessingML file. In my next post on this topic, I'll look at how we can create an XSLT to make a Word document in a format of our design.
WordprocessingML is a neat language that allows you to serialise an entire Word document as an XML file. The majority of the file contains tags that start with "w:". The text is typically built up from paragraphs (w:p), runs (w:r) and text (w:t) elements.
Open up Notepad and enter this text:
<?xml version="1.0"?>
<?mso-application progid="Word.Document"?>
<w:wordDocument xmlns:w="http://schemas.microsoft.com/office/word/2003/wordml">
<w:body>
<w:p>
<w:r>
<w:t>WordML Rocks!</w:t>
</w:r>
</w:p>
</w:body>
</w:wordDocument>
Now save the file as "WordML Rocks.xml". Even though the file extension is xml, the file is displayed with a WordML icon. This is because of the progid="Word.Document" property. Explorer is looking inside the xml file to determine how to display the icon.
Double click the file and Word will launch and display a document with a single line of text.
That's all for now. If you want to earn bonus points, you could take a look at the XSLT templates used in the CRONUS company and the XML files they produce.
Thursday, 3 May 2007
Dynamics NAV 5.0 - Send to Application Feature - Part 1
There are four new buttons on the toolbar for Microsoft Dynamics NAV 5.0. This posting starts to look at the three buttons used for sending data to other programs.
Word springs into life with a new document (called “10000 The Cannon Group PLC – Customer Card.xml”), stored in your temporary file path.
The sample document is a letter formatted to contain a CRONUS company logo and address details, Customer Address Details, Today’s Date, Salutation, etc. There is a place for you to type your letter contents.
Close Word and return to Dynamics NAV. Now hit the Send to Microsoft Office Excel button (you could use the Ctrl+E shortcut).
This time Excel opens and we are looking at another xml file. There is one Excel sheet within the workbook for each of the tab pages on the NAV form. Each sheet contains a title, the caption for the tab and the labels and data values for each of the fields on the tab page.
From Office 2003 onwards, Microsoft provided the ability to save a Word or Excel document as an XML file using their WordprocessingML or SpreadsheetML schemas. The new feature in Dynamics NAV takes advantage of this by grabbing the information on the screen and generating an XML file which it then transforms into another format by using a pre-defined XSLT (a file that describes how one XML file should be transformed into another).
You can create your own XSLT files and load them into NAV so that they can be used to make transformations. You can even specify your own applications to handle the new file, so you are not limited to using only Word or Excel.
I have two issues with this new feature. 1) Creating the XSLT file is not easy. If you have the ability to do this, you could probably have written some C/AL code to create the Word document directly. 2) Why would you use this feature? I am really struggling to think of a situation where this would be useful. If anyone has any suggestions, I would like to know.
I could only think of one possible use for this: if I wanted to write a user training document or document a test case and I wanted to list all of the fields on a form, this would be quite a neat way of doing it, but this is not a typical scenario for an end-user. Maybe I am not thinking laterally enough.
In the next post on this subject, I’ll take a look at how to set up a new XSLT so I can see what NAV is giving us to work with. Then, I’ll look at creating a Word document from scratch by making a new XSLT for WordprocessingML.
You’ll find the relevant help topic under Welcome to Dynamics NAV Help > Using Microsoft Dynamics NAV > Sending Data to Other Programs. This tells us that we can export data from NAV to other programs such as Microsoft Office Word or Excel. You can also export data to any other program that can handle an XML file.
To see this in action, use the CRONUS demo company for version 5.0 and open a customer card (Sales & Marketing > Order Processing > Customers); I am using customer account 10000 for The Cannon Group PLC. Now click on the Send to Microsoft Office Word button (or use the Ctrl+W shortcut key).
Word springs into life with a new document (called “10000 The Cannon Group PLC – Customer Card.xml”), stored in your temporary file path.
The sample document is a letter formatted to contain a CRONUS company logo and address details, Customer Address Details, Today’s Date, Salutation, etc. There is a place for you to type your letter contents.
Close Word and return to Dynamics NAV. Now hit the Send to Microsoft Office Excel button (you could use the Ctrl+E shortcut).
This time Excel opens and we are looking at another xml file. There is one Excel sheet within the workbook for each of the tab pages on the NAV form. Each sheet contains a title, the caption for the tab and the labels and data values for each of the fields on the tab page.
From Office 2003 onwards, Microsoft provided the ability to save a Word or Excel document as an XML file using their WordprocessingML or SpreadsheetML schemas. The new feature in Dynamics NAV takes advantage of this by grabbing the information on the screen and generating an XML file which it then transforms into another format by using a pre-defined XSLT (a file that describes how one XML file should be transformed into another).
You can create your own XSLT files and load them into NAV so that they can be used to make transformations. You can even specify your own applications to handle the new file, so you are not limited to using only Word or Excel.
I have two issues with this new feature. 1) Creating the XSLT file is not easy. If you have the ability to do this, you could probably have written some C/AL code to create the Word document directly. 2) Why would you use this feature? I am really struggling to think of a situation where this would be useful. If anyone has any suggestions, I would like to know.
I could only think of one possible use for this: if I wanted to write a user training document or document a test case and I wanted to list all of the fields on a form, this would be quite a neat way of doing it, but this is not a typical scenario for an end-user. Maybe I am not thinking laterally enough.
In the next post on this subject, I’ll take a look at how to set up a new XSLT so I can see what NAV is giving us to work with. Then, I’ll look at creating a Word document from scratch by making a new XSLT for WordprocessingML.
Subscribe to:
Posts (Atom)
