One of our developers asked about transferring data from A-Shell to Microsoft Word in a particular context. Here's a description of one way of accomplishing the transfer.

====================

Situation: A client uses Microsoft Word to generate pro-forma invoices. She opens a Word document or template, which is a fairly sophisticated form, and types in (a) all the customer data like ship-to address, bill-to address, contact info, etc., and (b) the temporary invoice data. She sends it to the customer as a Word document or PDF or printed page. She saves the word document as "customer1.doc," because she might have to go back and reference that document, or perhaps modify and reprint it.

Problem: typing the customer data into the invoice is time-consuming and subject to keyboard errors.

Objective: Do not change anything about the process described above except one thing: instead of having the operator type in the customer data (ship-to, bill-to, etc.), have that data automatically stuffed into the form by A-Shell.

Solution:

1. In A-Shell, client executes a function that means "generate customer data for insertion into pro-forma invoice."

2. A-Shell writes that data into a CSV file.

3. Client opens the Word document, which contains links to individual data fields in the CSV file; data from the CSV file is sucked into the Word document.

4. The Word document now has all customer data. Client finishes entering invoice data and otherwise customizes the document.

5. In Word, client manually executes "Select All" and "Unlink" (two keystrokes).

6. Customer prints and saves "customer1.doc." Next time she opens it, the data fields will NOT be updated, since all the links have been disabled.

7. The original Word document/template has not been changed, so it and the CSV file are ready for the next instance of the process.

Observations:

a. A similar solution can be effected by having A-Shell write the data to the Windows clipboard, and then having the client manually paste the data from the clipboard into the applicable location in the Word document. The downside of this method is that the data must all be going to one, contiguous space in the Word document. With the links method described above, the data fields can be anywhere in the document.

b. In step 3 above, the updating of the Word doc can be automatic or in response to an "Update links?" prompt.

c. A variation of this method can be used to create multiple (tens/hundreds/thousands) "mail merge" Word documents for monthly statements, etc., that allow the client to create fancy, exotic forms for customer data while keeping the data itself firmly under control of the originating A-Shell program.

d. The MicroSabio staff has a modest amount of knowledge and experience with Word and Excel, and can help you design projects of this sort.

Interesting topic Ty, We have on-going thoughts on something similar where a customer wants their "quotations" and "certificates" they create currently in Madics/Ashell in a MS Word document (or PDF) where they then can amend/append/change the document before they finally print/email it to their customer.

We originally also tried the CSV methods and mail merge and/or macros in MS Word, but had several formatting issues due to different data coming across from Madics/Ashell (they are complex documents) and not 100% the same each time.

Currently we have found the best route (so far) is to create a text file document and display it a RTF XText, the user then can copy/paste and add images and tables here, and once they are happy they have the option to use the Xtext "Save as" to save it as a RTF file (and then use MS Word) on their PC, or we use the Ashells GDI printing to go further and create a "calibration documents" where we includes the RTF file with in it.

There are ups and downs to this and the customers not fully gone live with this yet, so if anyone does come up with some other great solutions to Ashell -> MS Word integration im also all ears.

Steve--I think that if there is a one-to-one relationship between A-Shell data elements and the Word data elements, then the method that I described should work fine. But if there are different data elements included in each output document, as sounds like there are in your situation, then the links strategy wouldn't work and your XTEXT approach would be better. Jack was going to write an add-on note to my post talking about using XTEXT in that context, he now may or may not add something to your note. Thanks

I was just going to note that XTEXT supports a merge facility during printing, via the //XMFIELDS and //XMDATA GDI commands. But in this case, the output is going to be a printed document (or PDF), not another editable document.

We do something similar. A Word document template (.DOT) is created with 'placeholders' (Invoice, Statement, PO, etc). The A-Shell program then creates a text file of placeholder translations and other instructions (i.e. email, fax, print, save, PDF). Finally the A-Shell program launches a program on the PC (.EXE) that reads the text file and merges it with the template to create the final Word document.