🚀 Synthesized 12 highly-detailed Agile User Stories covering 12 EDI-active COBOL programs in CA Cargo.
🔍

Module: GCCCANRL 1 Consolidated Epic Story

Epic: GCCCANRL Complete EDI Specification Extracted from Legacy
Contains 17 distinct extracted legacy rules
EDI Epic Specification
As an EDI Gateway Service,
I want to orchestrate and execute all GCCCANRL EDI data mapping and validation logic,
So that I can ensure strict compliance with US Customs (P140) automated payload constraints in a single consolidated service.
Prerequisites & Setup
  • [Initialize Empty Segment]
    The table response is not available → The Master Control table segment should be initialized to empty values
Core Acceptance Criteria
  • [11:Set Manual Change Flag]
    The system updates manifest data → The 309 manual change flag is set to true
  • [Log Cancel Release Activity]
    Cancel release processing is complete → Create audit log entry with security information, CCN key, transaction details, user ID, timestamp, and cargo release removal action code, then write the log message to the system
  • [Extract Station Number from Retrieved Record]
    The system processes the retrieved station information → The station number is extracted from the master control segment and moved to the table segment
  • [Use Current Manifest Station Number]
    The system handles the lookup failure → The master control segment is initialized to empty values
  • [Set Destination Station Number for Index]
    The system needs to set the destination station number for indexing → The existing destination station number from the manifest is used for the index field
  • [Extract Station Number from Response]
    The response contains valid station information → The station number should be extracted from the response segment
  • [Set Manual Change Flag to TRUE]
    The system is setting cancel release data for the manifest → The manual change flag (309-MANUAL-CHANGE) must be set to TRUE to indicate manual intervention
  • [Prepare Log Message]
    Preparing to send the log entry → The audit information should be formatted into the message structure and the accept status should be cleared
  • [Send Log Entry to Audit System]
    Sending the log entry to the audit system → The system should call the audit service to process the log entry
  • [Write Message to Log]
    Writing to the system log → The message should be written to the log with proper message code, content, length, and module name
  • [Set Security Information]
    The system prepares the audit log message → The security byte is set to high-values for maximum security classification
  • [Format Complete Log Message]
    The log message needs to be transmitted → The complete log input structure is moved to the message format for processing
  • [Format Message for Logging]
    The system prepares to send the audit entry → The log input data must be moved to the message structure for proper formatting
  • [Send Message to Audit System]
    The system sends the audit entry → The CIMS program must be called with CHNG function to transmit the audit message through the alternate PCB
  • [Write Message to Log]
    The system writes the message to the log → The WRITMSGL program must be called with the message code, message content, message length, and module name
  • [Purge Message Queue]
    The system completes the logging process → The CIMS program must be called with PURG function to purge the message queue through the alternate PCB
Structural Validations
  • None explicitly identified in logic extraction.