If you have multiple documents and you don't want to make hard-coding the document filling code your life's work, then you absolutely need to tablize the data to handle the filling.
I have two different methods I use in applications. One is very complicated and gives the user the ability to actually define new data fields. This is still within limits though. the application is used to fill the documents used to create an insurance policy. The company was a startup and was rapidly expanding the types of policies they would write. Policies had common data and they had unique data. It was the unique data fields that the users could define. This data was stored in an ultra-normalized table that stored each data field as a separate row. So the table had the following fields:
RecID (autonumber, PK)
PolicyID (FK to tblPolicies)
FieldID (FK to tblFields)
TextValue
The tblFields contains the definition for a field as well as its name. To provide flexibility, ALL data is entered as text. The tblFields species the data type and even provides a query name if the data should displayed as a combo.
Then there's other tables to connect fields to policyTypes and documents.
The simpler method provides a fixed set of data so if you need to change the data that is used to fill the forms, you need to modify the program since the tables are standard rather than Name/value lists like the complex example.
I've posted pictures of the complex solution multiple times. But here is a picture of the form where you define a new Document and then map fields to bookmarks. For the sake of sanity, I use the fieldname as the bookmark name but sometimes, you need to use the same field in a document multiple times. Notice that AmnestyEndDate is used three times and so has three bookmarks. Bookmark names in a document MUST be unique so I use a numeric suffix.
Since many documents have a similar set of fields, there is a copy option. For this process, you create the new doc header and then use the combo to pick the "from" document. You can obviously do this the other way if you prefer. But I think this ends up being more flexible if you want to merge documents. You can copy the bookmarks from multiple documents. Due to the indexes, only one instance of the book mark will be added. Duplicates will be discarded.
Since this is a small project and all the data can be selected by a single query, there isn't an option to pick a query to associate with the document but you could do that. Some of these documents use those little tables you see in the example. Since there were only three of them and there was little chance of having to make more due to the type of data, I went the hardcode route. If the FieldName is one of the "special" ones, the app opens a query to select the dependent data to build the table and then insert it into the document. As you can see by the example, this process is separate from the main line of filling the form fields.
View attachment 104739
This application, since it was intended to create letters to employees offered the option of a language preference. All the user needed to do was to create whatever versions of the document he wanted and use "_English", "_Spanish", whatever as the suffix. You could of course just create duplicate documents with hard coded language in the names but this seemed cleaner.
