This content has been marked as final. Show 2 replies
there are several ways in which you can achieve this, depending on your data:
1. use a multi-step job with each job calling a different MDF.
2. use the ^form command within the preamble of Form A to call Form B.
3. use a transformation to insert ^form commands into the data file to call each form.
I probably missed this one earlier or felt that since it referenced an XML data file that I couldn't provide a definitive answer. I'm still not sure I can because we don't use XML for our data files, but use the "field nominated format".<br /><br />An expansion on Tammy's information:<br /><br />1. use a multi-step job with each <br />b task<br />calling a different MDF.<br />With this correction, it assumes that you either have access to set up the tasks/jobs yourself or can convince your Central administrator to do so. What happens is that TASKA is set up to reference FORMA and TASKB is set up to reference FORMB. Then a job is set up that causes both TASKA & TASKB to be ran. This will likely result in two different print files being sent to the printer. That may or may not be desirable, depending on whether your printer is set up to do something special between each print file (insert separator page, offset, whatever). Personally, I don't recommend this as it can quickly cause an unnecessary proliferation of tasks and jobs (we print 100's of differing form combinations with a single job definition).<br /><br />2. I can't really address this as I didn't even know that a single form could cause another to be called. I would expect that unless the "base" form (say it is FORMA) is to always print with the secondary form (FORMB) it is restrictive and has the potential to cause a proliferation of FORMA files for the various combinations that are to be printed. Maybe it is possible to have logic to check the value of a data field to control what forms get called.<br /><br />3. If you pass the XML file through a translation step and then through the transformation agent (maybe it can be done in a single step) this should work. It does add another step to the job as well as requiring learning to use the transformation agent. Depending on the combination of forms to be printed, you might need a different translation definition for each one, or at the very least have a data field that you can check the value of to determine what ^form commands to put in the output file.<br /><br />4. My recommendation is based on assuming an XML data file has the same capabilities as a field nominated file. Within a field nominated file are various print agent commands, including references to data as well as which forms are to be printed (and a whole bunch of other commands). An XML file should have the same features - I just can't say what they might look like. If your current data file has no "form" reference but depends on the job/task definition you might have to stick with option 1. If it has a "form" reference, then you just need to insert additional references for additional forms. Then it is up to the source of your data (or a transformation agent step) to specify which forms are to be printed. For example, in field nominated format, the file might look like:<br /><br />^job XYZ additional parameters<br />^form FORMA.MDF<br />^field FIELD1<br />data<br />^field FIELD2<br />data<br />^form FORMB.MDF<br />^field FIELD1<br />data<br />^field FIELD3<br />data<br /><br />or it might look like the way our files look:<br /><br />^job XYZ additional parameters<br />^global FIELD1<br />data<br />^global FIELD2<br />data<br />^global FIELD3<br />data<br />^form FORMA.MDF<br />^form FORMB.MDF<br /><br />As you can see in the first example, there is a reference to the form followed by all fields that go on it followed by another form reference with the fields that go on it. This particular method, using all "^field" commands for defining the data requires that data duplicated between the forms be duplicated. (Or, the use of some ^global commands like the following.)<br /><br />In the second example, all data is defined first using the "^global" command followed by all of the form references. This allows for the data to be defined only once. If there is something unique regarding a particular form the field can be ^global at the beginning or it can be ^field <br />b after<br />the ^form reference (similar to the first example).<br /><br />As previously mentioned, the XML file should have the same capability but in XML notation, something like the following (forgive me as it has been years since I took the XML class and don't use it in my daily work so the actual format could be wrong, not to mention the actual labels):<br /><br /><job name=XYZ,option=aaaa,option=bbbbbbb><br /> <form name=FORMA.MDF><br /> <field name=FIELD1, value=xxxxxxxxxxx></field><br /> <field name=FIELD2, value="xxxxxxxxxxxxx"></field><br /> </form><br /> <form name=FORMA.MDF><br /> etcetera<br /></job><br /><br />or maybe:<br /><br /><job name=XYZ,option=aaaa,option=bbbbbbb><br /> <global name=FIELD1,value=xxxxxxxxxxxx></global><br /> <global name=FIELD2,value="xxxxxxxxxxxxx"></global><br /> etcetera<br /> <form name=FORMA.MDF></form><br /> <form name=FORMB.MDF></form><br /></job><br /><br />or even (but I doubt it):<br /><br /><job name=XYZ,option=aaaa,option=bbbbbbb><br /> <globals><br /> name=FIELD1,value=xxxxxxxxxxxxxxxx,<br /> name=FIELD2,value="xxxxxxxxxxxxxxx"<br /> </globals><br /> <forms><br /> name=FORMA.MDF,<br /> name=FORMB.MDF<br /> </forms><br /></job>