10 Gazillion Form Letters

[macguys]

I've been assigned to add a whole slew of form letters to a database. The letters require merge fields. Most of the form letters are consistant but some are going to change over time. The client will also have to write the occasional custom letter. I'm looking for a best practice suggestion for handling this. I've looked at having each letter be a separate layout but that means that any changes to the text will have to be done by editing the layout; something that I don't really want my users doing.

I've explored eZxslt and am wondering if that is the right way to proceed.

Regards,

Dave

[Ender]

Hi Dave,

I have done this in my current project. Structurally, each form letter is kept in a Stationary table, Contacts are then assigned to receive a particular Stationary letter by adding a record in a Contact_Stationary join table.

For putting the form letter together, I use a Letter Body field that is entered by the user. They can insert merge fields within this text by typing one of the allowed fields in the proper format, or by choosing a merge field from a list in a portal. In the join table, a calculation substitutes the merge fields names for the corresponding related contact field.

I started out doing this with my FieldSubstitute() Custom Function , but this custom function as it is could give users access to data they shouldn't see, so I have adjusted it to only allow related fields from Contact and Stationary.

This substitution could also be done explicitly by using multiple substitute() functions. Database Pros has as an example of this, and BobWeaver recently posted a description.

One of the tricky things I ran into while doing this is dealing with formatting. It makes sense that in some cases users may wish to use a larger or smaller font than what you have as the default. Allowing them to set the formatting within the Letter Body field causes problems, both in readablity on screen and in the resulting merge letter. It's better to set the style explicitly by using the new text style functions, or as in my case, use The Shadow's CopyStyles() Custom Function (it's in the thread for FieldSubstitute(),) to copy a style that the user sets in a Style field.

Hopefully that gives you some idea of how to do this entirely within FileMaker.

I don't know the details of how the xslt output thing works, but I saw it in a demo, and it's an neat way to do this. Maybe someone else has more on this.

[Fenton]

Ender's method is probably the best, especially for "gazillion" letters. But I wanted to point out that in version 7 you can now allow user access to specific layouts, and allow them to even access new layouts they create (though that's kind of a scary idea).

Another huge factor is whether some of these are truly a "custom" letter, or whether they are simply modified bulk letters. The difference is that a real custom letter must be saved, the entire text, as is. Whereas a modified bulk letter, where you've changed it a little, but don't really care to save the exact older text (certainly not for every letter sent), does not.

If the letter is simply a layout, then there is no easy way to "save" the letters sent earlier, if you modify the layout text (except maybe in a global field as picture, or as a PDF file). A letter which has been produced by Substituting into a (larger) text field with data from fields can be saved as text.

Whether you would want to save the entire text of every single letter is another question, and one worth asking; because it can use a lot of disk space, bloating the file (but not such a huge consideration in 7).

The ideal system would use the appropriate one, saving as needed. Kind of a lot of work. Not terribly hard if you have copies of all the letters, so you can analyze. But I would think difficult for the user to add letters, unless they understood the difference.

"Field-based", with saving when needed, otherwise not, is good; though layout-based is nice for bulk forms, especially if there is a lot of wacky formatting, or images. But it's important to find out about the types of letters they'll want to send, and what exactly they want to save.

It is not as hard as one would think to combine different methods, especially in version 7; with the new Go To Layout [ name of the layout ]. That means you can create a value list of layout names for layout-based Form letters, as well as for the "field-based" letters.

[macguys]

This system is for a law office doing Social Security and Workers Comp litigation. The Social Security stuff is mostly boilerplate with the occasional custom letter. The Workers Comp stuff is all custom. I've played with the eZxslt and it works pretty well. My current plan is to use a combination of boiler plate letters and Enders letter body variable approach. In both cases, I'll export the data to Word using XML. The reason that I want to use Word has to do with, as Ender suggested, has to do with formatting. I've found that using small font sizes on layouts in FMP can cause problems. Lawyers are all about the "fine print".