Input.CheckDuplicateMacro(*) | To use the Cancel and Error modes for duplicate checking, an additional field macro expression is required to perform this check. The function BatchExists(), for example, is specifically designed for this purpose. The field macro expression must return a Boolean value indicating whether the batch already exists. Alternatively, an array might be returned. In the case of the latter, the existence of array elements will indicate that batches exist. The field variables that can be used in this expression refer to the first document in the batch if the batch contains multiple documents. |
Input.DocSplit.Mode Input.DocSplit.ConditionMacro(*) Input.DocSplit.FileFilter | Definition of the restructuring of batch contents Restructuring involves separating a batch of documents into multiple individual documents. The file attachments of the documents serve as a basis for this. For separation, a document must have more than one file attachment (e.g., to create an independent document from each file attachment). Barcode separation is the only case where splitting does not proceed across multiple file attachments. Here, a single attachment is split into multiple documents. The working mode of the separation is set via the .Mode property: All modes except Barcode refer to the file attachments as a whole. Depending on the mode selected, specify an additional parameter in the .ConditionMacro property. Syntactically, this will always be a field macro expression; however, this expression could represent a single constant, for example. StartCondition, EndCondition and RepeatNamePart can use not only general document-specific variables, but also variables that relate to the file attachment currently being evaluated (see Variables). The purpose of the .FileFilter property is to select the file attachments that will be used for separation (default value: *). All other attachments are attached unchanged as copies to each split document. The split documents generated are given the name suffix .splitN, in which N represents a serial number. FixedFileNo mode: the macro must return an integer value n, which defines that the document will be split into a separate document after every nth file attachment. This separation always refers to the order in which the attachments are assigned to the document. This also applies to the two subsequent modes.
StartCondition and EndCondition modes: the macro is executed by file attachment. The macro must return a Boolean value that defines that a splitting of the document occur.
The following example shows how, for each attachment with "Invoice" in its name, a new document starts: Contains(@FileName, "Invoice") NoticeIn StartCondition mode, note the following: if the first file attachment with a positive separation condition is not at the beginning, no separation will be made by default. Instead, the preceding file attachments will be assigned to the first document. Example: There are two file attachments, Attachment and Invoice, in the incorrect sequence. With this sequence, the separation condition mentioned above would result in Attachment being separated out. The attachment that actually belongs to the invoice would become a document in its own right. Such an error case with a reversed sequence can thus be intercepted. However, if there are multiple invoices and associated attachments, the sequence must be adhered to in order to correctly assign the attachments to their respective invoices. If this implicit mode of operation is not desired, it must be explicitly overridden (e.g., by adding a condition that always makes the first file attachment a separate document): (@FileNo == 1) || Contains(@FileName, "Invoice") RepeatNamePart mode: the macro is executed by attachment. The macro must supply a string. This string is typically obtained from the file name. Out of multiple attachments that are all identified with the same string, multiple independent documents will be formed, one for each attachment.
The first 8 digits may contain an invoice number. Here is an example that shows how to extract these digits from the name, and how to combine all attachments that have the same digits in their names: Left(@FileName, 8) Barcode mode: use the file macro SplitByBarcode(). Use same parameterization for this as for the other use of this macro. The first default parameter for the input file pattern will be ignored. The reason for this is that a separate property for it exists in this context with .FileFilter
Example: SplitByBarcode( , , "All", "Simple", "########")
The variable %SplitFileNo% must be used in the output file name for the sequential number of the split file, as %FileNo% refers to the number of the source file in this context. |
Input.DocSplit.PreProcessMacro[] Input.PreProcessMacro[] Input.PostProcessMacro[] | When new documents are read, the definition of macro functions of any type, executed in a pre-processing step or a post-processing step "Pre-processing" refers to the processing of content that has already been read. Data is first read in from the input system, and then pre-processing macros are executed. Then the two levels of pre-processing will be available: Pre-processing that takes place before a restructuring of the batch defined by Input.DocSplit (. DocSplit.PreProcessMacro[]) Pre-processing that takes place after a restructuring of the batch defined by Input.DocSplit (.PreProcessMacro[])
Finally, the post-processing macros are executed (.PostProcessMacro[]). At this point, no field catalog is assigned to the documents. This assignment is not made until the index data reading process in the subsequent processing step. Therefore, macro functions in the input step cannot reference fields that have already been read in. At this point, however, functions can be called that read properties of file attachments or values from file attachments, etc. If multiple functions are executed one after the other, these values can be assigned to temporary variables. These temporary variables can be referenced in subsequent functions. The variables will be valid only in the context of the macroblock to be executed. A field value that has already been generated by macro in the input step might be temporarily stored and transferred to the orocessing step despite a missing field catalog. If such a value is assigned to a temporary variable and this variable has the same name as a field from the field catalog, the variable value is implicitly used as the initial value of the field when the field catalog is assigned. If there is an initial value defined directly for the field, it will be ignored. |
Input.TrackingIdMacro Input.TrackingKeyMacro Input.CustomKeyMacro | Macro functions that generate specific key values for a document (optional) .TrackingIdMacro and .TrackingKeyMacro are technical keys that are primarily used in interaction with other xSuite applications. This enables tracking of documents across all the programs involved in a processing route. Syntactically, UUIDs or a sequential counter are typically used. If documents are initially read in or generated by xSuite Interface, the tracking values should also be generated using the adjacent configuration properties.
In particular, the field macro functions GetUuid() and GetDbCounter() are meant for generating tracking values. For all xSuite applications that serve as input systems or output systems and explicitly support tracking, the respective values are automatically adopted or transferred. You do not need to perform any separate configuration for this. For input interfaces to xSuite Helix Cloud, note that only the tracking key can be transferred. The tracking ID is generated by xSuite Helix itself. .CustomKeyMacro is a key of type "Text". You can define this key as desired to describe field content. The purpose of this key is to display relevant index field contents from the field catalog directly in a dedicated property of the document. When monitoring, content is then identified quicker, allowing more targeted searching.
The three configuration properties exist in identical form for the property Process. Depending on where of the two places the configuration properties are used, the documents receive the result values in the input step or in the processing step. Note that the index field contents of the documents are not read until the processing step. Therefore, when referenced, that is the only place where the key values can be generated. |