@ayyappanprofile
We reproduced these steps and our resultant document is the same as your “Template_GeneratedByGroupDocs.doc”.
What you described is expected and programmed behavior for the GroupDocs.Editor at this moment. In the original document all of these data fields, driven by formulas, are internally implemented by the so-called “fields” (list of field codes). We’ve inspected the original document and most of fields are MERGEFIELD and IF fields. They may be treated as the tiny coroutines in the WordProcesing document, like macros in MS Excel. And the problem is that when we convert document to the HTML/CSS (represented by EditableDocument instance), we can preserve only appearance, but not the behavior. Fields mean some action or behavior, and in order to translate this to some other format (HTML in our case) you should be able to store the “programming routine”. But HTML/CSS are markup and spreadsheet languages, not the programming languages.
Theoretically it is possible to preserve field codes by using a JavaScript. But in this case we will lose one of our biggest advantages — compatibility with any possible WYSIWYG-editor. When emitting not only the HTML/CSS, but also JavaScript, we become dependent on the specific WYSIWYG-editor, where the document content is loaded and edited.
So, concluding: at this moment fields are transformed to the plain text when saving document to the HTML/CSS. And when you convert document back to the DOC format, they are absent.
However, we can suggest you one option. If you do not require fully functional field in the intermediate HTML/CSS, but require them as fields, not as plain text, in the output/resultant DOC(X), we can make the next approach: when forward-converting to HTML/CSS, we store something like little hidden breadcrumbs in the HTML-markup (for example, some custom “aw-*”-prefixed HTML attributes), which encode original fields in the exact locations where they are present in the original document. In the WYSIWYG-editor, where you edit the document content, these breadcrumbs are hidden. But when edited HTML-content will be obtained by the GroupDocs.Editor for the backward conversion, the backward converter will detect these breadcrumbs and restore the original fields not as a plain text, but as fully-functional fields.
If such approach is viable for you, please let us know, which field codes are the most important for you, so we implement their preserving and restoring in the resultant DOC(X).