A collection enables a dynamic process flow when you print several application forms in the print event.
The process flow hierarchy of a collection is processed similar to that of an application form. This means that the system calls the individual nodes from top to bottom hierarchically, and depending on the node type, carries out one of the following activities:
· Print application form
· Create composition
· Call user exit
You can
deactivate the node types composition and application form in Customizing so
that these are no longer processed. You can also deactivate each node
dynamically via user exit.
Collections are called up externally like normal application forms via the
modules EFG_PRINT or EFG_PRINT_EXPANDED. You enter the print parameters when
you call the collection, and, apart from the printer and the storage mode, you
can no longer change the parameters in the collection. For each collection
there is one generated module that contains the flow logic of a collection.
When an application calls up a collection, it can transfer additional
selection information for other form classes to the collection for processing.
The import variable X_TABN_SEL_PER_FCLASS of category EFG_TABN_SEL_PER_FCLASS
is available in module EFG_PRINT(_EXPANDED) for this. Usually, only the
selection data for one form class is transferred.
If you want to use an application form more than once in a collection, you
have to identify each use uniquely with a simple character string. This is the
only way that the macros MAC_DEACTIVATE and MAC_ACTIVATE, and the processes
for processing the application form can identify the nodes.
For each application form included in the collection, you can define
conditions. These conditions determine whether the application form is
processed. You can thereby make the issue of an application form dependent,
for example, on the send type or the RDI or XSF output format. Using user
exits and the macros MAC_DEACTIVATE and MAC_ACTIVATE, you can also make the
issue of an application form or a composition dynamic.
For each application form in a collection, you can define an output device and
a storage mode. These specifications override existing settings; if the fields
remain empty, the setting from the print parameters of the print process is
retained.
If there is no selection data (ranges table of module EFG_PRINT), various
different constellations can occur in the process flow of cross-form class
collections. If the application has already transferred selection parameters
for several form classes when calling EFG_PRINT, this information is forwarded
to the relevant application form dependent on the form class. However, if the
application only transfers the selection parameters for one form class
(standard case), an application form may have to be called without selection
parameters. To improve your control of the behavior of the collection
concerned, you can configure the behavior of the program as
follows:
· Suppress output
· Trigger errors
·
Call
application form
In this case, the application form or form class called must be able to derive
the selection parameters required for data procurement from other information,
for example, using the variable X_TAB_GENDATA transferred. This variable can
be delivered in the collection in a user exit by filling table C-T_GENDATA.
If you use the form type Smart Forms, the application form called can return the selected data to the collection using the parameter Data Handling, either in addition to the output or instead of it. The data is transferred to the variable C-T_GENDATA in the following key:
TYPE = “PWB_DATA”
KEY = <Name of application form>
ATTR = <Identification>
REF_TO_DATA = Data reference from the deep data type of the form class
XSTRING = Data as XML, including the variables in the user top include
In a user exit, you can supplement the process flow of a collection with additional dynamic logic. To do this, you have to create a form routine with the required coding in the user exit include. Within a user exit, you can, for example, access the variable C and dynamically deactivate specific nodes using the macro provided.