Validate and Split File
Parses, Validates, and Splits a document according to specified rules.
Note
The Validate and Split File operation should not be used to parse 999 files. The Validate File widget must be used instead.
Widget
Configuration
Fill in the following fields:
Description: Allows changing the name that appears on the widget. This may be useful to quickly find a particular widget or distinguishing it from other similar shovel operation widgets when building large flows.
Shovel Operation: The name of the Shovel Operation. Pre-configured to ValidateAndSplitFile.
processorType: This is the type of processor used to perform the validation. At the moment the only processor type available is Vix12.
fileType: A validation processor can potentially parse and validate different types of file. Use this property to specify the file type being parsed and validated. The possible values are the following: X12, 837i, 837p, 835, 834, 999)
parseContext: The name of the context document where the result of the parsed entity (claims or enrollment records) will be saved.
validationContext: The context document to add validation results to.
validationRules: These are the validation rule to apply while validating the file in order to bypass the standard rules.
The exception rules need to be configured on each transaction coming from the network, below are the two exceptions that needs to be configured:
Loop 2300: REF segment is required where REF01 = F8 (so REF01 and REF02 should be
Loop 2010BA – In NM1 segment, NM108 will be “SI” (a non standard qualifier) and NM109 is required
JSON:
[ { "Type": "change_object_min", "Rule": { "Location": { "Loop": [ "2000C", "2300" ], "Object": { "ID": "REF", "Name": "Payer Claim Control Number" } }, "Min": 1 } }, { "Type": "set_element_allowed_values", "Rule": { "Location": { "Loop": [ "2000B", "2010BA" ], "Object": { "ID": "NM1", "Name": "Subscriber Name" } }, "ElementIndex": 8, "Values": ["SI"] } }, { "Type": "set_element_usage", "Rule": { "Location": { "Loop": [ "2000B", "2010BA" ], "Object": { "ID": "NM1", "Name": "Subscriber Name" } }, "ElementIndex": 9, "Usage": "REQUIRED" } } ]
splitSegmentLoop: Loop to split the segments into new flow files. Allows treating good and bad segments separately since they will be independent in the flow files.
send999Accepts:
True: Send AK2/IK5 always for every transaction set.
False: Send AK2/IK5 only for rejected transaction sets. This is the recommended setting for large files.
outputTransactionSetImmediately:
enrichOutput: Add human readable details to the parsed split portions of the file.
enrich999Output: Add human readable details to the generated 999 JSON
snip3Validation: If true this will validate the SNIP 3 rules in the X12 Schema. If false, it will not validate them.
snip4Validation: If true this will validate the SNIP 4 rules in the X12 Schema. If false, it will not validate them.
snip5Validation: If true this will validate the SNIP 3 rules in the X12 Schema. If false, it will not validate them.
loggedFields: Map of the logging name to the X12 field name. For example {"PayerClaimID":"claimId"} the X12 field must be an annotated field within the schema and must be loggable according to the schema.
If necessary, click the Notes tab and enter any relevant information.
Click Save.
The widget will be marked with a green check.
