Interchange Accept Process

This section is specific to the E2B (R3) Import.

The application function flow for importing (R3) based ICSR messages in the Interchange accept process is similar to that of the (R2) except for the updates specified in this section.

Note:

Any xsd/xslt/dtd validations that may apply to any of the internal processing/ massaging/ transformations of the xml message are configurable at profile level.

• The application supports importing of batch (R3) messages consisting of more than one report.
• The maximum file size allowed to be imported into Argus respects the value configured in Argus Console -> Reporting Destination -> EDI -> Allowed report size (in MB) for the receiving Agency.
• The Interchange Accept process performs the following validations on the incoming (R3) message:

  Hard Validation: In case of a validation error under this category, the Interchange Accept process rejects the incoming message and generates a negative ACK with the required error message. For more information on ACK mapping details, refer to the ACK element level mappings. The following are the categories of hard validations:

  1. Length validation
  2. Code list data validations
  3. Minimum case creation validation

  Soft Validation: In case of a validation error under this category, the Interchange Accept process does not reject the incoming message. Instead, the process maintains a log of errors under this category for future reference in the ICSR Pending screen (for more details, refer to the ICSR Pending screen) and in the Case Attachment (for more details, refer Case creation/updation section). The following are the categories of soft validations:

  1. Element Conformance validation
  2. Mandatory along with validation
  3. Additional validation

  The logic to identify the case over which the Incoming (R3) ICSR message is imported as a Follow-up is configurable at the profile level.

• The accept process loads all the data from the incoming (R3) based ICSR message to staging schema without any data loss.
• The application logic to identify the Agency whose profile configuration is used during the import of the (R3) based ICSR message is as follows:
  1. Reporting Destination'EDI'Agency Identifier: N.1.3-BATCHMESSAGESENDERIDENTIFIER / N.2.r.2 - MESSAGESENDERIDENTIFIER
  2. Reporting Destination'EDI'Company Identifier: N.1.4-BATCHMESSAGERECEIVERIDENTIFIER / N.2.r.3 - MESSAGERECEIVERIDENTIFIER
  3. Reporting Destination'EDI' Primary Receive Agency: Checked
• All the respective statuses that are applicable for the existing (R2) message have been updated for the (R3) message in a similar manner. These statuses can be tracked in various screen in Argus UI such as Reports > ICSR Pending (Pending & processed tabs) & Utilities > ICSR > ICSR Receive Status).
• Duplicate (R3) message identification is governed based on the value in the N.1.2 -BATCHMESSAGENUMB tag.
• The existing application to identify the Initial/Follow-up/Downgrade/Nullification has been enhanced to identify the Amendment report based on the C.1.11.1- CASENULLIFICATION. The amendment identification is only applicable for (R3) message as the concept of amendment report is specific to (R3) reports only.
• The acceptance process every stage of import evaluates the various import stages and generates the ACK in the (R3) format.