Unique ID for MS Word 2007 paragraph - ms-word

I am writing large MS Word 2007 documents, which are often being changed. I have to number paragraphs with stationary unique numbers, that will not change while changing the documents. The numbers should be unique, and will not change even if previous numbers are deleted. The order of the list is not mandatory, and addition of a new number before existing numbers is possible (for instance: the sequence 1, 4, 3 means that paragraphs 1-3 were written, then #2 was deleted, then #5 was added. #3 was not affected by the later editing)
The mechanism should be internal to the document, as I am working on line and off line. The numbers are allocated to every document individually.
Since I don't know to program under MS Word, I'd appreciate getting a complete solution.

Nope, it's not possible out-of-the-box. Word does not assign a permanent index to paragraphs. The simpliest way, but it ain't so simple, to do this is to programmatically assign an index number of each Paragraph range item to a CustomXML control that wraps the paragraph on load or whenever you run it. For this or any other solution, you'll need to learn the Word object model and program it through VBA or VSTO or OpenXML.

You can wrap a paragraph in a content control (structured document tag); these can have IDs.
Iirc, Word 2010 allows paragraphs to have IDs. M$ added this because they needed it for the concurrent editing introduced in 2010.

Related

Creating a derived document in MS Word

Is it possible to create a dynamic document derived from a second document? For example a student document that contains problems, and then a teacher's version which has the exact same contents as the student one, but has additional paragraphs with discussion points and solutions.
The dynamic part is important so that if changes are made to a problem in one document the other gets updated.
Perhaps using hidden text and only copying the non-hidden parts to the second document?

Insert a word document into another word document without losing formatting

I am working on my portfolio for grad school and I am having an issue with inserting a word document into another and keeping the original formatting of both. I built the main document so that all I would need to do is insert my supporting documentation which has to be of a different format. I tried next page section breaks and it generates the next page but all the formatting is still tied to the main document. Thanks in advance.
Just make a regular copy and paste. Control+C on source and Control+V on destiny. Best.

Mail Merge with multiple child records

I have a mail merge template, which includes a bunch of information about the entity that it is associated with in CRM. However, I'm needing a way to add all of the child records from my main entity in to the mail merge template as well.
Is there a way to have a sub record set inside a template?
The easiest solution might be Invantive Composition by inserting a <invantive:foreach>...</invantive:foreach> or through insert building block in the ribbon (note that I work there, but there is also a free version). Alternative solution I've used in the past are programming it completely (using RTF generation outside of Word or VBA or VSTO in Word). But this is quite hard to get right for tables. When the amount of sub records is somewhat limited, you might use PIVOT (see this for example) to change it all into one big record and insert the fields in your document. In the document you may need to hide all placeholders for the sub records not present in a specific instance.

Itemized bills in Word

I'd like to generate itemized bills for a non-profit as a Word mail merge.
Right now, the source data is stored in Excel in a pivot-table-like structure (this wasn't my idea) with two cells (owed and paid) per item type per customer. (Each customer has one row, and each item type has two columns). The existing data is in this structure, but if there's a way to automatically convert it to something better, I'm open to ideas.
I currently have a Word mail merge document generated by a Word macro that writes a Word IF field code for every pair of columns (item type). (Not all customers have all item types, so I need IF fields to exclude the ones each customer doesn't owe).
The problem is that only I know how to operate this system, and I no longer have time to generate all of the bills myself.
Ideally, I'd write my own billing app (this would also solve a number of other problems), but I don't have time for that, either.
Is there any way to (reasonably quickly) make a system to allow somewhat less technical people to do all of the billing without me?
We've looked into QuickBooks, but it cannot import the existing transactions.
Here is one solution I've thought of:
Manipulate the Excel data into a non-pivoted form with one row per transaction (per item per customer, or per pair of cells in the current structure). I actually already did this in a failed attempt to import the transactions to QuickBooks.
Each row would turn into one item in the bill (as opposed the the current, pivoted, form where each row turns into an entire page with many items)
Then, make a Word merge document that checks whether the current row is the first row for a different customer, and, if it is, include the entire text of the bill (as opposed to the items) in two (very large) IF field codes.
All of the rows would generate an item in the bill.
Each customer's last row would follow that with the second half of the text for the old customer (the part after the items).
Each customer's first row would precede it with the first half of the text for the new customer (the part before the items).
Two IFs are necessary to handle the first and last customer.
I would have to add a formula column to the spreadsheet that tells me whether to insert the prefix, the suffix, or neither, as that's impossible to do in Word. (You can't peek the next record)
The merge generator would still be a complicated monstrosity, but it would never need to change; new item types would be picked up from the source data. (Unlike the current merge generator which requires a new macro-generated field code for each new item type). Even so, I'd probably make a macro to generate it in case the texts change. (Editing texts inside field codes is very annoying).
Both Word and Excel have VBA built-in and if you use these, then you are not limited in what you can do. This type of application really should be driven from a database (Access) which would generate itemized bills, add a preamble, and a bottom total and miscellaneous after the itemization.
However, if you need to stick with the Excel data, then think of Excel as the database, write your VBA code in Excel to produce the bills, and then either assemble the word document in Excel (VBA) or place it in a worksheet format that only requires trivial work from a Word template to pull it all in.

Mailmerge Field not always saved the same way in Word .docx

I have created a Word document with Word 2003 and inserted some MergeField via the GUI.
I have saved it as a .docx by using Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats. Some Mergefields are stored as a SimpleField, while others are stored as a FieldCode (with start-FieldChar and end-FieldChar). Some Googling brought me to this blog. As you can see the guy is facing the same problem; but hasn't found a solution yet.
I'm using the following code sample on Codeplex [Fill Mergefields] to replace the MergeFields with the actual values from different datasources.
Any help is welcome.
If a field's value is just simple text with consistent formatting, it can be stored as a fldSimple node. However, if the field's value has varying formatting, it has to be saved as a complex field (fldChar Start, Optional Separate, and End) so that each run within the field's value can have it's different formatting defined in the run properties <w:rPr>. I think that also happens if word uses the rsid attributes to track changes. The fldChar Start/Separate/End are also necessary if the fields are nested, such as multiple IF fields, so that it can store an arbitrary number of <w:r>, <w:p>, <w:tbl> as the field's value.
And sometimes it stores them like that for seemingly no good reason. (As that blog noted).