That is what we are already doing. We use insurance forms for all 50 states such as applications, loss notices, endorsements, binders, etc. Adobe handles it all. We store the data in our VFP app and pass it to Adobe Reader by creating an xfdf file which is associated with pdf files. The xfdf file is actually an xml file that matches the fields on the pdf form (fillable pdf forms). We launch Adobe Reader from our VfP app by sending the xfdf file name and the form is launched with all of the fields on the pdf form filled in.

Tracy

>Hi Tracy,
>
>I don't think we have a standard - maybe for "typical" life co. products life Life or Term Insurance but this client sells annuities for accident victims etc and it seems that the forms are always "low priority" for the life companies to automate because they are such a small part of their business (high dollar but low volume so they drag their heels).
>
>Anyhow, I talked to an Adobe rep and they gave me the pricing on the server product - they were supposed to call back with a "techie" but they have not yet - maybe when they figured out there was no sales of a server, their screening screened us out.
>
>I looked a bit at the Adobe Output Designer (latest name I think) and it did not mention being able to "pre-stuff" the form with data - if that is the case, then I only need to buy 1 designer package and we are away.
>
>When you say that you use VFP to send the data to the Adobe form, how is this done ie. how does the xml string get into the Adobe reader? Is this done by some sort of file association (set xml documents to open via Adobe reader) or is there some sort of automation you can do so that you can fire up Adobe from within VFP and then access properties to stuff the data into?
>
>Also, these forms are "mega-complex" - from 3 to 5 pages each with lots of detail and lots of data transformations ie. for one company, the user would have filled in an "M" or "F" for Gender whereas another company has the user check a [ ]male or [ ]female checkbox. Same goes for lots of other detail (read "pain") - some break their dates into 3 fields and others use one field. One question: the data is such that it is "one to many" for numereous fields (not sure the correct term for this). e.g. there is always one application ("app") but there can be 1 to many "beneficiaries" (each with their own address); there can be 1 or more "owners" (the person and optinally a spouse); there can be one or more income streams (eg. a monthly payment and then another "stream" of yearly payments). So do you think Adobe can handle this type of data? Some things like multiple beneficiaries show up as separate fields on the form eg. if there are 2 owners, then there might be two spaces on the form
>for LastName1, FirstName1, Middle1 etc and then a Lastname2, FirstName2 etc (along with all the other info). Whereas other things like the payment streams typically can be put into a grid. I have done a bit in xml but not enough to know who you can handle "grid" like data structures.
>
>Anyhow, enough questions! Thanks for the help - I was leaning away from Adobe as I did not think their Designer product would do what I needed.
>
>Albert
>
>>You say that these forms will be sent to insurance companies. Is there a standard in Canada like there is in the U.S. that produces acceptable forms? In the U.S. we have ACORD. It is the insurance standard industry and actually produces the forms for all states. We pay a membership fee to ACORD for using and redistributing the forms (since they can change frequently). ACORD produces the forms in many different formats and will be making fillable pdf forms available in September. Up to now we received the pdf forms and had to add the fillable fields to them ourselves using Acrobat. You simply send the data to the pdf in an xml file which we do now from our VFP app and launch the pdf form in Adobe Reader on the user's workstation. Adobe also has a new product called Form Designer which is not the same as the Acrobat product and allows you to fully create the form from scratch, add the fields, connect to backend databases, etc. If you are only using it to design the forms and
>you
>> pass the data via an xml file than you don't need the server version. The server version is only needed if you set it up like a server with an inhouse backend to populate the form fields with. If you pass the values to fill the fields instead to the already existing form, then you only need the designer to create the form to begin with.
>>
>>
>>
>>>Hi,
>>>
>>>A client of mine has used Delrina Form Flow (old product) to replicate some very complex forms required by insurance companies. These forms were too complex to reproduce in Foxpro. They would now like to upgrade to something that would allow them to pass data from VFP to these forms (the previously re-entered the data - it was set up about 8 years ago).
>>>
>>>Delrina was bought by JetForm and then Jetform somehow is now an Adobe product. Adobe has a server product that would allow me to send xml data to the server that would then be merged into the forms template and then printed (for signing and mailng to the insurace co.). Only problem is, Adobe server is $9,000 US and this is being used by a 2 person office - I don't think I have a hope in heck of getting them to go for that.
>>>
>>>So anyone use any really good forms software that I could send data to it either via xml or via some other way?
>>>
>>>Thanks,
>>>Albert