236 lines
6.8 KiB
Plaintext
236 lines
6.8 KiB
Plaintext
JIRA Story - RAG Knowledge Base
|
|
Accounting IA-2827: Preload iSeries Data for Pending Cancel and Billing Statements
|
|
Chunk 1: Overview
|
|
|
|
Metadata:
|
|
storyId=IA-2827, type=overview, domain=dataPreload, workflow=nightlyProcessing
|
|
|
|
Content:
|
|
Purpose: Preloads iSeries-derived data into AWS data store for Pending Cancel and Billing Statement documents to support downstream nightly processing.
|
|
|
|
Business Goal:
|
|
Ensure required historical and current data is available in AWS so that nightly processes can accurately evaluate policy state and prior notifications.
|
|
|
|
Core Behavior:
|
|
|
|
Extract data from upstream systems (iSeries and/or EDW)
|
|
Store normalized data in AWS data store
|
|
Enable lookup of prior billing and cancellation events during nightly checks
|
|
|
|
Outcome:
|
|
Nightly workflows can reliably determine whether billing statements or pending cancellation notices have been previously issued.
|
|
|
|
Chunk 2: Preconditions and Dependencies
|
|
|
|
Metadata:
|
|
storyId=IA-2827, type=preconditions, dependencies=iSeries,EDW,Oracle
|
|
|
|
Content:
|
|
Required Preconditions:
|
|
|
|
Data must be extracted from iSeries and/or EDW
|
|
Payment schedule data may include Oracle identifiers (needs confirmation)
|
|
|
|
Dependencies:
|
|
|
|
iSeries as primary source of policy and installment data
|
|
EDW as potential supplemental data source
|
|
AWS data store for persistence
|
|
Nightly processing workflows consuming preloaded data
|
|
|
|
Implicit Rule (Made Explicit):
|
|
|
|
If Oracle identifiers are not present, downstream processes must still function using available keys (e.g., AccountIdentifier, PolicyNumber)
|
|
Chunk 3: Functional Requirement - Pending Cancel Document
|
|
|
|
Metadata:
|
|
storyId=IA-2827, type=functional, documentType=PendingCancel
|
|
|
|
Content:
|
|
Required Fields (Normalized):
|
|
|
|
AccountIdentifier
|
|
PrimaryCancellationReason
|
|
CancellationNoticeDate
|
|
CancellationEffectiveDate
|
|
PolicyNumber
|
|
|
|
Purpose:
|
|
Represents policies that are at risk of cancellation and have been issued a pending cancellation notice.
|
|
|
|
Implicit Rules (Made Explicit):
|
|
|
|
Presence of record implies a pending cancellation notice has been sent
|
|
CancellationEffectiveDate represents the future termination date if no action taken
|
|
PrimaryCancellationReason must be preserved for downstream decisioning
|
|
Chunk 4: Functional Requirement - Billing Statement Document
|
|
|
|
Metadata:
|
|
storyId=IA-2827, type=functional, documentType=BillingStatement
|
|
|
|
Content:
|
|
Required Fields (Normalized):
|
|
|
|
AccountIdentifier
|
|
PaymentDueDate
|
|
StatementType
|
|
PolicyNumber
|
|
|
|
Purpose:
|
|
Represents billing statements issued to customers for payment collection.
|
|
|
|
Implicit Rules (Made Explicit):
|
|
|
|
Presence of record implies a billing statement has been generated/sent
|
|
PaymentDueDate is used for delinquency and cancellation evaluation
|
|
StatementType differentiates billing scenarios (e.g., regular, special)
|
|
Chunk 5: Functional Requirement - Installment and Notice Tracking
|
|
|
|
Metadata:
|
|
storyId=IA-2827, type=functional, concept=installmentTracking
|
|
|
|
Content:
|
|
Required Output Fields:
|
|
|
|
HeaderNumber
|
|
PaymentNumber (InstallmentNumber)
|
|
BillingNoticeSent (Y/N)
|
|
PendingCancelNoticeSent (Y/N)
|
|
PolicyNumber (12 digits)
|
|
AccountKey
|
|
|
|
Core Logic:
|
|
|
|
Identify the highest active PaymentNumber (InstallmentNumber)
|
|
Determine whether:
|
|
Billing statement has been sent
|
|
Pending cancellation notice has been sent
|
|
|
|
Implicit Rules (Made Explicit):
|
|
|
|
“Highest active” implies latest installment that is still open/active
|
|
Flags (Y/N) are derived from presence of corresponding document records
|
|
PolicyNumber must be normalized to 12-digit format
|
|
Chunk 6: Workflow and Processing Flow
|
|
|
|
Metadata:
|
|
storyId=IA-2827, type=workflow, orchestration=dataPreload
|
|
|
|
Content:
|
|
Processing Flow:
|
|
|
|
Extract data from iSeries and/or EDW
|
|
Normalize and map fields to AWS data model
|
|
Identify latest active installment per PolicyNumber
|
|
Evaluate presence of:
|
|
Billing statements
|
|
Pending cancel notices
|
|
Derive indicator flags (BillingNoticeSent, PendingCancelNoticeSent)
|
|
Store enriched records in AWS data store
|
|
Nightly process queries this data for decisioning
|
|
|
|
Key Rule:
|
|
Preloaded data must be available before nightly process execution
|
|
|
|
Chunk 7: Non-Functional Requirements
|
|
|
|
Metadata:
|
|
storyId=IA-2827, type=nonFunctional, category=dataAvailability
|
|
|
|
Content:
|
|
System Requirements:
|
|
|
|
Data must be preloaded prior to nightly batch execution
|
|
Data retrieval and storage must be reliable and repeatable
|
|
System should support incremental updates as new installments are generated
|
|
|
|
Performance Consideration:
|
|
|
|
Preload process must complete within batch window
|
|
Efficient lookup required for nightly processing queries
|
|
Chunk 8: External System Responsibilities
|
|
|
|
Metadata:
|
|
storyId=IA-2827, type=externalSystems, systems=iSeries,EDW,AWS
|
|
|
|
Content:
|
|
iSeries Responsibilities:
|
|
|
|
Provide PolicyNumber, InstallmentNumber (PaymentNumber), document indicators
|
|
Provide core billing and cancellation data
|
|
|
|
EDW Responsibilities:
|
|
|
|
Supplement missing or derived data fields (if applicable)
|
|
|
|
AWS Responsibilities:
|
|
|
|
Store normalized data
|
|
Provide query access for nightly processing
|
|
|
|
Oracle (Conditional):
|
|
|
|
May provide identifiers within payment schedule data (if available)
|
|
|
|
Implicit Rule (Made Explicit):
|
|
|
|
AWS acts as the system of aggregation and lookup, not the source of truth
|
|
Chunk 9: Business Rules
|
|
|
|
Metadata:
|
|
storyId=IA-2827, type=businessRules, domain=policyProcessing
|
|
|
|
Content:
|
|
Core Rules:
|
|
|
|
Highest active installment must be identified per PolicyNumber
|
|
Billing and cancellation indicators derived from document presence
|
|
PolicyNumber must be standardized to 12 digits
|
|
AccountIdentifier and AccountKey must consistently map across systems
|
|
|
|
Edge Cases:
|
|
|
|
Missing Oracle identifier → processing continues using available keys
|
|
Multiple documents → only latest active installment considered
|
|
No documents present → both flags set to "N"
|
|
Chunk 10: Data Quality Assumptions and Risks
|
|
|
|
Metadata:
|
|
storyId=IA-2827, type=dataQuality, riskLevel=low
|
|
|
|
Content:
|
|
Assumptions:
|
|
|
|
iSeries data is accurate and up-to-date
|
|
Installment numbering correctly reflects payment sequence
|
|
Document generation events are reliably recorded
|
|
|
|
Risks:
|
|
|
|
Missing or inconsistent AccountIdentifier across systems
|
|
Incorrect identification of “highest active” installment
|
|
Incomplete document history leading to incorrect flags
|
|
|
|
Mitigation:
|
|
|
|
Validate data completeness during preload
|
|
Normalize identifiers consistently
|
|
Cross-check installment sequencing logic
|
|
Chunk 11: Search Queries Supported
|
|
|
|
Metadata:
|
|
storyId=IA-2827, type=queryPatterns, purpose=RAGRetrieval
|
|
|
|
Content:
|
|
This knowledge base supports queries such as:
|
|
|
|
"How is iSeries data preloaded for billing and cancellation processing?"
|
|
"What fields are required for Pending Cancel documents?"
|
|
"What data is stored for billing statements?"
|
|
"How is the highest active installment determined?"
|
|
"How are billing and cancellation notice flags calculated?"
|
|
"What data does nightly processing rely on?"
|
|
"What happens if Oracle identifiers are missing?"
|
|
"How are PolicyNumbers normalized?"
|
|
"What systems provide data for preload processing?"
|
|
"How do we determine if a billing statement was sent?" |