190 lines
6.4 KiB
Plaintext
190 lines
6.4 KiB
Plaintext
JIRA Story - RAG Knowledge Base
|
|
|
|
Accounting IA-2855: Add Transaction ID and Installment # to be Stored for Billing Statements
|
|
|
|
Chunk 1: Overview
|
|
|
|
Metadata:
|
|
storyId=IA-2855, type=overview, domain=billingStatement, workflow=dataStorage
|
|
|
|
Content:
|
|
Purpose:
|
|
Enhance the Billing Statement data model in AWS to include TransactionId and InstallmentNumber, ensuring each statement is traceable to its source transaction invoice.
|
|
|
|
Business Goal:
|
|
Enable accurate reconciliation and processing of Billing Statements by linking them to the originating transaction invoice, allowing step functions and lambdas to filter and process data effectively.
|
|
|
|
Core Behavior:
|
|
|
|
Store TransactionId and InstallmentNumber in AWS DynamoDB Billing Statement table
|
|
Allow filtering by PolicyNumber, TransactionId, and InstallmentNumber
|
|
Treat latest TransactionId as the active invoice during processing
|
|
|
|
Outcome:
|
|
|
|
Billing Statement records are fully traceable to source transactions
|
|
Step Functions and Lambdas can reliably filter and reconcile Billing Statement data
|
|
Supports consistent downstream processing and reporting
|
|
Chunk 2: Preconditions and Dependencies
|
|
|
|
Metadata:
|
|
storyId=IA-2855, type=preconditions, dependencies=AWS,DynamoDB,iSeries,Lambda,StepFunctions
|
|
|
|
Content:
|
|
Required Preconditions:
|
|
|
|
AWS DynamoDB Billing Statement table exists
|
|
Step Functions and Lambdas for Billing Statement processing are deployed
|
|
iSeries data flow for Billing Statements is operational
|
|
|
|
Dependencies:
|
|
|
|
DynamoDB schema must support TransactionId and InstallmentNumber attributes
|
|
Step Functions and Lambdas must be updated to filter by PolicyNumber, TransactionId, and InstallmentNumber
|
|
Latest TransactionId per PolicyNumber must be treated as active
|
|
|
|
Implicit Rule (Made Explicit):
|
|
|
|
Processing cannot accurately filter or reconcile Billing Statements without the new attributes
|
|
iSeries will not send TransactionId back to AWS; system must use previously stored data
|
|
Chunk 3: Functional Requirements - Billing Statement Data
|
|
|
|
Metadata:
|
|
storyId=IA-2855, type=functional, documentType=BillingStatement
|
|
|
|
Content:
|
|
Required Fields (Normalized):
|
|
|
|
PolicyNumber
|
|
TransactionId
|
|
InstallmentNumber
|
|
BillingStatementDate
|
|
Status (Active/Processed)
|
|
|
|
Purpose:
|
|
Enhance Billing Statement records to maintain traceability to the originating transaction invoice.
|
|
|
|
Implicit Rules (Made Explicit):
|
|
|
|
PolicyNumber remains the primary key
|
|
TransactionId represents the source transaction invoice
|
|
InstallmentNumber identifies the specific installment related to the Billing Statement
|
|
Latest TransactionId per PolicyNumber is treated as the active invoice
|
|
Chunk 4: Workflow / Processing Flow
|
|
|
|
Metadata:
|
|
storyId=IA-2855, type=workflow, orchestration=billingStatementProcessing
|
|
|
|
Content:
|
|
Processing Flow:
|
|
|
|
Receive Billing Statement data from iSeries
|
|
Query DynamoDB using PolicyNumber
|
|
Store or update TransactionId and InstallmentNumber attributes
|
|
Step Functions and Lambdas filter records using PolicyNumber, TransactionId, and InstallmentNumber
|
|
Select the latest TransactionId as the active invoice for downstream processing
|
|
Generate billing notices or trigger downstream workflows based on active invoices
|
|
|
|
Key Rule:
|
|
|
|
Only the latest TransactionId per PolicyNumber is considered active; older transactions are ignored
|
|
Chunk 5: Non-Functional / Technical Requirements
|
|
|
|
Metadata:
|
|
storyId=IA-2855, type=nonFunctional, category=performanceReliability
|
|
|
|
Content:
|
|
System Requirements:
|
|
|
|
DynamoDB writes must be atomic and consistent
|
|
Step Functions and Lambdas must efficiently filter and process data
|
|
Existing primary key (PolicyNumber) must remain unchanged
|
|
|
|
Performance Consideration:
|
|
|
|
High-volume Billing Statement processing must not degrade Lambda performance
|
|
Queries by PolicyNumber, TransactionId, and InstallmentNumber must be efficient
|
|
Chunk 6: External System Responsibilities
|
|
|
|
Metadata:
|
|
storyId=IA-2855, type=externalSystems, systems=iSeries,AWS,DynamoDB,Lambda,StepFunctions
|
|
|
|
Content:
|
|
iSeries Responsibilities:
|
|
|
|
Provide Billing Statement records with PolicyNumber
|
|
TransactionId is not sent back; system must maintain mapping
|
|
|
|
AWS / DynamoDB Responsibilities:
|
|
|
|
Store Billing Statement records with TransactionId and InstallmentNumber attributes
|
|
Allow filtering and retrieval based on PolicyNumber, TransactionId, and InstallmentNumber
|
|
|
|
Lambda Responsibilities:
|
|
|
|
Filter, retrieve, and process Billing Statement records based on new attributes
|
|
|
|
Step Functions Responsibilities:
|
|
|
|
Orchestrate processing of Billing Statement records
|
|
Ensure active TransactionId is correctly selected for downstream workflows
|
|
|
|
Implicit Rule (Made Explicit):
|
|
|
|
AWS/DynamoDB is the authoritative source for TransactionId mapping since iSeries does not return it
|
|
Chunk 7: Business Rules
|
|
|
|
Metadata:
|
|
storyId=IA-2855, type=businessRules, domain=billingStatementProcessing
|
|
|
|
Content:
|
|
Core Rules:
|
|
|
|
Each Billing Statement must store TransactionId and InstallmentNumber
|
|
Latest TransactionId per PolicyNumber is active for processing
|
|
Step Functions and Lambdas must filter using PolicyNumber, TransactionId, and InstallmentNumber
|
|
Billing Statement records without TransactionId or InstallmentNumber are incomplete and flagged
|
|
|
|
Edge Cases:
|
|
|
|
Multiple Billing Statements for same PolicyNumber → only latest TransactionId is active
|
|
Missing TransactionId → reconciliation cannot proceed
|
|
InstallmentNumber mismatch → flag for review
|
|
Chunk 8: Data Quality Assumptions and Risks
|
|
|
|
Metadata:
|
|
storyId=IA-2855, type=dataQuality, riskLevel=low
|
|
|
|
Content:
|
|
Assumptions:
|
|
|
|
iSeries provides accurate Billing Statement data
|
|
DynamoDB writes succeed consistently
|
|
Step Functions and Lambdas correctly implement filtering logic
|
|
|
|
Risks:
|
|
|
|
Missing or incorrect TransactionId leads to reconciliation errors
|
|
InstallmentNumber inconsistencies cause mismatches
|
|
Lambda or Step Function failures may skip active TransactionId selection
|
|
|
|
Mitigation:
|
|
|
|
Validate completeness of Billing Statement records before storage
|
|
Implement idempotent writes in DynamoDB
|
|
Monitor Step Function and Lambda execution logs for failures
|
|
Chunk 9: Search Queries Supported
|
|
|
|
Metadata:
|
|
storyId=IA-2855, type=queryPatterns, purpose=RAGRetrieval
|
|
|
|
Content:
|
|
This knowledge base supports queries such as:
|
|
|
|
"How is TransactionId stored for Billing Statement records?"
|
|
"How do Step Functions filter Billing Statement data?"
|
|
"How is the latest TransactionId determined per PolicyNumber?"
|
|
"What fields are required for Billing Statement processing?"
|
|
"How are InstallmentNumber and TransactionId used in reconciliation?"
|
|
"Which AWS components handle Billing Statement storage and filtering?"
|
|
"What happens if TransactionId is missing from iSeries data?" |