Word Templates: We can't open template because we found a problem with its contents
Just recently I was working on a Sales Invoice Word Template customization for a customer and ran into a strange issue when attempting to print a batch of invoices for customers assigned to this template.
When printing the entire batch of invoices, the following error would appear:
Once the OK button was clicked, Word would proceed to display the following error message: "Word found unreadable content in "Template.docx". Do you want to recover the contents of this document? If you trust the source of this document, click Yes.".
Upon clicking the Yes button, Word would go to work and "recover" the document in perfectly good condition with the invoices matching to the penny.
What makes this even more puzzling is, if you print each invoice individually from the Sales Transaction Entry window, there would be no error and invoices would print fine.
Solution
To troubleshoot this issue, one just needs to focus on the original error - I assume the second error is simply a consequence of the first - specifically, on the Details where Word is specifically complaining about the header6.xml section. Also, part of finding the solution is understanding how the actual documents are generated from the templates.
To render a report from a template, Microsoft Dynamics GP uses Open XML, which uses a set of APIs to stream data into ZIP and XML standards - a DOCX is nothing more than a structured zip file containing a bunch of XML documents that define the structure and content of the document in question. The vehicle to stream the data into a template of course, is Report Writer.
With that said, when you look at the error, it clearly indicates that there's an issue with the way part of the formatted XML is being generated (as referenced by header6.xml). Troubleshooting 101, always suggests to test a standard unmodified template to see if the behavior persists and compare the standard unmodified template to the modified template causing the issue.
In looking at the original template, I immediately identified the difference between the original body section of the template...
... and what my modified template was showing:
As you can tell, the modified section of the body is missing the Serial/Lot and Item Notes row sections. When Microsoft Dynamics GP tries to stream data from Report Writer to the template, it is clear that this missing section will cause the XML data to be formatted incorrectly since the data exist in the stream, but there's no matching elements on the template. Since each section of the document is written one at a time and document by document, the resulting DOCX is saved each time each section is completed. Once the DOCX construction is finished, it will finish with an error message, which immediately forces Microsoft Word to go into recovery mode. Nonetheless, the recovery is of the last save operation, which still brings up the document.
Now, when an individual document is printed, it would seem that all XML tags are closed regardless of whether the data stream could be written to the appropriate template section. This is probably why no error is produced when an individual document is printed.
The solution in this case was to recreate the template and leave the previously removed sections intact. In my customer's case, they had no serial numbers to worry about, but had the occasional note that will print, so leaving these in the document was probably a good idea to begin with.
Until next post!
MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
When printing the entire batch of invoices, the following error would appear:
Once the OK button was clicked, Word would proceed to display the following error message: "Word found unreadable content in "Template.docx". Do you want to recover the contents of this document? If you trust the source of this document, click Yes.".
Upon clicking the Yes button, Word would go to work and "recover" the document in perfectly good condition with the invoices matching to the penny.
What makes this even more puzzling is, if you print each invoice individually from the Sales Transaction Entry window, there would be no error and invoices would print fine.
Solution
To troubleshoot this issue, one just needs to focus on the original error - I assume the second error is simply a consequence of the first - specifically, on the Details where Word is specifically complaining about the header6.xml section. Also, part of finding the solution is understanding how the actual documents are generated from the templates.
To render a report from a template, Microsoft Dynamics GP uses Open XML, which uses a set of APIs to stream data into ZIP and XML standards - a DOCX is nothing more than a structured zip file containing a bunch of XML documents that define the structure and content of the document in question. The vehicle to stream the data into a template of course, is Report Writer.
With that said, when you look at the error, it clearly indicates that there's an issue with the way part of the formatted XML is being generated (as referenced by header6.xml). Troubleshooting 101, always suggests to test a standard unmodified template to see if the behavior persists and compare the standard unmodified template to the modified template causing the issue.
In looking at the original template, I immediately identified the difference between the original body section of the template...
 |
| Original Template |
... and what my modified template was showing:
 |
| Modified Template of Original |
As you can tell, the modified section of the body is missing the Serial/Lot and Item Notes row sections. When Microsoft Dynamics GP tries to stream data from Report Writer to the template, it is clear that this missing section will cause the XML data to be formatted incorrectly since the data exist in the stream, but there's no matching elements on the template. Since each section of the document is written one at a time and document by document, the resulting DOCX is saved each time each section is completed. Once the DOCX construction is finished, it will finish with an error message, which immediately forces Microsoft Word to go into recovery mode. Nonetheless, the recovery is of the last save operation, which still brings up the document.
Now, when an individual document is printed, it would seem that all XML tags are closed regardless of whether the data stream could be written to the appropriate template section. This is probably why no error is produced when an individual document is printed.
The solution in this case was to recreate the template and leave the previously removed sections intact. In my customer's case, they had no serial numbers to worry about, but had the occasional note that will print, so leaving these in the document was probably a good idea to begin with.
Until next post!
MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Comments
I just read your post on this as we are having the same issue when we print a batch of RM Statements, but printing individual statements works fine.
However, I also just read this article
http://www.encorebusiness.com/blog/office-2010-compatibility-issues-dynamics-gp/
and this offered a different reason and solution.
Could you please let me know which approach I should take?
I will be reading the Encore blog post and let you know.
Thanks,
MG.-