We are in the final stages of developing an end-to-end solution for weekly
status reports being rolled up through the merge forms method in a SharePoint
Library.  It starts with an InfoPath 2007 form template having client-side,
managed code behind a button to successfully convert data (including RTF
fields, and with some of those controls embedded in repeating sections), and
rendering these properly in a Word .docx template.  All of this builds on the
marvelous technique first documented by S.Y.M Wong-A-Ton, a constant
contributor to this community.

An interesting discovery, and one that is optimal in our situation, is that
the form may be published to a SharePoint Document Library without
administrator intervention because the code does not require .NET,
server-side interaction.  Most of what I read states clearly, if there is any
'managed code' behind the form, administrative credentials are required to
publish it on SharePoint.  I do not know what to say.  I published the form
to a production server for which I do not possess administrative privileges
and later downloaded it to the InfoPath client on my laptop.

Good so far, but I ran into the latest wall when I went to add the standard,
unique file-naming functionality for a Form Submit to a single location (the
SharePoint Document Library) by trying to use the Fx button to insert a field
or a function.  Nothing works.  Everything I try produces a 'duplicate
attribute' error.  I read where someone experienced this when a Receive data
connection involved an XSLT file, such as we use.  I temporarily deleted this
single, existing data connection and rebuilt the form within the VS2005
project, but the same behavior persists.  I see references to this error in
various searches, but I do not see real solutions, except that the Fx
capabilities should work.  E.g., I have tried to insert the function today(),
or any field element in my Data Source or even a field attribute that I
created for the intension of hiding it with the concatenated filename of
practiceName, userName, and the substrings to create the YYYYMMDD of the
reportDate field.

So, I am pulling out what little hair is left trying to imagine what to do
next.  Thus, I  come back to where this all started.  My appreciation will
only be exceeded by the glee of seeing some viable resolution of this issue.  
As I stated previously, this solution will be shared once it is piloted and
rolled out to our group (over 30 consultants).  I intend to forward what I
have to S.Y.M Wong-A-Ton, who may then elect to tighten up the code and help
to improve what documentation will be provided, in an effort to get it out
for others to use.

  Joe