189 lines
6.4 KiB
Plaintext
189 lines
6.4 KiB
Plaintext
JIRA Story - RAG Knowledge Base
|
|
|
|
Accounting IA-2854: Add Transaction ID & Installment # to be Stored for Pending Cancel
|
|
|
|
Chunk 1: Overview
|
|
|
|
Metadata:
|
|
storyId=IA-2854, type=overview, domain=pendingCancel, workflow=dataStorage
|
|
|
|
Content:
|
|
Purpose:
|
|
Capture TransactionId and InstallmentNumber for each Pending Cancel record in AWS to maintain traceability to the source transaction invoice.
|
|
|
|
Business Goal:
|
|
Enable precise identification and reconciliation of Pending Cancel notices with their originating transactions, ensuring accurate processing, filtering, and reporting.
|
|
|
|
Core Behavior:
|
|
|
|
Store TransactionId and InstallmentNumber in AWS DynamoDB for each Pending Cancel
|
|
Allow filtering by PolicyNumber, TransactionId, and InstallmentNumber
|
|
Retrieve the latest transaction as the active invoice during processing
|
|
|
|
Outcome:
|
|
|
|
Pending Cancel records are fully traceable to their source transactions
|
|
Step Functions and Lambdas can accurately process, filter, and reconcile Pending Cancel data
|
|
Chunk 2: Preconditions and Dependencies
|
|
|
|
Metadata:
|
|
storyId=IA-2854, type=preconditions, dependencies=AWS,DynamoDB,iSeries,Lambda,StepFunctions
|
|
|
|
Content:
|
|
Required Preconditions:
|
|
|
|
AWS DynamoDB table for Pending Cancel data already exists
|
|
iSeries data flow for Pending Cancel records is operational
|
|
Step Functions and Lambdas for processing Pending Cancel data are deployed
|
|
|
|
Dependencies:
|
|
|
|
DynamoDB schema must support TransactionId and InstallmentNumber fields
|
|
Step Functions must consume Pending Cancel data with the new fields
|
|
Lambdas must filter and retrieve records based on PolicyNumber, TransactionId, and InstallmentNumber
|
|
|
|
Implicit Rule (Made Explicit):
|
|
|
|
Without DynamoDB table availability or schema updates, new fields cannot be captured
|
|
Step Functions and Lambdas must be updated in tandem with schema changes
|
|
Chunk 3: Functional Requirements - Pending Cancel Data
|
|
|
|
Metadata:
|
|
storyId=IA-2854, type=functional, documentType=PendingCancel
|
|
|
|
Content:
|
|
Required Fields (Normalized):
|
|
|
|
PolicyNumber
|
|
TransactionId
|
|
InstallmentNumber
|
|
PendingCancelNoticeDate
|
|
Status (Active/Processed)
|
|
|
|
Purpose:
|
|
Enhance Pending Cancel data model to enable traceability to original transactions and invoices.
|
|
|
|
Implicit Rules (Made Explicit):
|
|
|
|
PolicyNumber is primary key for retrieval
|
|
TransactionId represents the source invoice
|
|
InstallmentNumber identifies the specific installment linked to the Pending Cancel
|
|
Latest TransactionId per PolicyNumber is considered active for processing
|
|
Chunk 4: Workflow / Processing Flow
|
|
|
|
Metadata:
|
|
storyId=IA-2854, type=workflow, orchestration=pendingCancelProcessing
|
|
|
|
Content:
|
|
Processing Flow:
|
|
|
|
Receive Pending Cancel data from iSeries
|
|
Use PolicyNumber to query existing DynamoDB records
|
|
Store TransactionId and InstallmentNumber alongside Pending Cancel record
|
|
Step Functions and Lambdas filter records by PolicyNumber, TransactionId, and InstallmentNumber
|
|
During reconciliation, use the latest TransactionId as the active invoice
|
|
Generate notices or downstream triggers based on active Pending Cancel records
|
|
|
|
Key Rule:
|
|
|
|
Only the latest TransactionId per PolicyNumber is considered active; older transactions are ignored for processing
|
|
Chunk 5: Non-Functional / Technical Requirements
|
|
|
|
Metadata:
|
|
storyId=IA-2854, type=nonFunctional, category=performanceReliability
|
|
|
|
Content:
|
|
System Requirements:
|
|
|
|
DynamoDB writes must be atomic and consistent to prevent mismatches
|
|
Step Functions and Lambdas must process and filter data with minimal latency
|
|
Ensure backward compatibility with existing Pending Cancel processing
|
|
|
|
Performance Consideration:
|
|
|
|
High-volume Pending Cancel loads must not degrade Lambda performance
|
|
DynamoDB queries by PolicyNumber, TransactionId, InstallmentNumber must be efficient
|
|
Chunk 6: External System Responsibilities
|
|
|
|
Metadata:
|
|
storyId=IA-2854, type=externalSystems, systems=iSeries,AWS,DynamoDB,Lambda,StepFunctions
|
|
|
|
Content:
|
|
iSeries Responsibilities:
|
|
|
|
Provide TransactionId, InstallmentNumber, PolicyNumber, and Pending Cancel records
|
|
|
|
AWS / DynamoDB Responsibilities:
|
|
|
|
Store Pending Cancel records with new TransactionId and InstallmentNumber fields
|
|
Provide query capabilities for filtering and retrieval
|
|
|
|
Lambda Responsibilities:
|
|
|
|
Filter, retrieve, and process Pending Cancel records using PolicyNumber, TransactionId, and InstallmentNumber
|
|
|
|
Step Functions Responsibilities:
|
|
|
|
Orchestrate processing of Pending Cancel records through multiple Lambdas
|
|
Ensure active TransactionId is selected for downstream actions
|
|
|
|
Implicit Rule (Made Explicit):
|
|
|
|
AWS/DynamoDB acts as the authoritative data store for Pending Cancel records
|
|
Step Functions and Lambdas must respect the active TransactionId logic
|
|
Chunk 7: Business Rules
|
|
|
|
Metadata:
|
|
storyId=IA-2854, type=businessRules, domain=pendingCancelProcessing
|
|
|
|
Content:
|
|
Core Rules:
|
|
|
|
Each Pending Cancel record must store TransactionId and InstallmentNumber
|
|
Latest TransactionId per PolicyNumber is active for processing
|
|
Step Functions and Lambdas filter based on PolicyNumber, TransactionId, and InstallmentNumber
|
|
Records without TransactionId or InstallmentNumber are considered incomplete and flagged
|
|
|
|
Edge Cases:
|
|
|
|
Multiple Pending Cancels for same PolicyNumber → only the latest TransactionId is active
|
|
Missing TransactionId → record cannot be reconciled
|
|
InstallmentNumber mismatch → flag for review
|
|
Chunk 8: Data Quality Assumptions and Risks
|
|
|
|
Metadata:
|
|
storyId=IA-2854, type=dataQuality, riskLevel=low
|
|
|
|
Content:
|
|
Assumptions:
|
|
|
|
iSeries provides complete TransactionId and InstallmentNumber data
|
|
DynamoDB writes are successful and consistent
|
|
Step Functions and Lambdas correctly implement filtering logic
|
|
|
|
Risks:
|
|
|
|
Missing or incorrect TransactionId may lead to incorrect Pending Cancel mapping
|
|
Inconsistent InstallmentNumber could cause reconciliation errors
|
|
Failure in Lambda processing could skip active TransactionId selection
|
|
|
|
Mitigation:
|
|
|
|
Validate iSeries data completeness prior to storage
|
|
Implement idempotent DynamoDB writes
|
|
Monitor Step Function and Lambda execution logs for failures
|
|
Chunk 9: Search Queries Supported
|
|
|
|
Metadata:
|
|
storyId=IA-2854, type=queryPatterns, purpose=RAGRetrieval
|
|
|
|
Content:
|
|
This knowledge base supports queries such as:
|
|
|
|
"How is TransactionId stored for Pending Cancel records?"
|
|
"How do Step Functions filter Pending Cancel data?"
|
|
"How is the latest TransactionId determined per PolicyNumber?"
|
|
"What fields are required for Pending Cancel processing?"
|
|
"How are InstallmentNumber and TransactionId used in reconciliation?"
|
|
"Which AWS components handle Pending Cancel storage and filtering?"
|
|
"What happens if TransactionId or InstallmentNumber is missing?" |