Add is_creative_request reaorganize books.
This commit is contained in:
209
Books/Accounting/Account.txt
Normal file
209
Books/Accounting/Account.txt
Normal file
@@ -0,0 +1,209 @@
|
||||
Title: ProcessAccountLinkUpdateLambda Component
|
||||
Metadata:
|
||||
• module: Account
|
||||
• component: ProcessAccountLinkUpdateLambda
|
||||
• type: component
|
||||
• domain: Account Management
|
||||
• system: Oracle Fusion
|
||||
Content:
|
||||
Purpose: AWS Lambda function that updates Oracle customer account descriptions with linked external account numbers using standardized HFA prefix format (see HFA Account Description Prefix Format Rule).
|
||||
Processing Logic:
|
||||
• Accepts AccountLinkUpdateDto containing ExistingCustomer and NewLinkedAccountNumber
|
||||
• Accesses first account in ExistingCustomer.Accounts[0]
|
||||
• Updates AccountDescription field using HFA prefix
|
||||
• Returns modified OracleCustomer object
|
||||
Key Rules:
|
||||
• Always updates first account in collection
|
||||
• Lambda configuration: 256MB memory, 30-second timeout
|
||||
• Mutates input object in place
|
||||
Example Questions:
|
||||
• How does the system link external accounts to Oracle customers?
|
||||
• Which Lambda updates Oracle customer account descriptions?
|
||||
• What format is used for linked account descriptions in Oracle?
|
||||
|
||||
Title: ProcessRetailCustomerNumberFromISeriesLambda Component
|
||||
Metadata:
|
||||
• module: Account
|
||||
• component: ProcessRetailCustomerNumberFromISeriesLambda
|
||||
• type: component
|
||||
• domain: Account Management
|
||||
• system: iSeries
|
||||
Content:
|
||||
Purpose: AWS Lambda function that extracts retail customer numbers from iSeries legacy account key identifiers (see iSeries Account Key Substring Extraction Rule).
|
||||
Processing Logic:
|
||||
• Accepts RetailCustomerNumberRequest containing iSeriesAccountKey
|
||||
• Applies substring extraction: positions 5–11, length 7
|
||||
• Returns 7-character retail customer number string
|
||||
Key Rules:
|
||||
• Zero-based indexing: start at position 5
|
||||
• Requires minimum key length of 12 characters
|
||||
• Lambda configuration: 256MB memory, 30-second timeout
|
||||
• No input validation implemented
|
||||
Example Questions:
|
||||
• How do you extract retail customer numbers from iSeries keys?
|
||||
• Which Lambda processes iSeries account identifiers?
|
||||
• What is the retail customer number extraction logic?
|
||||
|
||||
Title: AccountLinkUpdateDto Data Transfer Object
|
||||
Metadata:
|
||||
• module: Account
|
||||
• component: AccountLinkUpdateDto
|
||||
• type: component
|
||||
• domain: Account Management
|
||||
• system: Oracle Fusion
|
||||
Content:
|
||||
Purpose: DTO that encapsulates customer and account linking information for account update operations.
|
||||
Processing Logic:
|
||||
• Contains ExistingCustomer (OracleCustomer)
|
||||
• Contains NewLinkedAccountNumber (string)
|
||||
• Simple property container for Lambda input
|
||||
Key Rules:
|
||||
• Located in Accounting.Orchestration.Account.Dto namespace
|
||||
• References OracleCustomer model
|
||||
• No validation logic
|
||||
Example Questions:
|
||||
• What data is needed to link an account to an Oracle customer?
|
||||
• Which DTO is used for account linking operations?
|
||||
• What properties does AccountLinkUpdateDto contain?
|
||||
|
||||
Title: RetailCustomerNumberRequest Input Model
|
||||
Metadata:
|
||||
• module: Account
|
||||
• component: RetailCustomerNumberRequest
|
||||
• type: component
|
||||
• domain: Account Management
|
||||
• system: iSeries
|
||||
Content:
|
||||
Purpose: Input model for retail customer number extraction Lambda.
|
||||
Processing Logic:
|
||||
• Single property: iSeriesAccountKey (string)
|
||||
• Passed directly to ProcessRetailCustomerNumberFromISeriesLambda
|
||||
Key Rules:
|
||||
• Must contain complete iSeries account key, minimum 12 characters
|
||||
• Property uses camelCase
|
||||
• No validation implemented
|
||||
Example Questions:
|
||||
• What input does the retail customer number extraction Lambda expect?
|
||||
• How is the iSeries account key passed to the extraction function?
|
||||
• What is the structure of RetailCustomerNumberRequest?
|
||||
|
||||
Title: HFA Account Description Prefix Format Rule
|
||||
Metadata:
|
||||
• module: Account
|
||||
• component: N/A
|
||||
• type: rule
|
||||
• domain: Account Management
|
||||
• system: Oracle Fusion
|
||||
Content:
|
||||
Purpose: Standardized format for Oracle account descriptions when linking external accounts.
|
||||
Processing Logic:
|
||||
• Prefix: "HFA_"
|
||||
• Format template: HFA_{LinkedAccountNumber}
|
||||
• Applied during ProcessAccountLinkUpdateLambda
|
||||
Key Rules:
|
||||
• Prefix is underscore-delimited
|
||||
• Overwrites Accounts[0].AccountDescription
|
||||
• No validation on linked account number format
|
||||
Example Questions:
|
||||
• What format is used for linked account descriptions?
|
||||
• What does the HFA_ prefix indicate?
|
||||
• How are external account numbers stored in Oracle customer records?
|
||||
|
||||
Title: iSeries Account Key Substring Extraction Rule
|
||||
Metadata:
|
||||
• module: Account
|
||||
• component: N/A
|
||||
• type: rule
|
||||
• domain: Account Management
|
||||
• system: iSeries
|
||||
Content:
|
||||
Purpose: Defines extraction logic for retail customer numbers from iSeries keys.
|
||||
Processing Logic:
|
||||
• Start: index 5 (zero-based)
|
||||
• Length: 7 characters
|
||||
• Method: Substring(5, 7)
|
||||
• Returns characters at positions 5–11 inclusive
|
||||
Key Rules:
|
||||
• Input key must have minimum length 12
|
||||
• Fixed-position extraction
|
||||
• Case-sensitive
|
||||
Example Questions:
|
||||
• How many characters are in an iSeries retail customer number?
|
||||
• At what position does the customer number appear?
|
||||
• What substring operation extracts customer numbers from iSeries keys?
|
||||
|
||||
Title: Account Linking Workflow
|
||||
Metadata:
|
||||
• module: Account
|
||||
• component: N/A
|
||||
• type: workflow
|
||||
• domain: Account Management
|
||||
• system: Oracle Fusion
|
||||
Content:
|
||||
Purpose: Process for linking external account numbers to Oracle customer records.
|
||||
Processing Logic:
|
||||
|
||||
Retrieve ExistingCustomer
|
||||
Obtain NewLinkedAccountNumber
|
||||
Package into AccountLinkUpdateDto
|
||||
Invoke ProcessAccountLinkUpdateLambda
|
||||
Lambda updates Accounts[0].AccountDescription with HFA prefix
|
||||
Return modified customer
|
||||
Persist to Oracle
|
||||
Key Rules:
|
||||
• Only first account updated
|
||||
• Overwrites previous description
|
||||
• No validation
|
||||
Example Questions:
|
||||
• What is the process for linking external accounts?
|
||||
• How does account linking modify Oracle data?
|
||||
• Which account in collection receives the linked number?
|
||||
|
||||
Title: iSeries Customer Number Extraction Workflow
|
||||
Metadata:
|
||||
• module: Account
|
||||
• component: N/A
|
||||
• type: workflow
|
||||
• domain: Account Management
|
||||
• system: iSeries
|
||||
Content:
|
||||
Purpose: Process for extracting retail customer numbers from iSeries keys for lookup.
|
||||
Processing Logic:
|
||||
|
||||
Receive iSeries account key
|
||||
Package into RetailCustomerNumberRequest
|
||||
Invoke ProcessRetailCustomerNumberFromISeriesLambda
|
||||
Lambda executes Substring(5,7)
|
||||
Return 7-character customer number
|
||||
Use extracted number for downstream lookup
|
||||
Key Rules:
|
||||
• Single-step transformation
|
||||
• Stateless, no caching
|
||||
• No validation
|
||||
Example Questions:
|
||||
• How are retail customer numbers obtained from iSeries?
|
||||
• What workflow extracts customer identifiers from legacy keys?
|
||||
• How many steps are in the extraction process?
|
||||
|
||||
Title: iSeries Account Key Structure Concept
|
||||
Metadata:
|
||||
• module: Account
|
||||
• component: N/A
|
||||
• type: concept
|
||||
• domain: Account Management
|
||||
• system: iSeries
|
||||
Content:
|
||||
Purpose: Defines structure of iSeries legacy account keys for customer number extraction.
|
||||
Processing Logic:
|
||||
• Positions 0–4: prefix/qualifier
|
||||
• Positions 5–11: retail customer number
|
||||
• Positions 12+: optional suffix/metadata
|
||||
• Fixed-position format, no delimiters
|
||||
• Minimum key length: 12
|
||||
Key Rules:
|
||||
• Customer number always at positions 5–11
|
||||
• Structure consistent across all iSeries keys
|
||||
Example Questions:
|
||||
• What is the structure of an iSeries account key?
|
||||
• Where is the customer number located?
|
||||
• How long is an iSeries account key identifier?
|
||||
415
Books/Accounting/BankFeed.txt
Normal file
415
Books/Accounting/BankFeed.txt
Normal file
@@ -0,0 +1,415 @@
|
||||
BankFeeds Module — RAG Knowledge Base (Optimized)
|
||||
|
||||
Chunk 1: BankFeeds Module Overview
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: N/A
|
||||
• type: overview
|
||||
• domain: PaymentProcessing
|
||||
• system: AWS Step Functions
|
||||
• purpose: Bank feed ingestion, transformation, and Oracle posting
|
||||
• tags: stepFunctionPipeline, multiBank, orchestration
|
||||
|
||||
Content:
|
||||
Purpose: Multi-stage AWS Step Functions pipeline for processing bank payment feeds into Oracle AR cash receipts.
|
||||
Processing Logic:
|
||||
|
||||
Stage 1: Parse raw bank feed rows into PaymentRecord objects.
|
||||
Stage 2: Enrich PaymentRecords into CashReceipt objects.
|
||||
Stage 3: Group CashReceipts into ClientBatch for Oracle OIC submission.
|
||||
Supported Banks: U.S. Bank Lockbox, U.S. Bank ELockbox (electronic), First Horizon Bank.
|
||||
Integration: Oracle Integration Cloud (OIC) for AR posting, DynamoDB for state, CloudWatch for metrics.
|
||||
Key Concepts: payment record transformation, orphan detection, chargeback handling, policy validation, batch submission.
|
||||
References: ParseBankFeedLambda Stage, EnrichmentLambda Stage, GroupingLambda Stage
|
||||
|
||||
Chunk 2: ParseBankFeedLambda Stage
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: ParseBankFeedLambda
|
||||
• type: component
|
||||
• domain: PaymentProcessing
|
||||
• system: AWS Lambda
|
||||
• stage: 1
|
||||
• purpose: Raw feed parsing
|
||||
• tags: parser, lambda, bankFeed
|
||||
• references: IBankFeedParser, Orphan Detection and Handling
|
||||
|
||||
Content:
|
||||
Purpose: Converts raw bank feed rows into PaymentRecord objects.
|
||||
Processing Logic:
|
||||
|
||||
Receives StepFunctionContext with FeedType, BatchReference, RawRows.
|
||||
Resolves appropriate parser via IBankFeedParserResolver.
|
||||
Invokes parser.ParseAsync to produce Payments, OrphanRemits, OrphanChecks, Errors, ChargeBacks.
|
||||
Wraps in try-catch; logs exceptions; fails Step Function task on unexpected errors.
|
||||
Output: Payments array, OrphanRemits/OrphanChecks, Errors list, ChargeBacks list.
|
||||
Key Rules: StepFunctionContext updated per batch; errors do not halt entire batch; first stage of 3-stage pipeline.
|
||||
|
||||
Chunk 3: EnrichmentLambda Stage
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: EnrichmentLambda
|
||||
• type: component
|
||||
• domain: PaymentProcessing
|
||||
• system: AWS Lambda
|
||||
• stage: 2
|
||||
• purpose: Payment enrichment
|
||||
• tags: enrichment, lambda
|
||||
• references: Lockbox Enrichment Pipeline, ELockbox Enrichment Pipeline, First Horizon Enrichment Pipeline
|
||||
|
||||
Content:
|
||||
Purpose: Transforms PaymentRecord objects into CashReceipt objects.
|
||||
Processing Logic:
|
||||
|
||||
Resolves bank-specific enrichment pipeline via IBankFeedEnrichmentPipelineResolver.
|
||||
Calls pipeline.EnrichPayments with Payments array.
|
||||
Handles empty payment arrays without breaking workflow.
|
||||
Logs payment counts or reports no payments with orphan counts.
|
||||
Output: Receipts array in StepFunctionContext.
|
||||
|
||||
Chunk 4: GroupingLambda Stage
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: GroupingLambda
|
||||
• type: component
|
||||
• domain: PaymentProcessing
|
||||
• system: AWS Lambda
|
||||
• stage: 3
|
||||
• purpose: Cash receipt batching
|
||||
• tags: batch, aggregation, lambda
|
||||
• references: ClientBatch Model
|
||||
|
||||
Content:
|
||||
Purpose: Aggregates CashReceipt objects into ClientBatch for Oracle submission.
|
||||
Processing Logic:
|
||||
|
||||
Creates ClientBatch using BatchReference.
|
||||
Adds all CashReceipts to batch.
|
||||
Serializes batch to JSON (BatchJson).
|
||||
Sets Status to Completed and ExecutionCompletedUtc timestamp.
|
||||
Publishes EnrichmentLogSummary via IBankFeedMetricsPublisher if available.
|
||||
Validation: Throws InvalidOperationException if Receipts null or empty.
|
||||
|
||||
Chunk 5: Lockbox Parser (U.S. Bank)
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: LockboxParser
|
||||
• type: component
|
||||
• domain: PaymentProcessing
|
||||
• system: U.S. Bank
|
||||
• feedType: Lockbox
|
||||
• purpose: Parse paper check/remit feeds
|
||||
• tags: parser, checkRemit, validation
|
||||
• references: PaymentRecord Model, Orphan Detection and Handling, Transaction Validation Rules
|
||||
|
||||
Content:
|
||||
Purpose: Parses Lockbox feeds with check and remittance rows.
|
||||
Processing Logic:
|
||||
|
||||
Groups rows by integer TransactionId.
|
||||
Pairs remits to checks.
|
||||
Validates check total equals sum of remits within $0.01 tolerance.
|
||||
Orphan checks/remits collected and logged.
|
||||
Returns PaymentRecord objects for paired transactions.
|
||||
|
||||
Chunk 6: ELockbox Parser (U.S. Bank Electronic)
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: ELockboxParser
|
||||
• type: component
|
||||
• domain: PaymentProcessing
|
||||
• system: U.S. Bank
|
||||
• feedType: ELockbox
|
||||
• purpose: Parse electronic Lockbox feeds
|
||||
• tags: parser, electronic, checkRemit
|
||||
• references: PaymentRecord Model, Orphan Detection and Handling
|
||||
|
||||
Content:
|
||||
Purpose: Parses electronic Lockbox feeds using string TransactionId.
|
||||
Processing Logic:
|
||||
|
||||
Groups rows by string TransactionId.
|
||||
Pairs REMIT and CHECK rows.
|
||||
Assigns PolicyNumber to ReceiptNumber.
|
||||
Orphan remits/checks logged; no balance validation.
|
||||
Returns PaymentRecord objects for paired transactions.
|
||||
|
||||
Chunk 7: First Horizon Parser
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: FirstHorizonParser
|
||||
• type: component
|
||||
• domain: PaymentProcessing
|
||||
• system: First Horizon Bank
|
||||
• feedType: FirstHorizon
|
||||
• purpose: Parse simple payment rows and detect chargebacks
|
||||
• tags: parser, chargeback
|
||||
• references: PaymentRecord Model, ChargebackRecord Model
|
||||
|
||||
Content:
|
||||
Purpose: Parses single-row-per-payment structure; detects chargebacks.
|
||||
Processing Logic:
|
||||
|
||||
Creates PaymentRecord for each valid payment.
|
||||
Identifies chargebacks via ReturnIndicator → IsChargeback flag.
|
||||
Logs ChargebackRecord; excludes chargebacks from enrichment.
|
||||
|
||||
Chunk 8: PaymentRecord Model
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: PaymentRecord
|
||||
• type: model
|
||||
• domain: PaymentProcessing
|
||||
• system: AWS Lambda
|
||||
• purpose: Intermediate payment representation
|
||||
• tags: parserOutput, enrichmentInput
|
||||
• references: RemittanceDetail Model, CashReceipt Model
|
||||
|
||||
Content:
|
||||
Properties: InternalPolicyNumber, CustomerAccountNumber, Amount, Currency, PaymentDate, ReceiptNumber, Remittances (list of RemittanceDetail).
|
||||
Usage: Created by parser, consumed by enrichment pipeline.
|
||||
|
||||
Chunk 9: CashReceipt Model
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: CashReceipt
|
||||
• type: model
|
||||
• domain: OracleAR
|
||||
• system: Oracle Fusion
|
||||
• purpose: AR cash receipt record
|
||||
• tags: oracleDocument, enrichmentOutput
|
||||
• references: PaymentRecord Model, Policy Number Validation
|
||||
|
||||
Content:
|
||||
Properties: ReceiptNumber, ReceiptMethod, BusinessUnit, Amount, Currency, ReferenceNumber, BusinessGroup, IntercompanyPaymentReference, UnidentifiedFundsClassification, RefundInvoiceNumber.
|
||||
Logic: Matches valid policy → ReceiptMatchBy="Purchase Order"; invalid → UnidentifiedFundsClassification set.
|
||||
|
||||
Chunk 10: ClientBatch Model
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: ClientBatch
|
||||
• type: model
|
||||
• domain: OracleAR
|
||||
• system: Oracle Fusion
|
||||
• purpose: Grouped CashReceipts for OIC submission
|
||||
• tags: batch, serialization
|
||||
• references: CashReceipt Model
|
||||
|
||||
Content:
|
||||
Properties: BatchReference, Receipts array.
|
||||
Methods: Add(CashReceipt), Count.
|
||||
Serialization: JsonProperty attributes for Oracle OIC.
|
||||
|
||||
Chunk 11: RemittanceDetail Model
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: RemittanceDetail
|
||||
• type: model
|
||||
• domain: PaymentProcessing
|
||||
• system: AWS Lambda
|
||||
• purpose: Invoice-level remittance detail
|
||||
• tags: lineItem, parserOutput
|
||||
• references: PaymentRecord Model, CashReceipt Model
|
||||
|
||||
Content:
|
||||
Represents amount applied to an invoice/policy.
|
||||
Parsed from Lockbox REMIT rows; multiple per PaymentRecord; generates CashReceipt per remittance.
|
||||
|
||||
Chunk 12: ChargebackRecord Model
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: ChargebackRecord
|
||||
• type: model
|
||||
• domain: PaymentProcessing
|
||||
• system: First Horizon Bank
|
||||
• purpose: Track returned payments
|
||||
• tags: exceptionTracking, chargeback
|
||||
• references: First Horizon Parser
|
||||
|
||||
Content:
|
||||
Properties: PolicyNumber, Amount, Reason, PaymentDate.
|
||||
First Horizon parser sets IsChargeback; stored in ParseResult.ChargeBacks; not enriched downstream.
|
||||
|
||||
Chunk 13: StepFunctionContext Model
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: StepFunctionContext
|
||||
• type: model
|
||||
• domain: PaymentProcessing
|
||||
• system: AWS Step Functions
|
||||
• purpose: Workflow state container
|
||||
• tags: context, stateObject
|
||||
• references: All Lambda Stages, ClientBatch Model
|
||||
|
||||
Content:
|
||||
Properties: FeedType, BatchReference, RawRows, Payments, OrphanRemits, OrphanChecks, Errors, ChargeBacks, Receipts, BatchJson, Status, ExecutionCompletedUtc.
|
||||
Lifecycle: Created by Step Function → parser → enrichment → grouping.
|
||||
Serialization: JSON between Lambda invocations.
|
||||
|
||||
Chunk 14: Lockbox Enrichment Pipeline
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: LockboxEnrichmentPipeline
|
||||
• type: component
|
||||
• domain: PaymentProcessing
|
||||
• system: AWS Lambda
|
||||
• feedType: Lockbox
|
||||
• purpose: Convert PaymentRecords to CashReceipts
|
||||
• tags: enrichment, policyValidation
|
||||
• references: PaymentRecord Model, CashReceipt Model, Policy Number Validation
|
||||
|
||||
Content:
|
||||
|
||||
Iterates PaymentRecord.Remittances.
|
||||
Validates policy using RegexPatterns.PolicyRegex.
|
||||
Creates CashReceipt per RemittanceDetail; sets ReferenceNumber if policy valid; otherwise sets UnidentifiedFundsClassification.
|
||||
ReceiptMethod="HFA US Bank", BusinessUnit/Group=HFA constants.
|
||||
|
||||
Chunk 15: ELockbox Enrichment Pipeline
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: ELockBoxEnrichmentPipeline
|
||||
• type: component
|
||||
• domain: PaymentProcessing
|
||||
• system: AWS Lambda
|
||||
• feedType: ELockbox
|
||||
• purpose: Convert electronic PaymentRecords to CashReceipts
|
||||
• tags: enrichment, electronic
|
||||
• references: PaymentRecord Model, CashReceipt Model, Policy Number Validation
|
||||
|
||||
Content:
|
||||
Similar to Lockbox enrichment; tailored to electronic feed; validates policy; creates receipts per remittance. ReceiptMethod adjusted for electronic.
|
||||
|
||||
Chunk 16: First Horizon Enrichment Pipeline
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: FirstHorizonEnrichmentPipeline
|
||||
• type: component
|
||||
• domain: PaymentProcessing
|
||||
• system: AWS Lambda
|
||||
• feedType: FirstHorizon
|
||||
• purpose: Convert PaymentRecords to CashReceipts using confirmation numbers
|
||||
• tags: enrichment, chargebackExcluded
|
||||
• references: PaymentRecord Model, CashReceipt Model
|
||||
|
||||
Content:
|
||||
Creates one CashReceipt per PaymentRecord; validates policy; confirmation number → ReceiptNumber. Chargebacks excluded.
|
||||
|
||||
Chunk 17: Orphan Detection and Handling
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: N/A
|
||||
• type: rule
|
||||
• domain: PaymentProcessing
|
||||
• system: All Lockbox Banks
|
||||
• purpose: Identify unmatched check/remit rows
|
||||
• tags: exceptionTracking
|
||||
• references: ParseBankFeedLambda, LockboxParser, ELockboxParser
|
||||
|
||||
Content:
|
||||
|
||||
OrphanChecks: checks without remits; added to ParseResult.OrphanChecks.
|
||||
OrphanRemits: remits without checks; added to ParseResult.OrphanRemits.
|
||||
Logged as errors; require manual research.
|
||||
|
||||
Chunk 18: Transaction Validation Rules
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: N/A
|
||||
• type: rule
|
||||
• domain: PaymentProcessing
|
||||
• system: Lockbox
|
||||
• purpose: Ensure payment data integrity
|
||||
• tags: validation
|
||||
• references: Lockbox Parser
|
||||
|
||||
Content:
|
||||
|
||||
Check amount = sum of remits (tolerance $0.01).
|
||||
Duplicate check detection per TransactionId.
|
||||
Missing check numbers flagged.
|
||||
Unbalanced transactions logged as errors.
|
||||
|
||||
Chunk 19: Policy Number Validation
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: RegexPatterns.PolicyRegex
|
||||
• type: rule
|
||||
• domain: PaymentProcessing
|
||||
• system: Oracle Fusion
|
||||
• purpose: Validate policy numbers for Oracle matching
|
||||
• tags: validation, receiptMatching
|
||||
• references: Lockbox Enrichment Pipeline, First Horizon Enrichment Pipeline
|
||||
|
||||
Content:
|
||||
Valid policy → ReceiptMatchBy="Purchase Order", ReferenceNumber set. Invalid/missing → UnidentifiedFundsClassification applied.
|
||||
|
||||
Chunk 20: Business Unit, Legal Entity, and Receipt Method Defaults
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: CashReceiptConstants
|
||||
• type: concept
|
||||
• domain: Oracle AR
|
||||
• system: Oracle Fusion
|
||||
• purpose: Organizational defaults for receipts
|
||||
• tags: configuration
|
||||
• references: CashReceipt Model, Enrichment Pipelines
|
||||
|
||||
Content:
|
||||
|
||||
BusinessUnit_HFABU, BusinessGroup_HFA, LegalEntity_HfaLegalEntityID.
|
||||
CurrencyUSD applied.
|
||||
ReceiptMethod bank-specific: Lockbox="HFA US Bank".
|
||||
|
||||
Chunk 21: Error Collection and Reporting
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: ParseResult.Errors
|
||||
• type: concept
|
||||
• domain: PaymentProcessing
|
||||
• system: All Banks
|
||||
• purpose: Track parsing/enrichment errors
|
||||
• tags: errorHandling
|
||||
• references: ParseBankFeedLambda, EnrichmentLambda
|
||||
|
||||
Content:
|
||||
|
||||
Logs balance failures, duplicates, orphan rows, unknown types.
|
||||
Does not halt processing; partial batches allowed.
|
||||
Included in EnrichmentLogSummary for monitoring.
|
||||
|
||||
Chunk 22: Use Case — Standard Lockbox Processing
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: N/A
|
||||
• type: workflow
|
||||
• domain: PaymentProcessing
|
||||
• system: U.S. Bank
|
||||
• purpose: Daily Lockbox batch processing
|
||||
• tags: workflow, example
|
||||
• references: Lockbox Parser, Lockbox Enrichment Pipeline, GroupingLambda Stage
|
||||
|
||||
Content:
|
||||
Scenario: Daily Lockbox file received with check/remit data.
|
||||
|
||||
Parser pairs checks/remits, validates balances.
|
||||
Enrichment pipeline creates CashReceipts per remittance with policy validation.
|
||||
GroupingLambda submits ClientBatch to Oracle OIC.
|
||||
Orphans tracked for manual research.
|
||||
|
||||
Chunk 23: Use Case — First Horizon Chargeback Detection
|
||||
Metadata:
|
||||
• module: BankFeeds
|
||||
• component: N/A
|
||||
• type: workflow
|
||||
• domain: PaymentProcessing
|
||||
• system: First Horizon Bank
|
||||
• purpose: Detect returned payments
|
||||
• tags: workflow, example
|
||||
• references: First Horizon Parser, ChargebackRecord Model
|
||||
|
||||
Content:
|
||||
Scenario: Feed includes payment flagged as ReturnIndicator.
|
||||
|
||||
Parser sets IsChargeback, creates ChargebackRecord.
|
||||
Chargebacks excluded from enrichment; logged for potential future processing.
|
||||
169
Books/Accounting/BillingChange.txt
Normal file
169
Books/Accounting/BillingChange.txt
Normal file
@@ -0,0 +1,169 @@
|
||||
BillingChange Module - Optimized RAG Knowledge Base
|
||||
|
||||
Chunk 1: Module Overview
|
||||
Metadata: module=BillingChange, type=overview, location=CMH.HFA.Accounting.Orchestration/src/BillingChange, domain=billingModifications, purpose=midTermBillingAdjustments, components=5, scenarios=2
|
||||
Purpose: Handles mid-term policy billing modifications requiring coordinated credit memo and invoice generation workflows.
|
||||
Scope:
|
||||
|
||||
Billing plan changes (payment schedule modifications)
|
||||
Billing type changes (internal/external lender transitions)
|
||||
Components: BillingPlanChangeLambda, BillingTypeChangeLambda, BillingChangeService, BillingChangeModel, BillingTypeChangeDto
|
||||
Integration Points: Oracle Fusion AR (invoice/credit memo posting), Oracle OIC (memo line lookups)
|
||||
Key Concepts: credit memo reversal, invoice regeneration, double-entry accounting, payment term changes, billing type transitions
|
||||
|
||||
Chunk 2: BillingPlanChangeLambda – GetCreditMemo Operation
|
||||
Metadata: component=BillingPlanChangeLambda, type=Lambda, operation=GetCreditMemo, scenario=planChange, output=CreditMemo, references=BillingChangeService, BillingPlanChangeDto
|
||||
Purpose: Creates credit memo reversing original billing plan charges for mid-term plan change.
|
||||
Input: BillingPlanChangeDto (OracleCustomer, OracleInvoice, NewBillingPlan)
|
||||
Processing: Delegates to BillingChangeService.MapCreditMemo with BillingChangeEvent.PlanChange
|
||||
Output: CreditMemo object with negated amounts, mapped transaction type, organizational defaults (BU=HFA, LegalEntity=HFA ID)
|
||||
Validation: Ensures original invoice exists and has AR clearing lines; throws InvalidOperationException if not
|
||||
|
||||
Chunk 3: BillingPlanChangeLambda – GetInvoice Operation
|
||||
Metadata: component=BillingPlanChangeLambda, type=Lambda, operation=GetInvoice, scenario=planChange, output=OracleInvoice, references=BillingChangeService, BillingPlanChangeDto
|
||||
Purpose: Creates new invoice with updated payment terms
|
||||
Input: BillingPlanChangeDto
|
||||
Processing: Delegates to BillingChangeService.MapInvoicePlanChange, preserves original premium amount, maps transaction type based on original Internal/External classification
|
||||
Output: OracleInvoice with new payment terms, accounting date set to today, AR clearing line applied
|
||||
Use Case: Customer switches from monthly to annual or vice versa mid-term
|
||||
|
||||
Chunk 4: BillingTypeChangeLambda – GetCreditMemo Operation
|
||||
Metadata: component=BillingTypeChangeLambda, type=Lambda, operation=GetCreditMemo, scenario=typeChange, output=CreditMemo, references=BillingChangeService, BillingTypeChangeDto
|
||||
Purpose: Creates credit memo reversing original billing type charges
|
||||
Input: BillingTypeChangeDto (OracleCustomer, OracleInvoice, UnpaidServiceFee)
|
||||
Processing: Delegates to BillingChangeService.MapCreditMemo with BillingChangeEvent.TypeChange
|
||||
Amount: InvoiceBalanceAmount minus absolute UnpaidServiceFee
|
||||
Output: CreditMemo with negated amounts, classification preserved (no flip), organizational defaults applied
|
||||
|
||||
Chunk 5: BillingTypeChangeLambda – GetInvoice Operation
|
||||
Metadata: component=BillingTypeChangeLambda, type=Lambda, operation=GetInvoice, scenario=typeChange, output=OracleInvoice, references=BillingChangeService, BillingTypeChangeDto
|
||||
Purpose: Creates invoice for billing type transition with balance adjustment for unpaid fees
|
||||
Processing:
|
||||
|
||||
ShallowCopy of original invoice, clears TransactionID
|
||||
TransactionType mapped via MapInvoiceBillingTypeTransactionType (Internal ↔ External flip)
|
||||
PaymentTerms reset to "1 Pay Plan"
|
||||
InvoiceBalanceAmount reduced by unpaid service fee
|
||||
AccountingDate set to today
|
||||
Validation: Throws exception if due date parsing fails
|
||||
|
||||
Chunk 6: BillingTypeChangeLambda – IsBillingTypeChanged Operation
|
||||
Metadata: component=BillingTypeChangeLambda, type=Lambda, operation=IsBillingTypeChanged, scenario=typeChange, output=bool, references=BillingTypeChangeDto, BillingChangeStatic
|
||||
Purpose: Determines if billing type change is required
|
||||
Logic:
|
||||
|
||||
Parses original type using GetTransactionType
|
||||
Evaluates NewBillingType vs OtherInterest.InternalLender
|
||||
Returns true if classification (Internal/External) differs
|
||||
Validation: Supports only "OtherInterest" or "Client"; throws ArgumentOutOfRangeException for unsupported values
|
||||
|
||||
Chunk 7: BillingChangeService – MapCreditMemo Method
|
||||
Metadata: component=BillingChangeService, type=serviceMethod, operation=MapCreditMemo, references=BuildTransactionLines, BillingChangeModel
|
||||
Purpose: Generates reversal credit memo for plan or type change
|
||||
Processing:
|
||||
|
||||
Extracts AR clearing lines via IMemoLookup
|
||||
Negates UnitPrice for reversal
|
||||
Maps TransactionType (plan/type)
|
||||
Sets organizational defaults (BU, LegalEntity, Currency=USD)
|
||||
TransactionDate and AccountingDate set to today
|
||||
Output: CreditMemo object ready for AR posting
|
||||
|
||||
Chunk 8: BillingChangeService – MapInvoicePlanChange Method
|
||||
Metadata: component=BillingChangeService, type=serviceMethod, operation=MapInvoicePlanChange, scenario=planChange, references=BuildTransactionLines
|
||||
Purpose: Creates new invoice reflecting updated billing plan
|
||||
Processing:
|
||||
|
||||
Preserves premium amount and original invoice metadata
|
||||
Updates PaymentTerms to NewBillingPlan
|
||||
Maps TransactionType via MapInvoiceBillingPlanTransactionType
|
||||
Includes AR clearing line only
|
||||
Output: OracleInvoice ready for posting
|
||||
|
||||
Chunk 9: BillingChangeService – MapInvoiceTypeChange Method
|
||||
Metadata: component=BillingChangeService, type=serviceMethod, operation=MapInvoiceTypeChange, scenario=typeChange, references=BuildTransactionLines
|
||||
Purpose: Creates invoice for billing type transition with balance adjustment
|
||||
Processing:
|
||||
|
||||
Shallow copy of original invoice
|
||||
Flip transaction type Internal ↔ External
|
||||
Reduce InvoiceBalanceAmount by unpaid service fee
|
||||
Reset PaymentTerms to "1 Pay Plan"
|
||||
Set AccountingDate and TransactionDate to today
|
||||
Validation: Ensures due date is valid
|
||||
|
||||
Chunk 10: BuildTransactionLines Method
|
||||
Metadata: component=BillingChangeService, type=helperMethod, purpose=transactionLineConstruction
|
||||
Purpose: Builds transaction lines for invoices and credit memos
|
||||
Logic:
|
||||
|
||||
Filters memo lines by action type (PlanChange/TypeChange) and AR clearing type
|
||||
Generates sequential LineNumbers
|
||||
Calculates UnitPrice using GetDistributionAmountByAssurantStatus
|
||||
Output: List<TransactionLine> ready for document assignment
|
||||
|
||||
Chunk 11: Transaction Type Parsing and Mapping
|
||||
Metadata: component=BillingChangeService, type=helperMethod, references=BillingChangeStatic
|
||||
Purpose: Determine Internal/External classification and map to codes
|
||||
Methods:
|
||||
|
||||
GetTransactionType: Parses string aliases (Internal: "internal","intern","int"; External: "external","extern","ext")
|
||||
MapInvoiceBillingPlanTransactionType: preserves classification
|
||||
MapInvoiceBillingTypeTransactionType: flips classification
|
||||
MapCreditMemoBillingPlan/TypeTransactionType: preserves classification
|
||||
Purpose: Ensures proper GL posting based on original or transitioned type
|
||||
|
||||
Chunk 12: BillingChangeModel Enumerations and Static Data
|
||||
Metadata: module=BillingChange, type=model, references=BillingChangeService, DTOs
|
||||
Purpose: Define billing change events, transaction types, and alias dictionaries
|
||||
Details:
|
||||
|
||||
BillingChangeEvent: PlanChange, TypeChange
|
||||
TransactionType: Internal, External
|
||||
BillingChangeStatic: arrays of aliases, mapping dictionaries
|
||||
|
||||
Chunk 13: DTOs – BillingTypeChangeDto & IsBillingTypeChangedDto
|
||||
Metadata: type=DTOs, references=BillingTypeChangeLambda
|
||||
Purpose: Encapsulate input parameters for Lambda functions
|
||||
Fields:
|
||||
|
||||
BillingTypeChangeDto: OracleCustomer, OracleInvoice, UnpaidServiceFee
|
||||
IsBillingTypeChangedDto: OriginalTransactionType, NewBillingType, OtherInterest
|
||||
|
||||
Chunk 14: Business Rules – Unpaid Service Fee
|
||||
Metadata: concept=unpaidServiceFee, scope=typeChange
|
||||
Purpose: Adjust invoice balances for unpaid service fees
|
||||
Applies To: Type change only
|
||||
Logic: MapInvoiceTypeChange reduces InvoiceBalanceAmount, MapCreditMemo subtracts absolute UnpaidServiceFee
|
||||
|
||||
Chunk 15: Double-Entry Accounting Pattern
|
||||
Metadata: pattern=doubleEntry, documents=2, sequence=creditThenInvoice
|
||||
Purpose: Maintain accounting integrity and audit trail
|
||||
Flow: Credit memo first (negates original charges) → Invoice second (applies new charges)
|
||||
Orchestration: Typically coordinated by Step Function calling GetCreditMemo → Oracle Integration → GetInvoice → Oracle Integration
|
||||
|
||||
Chunk 16: Use Case – Plan Change Scenario
|
||||
Metadata: useCase=planChange, trigger=customerRequest
|
||||
Scenario: Customer switches from monthly → annual payment plan
|
||||
Processing: Credit memo reverses original charges → Invoice generated with new payment terms → AR posting via Oracle
|
||||
|
||||
Chunk 17: Use Case – Type Change Scenario (Internal ↔ External)
|
||||
Metadata: useCase=typeChange, trigger=customerRequest
|
||||
Scenarios:
|
||||
|
||||
Internal → External: Credit memo with Internal codes, invoice flips to External, adjusts for unpaid fees
|
||||
External → Internal: Credit memo with External codes, invoice flips to Internal, adjusts for unpaid fees
|
||||
Change Detection: IsBillingTypeChanged prevents unnecessary processing if classification unchanged
|
||||
|
||||
Chunk 18: Search Queries Supported
|
||||
Metadata: type=queryPatterns, purpose=RAGRetrieval
|
||||
Sample Queries:
|
||||
|
||||
"How are billing plan changes processed?"
|
||||
"Which Lambda functions handle billing type changes?"
|
||||
"How are credit memos and invoices generated?"
|
||||
"What transaction codes apply for plan or type changes?"
|
||||
"How are unpaid service fees applied?"
|
||||
"How does internal vs external classification affect billing changes?"
|
||||
"How are AR clearing lines selected?"
|
||||
"What is the double-entry pattern for billing modifications?"
|
||||
155
Books/Accounting/CashReceipts.txt
Normal file
155
Books/Accounting/CashReceipts.txt
Normal file
@@ -0,0 +1,155 @@
|
||||
CashReceipts Module – Optimized RAG Knowledge Base
|
||||
|
||||
Chunk 1: Module Overview
|
||||
Metadata: module=CashReceipts, type=paymentProcessing, location=CMH.HFA.Accounting.Orchestration/src/CashReceipts, domain=retailPayments, purpose=paymentApplication, components=7, scenarios=2
|
||||
Purpose: Handles retail dealer payment events and applies those payments to outstanding invoice installments in Oracle AR.
|
||||
Scope:
|
||||
|
||||
Stage 1: Cash receipt creation from retail payment events
|
||||
Stage 2: Payment application to specific invoice installments
|
||||
Components: MapCashReceipt, MapCashReceiptApplication, OracleCashReceipt, OracleCashReceiptApplication, RetailPaymentEventPayload, MapCashReceiptDto, ApplyInvoiceDto
|
||||
Integration Points: Oracle Fusion AR (receipt/application posting), retail payment event system, policy invoice retrieval
|
||||
Key Concepts: cash receipt creation, installment-level application, unapplied amount tracking, greedy allocation, retail dealer payments
|
||||
|
||||
Chunk 2: MapCashReceipt Lambda Function
|
||||
Metadata: component=MapCashReceipt, type=Lambda, operation=receiptCreation, pattern=eventTransformation, deployment=serverless, references=MapCashReceiptDto, OracleCashReceipt
|
||||
Purpose: Converts retail payment events into Oracle AR cash receipt records
|
||||
Input: MapCashReceiptDto (OracleCustomer + RetailPaymentEventPayload)
|
||||
Processing: Extracts amount, policy number, date, receipt number; formats receipt as "Retail Deal {ReceiptNumber}"; sets UnappliedAmount = full payment amount
|
||||
Output: OracleCashReceipt object ready for Oracle integration
|
||||
Lambda Config: Execution role, 256MB memory, 30s timeout
|
||||
Use Case: Payment captured via POS or dealer portal; needs receipt before application
|
||||
|
||||
Chunk 3: MapCashReceiptApplication Lambda Function
|
||||
Metadata: component=MapCashReceiptApplication, type=Lambda, operation=paymentApplication, pattern=greedyAllocation, deployment=serverless, references=ApplyInvoiceDto, OracleCashReceiptApplication
|
||||
Purpose: Applies cash receipt to invoice installments sequentially
|
||||
Input: ApplyInvoiceDto (OracleCashReceipt + array of OracleInstallment)
|
||||
Processing: Iterates installments while UnappliedAmount > 0; applied amount = MIN(installment balance, unapplied amount); creates OracleCashReceiptApplication; reduces UnappliedAmount
|
||||
Output: List<OracleCashReceiptApplication> linking receipt to installments
|
||||
Allocation Pattern: Greedy sequential, supports partial payments, stops when receipt exhausted or all installments paid
|
||||
|
||||
Chunk 4: OracleCashReceipt Model
|
||||
Metadata: model=OracleCashReceipt, type=document, purpose=receiptRecord, oracleModule=AR
|
||||
Description: Represents cash receipt record in Oracle Fusion AR, tracking unapplied payments
|
||||
Key Properties:
|
||||
|
||||
ReceiptId, ReceiptNumber (formatted), ReceiptDate
|
||||
Amount, UnappliedAmount, Currency=USD
|
||||
CustomerAccountNumber, BusinessUnit=HFA, BusinessGroup=HFA
|
||||
ReceiptMethod="HFA I/C Retail"
|
||||
AccountingDate, PolicyNumber, IntercompanyPaymentReference
|
||||
Mutable State: UnappliedAmount decreases as payment applied
|
||||
Purpose: Enables separate AR receipt creation before payment application
|
||||
|
||||
Chunk 5: OracleCashReceiptApplication Model
|
||||
Metadata: model=OracleCashReceiptApplication, type=transaction, purpose=paymentApplication, granularity=installment
|
||||
Description: Represents application of receipt to a specific installment
|
||||
Key Properties:
|
||||
|
||||
ActionType="Apply", AmountApplied, ReceiptNumber/Id/Date, ReceiptMethod
|
||||
CustomerTrxId (invoice), Installment sequence, ApplicationDate, AccountingDate
|
||||
CustomerAccountNumber, optional Comments/Ids/Currency
|
||||
Installment-Level: Enables precise payment tracking
|
||||
Purpose: Links payments to invoice installments for aging and collections
|
||||
|
||||
Chunk 6: RetailPaymentEventPayload Model
|
||||
Metadata: model=RetailPaymentEventPayload, type=eventPayload, source=retailSystem, requiredFields=6
|
||||
Properties: AccountSourceReference, ReceiptNumber, PolicyNumber, ReceiptMethod, ReceiptDate, Amount, IntercompanyPaymentReference
|
||||
Event Wrapper: RetailPaymentEventMessage extends EventMessage<RetailPaymentEventPayload>
|
||||
Purpose: Standardized payment event structure from POS, portal, or payment processor
|
||||
|
||||
Chunk 7: MapCashReceiptDto
|
||||
Metadata: model=MapCashReceiptDto, type=inputDTO, purpose=receiptCreation, components=2
|
||||
Properties: Customer (OracleCustomer), RetailPaymentEventPayload
|
||||
Deconstruction: Enables tuple unpacking in Lambda handler
|
||||
Usage: Input to MapCashReceipt Lambda, passed from Step Function orchestration
|
||||
Purpose: Combines customer lookup and event payload for single Lambda invocation
|
||||
|
||||
Chunk 8: ApplyInvoiceDto
|
||||
Metadata: model=ApplyInvoiceDto, type=inputDTO, purpose=paymentApplication, components=2
|
||||
Properties: CashReceipt (OracleCashReceipt with ReceiptId), Installments (OracleInstallment[])
|
||||
Deconstruction: Supports tuple unpacking in Lambda
|
||||
Usage: Input to MapCashReceiptApplication Lambda
|
||||
Purpose: Packages receipt and target installments for application processing
|
||||
|
||||
Chunk 9: Greedy Payment Allocation Algorithm
|
||||
Metadata: algorithm=greedyAllocation, pattern=sequential, stopCondition=dual, precision=decimal
|
||||
Description: Sequentially applies receipt to installments until fully applied or installments exhausted
|
||||
Logic: MIN(installment balance, UnappliedAmount); create application record; decrement UnappliedAmount
|
||||
Partial Payment Support: Allows installments to be partially paid; supports overpayment
|
||||
Purpose: Matches Oracle AR standard allocation behavior
|
||||
|
||||
Chunk 10: Receipt Number Formatting
|
||||
Metadata: operation=receiptNumberFormatting, pattern=prefix, source=retailSystem
|
||||
Format: "Retail Deal {ReceiptNumber}"
|
||||
Purpose: Distinguishes retail payments from other sources, enables Oracle AR filtering
|
||||
Uniqueness: Assumes retail system provides unique numbers; no collision detection
|
||||
|
||||
Chunk 11: Customer Account Resolution
|
||||
Metadata: operation=accountResolution, method=GetBillToCustomer, extension=OracleCustomerExtensions
|
||||
Logic: Select first account with non-empty AccountNumber
|
||||
Purpose: Provides customer account reference for receipts and applications
|
||||
Usage: Called in MapCashReceipt Lambda
|
||||
|
||||
Chunk 12: Date Handling Patterns
|
||||
Metadata: dates=multiple, sources=2, timezone=notSpecified
|
||||
ReceiptDate: From RetailPaymentEventPayload, as-is
|
||||
ApplicationDate & AccountingDate: Current system date
|
||||
Purpose: Tracks payment vs posting dates correctly
|
||||
|
||||
Chunk 13: OrderInvoices Helper Method
|
||||
Metadata: operation=OrderInvoices, sorting=documentNumber, filtering=openBalance, visibility=public
|
||||
Description: Prepares invoices for payment application by filtering InvoiceBalanceAmount > 0 and ordering by DocumentNumber
|
||||
Purpose: Ensures deterministic processing order
|
||||
|
||||
Chunk 14: Two-Stage Workflow Pattern
|
||||
Metadata: workflow=twoStage, stage1=receiptCreation, stage2=paymentApplication, orchestration=stepFunction
|
||||
Stage 1: MapCashReceipt → Oracle assigns ReceiptId
|
||||
Stage 2: MapCashReceiptApplication applies receipt to installments using greedy algorithm
|
||||
Purpose: Separate receipt creation and application for auditability and partial payments
|
||||
|
||||
Chunk 15: Installment Balance Tracking
|
||||
Metadata: concept=installmentBalance, property=InstallmentBalanceDue, tracking=Oracle
|
||||
Description: Each application reduces InstallmentBalanceDue; multiple receipts can apply until fully paid
|
||||
Purpose: Supports aging, collection workflows, and accurate balance tracking
|
||||
|
||||
Chunk 16: Intercompany Reference Handling
|
||||
Metadata: field=IntercompanyPaymentReference, type=integer, source=string, conversion=safe
|
||||
Logic: int.TryParse(payload.IntercompanyPaymentReference, out var reference) ? reference : 0
|
||||
Purpose: Tracks intercompany settlement reference safely
|
||||
|
||||
Chunk 17: Currency & Business Unit Defaults
|
||||
Metadata: defaults=hardcoded, currency=USD, businessUnit=HFA, businessGroup=HFA
|
||||
Currency: "USD"; BusinessUnit: HfaStatic.HfaBusinessUnit; BusinessGroup: HfaStatic.HFA
|
||||
ReceiptMethod: "HFA I/C Retail"
|
||||
Purpose: Applies consistent organizational context
|
||||
|
||||
Chunk 18: Use Case Scenarios
|
||||
Metadata: useCases=retailPayments, channels=POS/portal, frequency=perTransaction
|
||||
|
||||
POS Payment: Customer pays at dealer; receipt created and applied
|
||||
Portal Payment: Customer pays online; same workflow
|
||||
Partial Payment: Applied to earliest installments
|
||||
Overpayment: Remaining UnappliedAmount tracked
|
||||
Multiple Installments: Single receipt can cover multiple installments
|
||||
|
||||
Chunk 19: Search Queries Supported
|
||||
Metadata: type=queryPatterns, purpose=RAGRetrieval
|
||||
Sample Queries:
|
||||
|
||||
"How are retail dealer payments processed?"
|
||||
"What Lambda functions handle receipt creation and application?"
|
||||
"How are payments applied to invoice installments?"
|
||||
"What is the greedy allocation algorithm?"
|
||||
"How are retail payment events transformed to Oracle cash receipts?"
|
||||
"What properties does OracleCashReceipt contain?"
|
||||
"How is the unapplied amount tracked?"
|
||||
"What is the two-stage workflow?"
|
||||
"How are installment balances updated?"
|
||||
"How is receipt number formatted?"
|
||||
"How is customer account resolved?"
|
||||
"What dates are set on cash receipt applications?"
|
||||
"How are partial payments handled?"
|
||||
"What happens when payment exceeds installment balance?"
|
||||
"How is intercompany reference converted?"
|
||||
"What business unit and currency defaults apply?"
|
||||
137
Books/Accounting/Common.txt
Normal file
137
Books/Accounting/Common.txt
Normal file
@@ -0,0 +1,137 @@
|
||||
Common Module – Optimized RAG Knowledge Base
|
||||
|
||||
Chunk 1: Module Overview
|
||||
Metadata: module=Common, type=sharedKernel, location=CMH.HFA.Accounting.Orchestration/src/Common, domain=insuranceDomain, pattern=valueObjects, count=2
|
||||
Purpose: Shared kernel domain models representing core insurance business concepts used across multiple bounded contexts.
|
||||
Scope: Two lightweight domain models for coverage information and lender relationships, with no business logic or external dependencies.
|
||||
Design Pattern: Shared kernel consumed by multiple modules (BillingChange, Policy, Cancellations, Endorsement)
|
||||
Key Concepts: Coverage block representation, lender interest tracking, internal vs external lender classification, premium allocation, multi-coverage policies
|
||||
|
||||
Chunk 2: CoverageBlock Model
|
||||
Metadata: model=CoverageBlock, type=valueObject, location=Common/Model, purpose=coverageRepresentation, granularity=perCoverage
|
||||
Description: Represents a single insurance coverage item within a policy for granular premium tracking and allocation.
|
||||
Properties:
|
||||
|
||||
Code: Coverage type identifier or classification code
|
||||
Coverage: Decimal coverage amount or limit
|
||||
Premium: Decimal premium for this coverage block
|
||||
Purpose: Enables multi-coverage policy representation, pro-rated refund calculations, and coverage-specific premium allocation
|
||||
Mutability: Simple get/set properties
|
||||
|
||||
Chunk 3: CoverageBlock Use Cases
|
||||
Metadata: useCases=CoverageBlock, consumers=3+, scenarios=multiCoverage
|
||||
|
||||
Policy Cancellations: Enables unearned premium calculations and pro-rated refunds when partial coverage canceled
|
||||
Policy Issuance: Tracks original coverage composition
|
||||
Premium Distribution: Allocates GL accounts based on coverage type codes
|
||||
Refund Calculations: Distribute unearned premium proportionally
|
||||
Example: Policy with Collision ($800), Comprehensive ($300), Liability ($100) tracked as three CoverageBlock instances
|
||||
|
||||
Chunk 4: OtherInterest Model
|
||||
Metadata: model=OtherInterest, type=valueObject, location=Common/Model, purpose=lenderTracking, classification=InternalExternal
|
||||
Description: Represents third-party financial interests in a policy (lenders or financing entities).
|
||||
Properties:
|
||||
|
||||
LenderCode: Unique lender identifier
|
||||
Name: Lender name
|
||||
OtherInterestUniqEntity: Integer unique entity ID
|
||||
InternalLender: Boolean (internal organization lender vs external)
|
||||
Purpose: Tracks financial stakeholders, drives transaction type routing, affects GL account selection
|
||||
|
||||
Chunk 5: OtherInterest Use Cases
|
||||
Metadata: useCases=OtherInterest, consumers=billingAndCancellation, impactArea=transactionTyping
|
||||
|
||||
Billing Type Determination: Used in BillingTypeChangeLambda to identify billing type transitions
|
||||
Transaction Classification: Internal vs External based on InternalLender flag
|
||||
Policy Cancellations: Tracks lender interests for cancellations
|
||||
Refund Routing: Determines intercompany vs customer refund routing
|
||||
GL Account Selection: Internal vs External affects GL codes (e.g., HfaCmTypeChgInt vs HfaCmTypeChgExt)
|
||||
|
||||
Chunk 6: Internal Lender Business Logic
|
||||
Metadata: concept=internalLenderLogic, impact=transactionTyping, codes=IntVsExt
|
||||
Logic: BillingType = "OtherInterest" AND any OtherInterest.InternalLender=true → Internal transaction
|
||||
Else → External
|
||||
Transaction Codes:
|
||||
|
||||
Internal Invoice: HfaInvoiceInternal, HfaInvTypeChgInt, etc.
|
||||
External Invoice: HfaInvoiceExternal, HfaInvTypeChgExt, etc.
|
||||
Internal Credit Memo: HfaCmEndorseInt, HfaCmTypeChgInt, etc.
|
||||
External Credit Memo: HfaCmEndorseExt, HfaCmTypeChgExt, etc.
|
||||
Purpose: Routes transactions to appropriate GL accounts based on lender relationship
|
||||
|
||||
Chunk 7: Namespace and Location
|
||||
Metadata: namespace=Accounting.Orchestration.Common.Model, accessibility=public, dependencies=none
|
||||
Namespace: Accounting.Orchestration.Common.Model
|
||||
Access Modifier: Classes are public
|
||||
Dependencies: None beyond .NET primitives (string, decimal, int, bool)
|
||||
Import Pattern: using Accounting.Orchestration.Common.Model;
|
||||
Design Principle: Dependency-free shared kernel reduces coupling
|
||||
|
||||
Chunk 8: Data Transfer Characteristics
|
||||
Metadata: pattern=DTOs, serialization=supported, immutability=mutable
|
||||
DTO Pattern: Models act as simple property bags
|
||||
Serialization: Compatible with JSON.NET or System.Text.Json
|
||||
Immutability: Mutable get/set properties
|
||||
Behavior: No methods or validation; pure data structures
|
||||
Event Usage: Included in PolicyIssuedEvent, CancellationEvent, etc.
|
||||
|
||||
Chunk 9: Module Consumption Pattern
|
||||
Metadata: consumers=multiModule, count=4+, sharingScope=orchestration
|
||||
Consumers: BillingChange, Policy, Cancellations, Endorsement
|
||||
Sharing Scope: Orchestration project only
|
||||
Access Pattern: Modules reference Common.Model namespace; receive models via deserialization
|
||||
Design Rationale: Avoid duplication of core insurance concepts
|
||||
|
||||
Chunk 10: Evolution and Stability
|
||||
Metadata: stability=high, evolutionRate=low, backwardCompatibility=critical
|
||||
Stability: Models represent fundamental insurance concepts, unlikely to change
|
||||
Change Impact: Affects multiple modules, requires coordinated updates
|
||||
Backward Compatibility: Additions safe; removals/renames need coordination
|
||||
Extension: Add new properties or new model files in Common/Model
|
||||
|
||||
Chunk 11: Coverage Type Taxonomy
|
||||
Metadata: concept=coverageTypes, examples=provided, extensibility=open
|
||||
Common Types: Collision, Comprehensive, Liability, ESC, Gap, VSC
|
||||
Code Property: Maps to product codes or coverage classification
|
||||
Variable Count: 1-N CoverageBlocks per policy
|
||||
Premium Aggregation: Total policy premium = sum of coverage block premiums
|
||||
Use: Pro-rating, refunds, GL allocation
|
||||
|
||||
Chunk 12: Lender Relationship Examples
|
||||
Metadata: examples=lenderScenarios, scenarios=3, realWorld=true
|
||||
|
||||
Internal Financing: OtherInterest.InternalLender=true → Internal transaction
|
||||
External Financing: OtherInterest.InternalLender=false → External transaction
|
||||
Cash Purchase: No financing → defaults to External
|
||||
Multiple Lenders: Any single internal lender triggers Internal classification
|
||||
|
||||
Chunk 13: Validation and Business Rules
|
||||
Metadata: validation=none, businessRules=consumer, enforcement=external
|
||||
Validation: None at model level
|
||||
Business Rule Enforcement: By consuming services
|
||||
Null Handling: Properties allow null; consumers must check
|
||||
Defaults: No constructor initialization; properties default to type defaults
|
||||
Design: Simple models, push logic to service layer
|
||||
|
||||
Chunk 14: Integration with Event Models
|
||||
Metadata: integration=eventPayloads, eventTypes=3+, composition=nested
|
||||
PolicyIssuedEventV2Payload: List<OtherInterest>, List<CoverageBlock>
|
||||
InsurancePolicyCancelledEventPayload: List<OtherInterest>, List<CoverageBlock>
|
||||
Nested Structure: Common models embedded in event payloads
|
||||
Serialization Flow: JSON serialization/deserialization for EventBridge/SQS/SNS
|
||||
Purpose: Consistent data across event-driven workflows
|
||||
|
||||
Chunk 15: Search Queries Supported
|
||||
Metadata: type=queryPatterns, purpose=RAGRetrieval
|
||||
Sample Queries:
|
||||
|
||||
"What models are in the Common module?"
|
||||
"What is a CoverageBlock?"
|
||||
"How are coverage blocks represented?"
|
||||
"What is the OtherInterest model used for?"
|
||||
"How do I determine if a lender is internal or external?"
|
||||
"What properties does CoverageBlock contain?"
|
||||
"How does InternalLender flag affect transaction types?"
|
||||
"What modules consume the Common models?"
|
||||
"How are Common models serialized in events?"
|
||||
"What is the shared kernel pattern in Common module?"
|
||||
171
Books/Accounting/Endorsement.txt
Normal file
171
Books/Accounting/Endorsement.txt
Normal file
@@ -0,0 +1,171 @@
|
||||
Endorsement Module – Optimized RAG Knowledge Base
|
||||
|
||||
Chunk 1: Module Overview
|
||||
Metadata: module=Endorsement, type=overview, location=CMH.HFA.Accounting.Orchestration/src/Endorsement, domain=monetaryEndorsements, purpose=midTermAdjustments, count=4
|
||||
Purpose: Lambda functions and services for processing monetary policy endorsements (mid-term premium/fee changes requiring accounting transactions)
|
||||
Scope: Handles both upward endorsements (premium increases) and downward endorsements (premium decreases) through dual invoice/credit memo workflow
|
||||
Components: MonetaryEndorsementLambda, MonetaryEndorsementService, EndorsementIssuedEventPayload, IMonetaryEndorsementService
|
||||
Integration Points: Oracle Fusion AR (invoice/credit memo posting), Oracle OIC (memo line lookups), endorsement event workflows
|
||||
Key Concepts: Monetary endorsement, mid-term adjustment, premium/fee change, invoice generation, credit memo creation, transaction line building, bidirectional adjustments
|
||||
|
||||
Chunk 2: MonetaryEndorsementLambda Functions
|
||||
Metadata: component=MonetaryEndorsementLambda, type=Lambda, operations=2, pattern=serviceWrapper, deployment=serverless
|
||||
Description: Lambda wrapper providing endpoints for endorsement processing
|
||||
Operations:
|
||||
|
||||
GetCreditMemoForEndorsement: Handles net decreases (Premium + Fee < 0), delegates to MonetaryEndorsementService.MapCreditMemo, returns CreditMemo or null
|
||||
GetInvoiceForEndorsement: Handles net increases (Premium + Fee > 0), delegates to MonetaryEndorsementService.MapInvoice, returns OracleInvoice or null
|
||||
EndorsementDto Model: Contains OracleCustomer, OracleInvoice, EndorsementIssuedEventPayload; supports tuple deconstruction
|
||||
Lambda Config: Execution role policies, 256 MB memory, 30 sec timeout
|
||||
|
||||
Chunk 3: EndorsementIssuedEventPayload Model
|
||||
Metadata: model=EndorsementIssuedEventPayload, type=eventPayload, requiredFields=4, purpose=endorsementData
|
||||
Properties:
|
||||
|
||||
AccountIdentifier: Required
|
||||
PolicyNumber: Required
|
||||
PremiumAmount: Decimal (positive = charge, negative = credit)
|
||||
FeeAmount: Decimal (positive = charge, negative = credit)
|
||||
Use Cases: Coverage additions/removals, premium adjustments, fee changes, any mid-term change affecting accounting
|
||||
Validation: Required enforced via required keyword
|
||||
|
||||
Chunk 4: MonetaryEndorsementService Core Logic
|
||||
Metadata: component=MonetaryEndorsementService, interface=IMonetaryEndorsementService, pattern=multiStage, purpose=documentGeneration
|
||||
Description: Transforms endorsement events into Oracle AR documents
|
||||
Processing Flow: Initializes EndorsementArgument, retrieves memo lines, builds transaction lines, generates CreditMemo or OracleInvoice, returns null if no lines
|
||||
Memo Line Retrieval: Calls IMemoLookup.GetMemoLookupAsync filtered by action, lineType (Premium/Fees), productType, state, organization, commission percent
|
||||
Document Construction: Maps transaction type, sets business unit/legal entity, links to original invoice
|
||||
Null Return: Returns null if validation fails or amounts zero
|
||||
|
||||
Chunk 5: Transaction Line Building Logic
|
||||
Metadata: operation=BuildTransactionLines, pattern=conditionalGeneration, lineTypes=2, validation=multiCriteria
|
||||
Processing Stages:
|
||||
|
||||
Skip Validation: Skip if zero total amount or opposite sign amounts
|
||||
Premium Lines: Generate if PremiumAmount ≠ 0
|
||||
Fee Lines: Generate if FeeAmount ≠ 0
|
||||
Commission Enrichment: Apply commission metadata
|
||||
Line Numbering: Sequential numbering
|
||||
Details: Uses GetPremiumLookups/GetFeeLookups, calculates distribution percentage, uses C# yield return
|
||||
|
||||
Chunk 6: Zero Amount and Validation Rules
|
||||
Metadata: validation=endorsementRules, skipCondition=zeroAmount, errorCondition=oppositeSigns
|
||||
|
||||
Zero Total Amount: Premium + Fee = 0 → skip transaction lines
|
||||
Opposite Sign Validation: Throws InvalidOperationException if Premium and Fee have opposite signs
|
||||
Error Message: "Premium and fee amounts cannot have opposite signs"
|
||||
Skip Decision: ShouldSkipProcessing method combines checks
|
||||
|
||||
Chunk 7: Memo Line Filtering Dimensions
|
||||
Metadata: operation=GetMemoLines, dimensions=7, pattern=multiDimensionalFiltering
|
||||
Filtering Parameters: Action, LineType, ProductType, State, Organization, Percent, To (not used)
|
||||
Methods: GetPremiumLookups / GetFeeLookups
|
||||
Purpose: Ensures correct GL account selection based on endorsement context
|
||||
|
||||
Chunk 8: Commission Line Detection and Enrichment
|
||||
Metadata: operation=commissionEnrichment, detection=descriptionBased, types=2
|
||||
Detection: MemoLine.Description contains "Retail Commission" or "HFA Commission"
|
||||
Fields Applied: BusinessGroup, NewOrRenewal, CommissionPercent, AgencyFirstWrittenDate
|
||||
Retail Commission: Producer=Clayton Retail, SubProducer/CommissionReference included
|
||||
HFA Commission: Producer=HFA, SubProducer/CommissionReference empty
|
||||
Purpose: Ensures commission metadata propagated to transaction lines
|
||||
|
||||
Chunk 9: Amount Distribution and Rounding
|
||||
Metadata: operation=CalculateUnitPrice, rounding=differential, recipients=3
|
||||
Distribution: amount * distributionPercentage / 100
|
||||
Rounding Rules:
|
||||
|
||||
Assurant Payable → Round UP (Math.Ceiling)
|
||||
Commission Lines → Round DOWN (Math.Floor)
|
||||
Other Lines → Banker's rounding (MidpointRounding.ToEven)
|
||||
Purpose: Penny-perfect allocations matching original invoice
|
||||
|
||||
Chunk 10: Credit Memo Construction
|
||||
Metadata: operation=BuildCreditMemo, documentType=CreditMemo, purpose=downwardEndorsement
|
||||
Properties: TransactionId empty, TransactionType from mapping, BusinessUnit HFA BU, CurrencyCode USD, GenerateBill=No
|
||||
Customer References: PurchaseOrderNumber=PolicyNumber, CustomerAccountNumber, Bill-To site
|
||||
Dates: TransactionDate=Today, AccountingDate=Today
|
||||
Original Invoice Link: PolicyTermOriginalInvoice
|
||||
Transaction Lines: ReceivablesCreditMemoLines array from BuildTransactionLines
|
||||
|
||||
Chunk 11: Invoice Construction
|
||||
Metadata: operation=BuildInvoice, documentType=OracleInvoice, purpose=upwardEndorsement
|
||||
Properties: TransactionId empty, TransactionType mapped, PaymentTerms=1 Pay Plan, ProductType/PremiumPayable/InstallmentFee inherited
|
||||
Customer References & Dates: Same as CreditMemo
|
||||
Original Invoice Link: PolicyTermOriginalInvoice
|
||||
Transaction Lines: Sorted & renumbered array from BuildTransactionLines
|
||||
Physical Address State: From original invoice for tax continuity
|
||||
|
||||
Chunk 12: Transaction Type Mapping
|
||||
Metadata: concept=transactionTypeMapping, dimensions=2, values=InternalExternal
|
||||
Invoice Types: HfaInvEndorseInt / HfaInvEndorseExt
|
||||
Credit Memo Types: HfaCmEndorseInt / HfaCmEndorseExt
|
||||
Logic: Switch on original invoice TransactionType; internal sources → Int-suffixed, external → Ext-suffixed
|
||||
Purpose: Maintains Internal vs External classification
|
||||
|
||||
Chunk 13: Transaction Line Ordering
|
||||
Metadata: operation=ArrangeTransactionLines, sorting=multiCriteria, renumbering=sequential
|
||||
Priority: 1. Premium-Assurant Payable, 2. Commission, 3. Fees, 4. Other
|
||||
Tie-Break: Original insertion order
|
||||
Post-Sort: LineNumber reassigned sequentially
|
||||
Purpose: Consistent invoice presentation, downstream processing
|
||||
|
||||
Chunk 14: EndorsementArgument Helper Class
|
||||
Metadata: class=EndorsementArgument, visibility=private, pattern=contextObject, purpose=encapsulation
|
||||
Properties: Customer, OriginalInvoice, Payload, TransactionLines
|
||||
CommissionLine Property: Returns commission line if present; else default with 30% commission
|
||||
Purpose: Simplifies service method signatures, safe commission access
|
||||
|
||||
Chunk 15: Bill-To Site Resolution
|
||||
Metadata: operation=GetBillToSiteNumber, pattern=LINQ, errorHandling=exception
|
||||
Logic: Traverse Customer → Accounts → Sites → SiteUses where Purpose="Bill To", select Site, throw if not found
|
||||
Error Message: "No Bill To site found for customer"
|
||||
Purpose: Oracle site number for invoice/credit memo
|
||||
|
||||
Chunk 16: Organization Determination
|
||||
Metadata: operation=GetOrg, values=2, source=commissionLine
|
||||
Logic: CommissionLine.CommissionOrganization = "Clayton Retail" → "Retail", else "HFA"
|
||||
Purpose: Organization context for memo line filtering & GL selection
|
||||
|
||||
Chunk 17: Endorsement Workflow Integration
|
||||
Metadata: workflow=endorsementProcessing, trigger=endorsementIssuedEvent, outputs=2possible
|
||||
Trigger: EndorsementIssuedEvent from policy system
|
||||
Decision: Caller determines GetCreditMemo vs GetInvoice based on net amount
|
||||
Paths: CreditMemo if net decrease, Invoice if net increase
|
||||
Downstream: Oracle OIC → Fusion AR
|
||||
Audit Trail: PolicyTermOriginalInvoice link
|
||||
|
||||
Chunk 18: Use Case Examples
|
||||
Metadata: useCases=endorsementScenarios, frequency=midTerm, complexity=variable
|
||||
|
||||
Coverage Addition → Invoice with premium + commission
|
||||
Coverage Removal → CreditMemo reversing premium + commission
|
||||
Premium Adjustment (risk change) → Invoice/CreditMemo based on direction
|
||||
Fee Adjustment → Appropriate document with fee lines
|
||||
Combined Changes → Single endorsement with net premium/fee change
|
||||
Validation → Premium increase + fee decrease of equal amount → exception
|
||||
|
||||
Chunk 19: Search Queries Supported
|
||||
Metadata: type=queryPatterns, purpose=RAGRetrieval
|
||||
Sample Queries:
|
||||
|
||||
"How are monetary endorsements processed?"
|
||||
"What creates endorsement invoices vs credit memos?"
|
||||
"How are endorsement transaction lines built with GL accounts?"
|
||||
"What validation rules apply to premium and fee amounts?"
|
||||
"How is commission metadata applied?"
|
||||
"What rounding logic is used for endorsements?"
|
||||
"How are Internal vs External transaction types determined?"
|
||||
"What happens if premium + fees = 0?"
|
||||
"How do endorsements link to original invoices?"
|
||||
"What memo line filtering criteria are used?"
|
||||
"How are commission lines detected/enriched?"
|
||||
"What is the transaction line sorting order?"
|
||||
"How does the service handle missing commission lines?"
|
||||
"Which Lambda functions process endorsements?"
|
||||
"How are Bill-To sites resolved?"
|
||||
"What default commission % is used?"
|
||||
"How does organization determination affect processing?"
|
||||
"What exception occurs with opposite sign premium/fee?"
|
||||
"How are endorsement dates set?"
|
||||
"Which Oracle document properties inherit from original invoice?"
|
||||
172
Books/Accounting/Fifo.txt
Normal file
172
Books/Accounting/Fifo.txt
Normal file
@@ -0,0 +1,172 @@
|
||||
Fifo Module – RAG Knowledge Base
|
||||
|
||||
Chunk 1: Module Overview
|
||||
Metadata: module=Fifo, type=overview, location=CMH.HFA.Accounting.Orchestration/src/Fifo, pattern=FIFO-queue, purpose=eventOrdering, storage=DynamoDB
|
||||
Purpose: First-In-First-Out event ordering and deduplication system for policy-related events; prevents race conditions, maintains data consistency
|
||||
Scope: Six components – Lambda functions for ingestion/completion, service layer for queue management, EventBridge publishing, repository abstractions, domain models
|
||||
Stack: AWS Lambda, DynamoDB (queue storage), EventBridge (publishing), MD5 hashing (deduplication), conditional updates (concurrency control)
|
||||
Key Concepts: Sequential event processing, policy-level isolation, deduplication, race condition prevention, status state machine, TTL-based cleanup, optimistic concurrency
|
||||
|
||||
Chunk 2: FifoLambda Entry Points
|
||||
Metadata: component=FifoLambda, type=Lambda, operations=2, pattern=orchestrationEndpoints
|
||||
Description: Lambda exposing two endpoints for FIFO queue lifecycle
|
||||
Operations:
|
||||
|
||||
Received: Handles incoming policy events, validates PolicyNumber & EventID, timestamp generated, delegates to FifoService.EnqueueAsync
|
||||
Completed: Marks event as completed, triggers next event, receives FifoEventDto, delegates to FifoService.DequeueAsync
|
||||
Validation: PolicyNumber required, EventID non-empty (Guid), throws ArgumentException/ArgumentNullException on failure
|
||||
Lambda Config: Execution role, 256 MB memory, 30 sec timeout
|
||||
|
||||
Chunk 3: Event Enqueue Processing
|
||||
Metadata: operation=EnqueueAsync, service=FifoService, pattern=conditionalProcessing, deduplication=MD5
|
||||
Purpose: Adds events to policy-specific queue, deduplicates, triggers immediate processing if no active events
|
||||
Steps:
|
||||
|
||||
MD5 key = {PolicyNumber}.{EventPayload}
|
||||
Query existing events for policy
|
||||
Exit if duplicate key found
|
||||
Create EventTableEntry (status PENDING or PROCESSING)
|
||||
If no active events → PROCESSING + EventBridge publish
|
||||
Else → PENDING + race condition guard
|
||||
Deduplication: Prevents double-processing from retries or replay
|
||||
|
||||
Chunk 4: Race Condition Guard
|
||||
Metadata: mechanism=raceConditionGuard, pattern=doubleCheck, atomicity=conditional
|
||||
Scenario: PENDING event saved, PROCESSING event finishes before guard
|
||||
Logic: Re-query policy events, check for active PROCESSING, find earliest PENDING
|
||||
Resolution: If no PROCESSING & current event earliest PENDING → atomically update status to PROCESSING, publish to EventBridge, handle ConditionalCheckFailedException
|
||||
Purpose: Closes timing window, ensures next event begins automatically
|
||||
|
||||
Chunk 5: Event Dequeue Processing
|
||||
Metadata: operation=DequeueAsync, service=FifoService, pattern=sequentialProcessing, cleanup=TTL
|
||||
Steps:
|
||||
|
||||
Lookup completed event by EventID (GSI)
|
||||
Update status → COMPLETED, set 30-day TTL
|
||||
Query PENDING events for same policy, order chronologically
|
||||
Find earliest PENDING → conditional update → PROCESSING
|
||||
Deserialize event body → extract type/source
|
||||
Publish next event to EventBridge
|
||||
TTL: DateTimeOffset.UtcNow.AddDays(30).ToUnixTimeSeconds()
|
||||
Conditional Update: Ensures race-free transition
|
||||
|
||||
Chunk 6: EventTableEntry Model
|
||||
Metadata: model=EventTableEntry, storage=DynamoDB, keyStructure=composite, ttlEnabled=true
|
||||
Keys: PK=PolicyNumber, SK=Timestamp (ISO 8601)
|
||||
Properties: EventId (Guid + GSI), Status (PENDING/PROCESSING/COMPLETED), EventBody (JSON), DeduplicationKey (MD5), TimeToLive
|
||||
GSI: EventIdIndex for O(1) lookup
|
||||
Purpose: Policy-scoped queries, event ID lookup, automatic cleanup
|
||||
|
||||
Chunk 7: Status State Machine
|
||||
Metadata: stateMachine=eventStatus, states=3, transitions=sequential
|
||||
States: PENDING → PROCESSING → COMPLETED
|
||||
Constraints: Only one PROCESSING per policy, PENDING processed FIFO
|
||||
Purpose: Enforces sequential processing, prevents concurrent policy modifications
|
||||
|
||||
Chunk 8: Deduplication Mechanism
|
||||
Metadata: feature=deduplication, algorithm=MD5, scope=perPolicy, collision=veryLow
|
||||
Hash Input: {PolicyNumber}.{EventPayload}
|
||||
Output: 32-char lowercase hex string
|
||||
Action: Duplicate detected → log & exit
|
||||
Use Cases: Lambda retries, EventBridge replay, double-sends
|
||||
Limitation: Scope per-policy
|
||||
|
||||
Chunk 9: Concurrency Control Mechanisms
|
||||
Metadata: concurrency=optimistic, mechanism=conditionalUpdates, exception=ConditionalCheckFailedException
|
||||
Pattern: UpdateItemAsync conditional on expected status
|
||||
Scenarios: Multiple Lambdas, cold starts, rapid arrivals, completion races
|
||||
Failure Handling: Log ConditionalCheckFailedException, no retry, graceful backoff
|
||||
Atomic Guarantee: Only one instance succeeds per transition
|
||||
|
||||
Chunk 10: EventBridge Integration
|
||||
Metadata: component=EventBridgePublisher, interface=IEventPublisher, destination=AWSEventBridge, pattern=publishSubscribe
|
||||
Purpose: Publishes events for downstream Step Functions or consumers
|
||||
EventBridgeDto: Source, DetailType, Payload
|
||||
Publishing: Immediate if no active events; deferred if queued → eligible later
|
||||
Integration: EventBridgeHelper + Lambda logging
|
||||
Purpose: Decouples FIFO queue, supports multi-consumer fan-out
|
||||
|
||||
Chunk 11: DynamoDB Table Structure
|
||||
Metadata: storage=DynamoDB, tableName=pattern, indexing=GSI, consistency=eventual
|
||||
Table: {ENVIRONMENT}-fifo-poc-table
|
||||
Primary Key: PK=PolicyNumber, SK=Timestamp
|
||||
GSI: EventIdIndex (EventID lookup)
|
||||
Query Patterns: Policy queue depth, PENDING filtering, EventID lookup, avoid scans
|
||||
TTL: Automatic deletion 30 days after completion
|
||||
|
||||
Chunk 12: Policy-Level Isolation
|
||||
Metadata: isolation=policyBased, concurrency=perPolicy, scalability=horizontal
|
||||
Isolation: Each policy independent, concurrent processing allowed
|
||||
Partition Strategy: PK=PolicyNumber
|
||||
Scaling: Unlimited policies, no global locks, hot partition risk for very active policy
|
||||
Benefits: High throughput, isolated failures, predictable performance
|
||||
|
||||
Chunk 13: TTL-Based Cleanup Strategy
|
||||
Metadata: cleanup=TTL, retention=30days, cost=zero, trigger=statusCompleted
|
||||
TTL Field: TimeToLive (Unix epoch)
|
||||
Set When: Status → COMPLETED
|
||||
Not Set: PENDING / PROCESSING
|
||||
DynamoDB deletes items asynchronously (≈48 hours)
|
||||
Purpose: Auto-clean completed events, maintain 30-day audit trail
|
||||
|
||||
Chunk 14: Error Handling Strategies
|
||||
Metadata: errorHandling=graceful, logging=comprehensive, propagation=selective
|
||||
Duplicate Detection: Log & ignore
|
||||
Race Conditions: Catch ConditionalCheckFailedException
|
||||
Missing Events: Throws KeyNotFoundException
|
||||
Concurrent Updates: Log winner, skip
|
||||
Function Errors: Logged, workflow continues
|
||||
Environment Errors: Throw if ENVIRONMENT missing
|
||||
|
||||
Chunk 15: Lambda Orchestration Use Cases
|
||||
Metadata: useCases=policyServicing, frequency=perTransaction, criticality=dataIntegrity
|
||||
Policy Updates: Endorsements, renewals, cancellations in order
|
||||
Billing Events: Sequential processing → accounting integrity
|
||||
State Transitions: Prevent race conditions
|
||||
Event Replay: Deduplication prevents double processing
|
||||
Distributed Processing: Multi-Lambda, per-policy ordering maintained
|
||||
Workflow: Step Functions consume knowing prior event completed
|
||||
|
||||
Chunk 16: Performance Characteristics
|
||||
Metadata: performance=latency, throughput=high, consistency=eventual
|
||||
Latency: DynamoDB query, conditional update, EventBridge publish, Lambda cold start
|
||||
Fast Path: No queue → query + save + publish
|
||||
Slow Path: Queued → query + save, later conditional update + publish
|
||||
Throughput: Limited per policy partition, unlimited across policies
|
||||
Optimization: Consistent reads, parallel processing
|
||||
|
||||
Chunk 17: Repository Abstraction
|
||||
Metadata: pattern=repository, interface=IFifoRepository, implementation=DynamoDbFifoRepository
|
||||
Operations: GetEventByIdAsync, QueryByPolicyNumberAsync, SaveEventAsync, UpdateStatusAsync
|
||||
Benefits: Isolates DynamoDB, unit-testable, future-proof storage backend
|
||||
Configuration: Table name via environment, consistent read, conditional expressions
|
||||
|
||||
Chunk 18: Event Body Preservation
|
||||
Metadata: storage=eventBody, format=JSON, purpose=replay, completeness=full
|
||||
Content: Serialized EventMessage including EventID, EventType, Source, Payload
|
||||
Purpose: Enables replay, debugging, audit trail
|
||||
Deserialization: Extract type/source for EventBridge DetailType
|
||||
Cleanup: TTL deletes after 30 days
|
||||
|
||||
Chunk 19: Search Queries Supported
|
||||
Metadata: type=queryPatterns, purpose=RAGRetrieval
|
||||
Sample Queries:
|
||||
|
||||
"How does the FIFO queue ensure sequential processing?"
|
||||
"What deduplication mechanism prevents duplicate processing?"
|
||||
"How are race conditions handled?"
|
||||
"What is the FIFO event status state machine?"
|
||||
"How long are completed events retained?"
|
||||
"What happens when two events arrive simultaneously for the same policy?"
|
||||
"How does FIFO integrate with EventBridge?"
|
||||
"What DynamoDB key structure is used?"
|
||||
"How are events ordered within a policy queue?"
|
||||
"What triggers automatic cleanup?"
|
||||
"How does conditional update prevent race conditions?"
|
||||
"Which Lambda functions are exposed?"
|
||||
"How is event deduplication calculated?"
|
||||
"What happens if event enqueued while another processing?"
|
||||
"How does race condition guard work?"
|
||||
"What exception indicates concurrent update conflict?"
|
||||
"How are policy-level queues isolated?"
|
||||
"What is the TTL strategy for completed events?"
|
||||
160
Books/Accounting/Integrations.txt
Normal file
160
Books/Accounting/Integrations.txt
Normal file
@@ -0,0 +1,160 @@
|
||||
Integrations Module – RAG Knowledge Base
|
||||
|
||||
Chunk 1: Module Overview
|
||||
Metadata: module=Integrations, type=infrastructure, location=CMH.HFA.Accounting.Orchestration/src/Integrations, pattern=baseClasses, purpose=externalSystemConnectivity
|
||||
Purpose: Foundational infrastructure for reusable HTTP client patterns, authentication, and configuration for external system integration
|
||||
Scope: Two base classes for Oracle Cloud Integration (OIC) and on-prem HFA APIs
|
||||
Stack: Flurl.Http for HTTP, AWS Secrets Manager for credentials, environment-based configuration
|
||||
Key Concepts: Integration abstraction, secret management, HTTP client configuration, environment-aware URL construction, authentication patterns, base class inheritance
|
||||
|
||||
Chunk 2: OracleIntegrationBase Class
|
||||
Metadata: component=OracleIntegrationBase, type=abstractBaseClass, integration=OracleCloudIntegration, authentication=BasicAuth, location=Integrations/Oracle
|
||||
Description: Abstract base for OIC API clients, providing authenticated HTTP requests
|
||||
Authentication: HTTP Basic Auth with username/password from AWS Secrets Manager
|
||||
Base URL: https://erp-{oicEnv}-oicintegration-idq4hj6bgo2f-ia.integration.ocp.oraclecloud.com
|
||||
Protected Method: GetRequestAsync(endpoint) returns pre-configured IFlurlRequest
|
||||
Inheritance: Derived classes implement specific services (e.g., MemoLookup)
|
||||
|
||||
Chunk 3: Oracle Secret Management
|
||||
Metadata: secrets=OracleCredentials, storage=AWSSecretsManager, count=3, pattern=environmentSpecific
|
||||
Secrets:
|
||||
|
||||
Username: {ENVIRONMENT}-hfa-oic-username
|
||||
Password: {ENVIRONMENT}-hfa-oic-password
|
||||
OIC Environment: {ENVIRONMENT}-hfa-oic-environment
|
||||
Retrieval: ISecretString service, async during request creation
|
||||
Environment Isolation: Separate credentials per deployment environment
|
||||
Purpose: Centralized credential management, supports rotation
|
||||
|
||||
Chunk 4: BaseOnPremIntegration Class
|
||||
Metadata: component=BaseOnPremIntegration, type=concreteBaseClass, integration=HFAOnPremises, authentication=ClientCredentials, location=Integrations
|
||||
Description: Base class for on-prem HFA services using client ID/secret headers
|
||||
Authentication: Custom headers (client-id and client-secret)
|
||||
URLs:
|
||||
|
||||
Prod: https://dat.homefirstagency.com
|
||||
Non-prod: https://dat.{environment}.homefirstagency.com
|
||||
Protected Methods: GetRequestAsync(), UpdateEndpoint(flurlRequest, endpoint)
|
||||
Caching: Flurl request cached for service instance lifetime
|
||||
|
||||
Chunk 5: On-Premises Secret Management
|
||||
Metadata: secrets=OnPremCredentials, storage=AWSSecretsManager, count=2, authentication=clientCredentials
|
||||
Secrets:
|
||||
|
||||
Client ID: {ENVIRONMENT}-hfa-licensing-api-client-id
|
||||
Client Secret: {ENVIRONMENT}-hfa-licensing-api-client-secret
|
||||
Header Format: Passed as custom headers
|
||||
Service Name Pattern: Constructor accepts serviceName for named HTTP client
|
||||
Purpose: Supports internal HFA API key authentication, enables per-service configuration
|
||||
|
||||
Chunk 6: Environment Variable Handling
|
||||
Metadata: configuration=environmentVariables, required=ENVIRONMENT, validation=constructor, failureBehavior=exception
|
||||
Required Variable: ENVIRONMENT (dev, test, prod)
|
||||
Validation: Both base classes validate in constructor, fail-fast if missing
|
||||
Usage: Drives secret key construction, URL routing, table patterns
|
||||
Purpose: Ensures environment isolation, prevents misconfiguration
|
||||
|
||||
Chunk 7: HTTP Client Factory Integration
|
||||
Metadata: pattern=HttpClientFactory, scope=OnPremOnly, dependency=IHttpClientFactory, namedClients=supported
|
||||
Pattern: BaseOnPremIntegration uses IHttpClientFactory, named client via serviceName
|
||||
OracleIntegrationBase: Direct Flurl request creation, no HttpClientFactory
|
||||
Purpose: Centralized HTTP client configuration, supports ASP.NET Core best practices
|
||||
|
||||
Chunk 8: Request Caching Strategy
|
||||
Metadata: optimization=caching, scope=OnPremOnly, pattern=lazy, field=_flurlRequest
|
||||
Caching: Flurl request cached for service instance lifetime
|
||||
OracleIntegrationBase: No caching, new request each call
|
||||
Benefit: Reduces secret retrieval overhead, improves performance
|
||||
|
||||
Chunk 9: URL Construction Patterns
|
||||
Metadata: concept=urlConstruction, components=2, patterns=environmentBased
|
||||
Oracle URL: Base from secret (oicEnv), endpoint concatenation via string addition
|
||||
On-Prem URL: Subdomain routing based on ENVIRONMENT, endpoint appended via UpdateEndpoint
|
||||
Purpose: Environment-specific API routing without code changes
|
||||
|
||||
Chunk 10: Known Implementations
|
||||
Metadata: implementations=derived, count=1known, location=StructuredTags
|
||||
Oracle: MemoLookup service (GL account memo line configs), implements IMemoLookup
|
||||
On-Prem: Expected – Licensing API, dealer info, sales data, policy lookup
|
||||
Pattern: Inherit base class, add endpoint methods, deserialize responses
|
||||
|
||||
Chunk 11: Dependency Injection Patterns
|
||||
Metadata: pattern=dependencyInjection, dependencies=2, testability=high
|
||||
Common: ISecretString for secret access
|
||||
On-Prem Additional: IHttpClientFactory + serviceName
|
||||
Oracle Minimal: Only ISecretString
|
||||
Purpose: SOLID-compliant, supports unit and integration testing with mocks
|
||||
|
||||
Chunk 12: Authentication Comparison
|
||||
Metadata: comparison=authenticationMethods, methods=2, security=secretBased
|
||||
Oracle: HTTP Basic Auth (Authorization: Basic {base64(username:password)})
|
||||
On-Prem: Custom headers (client-id, client-secret)
|
||||
Security: Both retrieve secrets from AWS Secrets Manager, no hardcoding, environment-isolated
|
||||
|
||||
Chunk 13: Extensibility Patterns
|
||||
Metadata: pattern=extensibility, method=inheritance, examples=provided
|
||||
Steps: Inherit base class → inject dependencies → call base constructor → add endpoint methods → use GetRequestAsync() → deserialize responses
|
||||
Example: CustomerIntegration : OracleIntegrationBase, DealerIntegration : BaseOnPremIntegration
|
||||
Purpose: Code reuse, consistent auth, standard integration patterns
|
||||
|
||||
Chunk 14: Error Handling Patterns
|
||||
Metadata: errorHandling=exceptions, validation=constructor, propagation=upstream
|
||||
ENV Errors: Throws generic exception if ENVIRONMENT missing
|
||||
Secret Retrieval: Exceptions propagate, no catch
|
||||
HTTP Errors: Base classes do not handle; derived classes responsible
|
||||
Null Handling: MemoLookup throws ArgumentNullException for null deserialization
|
||||
Pattern: Fail-fast, let exceptions bubble
|
||||
|
||||
Chunk 15: Integration Use Cases
|
||||
Metadata: useCases=multiple, frequency=perTransaction, criticality=high
|
||||
|
||||
Memo line lookups (GL account mappings per transaction)
|
||||
Customer queries (Oracle data retrieval)
|
||||
Invoice posting (Oracle endpoints)
|
||||
Payment processing (Oracle integrations)
|
||||
Licensing queries (on-prem)
|
||||
Sales data retrieval (on-prem)
|
||||
Frequency: High for memo lookups, lower for licensing/sales queries
|
||||
|
||||
Chunk 16: Design Benefits
|
||||
Metadata: benefits=architectural, principles=SOLID, maintainability=high
|
||||
|
||||
Single Responsibility: One base class per integration type
|
||||
DRY: Centralized auth/config logic
|
||||
Testability: Dependency injection
|
||||
Maintainability: Auth changes require only base class updates
|
||||
Scalability: Easy to extend
|
||||
Security: Secrets never hardcoded
|
||||
Environment Safety: Environment-isolated credentials
|
||||
|
||||
Chunk 17: Flurl HTTP Library Features
|
||||
Metadata: library=Flurl, features=utilized, purpose=fluentAPI
|
||||
|
||||
Fluent request building: WithHeader(), WithBasicAuth()
|
||||
URL construction: string concatenation
|
||||
Response handling: GetAsync(), GetStringAsync()
|
||||
Client configuration: FlurlClient wrapper
|
||||
Usage: Base classes return IFlurlRequest for derived execution
|
||||
|
||||
Chunk 18: Search Queries Supported
|
||||
Metadata: type=queryPatterns, purpose=RAGRetrieval
|
||||
Sample Queries:
|
||||
|
||||
"How do I integrate with Oracle Cloud Integration from Lambda?"
|
||||
"What base class should I use for Oracle OIC integration?"
|
||||
"How are Oracle credentials managed?"
|
||||
"What authentication method is used for on-prem HFA services?"
|
||||
"How do I create a new Oracle integration?"
|
||||
"What secrets are needed for Oracle integration?"
|
||||
"How does environment-based URL routing work?"
|
||||
"Difference between Oracle and on-prem integration classes?"
|
||||
"How do I implement a new on-prem service client?"
|
||||
"What HTTP client library is used for integrations?"
|
||||
"How are credentials retrieved?"
|
||||
"What environment variables are required?"
|
||||
"How does request caching work on-prem?"
|
||||
"What dependency injection is required?"
|
||||
"How do I extend OracleIntegrationBase for a new endpoint?"
|
||||
"What error handling patterns are used?"
|
||||
"How does memo lookup use Oracle integration?"
|
||||
"What benefits does the integration base class provide?"
|
||||
7718
Books/Accounting/Oracle/Oracle.txt
Normal file
7718
Books/Accounting/Oracle/Oracle.txt
Normal file
File diff suppressed because it is too large
Load Diff
151
Books/Accounting/PayoffBalance.txt
Normal file
151
Books/Accounting/PayoffBalance.txt
Normal file
@@ -0,0 +1,151 @@
|
||||
PayoffBalance Module – RAG Knowledge Base
|
||||
|
||||
Chunk 1: Module Overview
|
||||
Metadata: module=PayoffBalance, type=overview, location=CMH.HFA.Accounting.Orchestration/src/PayoffBalance, count=2, purpose=payoffCalculation, pattern=LambdaOrchestration
|
||||
Purpose: Lambda-based orchestration for calculating real-time insurance policy payoff balances
|
||||
Scope: Single Lambda function coordinating multiple downstream Lambda invocations to aggregate customer and invoice data
|
||||
Integration Points: Invokes customer retrieval Lambda, invokes invoice retrieval Lambda, returns calculated payoff balance to caller
|
||||
Key Concepts: policy payoff calculation, Lambda-to-Lambda invocation, installment balance aggregation, synchronous orchestration, balance reconciliation
|
||||
|
||||
Chunk 2: PayoffBalanceLambda Function
|
||||
Metadata: component=PayoffBalanceLambda, type=Lambda, operation=GetPayoffBalance, deployment=serverless, invocationType=synchronous
|
||||
Description: Orchestrator Lambda function calculating exact policy payoff by aggregating invoice balance and open installment adjustments
|
||||
Input: PayoffBalanceRequest containing PolicyNumber (required), AccountSourceReference (optional)
|
||||
Output: Decimal representing payoff balance, or -1 for customer/invoice not found
|
||||
Lambda Configuration: 256 MB memory, 30-second timeout, basic execution role
|
||||
Orchestration Pattern: Sequential Lambda invocations (customer retrieval → invoice retrieval → local calculation)
|
||||
|
||||
Chunk 3: Payoff Balance Calculation Formula
|
||||
Metadata: operation=CalculatePayoff, formula=balanceMinusAdjustments, precision=decimal
|
||||
Formula: Payoff Balance = Invoice Balance Amount - Sum(Open Installment Adjusted Amounts)
|
||||
Components:
|
||||
|
||||
Invoice Balance Amount: Total outstanding (InvoiceBalanceAmountDecimal)
|
||||
Open Installment Adjusted Amounts: Sum of AmountAdjusted for installments with InstallmentStatus="Open"
|
||||
Example: $1200 - $200 - $150 = $850
|
||||
Purpose: Accounts for partial payments or credits, provides exact full-settlement amount
|
||||
|
||||
Chunk 4: Customer Retrieval Step
|
||||
Metadata: operation=GetCustomerAsync, invocationType=RequestResponse, environmentVariable=GET_CUSTOMER_FUNCTION_NAME, returnType=OracleCustomer
|
||||
Process: Invokes Lambda to retrieve Oracle customer data
|
||||
Input Payload: Serialized PayoffBalanceRequest JSON
|
||||
Response Handling: Deserializes CustomerWrapper → extracts first account number → returns null if no customer or accounts
|
||||
Error Scenarios: Returns null → -1 payoff balance
|
||||
|
||||
Chunk 5: Invoice Retrieval Step
|
||||
Metadata: operation=GetInvoiceAsync, invocationType=RequestResponse, environmentVariable=GET_INVOICE_FUNCTION_NAME, returnType=OracleInvoiceWithInstallments
|
||||
Process: Invokes Lambda to retrieve invoice with installment details
|
||||
Input Payload: JSON containing PolicyNumber and AccountNumber
|
||||
Response Handling: Deserializes OracleInvoiceWithInstallments, logs errors, returns null if function fails
|
||||
Error Detection: Checks FunctionError property, logs errors, continues processing → returns null → -1 payoff
|
||||
|
||||
Chunk 6: PayoffBalanceRequest Model
|
||||
Metadata: model=PayoffBalanceRequest, type=inputDTO, requiredFields=1
|
||||
Properties:
|
||||
|
||||
AccountSourceReference: Optional
|
||||
PolicyNumber: Required
|
||||
Usage: Lambda input parameter, serialized for downstream Lambda invocations
|
||||
Validation: PolicyNumber validated in Lambda logic
|
||||
Purpose: Minimal input to initiate payoff workflow
|
||||
|
||||
Chunk 7: CustomerWrapper Model
|
||||
Metadata: model=CustomerWrapper, type=responseDTO, purpose=deserialization
|
||||
Structure: Single property Customer of type OracleCustomer
|
||||
Purpose: Wraps OracleCustomer for deserialization, temporary wrapper for account number extraction
|
||||
|
||||
Chunk 8: OracleInvoiceWithInstallments Model
|
||||
Metadata: model=OracleInvoiceWithInstallments, type=composite, includesInstallments=true
|
||||
Structure: Invoice header data (InvoiceBalanceAmountDecimal, etc.) + Installments array
|
||||
Installment Properties: InstallmentStatus (Open/Paid/Cancelled), AmountAdjusted (string → parsed via ParsedAmountAdjusted extension)
|
||||
Filtering: Only InstallmentStatus="Open" included in payoff calculation
|
||||
|
||||
Chunk 9: Not Found Handling
|
||||
Metadata: errorHandling=notFound, returnValue=-1, semantic=specialIndicator
|
||||
Not Found Scenarios: Customer null, Customer has no accounts, Invoice retrieval null
|
||||
Return Value: -1 decimal indicates not found
|
||||
Pattern: Sentinel value instead of exception
|
||||
Use Case: Invalid policy, account not created, policy exists but no invoice
|
||||
|
||||
Chunk 10: Environment Variable Configuration
|
||||
Metadata: configuration=environmentVariables, required=2, validation=startup
|
||||
Variables:
|
||||
|
||||
GET_CUSTOMER_FUNCTION_NAME: Lambda name/ARN for customer retrieval
|
||||
GET_INVOICE_FUNCTION_NAME: Lambda name/ARN for invoice retrieval
|
||||
Validation: Throws InvalidOperationException if null/empty
|
||||
Purpose: Environment-specific Lambda routing without hardcoding
|
||||
|
||||
Chunk 11: Lambda Invocation Pattern
|
||||
Metadata: pattern=synchronousInvocation, sdk=AmazonLambdaClient, invocationType=RequestResponse
|
||||
Client Creation: AmazonLambdaClient within using statement
|
||||
Invocation Type: RequestResponse synchronous
|
||||
Payload Handling: JSON serialization/deserialization
|
||||
Error Detection: Checks FunctionError, checks null Payload
|
||||
Use Case: Sequential dependency (invoice requires account number from customer)
|
||||
|
||||
Chunk 12: Installment Status Filtering
|
||||
Metadata: filtering=installmentStatus, statusValue=Open, caseSensitivity=exact
|
||||
Filter: InstallmentStatus == "Open" (case-sensitive)
|
||||
Purpose: Exclude Paid/Cancelled installments
|
||||
Aggregation: Sum filtered using ParsedAmountAdjusted()
|
||||
|
||||
Chunk 13: Amount Parsing Extension
|
||||
Metadata: extension=ParsedAmountAdjusted, sourceType=string, targetType=decimal
|
||||
Purpose: Convert AmountAdjusted string → decimal
|
||||
Usage: Called on each open installment
|
||||
Null Handling: Null collection → 0m
|
||||
Error Handling: Assumes valid numeric strings
|
||||
|
||||
Chunk 14: Use Cases and Workflows
|
||||
Metadata: type=useCases, consumers=multiple, timing=realTime
|
||||
Use Cases:
|
||||
|
||||
Policy cancellation → refund/owed amount
|
||||
Lender payoff quote → real-time settlement
|
||||
Customer inquiry → balance inquiry
|
||||
Refinancing → exact payoff to clear debt
|
||||
Account settlement → prevent over/underpayment
|
||||
|
||||
Chunk 15: Architectural Characteristics
|
||||
Metadata: architecture=microservices, coupling=loose, scalability=horizontal, statefulness=stateless
|
||||
Microservices: Customer retrieval, invoice retrieval, payoff calculation separated
|
||||
Benefits: Independent scaling, reusable Lambdas, isolated failure domains, separation of concerns
|
||||
Trade-offs: Multiple cold starts, increased latency, higher cost, distributed failure points
|
||||
Statefulness: Stateless, no caching
|
||||
|
||||
Chunk 16: Error Propagation Strategy
|
||||
Metadata: errorHandling=gracefulDegradation, exceptionStrategy=minimal
|
||||
Function Error Logging: Logs downstream errors, does not throw
|
||||
Null Propagation: Null responses → -1 result
|
||||
Environment Validation: Only throws exceptions
|
||||
Rationale: Caller distinguishes not found vs other errors, enables graceful orchestration
|
||||
|
||||
Chunk 17: Performance Considerations
|
||||
Metadata: performance=latency, coldStarts=3possible, invocationCount=3
|
||||
Latency Sources: Cold start of PayoffBalance Lambda, customer Lambda, invoice Lambda, serial invocation, network round trips
|
||||
Optimization: Parallel invocations, caching, direct DB/Oracle queries
|
||||
Current Approach: Simplicity and reusability over performance; suitable for infrequent payoff queries
|
||||
|
||||
Chunk 18: Search Queries Supported
|
||||
Metadata: type=queryPatterns, purpose=RAGRetrieval
|
||||
Sample Queries:
|
||||
|
||||
"How do I calculate insurance policy payoff balance?"
|
||||
"What Lambda calculates policy payoff amounts?"
|
||||
"How are open installments factored into payoff?"
|
||||
"What does -1 payoff balance mean?"
|
||||
"How do I invoke customer retrieval from Lambda?"
|
||||
"What environment variables are needed?"
|
||||
"What is the formula for payoff balance?"
|
||||
"How are invoice balance and installment adjustments combined?"
|
||||
"What happens when customer is not found?"
|
||||
"How does Lambda-to-Lambda invocation work?"
|
||||
"Return type for policy/customer not found?"
|
||||
"How are installment adjusted amounts parsed?"
|
||||
"Use cases requiring real-time payoff calculation?"
|
||||
"How does workflow handle downstream Lambda errors?"
|
||||
"Difference between invoice balance and payoff balance?"
|
||||
"How are open vs paid installments filtered?"
|
||||
"Configuration required for payoff Lambda?"
|
||||
"How does synchronous Lambda invocation work?"
|
||||
193
Books/Accounting/Policy.txt
Normal file
193
Books/Accounting/Policy.txt
Normal file
@@ -0,0 +1,193 @@
|
||||
Policy Module – RAG Knowledge Base
|
||||
|
||||
Chunk 1: Module Overview
|
||||
Metadata: module=Policy, type=overview, location=CMH.HFA.Accounting.Orchestration/src/Policy, domain=policyAccounting, scope=fullLifecycle
|
||||
Purpose: Comprehensive Lambda functions and services for insurance policy lifecycle events and accounting transactions
|
||||
Functional Domains: Policy issuance/renewals, monetary/non-monetary endorsements, policy cancellations, refunds, commissions, invoice adjustments, licensing management
|
||||
Integration Points: Oracle Fusion AR (invoice/credit memo posting), Oracle OIC (memo line lookups), customer management, commission tracking, AWS Step Functions
|
||||
Key Concepts: invoice generation, credit memo creation, commission allocation, endorsement adjustments, refund distribution, transaction line building, temporal validity, memo line configuration
|
||||
|
||||
Chunk 2: MapOracleInvoice Service
|
||||
Metadata: component=MapOracleInvoice, type=Lambda, operations=2, pattern=autoMapper, purpose=invoiceCreation
|
||||
Description: Orchestrates transformation of policy events into Oracle AR invoice structures
|
||||
Operations:
|
||||
|
||||
Map: Processes PolicyIssuedEvent for new invoices
|
||||
MapRenewed: Processes PolicyRenewedEvent for renewal invoices
|
||||
Processing Flow: Receives policy event + customer data, applies AutoMapper, determines transaction type (internal/external), invokes commission service, builds transaction lines using memo line lookups
|
||||
Transaction Type Logic: Maps Internal vs External based on BillingType, ProductType, lender status
|
||||
|
||||
Chunk 3: Invoice Commission Processing
|
||||
Metadata: component=InvoiceCommission, interface=IInvoiceCommission, pattern=multiStage, purpose=commissionCalculation
|
||||
Description: Multi-stage pipeline to calculate commission-related transaction lines
|
||||
Stages:
|
||||
|
||||
Pre-invoice line creation → maps premium and sales tax
|
||||
Commission line generation → Retail vs HFA
|
||||
Memo line retrieval → GL accounts via Oracle OIC
|
||||
Transaction line finalization → GL accounts, amounts, commission metadata
|
||||
Sorting → by type (premium, commission, fees) via TransactionLineComparer
|
||||
Licensing Integration: Differentiates licensed/unlicensed home centers for commission routing
|
||||
|
||||
Chunk 4: Policy Cancellation Processing
|
||||
Metadata: component=PolicyCancelService, operation=MapEventPayload, output=CreditMemo, purpose=cancellationAccounting
|
||||
Description: Generates credit memos for policy cancellations with coverage-based refund calculations
|
||||
Input: InsurancePolicyCancelledEventPayload (coverage blocks, unearned premium, sales tax refund, cancellation reason, billing type, other interests)
|
||||
Credit Memo Generation: Negates original invoice amounts, maps cancellation reason to Oracle credit reason codes, determines internal/external transaction type, links to original invoice
|
||||
Cancellation Reason Mapping: CustomerRequest, Flat, NonPayment, Repossession, ReplacementPolicy, Underwriting, HomeSold → "HFA-{Reason}" codes
|
||||
Coverage Block Processing: Allocates premiums to corresponding GL accounts for accurate refunds
|
||||
|
||||
Chunk 5: Refund Adjustment Service
|
||||
Metadata: component=RefundAdjustmentService, operation=GetCancellationRefundAdjustment, output=Adjustment, recipients=3
|
||||
Description: Creates AR adjustment records for cancellation refunds
|
||||
Recipient Types:
|
||||
|
||||
Retail → "HFA Retail I/C Refund"
|
||||
VMF → "HFA VMF I/C Refund"
|
||||
Customer → "HFA Auto Customer Refund"
|
||||
Adjustment Configuration: Sets ReceivableTrxId, OrgId, SetOfBooksId
|
||||
Comment Generation: Auto-generates descriptive comments
|
||||
Validation: Throws exception if refund amount zero or credit memo missing
|
||||
|
||||
Chunk 6: Endorsement Adjustment Service
|
||||
Metadata: component=EndorsementAdjustmentService, operation=MapEndorsementAdjustments, distribution=installmentBased, purpose=balanceSpread
|
||||
Description: Allocates endorsement balance changes across invoice installments proportionally
|
||||
Distribution Logic:
|
||||
|
||||
Single installment → full amount, rounding applied
|
||||
Multiple installments → divided equally, final rounding adjustment
|
||||
Zero balance → empty adjustment list
|
||||
Adjustment Structure: Adjustment records with CustomerTrxId, PaymentScheduleId, ReceivablesTrxId, AdjustmentType="M", Amount, ApplyDate, CurrencyCode, OrgId, SetOfBooksId
|
||||
Use Case: Monetary endorsements requiring proper AR aging
|
||||
|
||||
Chunk 7: Non-Monetary Endorsement Processing
|
||||
Metadata: component=ProcessNonMonetaryEndorsementCustomerLambda, type=Lambda, purpose=customerUpdates, changes=demographic
|
||||
Description: Updates customer data without affecting premium/fees
|
||||
Supported Updates:
|
||||
|
||||
Name: first, middle, last, suffix
|
||||
Address: street1-3, city, stateCode, zip.base/ext, country
|
||||
Processing Pattern: Iterates NonMonetaryUpdate objects, applies property path to Oracle customer, targets MAILING site
|
||||
Output: Modified OracleCustomer for downstream synchronization
|
||||
|
||||
Chunk 8: Invoice Filtering and Selection
|
||||
Metadata: components=2, purpose=invoiceQuery, operations=filterAndSelect
|
||||
|
||||
FilterOpenInvoicesLambda: Filters invoices with balance >0, orders by TransactionDate descending
|
||||
SelectValidInvoiceLambda: Selects most recent invoice matching valid transaction type whitelist (HFA internal/external, plan/type change, conversion), open balance >0
|
||||
Valid Transaction Types: HfaInvoiceInternal, HfaInvoiceExternal, HfaInvPlanChgInt/Ext, HfaInvTypeChgInt/Ext, HfaInternConv, HfaExternConv
|
||||
Use Cases: Endorsement workflows, billing change workflows
|
||||
|
||||
Chunk 9: Policy Number Management
|
||||
Metadata: component=DecrementPolicyNumberLambda, type=Lambda, operation=numberManipulation, pattern=wrapping
|
||||
Description: Decrements numeric suffix of policy numbers with wraparound logic
|
||||
Algorithm: Last 2 characters numeric → decrement modulo 100, maintains prefix, zero-padded 2-digit suffix
|
||||
Validation: Policy number min 2 chars, last 2 chars parse as int
|
||||
Example: "POL-12345-03" → "POL-12345-02"; "POL-12345-00" → "POL-12345-99"
|
||||
Use Case: Policy versioning/renewal numbering
|
||||
|
||||
Chunk 10: Policy Licensing Management
|
||||
Metadata: component=PolicyLicensingLambda, operations=2, purpose=licensingInfo, determination=dealerBased
|
||||
Operations:
|
||||
|
||||
MapIssuedLicensingInfo: Extracts licensing from issuance event
|
||||
MapRenewedLicensingInfo: Extracts licensing from renewal event + previous invoice
|
||||
LicenseInfo: IsHomeCenterLicensed, MasterDealerNumber, HomeCenterId, StateCode
|
||||
Dealer Logic: Producer=ClaytonRetail AND Product≠ESC → MasterDealerNumber=29; else 0
|
||||
Purpose: Influences commission calculations and transaction routing
|
||||
|
||||
Chunk 11: Cancellation Subfolder Components
|
||||
Metadata: subfolder=Cancellations, components=4, purpose=cancellationWorkflow
|
||||
|
||||
MapCancellation Lambda: Orchestrates credit memo creation
|
||||
MapCancellationRefund Lambda: Refund-specific logic
|
||||
PolicyCancelRefundAdjustmentDto: DTO with credit memo references, refund amounts, recipients
|
||||
InsurancePolicyCancelledEventPayload: Event model with policy/account identifiers, cancellation reasons, dates, other interests, billing type, coverage blocks, unearned premium, sales tax refund
|
||||
|
||||
Chunk 12: Event Domain Models
|
||||
Metadata: subfolder=Events, type=payloadModels, count=10+, compliance=PII
|
||||
|
||||
PolicyIssuedEventV2Payload: New policy event with account, policy, product, premium, coverage, billing, producer info
|
||||
InsurancePolicyRenewedEventPayload: Extends issuance payload, adds AgencyFirstWrittenDate
|
||||
CommissionDisbursementCreditedPayload: Commission payment events
|
||||
PolicyEventBase: Base class for policy events
|
||||
PII Compliance: Uses attributes on sensitive fields
|
||||
|
||||
Chunk 13: Transaction Type Determination
|
||||
Metadata: concept=transactionTypeMapping, factors=BillingType+OtherInterests, values=Internal/External
|
||||
Internal: BillingType="OtherInterest" AND OtherInterests contains InternalLender=true
|
||||
External: All other cases
|
||||
Transaction Codes: HfaInvoiceInternal/External for invoices; Credit Memos vary by operation with Int/Ext suffix
|
||||
|
||||
Chunk 14: Memo Line Integration Pattern
|
||||
Metadata: integration=MemoLineLookup, purpose=GLMapping, timing=temporal
|
||||
Lookup Pattern: IMemoLookup.GetMemoLookupAsync using invoice creation date
|
||||
Filtering: By Action, Type, ProductType, Organization, State, Commission Percent
|
||||
GL Assignment: MemoLine.Description → TransactionLine.MemoLine; distribution % → amount
|
||||
Temporal Guarantee: Historical accuracy, unaffected by configuration changes
|
||||
|
||||
Chunk 15: Transaction Line Sorting
|
||||
Metadata: component=TransactionLineComparer, type=comparator, purpose=lineOrdering
|
||||
Sort Order:
|
||||
|
||||
Premium Lines (Assurant Payable first)
|
||||
Commission Lines
|
||||
Fee Lines
|
||||
Other Lines (original order)
|
||||
Post-Sort: Renumber LineNumber sequentially
|
||||
Purpose: Consistent invoice presentation, supports downstream processing
|
||||
|
||||
Chunk 16: DTO Folder Components
|
||||
Metadata: subfolder=Dto, type=dataTransferObjects, count=6+, purpose=lambdaInputs
|
||||
|
||||
MapEndorsementAdjustmentsDto: Installments, OpenBalance, AdjustmentConfiguration
|
||||
PolicyRenewedInvoiceMaptDto: PolicyRenewedEvent, Customer, LicenseInfo, PreviousInvoice
|
||||
RenewedGetLicensingDto: PolicyRenewedEvent, PreviousInvoice
|
||||
NonMonetaryEndorsementUpdateDto: OldCustomer, Updates collection
|
||||
PolicyCancelRefundAdjustmentDto: Refund-specific data
|
||||
Pattern: DTOs implement deconstruction methods for tuple unpacking
|
||||
|
||||
Chunk 17: Coverage Block Processing
|
||||
Metadata: concept=coverageBlocks, purpose=premiumAllocation, granularity=perCoverage
|
||||
Structure: CoverageBlock → Code, Coverage, Premium
|
||||
Usage: Cancellations → pro-rated unearned premium; endorsements → coverage-specific adjustments; invoice generation → allocates premiums per coverage
|
||||
GL Distribution: Different coverage types route to GL accounts via memo line config
|
||||
|
||||
Chunk 18: Commission Metadata Enrichment
|
||||
Metadata: operation=commissionEnrichment, fields=7, differentiation=RetailVsHFA
|
||||
Common Fields: BusinessGroup, NewOrRenewal, CommissionPercent, AgencyFirstWrittenDate
|
||||
Retail: CommissionOrganization="Clayton Retail", Producer, SubProducer, CommissionReference
|
||||
HFA: CommissionOrganization="HFA", Producer, SubProducer=empty, CommissionReference=empty
|
||||
Detection: MemoLine.Description contains "Retail Commission" or "HFA Commission"
|
||||
Renewal: Copies AgencyFirstWrittenDate
|
||||
|
||||
Chunk 19: State and Jurisdiction Handling
|
||||
Metadata: concept=stateCodeProcessing, normalization=descriptionConversion, usage=memoLineFiltering
|
||||
State Sources: PhysicalStateCode → string description via ToDescription()
|
||||
Memo Line Filtering: State description used in GetMatchingLines
|
||||
Address Normalization: State codes → descriptions
|
||||
Tax Implications: State drives sales tax/refund in cancellations
|
||||
|
||||
Chunk 20: Search Queries Supported
|
||||
Metadata: type=queryPatterns, purpose=RAGRetrieval
|
||||
Sample Queries:
|
||||
|
||||
"How are policy issuance invoices created in Oracle?"
|
||||
"What is the commission calculation process?"
|
||||
"How do cancellations generate credit memos?"
|
||||
"What adjustment types are supported for refunds?"
|
||||
"How are endorsement balance changes distributed?"
|
||||
"How do non-monetary endorsements update customers?"
|
||||
"Transaction types for internal vs external billing?"
|
||||
"How are coverage blocks used in premium calculations?"
|
||||
"Memo line filtering criteria for invoices?"
|
||||
"How does licensing service determine dealer numbers?"
|
||||
"Transaction line sorting order on invoices?"
|
||||
"How are policy renewal invoices different from issuance?"
|
||||
"Cancellation reasons mapping?"
|
||||
"How do refunds distribute to Retail, VMF, or customers?"
|
||||
"Validation on invoice selection?"
|
||||
"How does temporal memo line lookup work?"
|
||||
"Which fields are updateable via non-monetary endorsements?"
|
||||
"Commission organization determination (Retail vs HFA)?"
|
||||
"How does system handle internal lenders for transaction typing?"
|
||||
121
Books/Accounting/Quote.txt
Normal file
121
Books/Accounting/Quote.txt
Normal file
@@ -0,0 +1,121 @@
|
||||
Quote Module – RAG Knowledge Base
|
||||
|
||||
Chunk 1: Module Overview
|
||||
Metadata: module=Quote, type=overview, location=CMH.HFA.Accounting.Orchestration/src/Quote, count=1, purpose=customerPreprocessing
|
||||
Purpose: Preprocessing layer transforming insurance quote events into Oracle customer master data structures
|
||||
Scope: Single Lambda function handling quote-to-customer conversion in the quote offering workflow
|
||||
Integration Points: Receives InsuranceQuoteOfferedEventPayload, produces OracleCustomer for Oracle Fusion, enables customer record initialization before policy issuance
|
||||
Key Concepts: quote preprocessing, customer data transformation, Oracle customer creation, account establishment, site configuration, bill-to designation
|
||||
|
||||
Chunk 2: PreprocessQuoteOfferedLambda Function
|
||||
Metadata: component=PreprocessQuoteOfferedLambda, type=Lambda, pattern=dataTransformation, deployment=serverless
|
||||
Description: Converts insurance quote event data into Oracle Fusion customer account structures
|
||||
Input: InsuranceQuoteOfferedEventPayload (demographics, address, account identifiers)
|
||||
Output: OracleCustomer object with complete account, site, and bill-to setup for Oracle integration
|
||||
Lambda Configuration: 256 MB memory, 30-second timeout, basic execution role policies
|
||||
Processing Pattern: Stateless, synchronous transformation, no external service calls
|
||||
|
||||
Chunk 3: Customer Demographic Mapping
|
||||
Metadata: operation=customerMapping, source=quotePayload, target=OracleCustomer, fields=name
|
||||
Extracted Fields: First, Last, Middle names, Name suffix
|
||||
Customer Properties: SourceSystem="HFA"
|
||||
Mapping Logic: Direct property-to-property assignment, handles optional middle name/suffix
|
||||
Purpose: Establishes customer identity for Oracle customer master
|
||||
|
||||
Chunk 4: Account Identifier Extraction
|
||||
Metadata: operation=accountIdentifierMapping, identifierTypes=2, primaryKey=AccountID
|
||||
Identifier Types:
|
||||
|
||||
AccountID → AccountSourceReference (primary account ID)
|
||||
iSeriesAccountKey → AccountDescription prefixed with "HFA_" for legacy correlation
|
||||
Extraction Method: Finds identifiers by Type property, non-null assertion
|
||||
Account Source: "HFA" (Home First Agency)
|
||||
Purpose: Links Oracle account to source system for reference and synchronization
|
||||
|
||||
Chunk 5: Account Configuration
|
||||
Metadata: entity=Account, properties=7, status=active, lifecycle=openEnded
|
||||
Account Properties:
|
||||
|
||||
AccountSourceReference → from AccountID
|
||||
AccountSource="HFA"
|
||||
AccountDescription="HFA_{iSeriesAccountKey}"
|
||||
CustomerClass="HFA Customer"
|
||||
AccountStatus="A"
|
||||
AccountEstablishedDate=current date
|
||||
AccountTerminationDate=4712-12-31 (open-ended)
|
||||
Purpose: Creates foundational account record for sites, payment terms, transaction history
|
||||
|
||||
Chunk 6: Site Record Configuration
|
||||
Metadata: entity=Site, siteName=MAILING, purpose=addressRepository, status=active
|
||||
Site Properties:
|
||||
|
||||
SiteName="MAILING"
|
||||
AddressLine1/2, City, State (converted via ToDescription()), PostalCode, Country="US"
|
||||
SiteStatus="A", AccountAddressSet="CHI_HFA_SET"
|
||||
Date Ranges: SiteFromDate=current date, SiteToDate=4712-12-31
|
||||
Purpose: Stores physical location for correspondence and compliance
|
||||
|
||||
Chunk 7: Bill-To Site Use Configuration
|
||||
Metadata: entity=SiteUse, purpose=BILL_TO, primaryIndicator=true, cardinality=one
|
||||
Site Use Properties:
|
||||
|
||||
Purpose="BILL_TO", primary indicator=true
|
||||
SiteUseFromDate=current date, SiteUseToDate=4712-12-31
|
||||
Cardinality: Single bill-to site per mailing site
|
||||
Purpose: Establishes billing destination for invoices, credit memos, payment applications
|
||||
|
||||
Chunk 8: Address Normalization
|
||||
Metadata: operation=addressMapping, source=quoteAddress, normalization=stateCode, defaultCountry=US
|
||||
Address Extraction: From InsuranceQuoteOfferedEventPayload.Address
|
||||
State Handling: Converts StateCode enum → string description using ToDescription()
|
||||
Zip Code Handling: Uses 5-digit base only
|
||||
Country Defaulting: US
|
||||
Purpose: Normalizes addresses for Oracle Fusion integration
|
||||
|
||||
Chunk 9: Temporal Validity Pattern
|
||||
Metadata: pattern=temporalValidity, startDate=today, endDate=4712-12-31, standard=Oracle
|
||||
Applied To: Account establishment/termination, Site from/to dates, SiteUse dates
|
||||
Semantic Meaning: Start date = effective date; End date 4712-12-31 = indefinite validity
|
||||
Purpose: Enables temporal querying and historical record keeping, indicates active status
|
||||
|
||||
Chunk 10: Quote-to-Policy Workflow Context
|
||||
Metadata: workflow=quoteToPolicy, stage=preprocessing, timing=quoteOffering
|
||||
Workflow Position: Initial step before binding decision
|
||||
Dependencies: Oracle customer must exist before policy issuance; account number needed for invoices; site configuration required for billing
|
||||
Event Trigger: InsuranceQuoteOfferedEvent
|
||||
Purpose: Decouples customer creation from policy issuance for workflow efficiency
|
||||
|
||||
Chunk 11: Oracle Integration Points
|
||||
Metadata: integration=OracleFusion, modules=CustomerMaster, operations=customerCreation
|
||||
Oracle Modules: Customer Master (HZ_PARTIES, HZ_PARTY_SITES), Accounts Receivable
|
||||
Data Structures: OracleCustomer, Account, Site, SiteUse matching Oracle REST API
|
||||
Integration Pattern: Lambda produces Oracle-formatted data; downstream orchestration sends to Oracle OIC
|
||||
Account Address Set: "CHI_HFA_SET" for HFA customer accounts
|
||||
Purpose: Ensures compatibility with Oracle Fusion REST APIs
|
||||
|
||||
Chunk 12: Data Quality and Defaults
|
||||
Metadata: dataQuality=defaulting, requiredFields=validated, optionalFields=graceful
|
||||
Required Fields: First name, Last name, AccountID, iSeriesAccountKey, primary address components
|
||||
Optional Fields: Middle name, name suffix, address line 2
|
||||
Default Values: Country="US", AccountSource="HFA", SourceSystem="HFA", CustomerClass="HFA Customer", SiteStatus="A", AccountStatus="A"
|
||||
Validation: Assumes required fields present, non-null assertion operators
|
||||
Purpose: Applies business rule defaults while maintaining Oracle customer master integrity
|
||||
|
||||
Chunk 13: Search Queries Supported
|
||||
Metadata: type=queryPatterns, purpose=RAGRetrieval
|
||||
Sample Queries:
|
||||
|
||||
"How are insurance quotes converted to Oracle customers?"
|
||||
"What Lambda function processes quote offered events?"
|
||||
"How is the bill-to site configured for new customers?"
|
||||
"What account identifiers are extracted from quote payloads?"
|
||||
"How are customer addresses normalized for Oracle?"
|
||||
"What is the temporal validity pattern for customer accounts?"
|
||||
"What default values are applied during quote preprocessing?"
|
||||
"How is the AccountDescription field constructed?"
|
||||
"What Oracle address set is used for HFA customers?"
|
||||
"When does customer record creation occur in the quote workflow?"
|
||||
"What fields are mapped from quote payload to Oracle customer?"
|
||||
"How are state codes converted for Oracle integration?"
|
||||
"What is the purpose of the MAILING site name?"
|
||||
"How long are customer accounts valid after creation?"
|
||||
125
Books/Accounting/Repository.txt
Normal file
125
Books/Accounting/Repository.txt
Normal file
@@ -0,0 +1,125 @@
|
||||
Repository Module – RAG Knowledge Base
|
||||
|
||||
Chunk 1: Module Overview
|
||||
Metadata: module=Repository, actualFolder=Respository, type=dataAccess, location=CMH.HFA.Accounting.Orchestration/src/Respository, storage=DynamoDB, count=2
|
||||
Purpose: Data access layer implementing repository patterns for DynamoDB persistence
|
||||
Scope: Two repositories – FIFO event queue and adjustment configuration storage
|
||||
Technology Stack: AWS DynamoDB SDK, DynamoDB DataModel context, Task.WhenAll for parallel operations, conditional updates for concurrency control
|
||||
Key Concepts: repository pattern, data access abstraction, DynamoDB document model, environment-based table naming, optimistic concurrency, TTL cleanup
|
||||
|
||||
Chunk 2: DynamoDbFifoRepository Class
|
||||
Metadata: component=DynamoDbFifoRepository, interface=IFifoRepository, purpose=eventQueuePersistence, pattern=FIFO
|
||||
Description: Manages FIFO event queue infrastructure with policy-based partitioning
|
||||
Table Structure: Partition key = PolicyNumber, Sort key = Timestamp (ISO 8601), GSI = EventId
|
||||
Table Naming: {ENVIRONMENT}-fifo-poc-table pattern
|
||||
Operations: Event retrieval by ID via GSI, policy-scoped queries, persistence, atomic status updates
|
||||
Concurrency Control: ConditionalCheckFailedException prevents race conditions
|
||||
|
||||
Chunk 3: FIFO Event Retrieval Operations
|
||||
Metadata: operation=GetEventByIdAsync, indexType=GSI, indexName=EventIdIndex, returnType=EventTableEntry
|
||||
Purpose: Retrieves single event by EventId using GSI
|
||||
Parameters: Guid eventId
|
||||
Query Behavior: Limits to 1 record, returns null if not found
|
||||
Use Case: Completion workflows or dequeue operations
|
||||
Performance: O(1) lookup via GSI, no full table scan
|
||||
|
||||
Chunk 4: FIFO Policy-Scoped Queries
|
||||
Metadata: operation=QueryByPolicyNumberAsync, keyType=partitionKey, filtering=optional, consistency=strong
|
||||
Purpose: Retrieves all events for a policy number, optional status filter
|
||||
Parameters: policyNumber, statusFilter
|
||||
Query Behavior: Partition key query with optional filter expression, consistent reads
|
||||
Use Case: FIFO service checking queue depth, next pending event, validating no events in processing
|
||||
|
||||
Chunk 5: FIFO Event Persistence
|
||||
Metadata: operation=SaveEventAsync, mutationType=insert, conflicts=allowDuplicates
|
||||
Purpose: Saves new event entry to DynamoDB FIFO table
|
||||
Parameters: EventTableEntry (PolicyNumber, Timestamp, EventId, Status, EventBody, DeduplicationKey)
|
||||
Behavior: Simple save, allows concurrent inserts, deduplication handled at service layer
|
||||
Use Case: Enqueue events for processing
|
||||
|
||||
Chunk 6: FIFO Status Updates
|
||||
Metadata: operation=UpdateStatusAsync, atomicity=conditional, concurrencyControl=optimistic
|
||||
Purpose: Updates event status with optional conditional check
|
||||
Parameters: policyNumber, timestamp, status, expectedStatus (optional)
|
||||
Conditional Path: Conditional expression requires current status match; throws ConditionalCheckFailedException on mismatch
|
||||
Unconditional Path: Loads entity, updates status, sets TTL if COMPLETED
|
||||
TTL Logic: 30-day expiry for automatic cleanup
|
||||
|
||||
Chunk 7: AdjustmentConfigRepository Class
|
||||
Metadata: component=AdjustmentConfigRepository, interface=IAdjustmentConfigRepository, purpose=configurationStorage, pattern=replace-all
|
||||
Description: Manages Oracle adjustment configuration records in DynamoDB
|
||||
Table Structure: Hash key = Id (Guid), Range key = ReceivableTrxId
|
||||
Table Naming: {ENVIRONMENT}-hfa-adjustement-configuration-table (note typo)
|
||||
Operations: Full table scan retrieval, transactional replace-all persistence
|
||||
Parallelization: Task.WhenAll for concurrent deletes and inserts
|
||||
|
||||
Chunk 8: Configuration Retrieval
|
||||
Metadata: operation=GetAllAdjustmentConfigurationsAsync, scanType=fullTable, parallelization=true
|
||||
Purpose: Retrieves all adjustment configurations
|
||||
Scan Strategy: Full table scan, parallel deserialization with Task.Run
|
||||
Return Type: IList<AdjustmentConfigurationModel>
|
||||
Use Case: Configuration lookup, admin display, filtering in service layer
|
||||
|
||||
Chunk 9: Configuration Persistence with Rollback
|
||||
Metadata: operation=SaveAdjustmentConfigurationsAsync, pattern=deleteAllThenInsert, transactional=applicationLevel, rollback=automatic
|
||||
Purpose: Replaces full table contents using application-level transaction
|
||||
Steps: Backup → Delete all → Insert new → Rollback on failure
|
||||
Atomicity: Application-level (not DynamoDB transaction), temporary empty table during delete-to-insert
|
||||
Use Case: Bulk updates, configuration migration
|
||||
|
||||
Chunk 10: Environment Configuration
|
||||
Metadata: concept=environmentVariables, required=true, validation=startup
|
||||
Requirement: Environment variable must be set (dev/test/prod)
|
||||
Validation: Repositories throw Exception if missing
|
||||
Table Naming Patterns:
|
||||
|
||||
FIFO: {ENVIRONMENT}-fifo-poc-table
|
||||
Adjustment Config: {ENVIRONMENT}-hfa-adjustement-configuration-table
|
||||
Purpose: Environment isolation, multi-environment deployments
|
||||
|
||||
Chunk 11: DynamoDB Context Configuration
|
||||
Metadata: concept=dynamoDBConfiguration, pattern=tableOverrides
|
||||
Configuration Objects: GetTargetTableConfig, FromDocumentConfig, LoadConfig, SaveConfig, DeleteConfig
|
||||
Override Pattern: OverrideTableName allows environment-specific routing
|
||||
Initialization: Configs created in constructor, reused for efficiency
|
||||
|
||||
Chunk 12: TTL (Time To Live) Implementation
|
||||
Metadata: feature=TTL, storage=DynamoDB, duration=30days, scope=completedEvents
|
||||
Purpose: Automatic cleanup of completed FIFO events
|
||||
TTL Field: TimeToLive (Unix timestamp)
|
||||
Calculation: DateTimeOffset.UtcNow.AddDays(30).ToUnixTimeSeconds()
|
||||
Trigger: Set on status COMPLETED, ignored for PENDING/PROCESSING
|
||||
DynamoDB Behavior: Deletes within ~48 hours, no cost
|
||||
|
||||
Chunk 13: Concurrency Patterns
|
||||
Metadata: concept=concurrencyControl, mechanism=conditionalUpdates, exception=ConditionalCheckFailedException
|
||||
FIFO Updates: Conditional expressions prevent multiple Lambda instances from transitioning same event
|
||||
Expected Status Pattern: Ensures current status matches expected before updating
|
||||
Race Conditions: Multiple Lambda cold starts, rapid event arrivals, completion races
|
||||
Exception Handling: Catch and ignore, losing instance backs off gracefully
|
||||
|
||||
Chunk 14: Parallel Processing Optimization
|
||||
Metadata: optimization=parallelization, mechanism=TaskWhenAll, scope=bulkOperations
|
||||
Adjustment Config Retrieval: Parallel deserialization
|
||||
Delete Operations: Parallel delete of existing configs
|
||||
Insert Operations: Parallel save of new configs
|
||||
Trade-offs: Higher Lambda memory, faster wall-clock time, rollback handles partial failures
|
||||
|
||||
Chunk 15: Search Queries Supported
|
||||
Metadata: type=queryPatterns, purpose=RAGRetrieval
|
||||
Sample Queries:
|
||||
|
||||
"How do I retrieve FIFO events by policy number?"
|
||||
"What is the repository pattern implementation for DynamoDB?"
|
||||
"How does conditional update work for FIFO event status?"
|
||||
"What table naming convention is used for repositories?"
|
||||
"How is TTL configured for completed events?"
|
||||
"What rollback mechanism exists for configuration saves?"
|
||||
"How do I query events by event ID?"
|
||||
"What concurrency control is used in FIFO repository?"
|
||||
"How are adjustment configurations stored in DynamoDB?"
|
||||
"What happens when environment variable is missing?"
|
||||
"How does parallel processing work in repositories?"
|
||||
"What is the Global Secondary Index structure for FIFO events?"
|
||||
"How long are completed events retained in DynamoDB?"
|
||||
"What exception indicates a race condition in status updates?"
|
||||
117
Books/Accounting/Services.txt
Normal file
117
Books/Accounting/Services.txt
Normal file
@@ -0,0 +1,117 @@
|
||||
Services Module – RAG Knowledge Base
|
||||
|
||||
Chunk 1: Module Overview
|
||||
Metadata: module=Services, type=overview, location=CMH.HFA.Accounting.Orchestration/src/Services, count=1
|
||||
Purpose: Lambda function wrapper layer for adjustment configuration management
|
||||
Scope: Single service class providing CRUD for Oracle receivables adjustment configurations stored in DynamoDB
|
||||
Integration Points: Consumed by endorsement processing workflows, refund adjustment workflows, policy cancellation services
|
||||
Key Concepts: adjustment configuration, receivables transaction mapping, Lambda endpoints, configuration retrieval and persistence
|
||||
|
||||
Chunk 2: AdjustmentConfigService Class
|
||||
Metadata: component=AdjustmentConfigService, type=service, pattern=repository-wrapper, deployment=Lambda
|
||||
Description: Exposes three Lambda endpoints for managing Oracle adjustment configurations
|
||||
Base Class: Extends BaseLambdaService for Lambda integration and service resolution
|
||||
Dependencies: IAdjustmentConfigRepository for data access
|
||||
Constructor Pattern: Dual constructors – parameterless for Lambda runtime, parameterized for dependency injection in tests
|
||||
Lambda Configuration: Uses LambdaFunction annotation for AWS Lambda deployment metadata
|
||||
|
||||
Chunk 3: GetConfigurations Operation
|
||||
Metadata: operation=GetConfigurations, httpMethod=N/A, returnType=IList<AdjustmentConfigurationModel>, filtering=none
|
||||
Purpose: Retrieves all adjustment configuration records without filtering
|
||||
Parameters: None
|
||||
Returns: Complete collection from DynamoDB
|
||||
Use Case: Admin audits, bulk export, dropdown population
|
||||
Behavior: Pass-through to repository GetAllAdjustmentConfigurationsAsync with no business logic
|
||||
|
||||
Chunk 4: GetConfiguration Operation
|
||||
Metadata: operation=GetConfiguration, filtering=multi-criteria, returnType=AdjustmentConfigurationModel, nullable=true
|
||||
Purpose: Retrieves single adjustment configuration by Name and Type with active status validation
|
||||
Parameters: GetAdjustmentConfigurationDto (Name, Type)
|
||||
Filtering Logic: Case-insensitive match on Name AND Type, active status evaluated via IsActive
|
||||
Validation: Null DTO check, required Name/Type validation, multi-error accumulation
|
||||
Use Case: Workflow-driven lookup for specific receivables transaction type
|
||||
|
||||
Chunk 5: SaveAsync Operation
|
||||
Metadata: operation=SaveAsync, mutationType=replace-all, transactional=true, rollback=automatic
|
||||
Purpose: Persists full collection of adjustment configurations using replace-all pattern
|
||||
Parameters: IList<AdjustmentConfigurationModel> collection
|
||||
Validation: Non-null, non-empty collection; throws ArgumentException if invalid
|
||||
Behavior: Delegates to repository SaveAdjustmentConfigurationsAsync which deletes all existing records, inserts new ones in parallel, automatically rolls back on failure
|
||||
Use Case: Bulk configuration refresh, migration, environment updates
|
||||
|
||||
Chunk 6: AdjustmentConfigurationModel Structure
|
||||
Metadata: model=AdjustmentConfigurationModel, storage=DynamoDB, keyType=composite
|
||||
Keys: Hash key = Id (Guid), Range key = ReceivableTrxId (Oracle transaction type)
|
||||
Oracle Integration Properties:
|
||||
|
||||
ReceivableTrxId: AR receivables transaction type ID
|
||||
OrgId: Oracle org ID for multi-org
|
||||
SetOfBooksId: Oracle ledger/set of books ID
|
||||
Configuration Properties:
|
||||
Name: Human-readable identifier
|
||||
Type: Category (e.g., Refund, Endorsement)
|
||||
Temporal Properties: IsActiveFlag (boolean), StartActiveDate, InactiveDate, EndActiveDate
|
||||
|
||||
Chunk 7: Active Status Evaluation
|
||||
Metadata: method=IsActive, type=businessRule, timezone=UTC
|
||||
Logic: Multi-condition temporal and flag-based evaluation
|
||||
Returns False if:
|
||||
|
||||
Current UTC < StartActiveDate
|
||||
Current UTC ≥ InactiveDate
|
||||
Current UTC ≥ EndActiveDate
|
||||
IsActiveFlag = false
|
||||
Returns True if all temporal boundaries satisfied AND IsActiveFlag = true
|
||||
Date Parsing: DateTime.TryParse with graceful handling of unparseable dates
|
||||
|
||||
Chunk 8: GetAdjustmentConfigurationDto
|
||||
Metadata: dto=GetAdjustmentConfigurationDto, purpose=queryInput, validation=required
|
||||
Properties: Name (string, required), Type (string, required)
|
||||
Validation: Both non-null/non-empty; violations thrown as ArgumentException with concatenated messages
|
||||
Usage: Passed as Lambda input, deserialized from JSON request, validated before lookup
|
||||
Example: Name="HFA Auto Customer Refund", Type="Refund"
|
||||
|
||||
Chunk 9: Configuration Categories
|
||||
Metadata: concept=configurationTypes, domain=adjustments
|
||||
Refund Types:
|
||||
|
||||
HFA Retail I/C Refund: Intercompany refunds to Retail org
|
||||
HFA VMF I/C Refund: Intercompany refunds to VMF org
|
||||
HFA Auto Customer Refund: Direct customer refunds
|
||||
Endorsement Types: For endorsement adjustment receivables
|
||||
Purpose: Determines which Oracle receivables transaction ID, org routing, and GL treatment applies
|
||||
Selection Logic: Based on refund recipient or adjustment nature
|
||||
|
||||
Chunk 10: Integration Workflows
|
||||
Metadata: type=useCases, consumers=multipleWorkflows
|
||||
Endorsement Adjustment Workflow: Retrieves endorsement config, creates Adjustment records with correct Oracle IDs
|
||||
Policy Cancellation Refund Workflow: Retrieves refund config, creates Adjustment record, applies to credit memo
|
||||
Configuration Management: Admin workflows retrieve and save configurations with automatic rollback
|
||||
Lambda Orchestration: Step Functions invoke these Lambda endpoints as discrete workflow steps
|
||||
|
||||
Chunk 11: Error Handling Patterns
|
||||
Metadata: concept=errorHandling, pattern=validation-first
|
||||
Validation Strategy: Fail-fast with comprehensive messages, multi-error accumulation
|
||||
Error Types:
|
||||
|
||||
ArgumentNullException: DTO null in GetConfiguration
|
||||
ArgumentException: Missing Name/Type, empty collection in SaveAsync
|
||||
Repository Exceptions: Propagated from DynamoDB layer
|
||||
Rollback Handling: SaveAsync automatically rolls back on repository failure
|
||||
|
||||
Chunk 12: Search Queries Supported
|
||||
Metadata: type=queryPatterns, purpose=RAGRetrieval
|
||||
Sample Queries:
|
||||
|
||||
"How do I retrieve Oracle adjustment configuration by name and type?"
|
||||
"What is the structure of adjustment configuration records?"
|
||||
"How does active status evaluation work for configurations?"
|
||||
"What Lambda functions are available for configuration management?"
|
||||
"How do I persist adjustment configurations?"
|
||||
"What rollback protection exists for configuration saves?"
|
||||
"What Oracle properties are stored in adjustment configurations?"
|
||||
"How are refund configurations categorized?"
|
||||
"What validation is performed on configuration retrieval?"
|
||||
"How do endorsement workflows use adjustment configurations?"
|
||||
"What is the difference between Retail, VMF, and Customer refund configurations?"
|
||||
"How does temporal validity work for adjustment configurations?"
|
||||
92
Books/Accounting/Starter.txt
Normal file
92
Books/Accounting/Starter.txt
Normal file
@@ -0,0 +1,92 @@
|
||||
StarterQuestions Module – RAG Knowledge Base
|
||||
|
||||
Chunk 1: Module Overview
|
||||
Metadata: module=StarterQuestions, type=guidance, location=CMH.HFA.Accounting.Orchestration/src/StarterQuestions, purpose=questionInspiration
|
||||
Purpose: Provides example questions and guidance for new users unfamiliar with the system. Helps users know what types of questions they can ask across modules.
|
||||
Scope: Covers Quote, Repository, Services, and StructuredTags modules with illustrative questions, plus general guidance on asking questions.
|
||||
Key Concepts: question examples, user guidance, RAG-friendly prompts, workflow understanding, module orientation.
|
||||
|
||||
Chunk 2: Quote Module Questions
|
||||
Metadata: domain=Quote, type=exampleQuestions, purpose=quotePreprocessing
|
||||
Sample Questions:
|
||||
• How are insurance quotes converted to Oracle customer records?
|
||||
• What Lambda function handles quote offered events?
|
||||
• How is the primary bill-to site configured?
|
||||
• How are customer addresses normalized for Oracle integration?
|
||||
• What default values are applied during quote preprocessing?
|
||||
• How is the AccountDescription field constructed?
|
||||
• When does customer record creation occur in the quote workflow?
|
||||
• What Oracle address set is used for HFA customers?
|
||||
• Which fields from the quote payload map to Oracle customer records?
|
||||
|
||||
Chunk 3: Repository Module Questions
|
||||
Metadata: domain=Repository, type=exampleQuestions, purpose=dynamoDBAccess
|
||||
Sample Questions:
|
||||
• How do I retrieve FIFO events by policy number?
|
||||
• What is the repository pattern implementation for DynamoDB?
|
||||
• How does conditional update work for FIFO event status?
|
||||
• What table naming convention is used for repositories?
|
||||
• How is TTL configured for completed events?
|
||||
• How does rollback work when saving adjustment configurations?
|
||||
• What concurrency control mechanisms prevent race conditions?
|
||||
• How are adjustment configurations stored in DynamoDB?
|
||||
• How do I query events by unique EventId?
|
||||
|
||||
Chunk 4: Services Module Questions
|
||||
Metadata: domain=Services, type=exampleQuestions, purpose=adjustmentConfiguration
|
||||
Sample Questions:
|
||||
• How do I retrieve an Oracle adjustment configuration by name and type?
|
||||
• How is active status evaluated for adjustment configurations?
|
||||
• How do I save all adjustment configurations at once?
|
||||
• What validation is performed during configuration retrieval?
|
||||
• How do endorsement workflows use adjustment configurations?
|
||||
• What is the difference between Retail, VMF, and Customer refund configurations?
|
||||
• Which Lambda functions are available for configuration management?
|
||||
• How does temporal validity work for adjustment configurations?
|
||||
• What Oracle properties are stored in adjustment configurations?
|
||||
|
||||
Chunk 5: StructuredTags Module Questions
|
||||
Metadata: domain=StructuredTags, type=exampleQuestions, purpose=glMapping
|
||||
Sample Questions:
|
||||
• How do I filter memo lines by commission percentage?
|
||||
• How are structured tags parsed and evaluated?
|
||||
• What dimensions can I use to filter GL account mappings?
|
||||
• How does temporal validity work for memo line configurations?
|
||||
• How do inclusions and exclusions (whitelist/blacklist) work?
|
||||
• How do I calculate distribution amounts for transaction lines?
|
||||
• Where do memo line configurations come from in the system?
|
||||
• How are GL account mappings assigned for credit memos or invoices?
|
||||
• How are Assurant vs non-Assurant rounding rules applied?
|
||||
|
||||
Chunk 6: General Guidance for Asking Questions
|
||||
Metadata: domain=AllModules, type=userGuidance, purpose=questionTips
|
||||
Guidance:
|
||||
|
||||
Think in terms of “What, How, When, Where”:
|
||||
What data is processed?
|
||||
How is it transformed?
|
||||
When in the workflow does this occur?
|
||||
Where is this information stored or sent?
|
||||
Consider module boundaries to narrow your questions:
|
||||
Quote → customer creation workflow
|
||||
Repository → data persistence and retrieval
|
||||
Services → Lambda endpoints and orchestration
|
||||
StructuredTags → GL account mapping and configuration rules
|
||||
Don’t worry about phrasing perfectly. Partial matches or paraphrases often work.
|
||||
Start with practical scenarios:
|
||||
“I want to know how a customer record is created from a quote.”
|
||||
“I need to find the configuration for a refund adjustment.”
|
||||
“I need to see how memo lines are filtered for commission calculations.”
|
||||
|
||||
Chunk 7: Sample RAG Queries
|
||||
Metadata: type=queryPatterns, purpose=RAGRetrieval, domain=AllModules
|
||||
Sample Queries:
|
||||
• “Show me how quote payloads become Oracle customer records.”
|
||||
• “Retrieve FIFO events for a specific policy number.”
|
||||
• “Explain the rollback mechanism for adjustment configurations.”
|
||||
• “Filter memo lines by action=Issue and percent=70.”
|
||||
• “What Lambda functions manage adjustment configurations?”
|
||||
• “How is the bill-to site set up for new customers?”
|
||||
• “What Oracle properties are stored for adjustment configurations?”
|
||||
• “How does temporal validity affect memo line selection?”
|
||||
• “How do inclusions and exclusions in structured tags work?”
|
||||
102
Books/Accounting/StructuredTags.txt
Normal file
102
Books/Accounting/StructuredTags.txt
Normal file
@@ -0,0 +1,102 @@
|
||||
StructuredTags Module – RAG Knowledge Base
|
||||
|
||||
Chunk 1: Module Overview
|
||||
Metadata: module=StructuredTags, type=overview, location=CMH.HFA.Accounting.Orchestration/src/StructuredTags
|
||||
Purpose: Configuration-driven GL account mapping for Oracle Fusion
|
||||
Functionality: Retrieves memo line configurations from Oracle OIC API, parses structured tags, filters by temporal validity and business criteria, generates transaction lines for invoices/credit memos with correct GL accounts
|
||||
Key Concepts: memo line lookup, structured tag parsing, GL account mapping, multi-dimensional filtering, temporal validity, distribution calculation
|
||||
|
||||
Chunk 2: MemoLookup Service
|
||||
Metadata: component=MemoLookup, type=service, interface=IMemoLookup, integration=OracleOIC
|
||||
Description: Retrieves and filters memo line configurations from Oracle Integration Cloud
|
||||
Methods:
|
||||
|
||||
GetMemoLookupAsync(DateTime): Retrieves active memo lines for a date, normalized to Eastern Time, filters by start/end validity
|
||||
GetMatchingLines(List<MemoLine>, string?, string?, string?, string?, string?, string?, string?, string?): Filters memo lines using up to 8 optional criteria (action, type, productType, org, product, state, percent, to)
|
||||
Integration: Extends OracleIntegrationBase, calls CHI_LOOKUP_API with LookupType=CHI_HFA_LOOKUPS
|
||||
Temporal Logic: Compares normalized ET against StartDateActive / EndDateActive for validity
|
||||
|
||||
Chunk 3: MemoLine Configuration Model
|
||||
Metadata: component=MemoLine, type=model, purpose=GLAccountConfiguration
|
||||
Description: Represents a single GL mapping rule with metadata and structured business rules
|
||||
Properties: Code, Meaning, Description, EnabledFlag, StartDateActive, EndDateActive, Tag (semicolon-delimited)
|
||||
Methods: IsAction, IsType, IsProductType, IsOrg, IsState, IsPercent, IsProduct, IsTo (dimension checks), GetDistributionPercentage (allocates percentage from tags)
|
||||
Pattern: Lazy initialization of StructuredTag parser for performance
|
||||
|
||||
Chunk 4: Structured Tag Format
|
||||
Metadata: component=StructuredTag, type=parser, format=keyValuePairs
|
||||
Format: Semicolon-delimited key=value pairs, comma-separated values
|
||||
Example: Actions=Issue,Renew;Types=Premium;Distribution=70;Org=Retail
|
||||
Syntax:
|
||||
|
||||
Inclusion: Key=Value1,Value2 (whitelist)
|
||||
Exclusion: Key=!Value1 (blacklist)
|
||||
Mixed: Supports inclusion and exclusion in same tag
|
||||
Parsing: Case-insensitive, splits semicolons then equals, comma-separated values become collections
|
||||
|
||||
Chunk 5: Filtering Dimensions
|
||||
Metadata: concept=filteringDimensions, type=businessRules, count=8
|
||||
Dimensions:
|
||||
|
||||
action – transaction operation type (Issue, Renew, Endorse, Cancel, BillingPlanChange, BillingTypeChange)
|
||||
type – line classification (Premium, Fees, AR Clearing)
|
||||
productType – insurance product filter (VSC, GAP, ESC)
|
||||
org – organization (Retail, HFA)
|
||||
product – specific product codes
|
||||
state – jurisdiction/state code
|
||||
percent – commission percentage
|
||||
to – recipient targeting (Assurant, others)
|
||||
Logic: Missing dimension = wildcard, present dimensions must match
|
||||
|
||||
Chunk 6: Distribution Calculation
|
||||
Metadata: component=MemoLineFilter, type=extensionMethod, purpose=amountAllocation
|
||||
Method: GetDistributionAmountByAssurantStatus(this MemoLine, decimal) – calculates allocated amounts with recipient-specific rounding
|
||||
Rounding Rules:
|
||||
|
||||
Assurant + 70/30: round up (Math.Ceiling)
|
||||
Non-Assurant + 70/30: round down (Math.Floor)
|
||||
Assurant + other splits: away-from-zero rounding
|
||||
Non-Assurant + other splits: banker's rounding (ToEven)
|
||||
Purpose: Prevents penny discrepancies, ensures totals net to zero
|
||||
|
||||
Chunk 7: TagValue Inclusion/Exclusion Logic
|
||||
Metadata: component=TagValue, type=collectionLogic, pattern=setMatching
|
||||
Behavior: Maintains separate inclusion/exclusion sets (HashSet<string>)
|
||||
Matching Logic:
|
||||
|
||||
Empty set → false
|
||||
Blacklist only → true unless excluded
|
||||
Whitelist only → true if included
|
||||
Mixed → true if included AND not excluded
|
||||
Parsing: Exclamation prefix = exclusion, unprefixed = inclusion
|
||||
|
||||
Chunk 8: Use Cases
|
||||
Metadata: type=useCases, consumers=multiple
|
||||
|
||||
Invoice Commission Processing: Filters by action/org/percent/state
|
||||
Endorsement Processing: Filters by action/type/productType
|
||||
Billing Changes: Queries BillingPlanChange or BillingTypeChange actions
|
||||
Cancellation Processing: Filters Cancel action with product/state
|
||||
Time-Based Retrieval: Uses transaction creation date to fetch historically accurate configurations
|
||||
|
||||
Chunk 9: Integration Architecture
|
||||
Metadata: type=architecture, pattern=configurationDriven
|
||||
Design: Separates business rules (OIC lookup tables) from code logic
|
||||
Benefits: Operations teams can modify GL mappings without code deployment; changes effective immediately; maintains audit trail with temporal validity
|
||||
Pattern: Specification pattern for multi-criteria filtering, lazy loading, permissive defaults
|
||||
Timezone Handling: Normalizes all dates to America/New_York for consistent evaluation
|
||||
|
||||
Chunk 10: Search Queries Supported
|
||||
Metadata: type=queryPatterns, purpose=RAGRetrieval
|
||||
Sample Queries:
|
||||
|
||||
"How do I filter memo lines by commission percentage?"
|
||||
"What is the rounding logic for Assurant payable lines?"
|
||||
"How are structured tags parsed and evaluated?"
|
||||
"What dimensions can I use to filter GL account mappings?"
|
||||
"How does temporal validity work for memo line configurations?"
|
||||
"What is the format of structured tags?"
|
||||
"How do exclusions work in memo line filtering?"
|
||||
"Where do memo lines come from in the system?"
|
||||
"How do I calculate distribution amounts for transaction lines?"
|
||||
"What is the difference between whitelist and blacklist filtering?"
|
||||
29
Books/Music/Articles/Gilmore.txt
Normal file
29
Books/Music/Articles/Gilmore.txt
Normal file
@@ -0,0 +1,29 @@
|
||||
ARTIST: David Gilmour
|
||||
GENRE: Rock, Art Rock, Blues Rock
|
||||
CONCEPTS: Target notes, pentatonic scales, melodic phrasing, ballad soloing
|
||||
SOURCE: Guitar Player Magazine
|
||||
TOPIC: Gilmour's melodic soloing approach using target notes
|
||||
|
||||
When I was an undergraduate jazz performance major struggling to get a handle on bebop improvisation, I remember my professor Dave LaLama admonishing me, <20>If you think playing over the fast tunes is hard, wait until you try playing over the ballads. What Dr. Lalama was trying to impart was that playing fast scales over fast changes could get you by, but playing melodically over slow tempos, when your note choices are much more exposed, would really test how well you could create meaningful phrases.
|
||||
|
||||
Although getting past the <20>this scale works over these chords<64> approach to improvisation generally requires hours of shedding, aiming for particular target notes (specific notes over specific chords) is an optimum strategy to maximize your practice time. In the realm of rock guitar, I can think of no greater master of the melodic target note technique while playing ballads than David Gilmour.
|
||||
|
||||
For the unfamiliar few, Gilmour was first enlisted by fledgling psychedelic rockers Pink Floyd in 1967, when original guitarist/vocalist Syd Barrett began having drug-induced struggles with mental health. The band experimented with various artistic approaches for several years before refining them into a cohesive <20>art rock<63> sound by the early <20>70s. The result was an unbroken streak of classic, genre-defining conceptual albums that included Meddle, The Dark Side of the Moon, Wish You Were Here, Animals, and The Wall. Although bassist/vocalist Roger Waters assumed the role of de facto bandleader and primary songwriter, Gilmour was a significant contributor who was praised for his soulful singing and expertly phrased lead playing that seemed to magically rework pedestrian blues phrases into sublimely evocative melodies. His focus on musicality over excessive displays of technique made him a musician<61>s musician of sorts and earned him a stellar reputation in guitar circles. When Roger Waters left Pink Floyd in the mid <20>80s, Gilmour surprised many by calmly assuming the leadership mantle, leading the band through another decade of chart-topping albums and stadium tours. Although Pink Floyd are not officially broken up (keyboardist and founding member Richard Wright died in 2008 while Gilmour and drummer Nick Mason joined forces with Ukrainian singer Andriy Khlyvnyuk on the one-off single <20>Hey Hey Rise Up<55> in 2022), Gilmour has mostly spent the last few decades concentrating on his solo career. His latest release, Luck and Strange, features his wife, novelist Polly Sampson, as primary lyricist and daughter Romany Gilmour as vocalist on several tracks. His recent tour filled arenas around the world.
|
||||
|
||||
Let<EFBFBD>s take a page from Gilmour<75>s hallowed playbook and see how incorporating a few well-chosen target notes can give our playing more melody and structure.
|
||||
|
||||
For the sake of simplicity, all the examples use the Gm/Bb major pentatonic scale forms. In my experience as a teacher, I find that most students can get a pretty solid handle on the root-position, Form-I minor pentatonic scale but struggle to incorporate the other four shapes while playing lead. One suggestion I give them is to work on playing the scales from the top notes down and focus on the four highest strings only. I believe this is a more logical and useful approach to incorporating these forms into your vocabulary.
|
||||
|
||||
Once you<6F>ve gotten a handle on the scales, try playing Ex. 5, which is loosely based on the extended introduction to Pink Floyd<79>s <20>Shine On You Crazy Diamond.<2E> We begin by soloing over a static Gm chord for four measures. As target notes, I<>ve chosen the root and 5th of the G minor chord ( the notes G and D, respectively). In the first measure, we<77>re starting in a minor pentatonic Form I with a bend up to the root of the Gm chord. A flurry of notes on beat 4 sets us up for the bend to the D in the second measure. The D note is again targeted in measure three<65>this time up an octave via a shift into the minor pentatonic Form II shape. Measure four aims for the G tonic up an octave, but ends with a bend that targets a C<>the root of the IVm (Cm) chord in the final measure. By focusing on target notes and connecting them with embellishing licks, your lead lines will have a much better sense of direction and melodic narrative. Also, by only targeting the root and 5th of the chord, the target note approach will be easily transferrable to songs in a G blues context (G pentatonic minor over a G major or G dominant tonality).
|
||||
|
||||
A further exploration of this approach, Ex. 6 begins with a two-beat pickup that resolves to the scale tonic G. This time however, the G isn<73>t serving as the root of the Im chord. Instead, it<69>s the 5th of Cm<43>the IVm chord. Employing the root of the pentatonic scale as the fifth of the IVm chord is a textbook Gilmour-ism and you can hear him use it to good effect on the extended intro to <20>Echoes<65> from Live in Gdansk. When approaching the C on beat 2 of the second full measure, bend up from the Bb on the 6th fret of the 1st string then slide up to the C on the 8th fret without releasing the bend or picking again. In the final measure, I<>ve introduced two Db notes, which serve as the b5 <20>blue note<74> of the scale and provide melodically compelling passing tones on the way to the G target note on beat 4.
|
||||
|
||||
Exclusively positioned in the Form-IV G minor pentatonic shape, Ex. 7 is based on a bluesy lick over the I chord in the first and third measures that alternately targets a resolution to the root of the IV chord (C ) and the root of the V chord (D7#9) in the second and fourth measures. Being able to resolve your lead phrases to the roots of the I, IV, and V chords on the fly is an essential skill ace improvisers like Gilmour have mastered.
|
||||
|
||||
Now let<65>s turn our attention to the Bb major pentatonic scale, which is the relative major of G minor. Play through the Form I and Form II shapes detailed in Ex. 8 and Ex. 9 below. You<6F>ll see I<>ve added an Eb to the scale (technically making them hexatonic scales). This allows us a bit more melodic freedom and<6E>most importantly<6C>gives us the root note of the IV chord.
|
||||
|
||||
Channeling the melodic mojo of Gilmour<75>s lead jaunts on Pink Floyd<79>s <20>Mother<65> and <20>Comfortably Numb,<2C> Ex. 10 targets chord tones from the I, IV, and V (Bb, Eb, and F) chords.
|
||||
|
||||
The muted-string rake in first measure helps <20>sting<6E> the F note, which is the 5th of the Bb. Measure two targets a G note which is the 3rd of the Eb. This same chord/target note pairing is repeated in the third and fourth measures, although the G is now down an octave. For the F and Eb chords of measures five and six, I<>ve mirrored a favorite Gilmour go-to: bending up to the 3rd of a chord then releasing and resolving to the root (an A resolving to an F for the F chord and a G resolving to an Eb for the Eb chord.) The final measure follows a melodic run down the Bb scale that ultimately resolves on the tonic. Be sure to pay attention to the intonation of all your bends, especially the half-step bend on the first beat of measure seven.
|
||||
|
||||
As a takeaway from this lesson, let<65>s strive to <20>Be Like Dave<76> and pay closer attention to target notes when soloing. Identify the roots of all the chords you<6F>re playing over in your scales and aim for them as the beginning and/or ending notes of your phrases. Think of these target notes as support beams that will provide structure to your lead lines and ultimately make them more melodically compelling.
|
||||
10
Books/Music/Articles/Gilmore2.txt
Normal file
10
Books/Music/Articles/Gilmore2.txt
Normal file
@@ -0,0 +1,10 @@
|
||||
ARTIST: David Gilmour
|
||||
GENRE: Rock, Art Rock, Blues Rock
|
||||
CONCEPTS: Target notes, pentatonic scales, melodic phrasing, ballad soloing
|
||||
SOURCE: Creative Guitar Studio
|
||||
TOPIC: David Gilmour Scale Concepts
|
||||
|
||||
The approach used by David Gilmour for the bulk of his scale ideas, is largely based upon the Blues scale and Minor Pentatonic, with a lot of reference to the Major 2nd degree from the Dorian mode.
|
||||
It's quick to hear on many of his solos, such as the one he plays in the Pink Floyd song, "Yet Another Movie." That solo is largely pentatonic thrashing for the most part, but it's also full of feeling.
|
||||
And, when we analyze the way he uses the; Blues, his bends and the obvious strong connection he has toward players like; Clapton, Jeff Beck and the Muddy Waters & John Lee Hooker sound...
|
||||
we end up with an instantly recognizable tone only associated to the David Gilmour style.
|
||||
34
Books/Music/Articles/Gilmore3.txt
Normal file
34
Books/Music/Articles/Gilmore3.txt
Normal file
@@ -0,0 +1,34 @@
|
||||
ARTIST: David Gilmour
|
||||
GENRE: Rock, Art Rock, Blues Rock
|
||||
CONCEPTS: Melody, Pentatonic Scales, Techniques
|
||||
SOURCE: Guitar World
|
||||
TOPIC: David Gilmour Techniques
|
||||
|
||||
Perhaps more than any other player, David Gilmour is the epitome of the lead guitarist who plays melodically and <20>for the song<6E>.
|
||||
|
||||
Though primarily a player with blues sensibilities, Pink Floyd<79>s progressive nature would see the younger Gilmour become an experimenter both sonically and melodically. Listen to Floyd<79>s recorded output, particularly from 1973<37>s Dark Side Of The Moon, nary a note is misplaced, every note counts and every phrase has a purpose.
|
||||
|
||||
And, though none of us has Gilmour<75>s musical ear, we can all learn from the way he approaches playing the guitar and writing songs. From his signature bending technique to his sublime note choice and phrasing there<72>s plenty in our lesson for you to try out. And once you<6F>ve had a go at our lesson, why not try writing some of your own Gilmour-style licks?
|
||||
|
||||
Here, we<77>re looking at a handful of scales. Get to grips with the shapes and you<6F>ll get a better understanding of his note choice and phrasing. First up is the minor pentatonic scale (shown here in D), which David uses to create those blues-influenced lead lines.
|
||||
|
||||
To add some sophisticated colour to the pentatonic sound he<68>ll often add E and B notes <20> creating the cooler, sweeter sounding Dorian mode. Our acoustic example is in the key of G major so the G major pentatonic will work here.
|
||||
|
||||
The key to clean tone solos such as Another Brick In The Wall, Pt. 2 is to select the neck pickup and dial in a fair amount of compression for extra smoothness and sustain. Pick lightly near the end of the fretboard for a fat, expressive tone.
|
||||
|
||||
David uses the good old minor pentatonic scale as the backbone of many of his solos, adding the odd extra note for colour. We<57>re using the D minor pentatonic scale here with major 2nd (E) and major 6th (B) intervals added . These notes can also be tasteful points to bend the string from.
|
||||
|
||||
Using doublestops (two notes at once) is a great way to introduce a little funky punctuation to proceedings, and it<69>s an approach Gilmour uses frequently. Check out Another Brick In The Wall, Pt. 2 at about 2:21 for a typical example of his phrasing. Our lick shows some of David<69>s typical shapes.
|
||||
|
||||
A fuzz pedal can be used to add a crazy amount of sustain. David used this effect to create the soaring solos in songs like Time and Comfortably Numb.
|
||||
|
||||
With their trademark drawn-out drawling sound, unison bends feature heavily in David<69>s lead style. Our example should give you the general idea. In each case, bend the third string until it reaches the pitch of un-bent note fretted on the second string. Vibrato is the icing on the cake.
|
||||
|
||||
Run Like Hell from The Wall is one of David<69>s signature dotted eighth note delay moments. For our simpler example we<77>ve set a tempo of 120 bpm with, therefore, a delay time of 375ms. For the full Run Like Hell effect, keep the number of repeats (aka feedback) fairly high for a cascading, layered sound.
|
||||
|
||||
We<EFBFBD>ve already shown you how David executes those huge wide-interval bends in tracks such as Another Brick In The Wall, Pt. 2 and Shine On You Crazy Diamond, but now it<69>s your turn to try it out over our backing track. We<57>ve stuck to three-semitone bends here, but you could try a four-semitone bend in bar 2 if you<6F>re feeling brave.
|
||||
|
||||
One of David<69>s signature sounds is the addition of vocal-like whammy bar vibrato on string bends and long held notes. He also uses the bar for <20>scoops<70>, such as in the repeating phrase idea we<77>ve included here in our tab example.
|
||||
|
||||
David is no stranger to the acoustic guitar and used it to great effect for songs like Wish You Were Here and Lost For Words. As with many of Gilmour<75>s melodic ideas, simplicity is the key here.
|
||||
|
||||
111
Books/Music/Articles/Gilmore4.txt
Normal file
111
Books/Music/Articles/Gilmore4.txt
Normal file
@@ -0,0 +1,111 @@
|
||||
ARTIST: David Gilmour
|
||||
GENRE: Rock, Art Rock, Blues Rock
|
||||
CONCEPTS: Melody, Pentatonic Scales, Techniques
|
||||
SOURCE: Kitrae
|
||||
TOPIC: Gilmour Playing Techniques, Picks, and Strings
|
||||
|
||||
It is almost cliche to say this, but a majority of what is percieved as Gilmour's tone and sound really does come from his fingers and playing. Gear selection helps, but much of the tone comes from the way the strings are picked, fretted, and how the tremolo is applied. Note choice is obviously a key to what makes a guitarist's style unique and identifiable, but you really need to invest the time to learn the picking, tremolo techniques, and phrasing to repicate the overall sound. David rarely lets a note just sit still. It is always moving or changing. Much of what people think is the gear making the tone sound good is simply the fingers making the gear sound good. For example, Big Muff's tend to be a bit harsh and fizzy, but when you add some fluidity and subtle harmonics to your playing it makes the Muff sound very un-Muff like, bringing something out of the it that you can't get with any other fuzz pedal. Add a sweet chorus or flange, some long delay, and you are in tonal heaven.
|
||||
|
||||
I spent a lot of time trying to be Eric Clapton, Jimi Hendrix, Pete Seeger, Leadbelly<6C>all sorts of other people on the guitar<61>and there was a moment when I actually liked something I played myself and started realizing that what I saw as my deficiencies actually could be turned into my qualities. - Gilmour interview by John Edginton in 2001
|
||||
|
||||
I think one thing about the fingers and the brain that I have been given is that the fingers make a distinctive sound. The fingers aren't very fast, but I think I am instantly recognizable. I can hear myself and just know that's me. And other people do, too. The way I play melodies is connected to things like Hank Marvin and the Shadows - that style of guitar playing where people can recognize a melody with some beef to it - Gilmour from Guitarist 2006
|
||||
|
||||
It's very hard to advise people, but in general I would say listen to as many different types of music as you can. And don't worry. Let everything come out of you in whatever way feels right, rather than wasting a lot of time and energy in trying to be someone else. That's what I'm trying to do myself. - Gilmour from Guitar World 1988
|
||||
|
||||
GILMOUR PLAYING STYLE
|
||||
It obviouly sounds better when you use the right gear, guitar, pickups, amp, and settings to replicaet Gilmour's guitar tones - but you still won't have that Gilmour sound and tone unless you take the time to learn his style of playing. As said above, most of what we hear as "tone" is from the playing. Using the right gear just brings out the colors and accents of the playing more.
|
||||
|
||||
I remember when I first began learning Gilmour songs around the time of his About Face (1984) album. I bought basically the same pedals David had at the time and a Strat style guitar, but I was frustrated that I could not get anything close to his sound. I learned the solos note for note, but I was just pressing frets, not actually playing in his style. Years later when I actually took the time to learn the subtleties of his style - finger and whammy tremolo, subtle picking harmonics, string bends, and phrasing - that sound came together rather easily. The correct gear was just tonal icing on top of that. That's why David says he can go into any music store and with just some basic gear he can still sound like himself - the gear does not make him sound like him. He does.
|
||||
|
||||
I love Dave<76>s guitar solos on DSOTM and on WYWH and on Animals and on The Wall and on The Final Cut. In my, albeit biased view, Dave<76>s solos on those albums constitute a collection of some of the very best guitar solos in the history of rock and roll. - Roger Waters on Twitter in 2023
|
||||
|
||||
FINGER AND WHAMMY BAR TREMOLO - Much of the beauty and soul of David's playing comes from his signature use of tremolo. Playing standard, one-speed tremolo on every note like 90% of the players out there do does not have even half the feeling that David can get out of one note with his style. He does not just generically shake a note when he adds tremolo. Sometimes he uses finger tremolo on the fret, other times he uses the whammy bar tremolo, and sometimes he goes from one right into the other on the same note.
|
||||
|
||||
David's use of finger tremolo is exceptional, but he only occasionally used the whammy bar tremolo in his early days with Pink Floyd. Like many Strat players, the bar was usually used for note dives or rapid tremolo effects, like in the solo in the funky part of Echoes from Live at Pompeii. During the recording sessions for Pink Floyd's The Wall album in 1978-79, his whole whammy bar style changed. He developed and refined a new technique that became a signature of his playing style from that point onward. He used a floating bridge so he could pitch notes up or down, and his whammy bar tremolo became just as smooth as his finger tremolo, but distinctly different. If you watch the live CBS promo videos for David's first solo album in 1978 and compare those to the live 1980 Pink Floyd vidoes from The Wall tour you can see how dramatically different this new approach to tremolo was.
|
||||
|
||||
David's whammy bar tremolo pitch was much deeper than his finger tremolo and he often kept the bar in his palm for whole solos. That technique was something David learned from watching one of his guitar heroes, Hank Marvin of the Shadows. Many of David's tremolo technniques can be traced back to similar things that Hank did, but David's version was uniquely different. This new style added much more feeling and emotion to his solos. The effect can be heard all over The Wall, in songs like Mother, What Shall We Do Now, Hey You, and the first Comfortably Numb solo in particular. David also used it to superb effect in his solos for Roger Waters The Final Cut album. He sometimes uses wide, deep, and slow tremolo for a more dramatic and emotional playing, like in the first Comfortably Numb solo. Other times he uses shorter, faster tremolo for a more intense, harder-edged feel, like in the second Comfortably Numb solo. He sometimes lets a note sustain before slowly starting the tremolo, other times starts right into the tremolo. He also sometimes goes from slow tremolo on one note to fast on the next, which adds another dynamic to his playing.
|
||||
|
||||
Like vibrato, for instance. I like a kind of refined version, which I do either with a finger or with a wang bar ... sometimes both at the same time. - David Gilmour, Guitar World, July 1988
|
||||
|
||||
As most guitarists know, David uses a lot of finger vibrato as well as the whammy bar, often at the same time. On the first solo of <20>Comfortably Numb<6D> he was exaggerating the effect quite dramatically. I asked if he thought it was too much and he replied, <20>No, I want it to sound drunk!<21> And there it was. - James Guthrie, producer/engineer on The Wall - Brain Damage 2013 interview
|
||||
|
||||
The tempo of the tremolo is very important. It really should be as close in time with the song tempo as possible. Most people can learn fast tremolo easily, but it takes some practice to learn how to accurately do slow tremolo and stay in time and pitch, especially with the tremolo bar on a Strat. Using a floating tremolo, the pitch from sharp to flat should be as smooth as possible, without going too sharp or too flat. Practice recording yourself playing a single note, intentionally trying to bend your tremolo up above the note pitch, sharp. Then do the same intentionally trying to go below the note pitch, flat. Then record yourself trying to do it right in the middle, not too sharp or too flat, and listen back to all three. If your correct attempt sounds more like the sharp or flat recordings, that indicates what you need to work on more. This was probably the most important part of applying Gilmour style temolo that I learned.
|
||||
|
||||
The bridge plates on Gilmour's Strats are resting on the body on the bridge screw side and raised on the saddle screw side.
|
||||
The 4th edition of the Black Strat book specifies the bridge floats 1.5mm off the body.
|
||||
|
||||
One part of David's whammy bar tremolo that took me a long time to figure out was if he was just pitching notes up, or pitching up and down evenly between flat and sharp. Non-floating bridges, like I believe David used in his early Pink Floyd days, can only pitch down. The bridges on David's Strats from around 1976 and later are floating just slightly off the body, so he can pitch up or down. What I noticed when trying to replicate certain solos is that he sometimes pitches up and down evenly, other times his tremolo is pitched slightly sharp, other times slightly flat. It really depends on the note in the solo.
|
||||
|
||||
When using the whammy bar it helps to have your bar cut short so you can hold the tip in your plam when playing, as David does. Some information on how to do this can be found here. It is not necessary, but it does help playing the way David does if you can hold it in your palm so it does not interfere with picking the strings.
|
||||
|
||||
|
||||
NOTE BENDS - Practice those bends! The Another Brick in the Wall II solo is a great one to study and master. David can bend and hold notes in exact pitch fluidly, and his bends are precise and in time with the song. He often bends up a whole or half step, holds, then bends up or down another step, then back to the original bend position before dropping the bend back to the original fretted note - sometimes adding his subtle tremolo to a few areas of these notes in mid bend! David also mixes slow bends with fast bends, but all in very precise time with the song tempo. It is rather easy once you get it down, and adds some great phrasing to your playing, but practice, practice, practice. Being slightly off key or out of time in a bend can ruin the effect.
|
||||
|
||||
PINCH SQUEALS AND PINCH HARMONICS - This is one of the most important keys to David's style of playing, and the one aspect of his sound that people most often confuse as something the gear David is using is doing. If you listen you will occasionally hear him add a pinch harmonic squeal to certain notes - such as the very first note in the Comfortably Numb outro solo, or many times in the Young Lust solo. David's sound very unique and subtle compared to the harsh, trebly pinch harmonics of some other players. Those pinch squeals are important to learn, and not very difficult for most players to master.
|
||||
|
||||
More important are the other harmonics that David applies. If you listen to his playing closely you will find that there are other subtle pick+thumb harmonics in many of the other notes in his solos, not just those pinch squeals. Many people mistake this as something the effects he uses are adding to the sound. Effects like chorus and the Big Muff can accent those harmonics, but David's fingers are where that sound is coming from, or more specifically, his thumb. When using a guitar pick he lets part of his thumb flesh brush across the string as he picks to add those subtle harmonic tonal variations to the notes. This harmonic phrasing and coloring is all over David's playing - to the extreme on just about every note in the Young Lust solo, and more of a subtle harmonic coloring in the Coming Back to Life or the On an Island solos. It is very evident in David's playing for Pink Floyd's Division Bell tour, heard on Pulse, and David's On an Island tour, featured in the Live in Gdansk film. Below are some examples of harmonic picking, comparing phrases with and without thumb+pick harmonics. I have exaggerated the effect to make the differences more apparent.
|
||||
|
||||
To learn this method of harmonic picking, first practice and master the less subtle pinch squeal effect. That is achieved by brushing the thumb across the string with the pick to get the harmonic squeal. We call it 'pinch harmonics' because you are pinching the pick and your thumb together as you pick hard, but it's really caused by both your thumb and pick touch the strings when you pick, so both touch the string at nearly the same time. When you have mastered being able to do that any time you want, then practice being more subtle with the thumb so you hear some of the harmonics, but not the harsher squeal. It often does not require hard picking to do this, and you will find that using more of the thumb than the pick creates one type of harmonic, and more of the pick than thumb another type. Once you have mastered that, then practice going back and forth between the subtler pinch harmonics and the harder pinch squeals until you can do it fluently.
|
||||
|
||||
You can do this type of picking with nearly any guitar pick, but it is much easier to do with smaller teardrop shaped picks than larger triangular shaped picks. Fender teadrop picks, size 354, are the best pick to use for this in my opinion. That is also what David uses.
|
||||
|
||||
FINGER PICKING - David has a very unique finger-picking style that he often uses. For examples, listen to Cluster One from the Division Bell, the intro to the live Strat Pack version of Coming Back to Life, or 5 A.M. from Rattle That Lock. That is all finger-picking on electric guitars. Rather than using specific fingers on specific strings, David mostly just uses his index finger as if it were a pick, with the occasional use of his thumb. He gets a wide variety of sounds just from the way he picks the string. Picking soft or hard, sliding the finger across the string, pulling off hard so the string "pops" like a compressive attack - these are all techniques that David uses to add color to the notes. He even gets subtle harmonics with his finger-picking. I learned how to finger pick traditionally, but I never got my playing to sound as expressive as David's. I thought it was something to do with the type of compressor David was using, or some other gear mystery. When I actually watched and studied how he finger picked, then re-learned how to pick just using my index finger, it all clicked into place. David often uses a compressor when finger picking on an electric, but most of the compression effects are really just from the way he picks.
|
||||
|
||||
Below are some examples of this finger picking style. Each time a phrase is repeated I change the way I am picking it to illustrate the wide variety of possible sounds. You can not only change the way the pick attack sounds, you can change the tone of the guitar simply by changing the way you pick.
|
||||
|
||||
"It think it's just pretty much him. He is obviously using a couple of effects, like a Big Muff and a delay, but it really is just his fingers, his vibrato, his choice of notes and how he sets his effects. I find it extraordinary when people think they can copy his sound by duplicating his gear. In reality, no matter how well you duplicate the equipment, you will never be able to duplicate the personality" - Gilmour's backline and gear tech, Phil Taylor
|
||||
|
||||
MORE NOTES VERSUS LESS - You will notice that David is not a very fast player, but at times he can sound more intense that someone playing a barrage of notes at light speed. That is because David adds all of these elements described above to his solos. Each note is always moving and doing something, adding to the complex feel some of his solos have. Just pressing frets abd picking the individual notes of those solos is not very complicated. When you add the tremolo, harmonics, bends, and other elements of David's playing, and how he plays over the music, it becomes something very complex and moving.
|
||||
|
||||
VOLUME SWELLS - This has nothing to do with the way you pick or play the guitar, but it is another part of David's playing that adds color to a solo. You kill the volume using a volume pedal, or volume knob on your guitar, pick a note, then raise the volume back up so the note fades in. This is also called a volume swell, and David uses a volume pedal for this effect, typically when he plays slide guitar. He often does this when bending or sliding a note up, and he is careful not to over use the effect. Listen to the slide guitar on Breathe and The Great Gig In The Sky from Dark Side of the Moon, or Beauty and A Boat Lies Waiting from Rattle That Lock for examples. Cluster One from the Division Bell and Evrika from The Endless River Deluxe Edition are examples of this technique with a regular guitar.
|
||||
|
||||
PICKS - The size, shape, and hardness of the guitar pick will affect how you play and your sound. David has used various shapes and sizes of picks throughout his career. He used Plain Herco heavy picks in the 1970s, but around the time of The Wall in 1980 he changed to small Fender teadrop picks, size 354, which are still his preferred electic guitar picks. He used Dunlop Herco Flex 75 1.01mm picks for his 2006 and 2015-16 tours, D'Andrea custom white 354 picks, as well as Fender 354 and Fender 351 style tear drop picks. David's pick attack on the strings can be very subtle or very hard, depending on the accent being applied to the note. When playing live, he is very hard on his picks. The edges look like they have been sawed into!
|
||||
|
||||
Gilmour Guitar Picks
|
||||
|
||||
Three standard sized pics (top) compared to Fender 354 tear drop shaped pics (bottom)
|
||||
|
||||
A few of David's used D'Andrea 354 picks from his 2016 tour showing the wear from his hard playing on fresh heavy gauge strings every show
|
||||
|
||||
As a general rule, larger picks work best for the early Pink Floyd material, and smaller picks work best for his later material and for applying harmonic tones. You can let the flesh of the thumb touch the string while picking using most picks, but tear dropped shaped picks, like the Fender 354 pick, are much easier to use for this than larger triangular shaped pics. The 354 pick is almost the same length as a standard pick, but not as wide and with a sharper point. They are sometimes difficult to find, but I have found the 354 "heavy" picks allow me to be the most expressive versus any other type pick.
|
||||
|
||||
STRINGS and STRING GAUGES FOR STRATS, TELE, AND LES PAUL - David Gilmour typically uses light gauge strings on he electric guitars. Over the years he has used various guitar string gauges on his Strats and various strings brands like Gibson, Rickenbacker, Ernie Ball, and GHS. For electrics he usually uses light gauge strings in the studio. When performing live he plays heavy handed and is harder on the strings so he uses a heavier gauge.
|
||||
|
||||
In the early 1970s David was using Gibson Sonomatic light gauge electric guitar strings on his Stratocasters. These were nickel wrapped, round wound strings.
|
||||
|
||||
Gibson Sonomatic Light Gauge - .011, .012, .019w, .028, .044, .050
|
||||
|
||||
Some time after that David used Ernie Ball light gauge strings, which I assume were the Regular Slinky nickel wound stings, not the Super Slinkys.
|
||||
|
||||
Ernie Ball Regular Slinkys .010, .013, .017, .026, .036, .046
|
||||
|
||||
In the late 1970s he was using a custom gauge set of Gibson Sonomatic on his Strats in the studio, and a set of different gauges when playing live.
|
||||
|
||||
late 1970s Strat gauges used in the studio - .010, .012, .016, .025, .034, .044
|
||||
|
||||
late 1970s Strat gauges used on stage - .010, .012, .016, .028, .038, .050
|
||||
|
||||
The Black Strat book contradicts this info, but I am going with what David actually said he used in a 1979 interview.
|
||||
|
||||
When recording The Wall in 1979 David changed to GHS Boomer strings and has continued to use them on his electrics. At the time I wrote this article David was still using GHS Boomers in non standard gauge sets for his Strats. GHS sold this exact set (as of 2008) as GB-DGF David Gilmour Signature Blue Set Electric Guitar Strings.
|
||||
|
||||
Strat string gauges from 1979 to now - .010, .012, .016, .028, .038, .048
|
||||
|
||||
David used a heavier gauge set on his Les Pauls. GHS sold this exact set (as of 2008) as GHS GB-DGG David Gilmour Signature Red Set Electric Guitar Strings.
|
||||
|
||||
Les Paul string gauges - .0105, .013, .017, .030, .040, and .050
|
||||
|
||||
Years ago I used to use regular light Gibson Sonomatics. I really liked them but they were a bit too heavy<76>.well, I didn't use the top end<6E>Let's see, and then I went to Ernie Balls because I could get them a bit lighter. And recently, I don't know quite when, Gibson started bringing out those Sonomatics in custom gauges, and I'm using those at the moment mostly...On my regular electric guitar at the moment (late 1978) I'm using the Gibsons (Sonomatics) again, which are 44, 34, 25, 16, 12, 10 gauges. It's pretty light for me. On stage actually with the Floyd I use heavier gauges, again on the bottom three I still use 10, 12, and 16 on the lighter strings, but I use 28, 38, 50 on the heavy bottom strings. That's for when I'm working on stage. I'm a bit heavy handed you know. - David Gilmour from a Steve Rosen interview for Guitar World conducted in late 1978 or early 1979
|
||||
|
||||
I use GHS strings, 10's - David Gilmour from Guitarist magazine June 1986
|
||||
|
||||
TELECASTER STRINGS - I do not think David has ever mentioned his Telecaster string gauges, but the Fitch/Mahon Comfortably Numb History of The Wall book lists Tele string gauges from The Wall period.
|
||||
|
||||
Telecaster string gauges from 1979 - .010, .012, .016, .024, .036, .044
|
||||
|
||||
LAP STEEL SLIDE GUITAR STRINGS - Around 2008 Phil Taylor said David currently used D<>Addario EHR360 half round jazz strings on his electric lap steels. These have a semi flat surface on the wound strings which creates a slightly smoother sound with a steel slide than regular round wound strings.
|
||||
|
||||
Lap Steel string gauges from 2008 - .013, .017, .026, .036, .046, .056.
|
||||
|
||||
|
||||
|
||||
69
Books/Music/Articles/Gilmore5.txt
Normal file
69
Books/Music/Articles/Gilmore5.txt
Normal file
@@ -0,0 +1,69 @@
|
||||
ARTIST: David Gilmour
|
||||
GENRE: Rock, Art Rock, Blues Rock
|
||||
CONCEPTS: Melody, Pentatonic Scales, Techniques
|
||||
SOURCE: Kitrae
|
||||
TOPIC: How To Sound Like David Gilmour
|
||||
|
||||
|
||||
David Gilmour is known for both incredible tone and highly emotive technique and note choice. He regularly appears in the top 3 (often at number 1) when guitar publications hold <20>best solo ever<65> polls. From iconic releases like Dark Side of the Moon, Wish You Were Here and The Wall through to 2006<30>s dreamy, reflective On An Island, great guitar tone and playing has been a hallmark of all his work. Rumor is he<68>s been back in the studio recently, so it seems like a good time to look at his sound.
|
||||
|
||||
Guitar
|
||||
|
||||
David<EFBFBD>s most famous guitar is his black Strat. This is the guitar you are hearing on the classic Pink Floyd albums of the seventies and early eighties.
|
||||
|
||||
Modifications to the guitar include a shortened tremolo arm, internal shielding, and a small recessed switch that adds the neck pickup to any selected configuration.
|
||||
|
||||
Over the years David and his tech Phil Taylor made other modifications that were eventually decided against- for example, fitting a Kahler tremolo, adding a humbucker between two of the pickups, and installing an XLR socket. These changes have been reversed with varying degrees of cosmetic success.
|
||||
|
||||
These days you can own an incredibly accurate replica of this guitar, by buying the Fender David Gilmour Signature Stratocaster. It includes all the wear and all the dodgy repair work <20> but if that<61>s not your style, they also do a guitar of the same spec but in <20>as new<65> (NOS <20> <20>new old stock<63>) condition.
|
||||
|
||||
Pickups
|
||||
|
||||
The neck and bridge pickups on the black Strat are the pickups that came with the guitar, but the bridge pickup is a custom pickup that Seymour wound especially for David, an overwound version of the SSL-1. The pickup in that guitar was called an <20>SSL-1C<31> (with the C standing for custom), but the pickup eventually went into production as the SSL-5. Putting the SSL-5 into your guitar is a surefire way to take a step towards the Gilmour sound. In fact, even if you<6F>re not chasing his tone, it<69>s a fantastic pickup in its own right that everyone should try. If you want flat polepieces for modern fingerboard radii then you should go for the SSL-6, or if you like a noiseless pickup, the STK-S6 is the Stack Plus version.
|
||||
|
||||
The difference between the SSL-5 and a regular Strat bridge pickup is more mids, more power and more <20>beef.<2E> It doesn<73>t lose the Strat character, but it has a more authoritative tone that<61>s great for lead work.
|
||||
|
||||
Strings
|
||||
If you had your own signature strings, a strap that used to belong to Jimi Hendrix, and the royalties from Dark Side of the Moon, you'd be this happy too.
|
||||
|
||||
If you had your own signature strings, a strap that used to belong to Jimi Hendrix, and the royalties from Dark Side of the Moon, you<6F>d be this happy too.
|
||||
|
||||
David uses a custom set of gauges on his Strat <20> .010, .012, .016, .028, .038, .048. These are available as a signature set of GHS Boomers. The first thing you<6F>ll notice here is that the B and G strings are lighter than you<6F>d normally see in a set of 10s. In fact, the G string is the same as you<6F>d normally see in a set of 9s! The effect this has is to make bending a little easier on those two strings. We<57>ll talk about bends a bit later on, but this is quite important.
|
||||
|
||||
The other unusual thing about the set is that the three wound things are slightly thicker. This gives them a bit more resistance when digging hard into chords, and a bit more punch when you get down to them in lead work. The set doesn<73>t feel unbalanced in the way that some hybrid gauge sets can, and it<69>s very comfortable to play on.
|
||||
|
||||
Pick
|
||||
|
||||
It<EFBFBD>s hard to find information on what picks David uses <20> in fact, he seems to change his mind quite a lot. My only advice on this would be not to use one that<61>s too soft, as you need to be able to dig in quite a lot.
|
||||
Amp
|
||||
|
||||
Here<EFBFBD>s where things start to get complicated. In the studio, David has used many different amps. A lot of his recorded tones actually result from plugging into several amps at once and recording the resulting mix. Still others result from taking a feed straight from the guitar to the desk, bypassing any amp completely. And yet it still sounds like him, on every track.
|
||||
|
||||
On stage, David usually uses his Hiwatt 100 watt heads into several 4<>12 cabinets. However, again, this frequently changes <20> he often uses the Alembic B2 preamp, feeding it into the power stage of the Hiwatts. My recommendation to start approaching the right tone is to find an amp that can be turned up very loud while staying clean. This is the basis of almost all of David<69>s tones.
|
||||
|
||||
Pedals
|
||||
David's 1994 Pulse rig, which handily doubles up as a life support machine for alien robot monsters.
|
||||
|
||||
David<EFBFBD>s 1994 Pulse rig, which handily doubles up as a life support machine for alien robot monsters.
|
||||
|
||||
Where do we even start? I wonder if an effects pedal has ever been made that David doesn<73>t own. Some of the rigs he has used on tour are actually clinically insane. Rather than list all these pedals for you here, I<>ll talk about what you can do to get yourself somewhere close without breaking the bank.
|
||||
|
||||
Even though probably the first pedal for lead tones that comes to mind when thinking about David<69>s tone is the Big Muff, the pedal that I actually found took my the furthest towards his sounds was a ProCo Rat. This has the advantage of being able to do reasonable impersonations of the Fuzz Face and the Big Muff as well as its own tones, so you get good value there.
|
||||
|
||||
On top of that, other essential items are a lush, whooshy phaser, a digital delay that will let you get up to at least 800ms of delay, a smooth overdrive pedal, a compressor, and possibly a chorus. You can research the exact units that David uses if you like, but I think it<69>s better to have devices that you feel comfortable using and that give a sound you like, because<73>
|
||||
|
||||
Playing Style
|
||||
|
||||
We all know the drill: you ask on the internet <20>how do I get that sound?<3F> and after three or four posts someone always pipes up <20>tone is all in the fingers<72>. If that<61>s true, why do these guys carry around tens of thousands of dollars worth of guitar equipment?
|
||||
|
||||
Well, I<>m sorry, but with David it<69>s actually true. You<6F>ve seen hints at this throughout the article <20> he can sound like himself with any pickup, with any pick, with any amp, with any set of pedals. Or without any of that stuff, just plugging the guitar straight into the desk.
|
||||
|
||||
The last few times I<>ve been lucky enough to receive a compliment along the lines of <20>you sound like Gilmour<75>, the first time I was playing a Tele with a Little 59 into an Orange Tiny Terror, and the second time I was playing a Les Paul with the Slash signature pickups into a modelled Marshall <20> both times, with no effects. And my rendition of the Comfortably Numb solo that I got the most awesome reaction ever for was an SG with EMGs in it, plugged through the RAT into a Fender Blues Junior. In this video of me attempting the Comfortably Numb solo, I<>m using a Seymour Duncan STK-S6 Custom Stack Plus (the noiseless version of the SSL-5), through a cheap modelling unit.
|
||||
|
||||
None of this is really anything like what David uses. So let<65>s look at what you can do to pick up that vibe in your playing.
|
||||
|
||||
First off <20> bending. David bends a lot. And we<77>re not just talking bending the seventh up to the root here. We<57>re talking one-and-a-half, two, even two-and-a-half step bends. Sometimes he plays an entire melodic lick by bending one note up and down through the different notes that make it up. There are lots of quarter bends. The one thing that is completely consistent is that the bends are absolutely to pitch. If you want to be able to play like David, then your number one priority is to be able to bend to pitch accurately, every time. In fact, you even need to be able to bend the string to pitch accurately before you play the note. So get practicing.
|
||||
|
||||
David<EFBFBD>s right-hand technique is quite aggressive on lead work. There is lots of digging in and almost every note will see a little skin touching the string after the pick. This means that there are lots of subtle harmonics on top of the main note.
|
||||
|
||||
There is no shredding here. David<69>s notes are individually chosen for effect and held for as long as they take to sink in. Vibrato is applied at various speeds and with left hand or tremolo arm depending on the desired effect. The only way to get a feel for this is to listen to the songs and then try to play them.
|
||||
1596
Books/Music/Articles/Satriani.txt
Normal file
1596
Books/Music/Articles/Satriani.txt
Normal file
File diff suppressed because it is too large
Load Diff
36
Books/Music/Articles/Satriani2.txt
Normal file
36
Books/Music/Articles/Satriani2.txt
Normal file
@@ -0,0 +1,36 @@
|
||||
ARTIST: Joe Satriani
|
||||
GENRE: Rock, Art Rock, Blues Rock
|
||||
CONCEPTS: Target notes, pentatonic scales, melodic phrasing, ballad soloing
|
||||
SOURCE: Guitar World
|
||||
TOPIC: Joe Satriani on scales
|
||||
|
||||
I was left to my own devices to practice. The idea behind learning scales I think was really revolutionized by my high-school music theory teacher who pointed out to me a couple of different things.
|
||||
|
||||
"He said that by the time I grew up, it may turn out I wasn't such a good guitar player that I thought I was gonna be, but I shouldn't let that hold me back. That the most important musical development was gonna take place in my mind. And that was limitless, so just keep feeding it, keep developing it.
|
||||
|
||||
"And one of the things that he did was to instruct me to sing scales to learn their intervals, to know what it was on paper, and to be able to generate it with my voice in any key that my vocal chords would allow. And then to look at it on the guitar, but not in terms of performance, but just in terms of learning what the space between each note really felt like.
|
||||
|
||||
"So I'm in G right now, I'm playing the notes of the G major scale. But he had me singing one, two, one, three, one, four, one, five, one, six, one, seven, one, one. And if those notes would be altered for a scale then I would say that altered interval. Like: one, flat second, one, major third, one, augmented fourth, one, augmented fifth... I would sing those notes in succession and I would have these little flash cards that had 15 scales on them. And I would learn how to play those scales in two octaves. I think that came from Billy Bauer.
|
||||
|
||||
"Billy Bauer was a local guitar teacher in Glen Cove. I'm not really quite sure how my mother discovered that he was in Glen Cove giving lessons. I don't think she knew that he used to play with Lennie Tristano. I certainly didn't. I didn't even know who Lennie was at the time. But I would appear down at the dinner table after practicing for hours and hours saying 'I've gotta find somebody to tell me what's going on. I'm just whipping myself to death and I don't know what I'm doing.
|
||||
|
||||
Billy gave me a lot of information. I took three lessons from him but I got back these little pamphlets on scales and arpeggios and things. It was a great way to organize it, especially for the singing exercise. Because I could just sort of forget about it and start singing, 'One, augmented fourth, one, five...' and really start to feel the difference in my body and hear it in my body.
|
||||
|
||||
"And then I could start to look at it but I kept thinking, 'I don't care what it looks like yet.' I'm just thinking about if I hear those two notes coming from a song on a radio I want my brain to say 'I know that! I recognize those two notes.'
|
||||
|
||||
"That was sort of like what Bill Wescott, my high-school music teacher, was trying to get at. He wanted me to do this 'one, major second, one, major third, one, perfect fourth, one, augmented fourth, one, perfect fifth...' And I would go through major, Dorian, Phrygian, Lydian, Mixolydian, natural minor scale, Locrian, Phrygian dominant, harmonic minor, melodic minor... I think that was about it around that time, that were all the scales that I was thinking about.
|
||||
|
||||
"I didn't bother with the pentatonic scales or anything less than seven-note scales. I don't even think I bothered with the diminished scale either. That was enough actually, just that. And I think I stayed in G because it was the only part of my vocal chords that would really hold steady long enough.
|
||||
|
||||
"Once I started to think about this long enough, I though. 'Well, I should be able to do it against a pedal note.' And I started doing that sitting down at a piano because it seemed a little bit easier. Because I wanted to do it in C or G or different keys and it's very hard on the guitar.
|
||||
|
||||
"So if I have this E drone and then I start playing the notes. And I just sort of soak it in and then I play something slightly different, which is a Lydian scale <20> major scale with a raised fourth. And I sort of register in my mind why is it so different than [the major scale]. With this note [drone E] it really made a difference because I could hear the tension and not so much tension. So when I did other [modes] it really made big difference to Phrygian dominant versus a Phrygian.
|
||||
|
||||
"And I was sort of making the fingering upas I went along. Since my high-school teacher was not a guitarist, he would look at me play guitar and go, 'It's so complicated, you just have to learn the notes everywhere.' And I thought 'That's easier said than done!' [Laughs] You just can't look at it and find them.
|
||||
|
||||
"But actually, yes, you can just look at it and find them. So why couldn't I? It's because I don't know the names of the notes. That was another big deal. And although I had a bunch of my time with all these things - learning the chords, learning the scales, singing the scales and the modes, figuring out the different fingerings, one octave, two octaves, three octave plus, all over, scales on one string at a time, learn the names of the notes on every string on every fret - I still had the school to go to and trouble to get in and all sorts of stuff. [Laughs]
|
||||
|
||||
"Eventually I said, 'Okay, I'm going to find E everywhere and I'll do that for five minutes. And then I'll do a couple of finger exercises. And then I'll do that where I'm singing [the intervals]. It was like building a giant structure starting with a big block of stone. I just though it's gonna work. Eventually there will be a beautiful statue here but I'm just gonna have to chip away at it bit by bit. But that's how I started it, that was really the beginning of working on those scales.
|
||||
|
||||
"The greatest resource now is just type it in and the internet will give you a million versions of where and how to play it. And just pick one, start from there. And most of the time the internet's correct, so you've got that going for ya.
|
||||
|
||||
35
Books/Music/Articles/Satriani3.txt
Normal file
35
Books/Music/Articles/Satriani3.txt
Normal file
@@ -0,0 +1,35 @@
|
||||
ARTIST: Joe Satriani
|
||||
GENRE: Rock, Art Rock, Blues Rock
|
||||
CONCEPTS: Pitch Axis
|
||||
SOURCE: Music Theory For Guitar
|
||||
TOPIC: Joe Satriani's Pitch Axis
|
||||
|
||||
The Emotions Behind Joe Satriani's Pitch Axis
|
||||
|
||||
guitar pitch axis
|
||||
|
||||
One of the compositional "secret weapons" of virtuoso guitarist Joe Satriani is the so-called Pitch Axis. In fact this is one of the ideas that made him famous, even if he is not the only one who uses it. I have seen good explanation of the Pitch Axis online, but I have not seen anybody tackling how Pitch Axis can help express specific emotions, so here we are.
|
||||
|
||||
The basic idea is simply to take all the modes that have the same root note (say, A) and freely use any chord from any of those modes in the same chord progression.
|
||||
|
||||
Here are the chords for the major scale modes with root A:
|
||||
|
||||
A Ionian: A Bm C#m D E F#m G#dim
|
||||
|
||||
A Dorian: Am Bm C D Em F#dim G
|
||||
|
||||
A Phrygian: Am Bb C Dm Edim F G
|
||||
|
||||
A Lydian: A B C#m D#dim E F#m G#m
|
||||
|
||||
A Mixolydian: A Bm C#dim D Em F#m G
|
||||
|
||||
A Aeolian: Am Bdim C Dm Em F G
|
||||
|
||||
A Locrian: Adim Bb Cm Dm Eb F Gm
|
||||
|
||||
Yes, those are just the modes of the major scale. To be complete, we should consider also the modes of melodic and harmonic minor scales, but we will start with the basics, ok? You can add the other modes later once you master those.
|
||||
|
||||
The problem is: now that you have all these modes and A LOT of chords to choose from, how do you use them to express emotion? How do you create shades of happiness and sadness, of brightness and darkness by using the modes?
|
||||
|
||||
Well, here's how:
|
||||
57
Books/Music/Articles/Satriani4.txt
Normal file
57
Books/Music/Articles/Satriani4.txt
Normal file
@@ -0,0 +1,57 @@
|
||||
ARTIST: Joe Satriani
|
||||
GENRE: Rock, Art Rock, Blues Rock
|
||||
CONCEPTS: Pitch Axis
|
||||
SOURCE: Wikipiedia
|
||||
TOPIC: Joe Satriani's Pitch Axis
|
||||
|
||||
Pitch axis theory refers to a way of thinking about chord progressions and modes, that was heavily used and popularized (though not invented) by the guitarist Joe Satriani.[1]
|
||||
|
||||
When composing using this concept, the pitch axis is simply a chosen note (a specific pitch), which is thought of as the tonic for a sequence of chords, which must all have this pitch as their root note. However, the other notes in each chord may be drawn from completely different keys. A mode (or any other scale) is chosen that fits with each chord, and also has the "pitch axis" as its root note. This sequence of scales is then used for creating a melody or improvising a solo.[2][3]
|
||||
|
||||
The term "pitch axis theory" has been criticized as misleading, as the above techniques do not represent a separate theory of music, and simply refer to the application of scales <20> according to standard music theory <20> over the common technique of a pedal point chord progression. However, the approach has also been praised as a useful compositional tool and perspective, which encourages experimentation with frequent key shifts and movements between parallel scales.[4]
|
||||
Examples
|
||||
Simple Example
|
||||
|
||||
As a simple example,[5] consider the following chord progression, which is non-diatonic (the chords are taken from multiple different keys), but all have root A.
|
||||
|
||||
| Amaj7(?11) | A7 | F/A | A7 |
|
||||
|
||||
In order to create a melody or improvise over this progression, we could use the following sequence of modes - which are different scales, but again, all have A as their root.
|
||||
|
||||
| A Lydian | A Mixolydian | A Aeolian | A Mixolydian |
|
||||
|
||||
In Satriani's terminology, this is a composition with a "pitch axis" of A
|
||||
Joe Satriani: "Not of This Earth"
|
||||
|
||||
Satriani chooses E Lydian, E Aeolian, E Lydian, and E Mixolydian as the modes to use for each chord.
|
||||
|
||||
The First chord, E?13, contains the 1st, 3rd, 6th, and 7th degrees of the E major scale. A common choice here might have been the Ionian mode (major scale), but Satriani prefers the Lydian scale with its ?4 - which is a perfectly acceptable choice as the chord itself does not specify ?4 or ?4.
|
||||
The Second chord is a Em7b6 with no 5th, making the E Aeolian mode (E-F?-G-A-B-C-D-E) a possible choice. However in the Context of coming/modulating from E Lydian, another option would be keeping the #4/b5 Bb note, implying a much more fitting "Aeolian b5" or "Locrian nat2" scale (aka Bayati Shuri/Kartzigar) which is the 6th mode of the Melodic Minor Scale.
|
||||
The Third chord is a EMaj7add6 with no 5th, where similarly, and given the Context, E Lydian mode could be used.
|
||||
The Fourth chord is a E7sus4 without a 3rd and 5th, where E Mixolydian mode could be used. Or again, Lydian Dominant if one wanted to preserve the #4/b5 note.
|
||||
Ultimately a number of different scales/modes could be used in the entirety of the progression,
|
||||
and it would be up to the personal taste/interpretation of the performer or composer to decide what would be a better fit, or which type of harmony to apply.
|
||||
Dream Theater: "Lie"
|
||||
The chord progression from "Lie" by Dream Theater.
|
||||
|
||||
The transition to the guitar solo in Dream Theater's "Lie" is built on Pitch Axis Theory.[citation needed] The bass and guitar play the root (B) while the keyboardist implies the chords in the progression: B5, Bm7, Bm6, G/B, A/B.
|
||||
|
||||
Ignoring the root, the scales used for each of these four chords would be B Aeolian (natural minor), B Dorian, C? Mixolydian, and E Aeolian, respectively. However, from the perspective of pitch axis theory, we consider all scales to have the B root - so we would say that the progression is B Aeolian, B Dorian, B Lydian, and B Phrygian.
|
||||
Joe Satriani: "Satch Boogie"
|
||||
|
||||
A more complex example is the bridge of "Satch Boogie", which still remains entirely in the "pitch axis" of A.[6]
|
||||
"Satch Boogie" bridge progression Play?.
|
||||
Artists who use pitch axis theory
|
||||
|
||||
These artists use pitch axis theory and shifting modes in their music.
|
||||
|
||||
Joe Satriani[5]
|
||||
Dream Theater
|
||||
Marty Friedman
|
||||
Guthrie Govan[7]
|
||||
Planet X[
|
||||
Yngwie Malmsteen
|
||||
Greg Howe
|
||||
Meshuggah
|
||||
Steve Lukather
|
||||
Nick Johnston
|
||||
11
Books/Music/Articles/Satriani5.txt
Normal file
11
Books/Music/Articles/Satriani5.txt
Normal file
@@ -0,0 +1,11 @@
|
||||
ARTIST: Joe Satriani
|
||||
GENRE: Rock, Art Rock, Blues Rock
|
||||
CONCEPTS: Pitch Axis
|
||||
SOURCE: Goodreads
|
||||
TOPIC: Joe Satriani's Pitch Axis
|
||||
|
||||
pitch axis theory, which I learned in high school from my music teacher Bill Westcott. It is a compositional technique that was actually developed at the turn of the last century, so this is something that had been around for a long time. I remember Bill saying, "I'm going to teach you this very cool compositional technique," and he sat me down at the piano, and he went, "Watch this: I'll hold this C bass note, and then I play these chords, and each chord will put me in a different key, but it will sound like C 'something' to you . . ." I was fascinated by it, because I thought, "That is the sound I'm hearing in my head." To me it sounded very "rock," because rock songs don't travel around in too many keys, and it was the antithesis of the modern pop music that had been around for fifty years. It was the total opposite of most commercial jazz, but not all jazz, as I learned when I started really listening closely to modern jazz. I realized, "Wow, John Coltrane is using pitch axis theory. Not only is he doing that, but he<68>s going beyond it with his 'sheets of sound' approach," where in addition to building modes in different keys off of one bass note, he was building modes off of notes outside the key structure as well. He had taken it a step further. But that<61>s not what I was looking for, except for in a song like "The Enigmatic," which has that sort of complete atonal-meetspsycho melodic approach. I was more interested in using the pitch axis where you really could identify with one key bass note, in a rock and R&B sort of fashion. Then all the chords that you put on top would basically put you in different keys. So on Not of This Earth, you have these pounding E eighth notes on the bass, and your audience says, "Okay, we're in the key of E." But the chords on top are saying, "E Lydian, E Minor, E Lydian, E Mixolydian in cyclical form." And I thought, "Well, this gives me great melodic opportunities, I'm not stuck with just the seven notes of one key. I've got seven notes for every different key that I apply on top of this bass note." And I just love that sound, so I applied it to quite a lot of my music.
|
||||
|
||||
|
||||
|
||||
|
||||
53
Books/Music/Articles/Satriani6.txt
Normal file
53
Books/Music/Articles/Satriani6.txt
Normal file
@@ -0,0 +1,53 @@
|
||||
ARTIST: Joe Satriani
|
||||
GENRE: Rock, Art Rock, Blues Rock
|
||||
CONCEPTS: Pitch Axis
|
||||
SOURCE: Goodreads
|
||||
TOPIC: Joe Satriani's Pitch Axis Theory and the Modal Method I: The simple concept
|
||||
|
||||
For those of you unaware of the details of pitch axis theory, the idea is basically to connect scales or their modes via an unchanging, or changing as little as possible, bass note. Used by classical composers such as Wagner and Stravinsky as well as modern guitarists like Joe Satriani and Steve Vai, it is a useful tool. But is it just another name for a technique that has been used before?
|
||||
|
||||
The first track on his first album, Not of this Earth, demonstrates Satriani<6E>s use of pitch axis theory perfectly, a pedal note of E, and four bars with a change of mode on each:
|
||||
|
||||
E Lydian <20> E Aeolian <20> E Lydian <20> E Mixolydian
|
||||
|
||||
Now, another way of putting it is that Satch is playing in the following keys but staying on the same bass note:
|
||||
|
||||
B Major <20> G Major <20> B Major <20> A Major.
|
||||
|
||||
Now we can see the interesting idea behind the sound of the modes, a large leap from B Major (5 sharps) to G Major (1 sharp), back again and then back twice in the circle of fifths to A Major (3 sharps).
|
||||
|
||||
It is quite an art form, choosing modes that suit the following or preceding of another, but we can see now the pattern:
|
||||
|
||||
Lydian <20> Aeolian <20> Lydian <20> Mixolydian
|
||||
|
||||
Now, none of this is new, there are plenty of instances where J. S. Bach uses multiple modes over the same bass note, notably over a bass that is acting as a dominant pedal.
|
||||
|
||||
Here is an example:
|
||||
|
||||
Mixolydian <20> Phrygian Major <20> Harmonic Major <20> Dominant #2 <20> Double Harmonic
|
||||
|
||||
The example above is played over a constant bass pedal, say A. That gives us the scales:
|
||||
|
||||
D Major <20> D Harmonic minor <20> A Harmonic Major <20> D Harmonic Major <20> D Hungarian minor
|
||||
|
||||
This sequence is typical of Bach as he has created a symmetrical sequence, with scales on D, D, A, D, D.
|
||||
|
||||
The Modal Method can help to take this concept one stage further. Say over a constant A bass I play the scales from the sequence:
|
||||
|
||||
G Major <20> A Melodic <20> E harmonic minor <20> B Neapolitan Major <20> A Neapolitan Major <20> E Locrian natural 7 (which is one of my favourite sequences). We get the modes in pitch axis theory of:
|
||||
|
||||
A Dorian <20> A Melodic <20> A Dorian #4 <20> A# Altbb3 <20> A Neapolitan Major <20> A Phrygian #4
|
||||
|
||||
I have simply used the sequence of scales that I have worked out using the tables in section I and played them over a static bass note. It<49>s that simple. NB: Although the A# in the Altbb3 mode clashes against the A bass note, it is consonant enough if resolved quickly and adds a good tension to the sequence.
|
||||
|
||||
I intend to add pitch axis examples as and when they come up and make a comprehensive list, so please add your ideas below in the comments. Here is a Steve Vai one, The Riddle:
|
||||
|
||||
E Lydian <20> E Lydian + - E Mixolydian <20> E Lydian
|
||||
|
||||
The scales are: B Major <20> B Melodic <20> A Major <20> B Major
|
||||
|
||||
So now we have:
|
||||
|
||||
1) Not of the Earth: Lydian <20> Aeolian <20> Lydian <20> Mixolydian (Satriani)
|
||||
|
||||
2) The Riddle: Lydian <20> Lydian + - Mixolydian <20> Lydian (Vai)
|
||||
2589
Books/Music/Books/Strange Beautiful Music - Joe Satriani.txt
Normal file
2589
Books/Music/Books/Strange Beautiful Music - Joe Satriani.txt
Normal file
File diff suppressed because it is too large
Load Diff
102
Books/Music/Theory/Augmented Chords.txt
Normal file
102
Books/Music/Theory/Augmented Chords.txt
Normal file
@@ -0,0 +1,102 @@
|
||||
Augmented Triads
|
||||
|
||||
An augmented triad is a 3-note chord built by stacking two major 3rds. The term <20>augmented<65> comes into play because the interval from the root of the chord to the 5th is an augmented 5th. Another helpful approach for constructing an augmented triad is to begin with a major triad and then raise the 5th by a <20> step. (Think: Root, 3rd, ?5).
|
||||
|
||||
Major 7(#5) Chords
|
||||
|
||||
Major 7(?5) Chords combine an augmented triad with a major 7th (Think: Root, 3rd, ?5, ?7). Building this chord on the note C, we get C<>E<EFBFBD>G?<3F>B. Common chord symbols for this chord include C?(?5), C?+ and Cmaj7(?5). You may even see this chord written as a slash chord, E/C.
|
||||
|
||||
Dominant 7(#5) Chords
|
||||
|
||||
Dominant 7(?5) Chords combine an augmented triad with a minor 7th. (Think: Root, 3rd, ?5, ?7). Building this chord on the note C, we get C<>E<EFBFBD>G?<3F>B?. Common chord symbols for this chord are C7+ and C7(?5). This chord is often associated with the Whole Tone Scale, particularly when the ?9 is included, as in C9(?5). However, C7(?5) is also found in the Altered Scale, where it can be voiced with either the ?9 or ?9.
|
||||
|
||||
Where do augmented chords come from?
|
||||
|
||||
Augmented chords can sometimes be confusing for music students. Certainly, one contributing factor is that out of the four types of triads (major, minor, diminished and augmented), the augmented triad is the only one that does not occur naturally within the major scale. Rather, the augment triad is a diatonic chord that occurs in both the Harmonic Minor Scale and the Melodic Minor Scale (ascending only). In both scales, the augmented triad occurs as the 3-chord (?+) as a result of the raised 7th scale degree.
|
||||
|
||||
The following examples notate and demonstrate the A Harmonic Minor Scale with its corresponding diatonic triads and 7th chords on piano. Notice that it is the 3-chord that produces the augmented chords (C+ and C?+).
|
||||
|
||||
Augmented Triads and Harmonic Function
|
||||
|
||||
Even though the augmented triad occurs in both the Harmonic Minor and Melodic Minor scales as a ?+ chord, it rarely functions this way. In other words, most augment triads you<6F>ll encounter won<6F>t make sense as a 3-chord of a minor key. More often, augmented triads will appear to be a ?+, ?+ or ?+ in a major key. However, as we<77>ll see later in this lesson, the augmented 5th interval usually results from chromatic voice leading over a major triad (?, ? or ?). In such cases, the presence of the augmented 5th interval is best understood as a passing tone.<2E>
|
||||
|
||||
In addition to the Harmonic Minor Scale and the Melodic Minor Scale, there is an additional scale that is also closely associated with augmented chords. The Whole Tone Scale produces augmented triads and dominant 7(?5) chords on each scale degree. For a deep dive on the Whole Tone Scale, check out our Quick Tip on Whole Tone Scale<6C>The Complete Piano Guide (Int).
|
||||
How many augmented triads are there?
|
||||
|
||||
Unlike most other chords which have 12 unique transpositions, there are only 4 unique augmented triads. This is because most other chords are asymmetrical (with the exception of fully-diminished 7th chords). However, the symmetrical structure of augmented chords means that all its chord tones are equidistant. In fact, the interval from the 5th of the chord up to the root is also a major 3rd. Therefore, an augmented triad divides the octave into 3 equal parts. Each part is comprised of 4 half-steps (or a major 3rd). Let<65>s take a closer look by constructing augmented triads on the roots C, D?, D and E?.
|
||||
|
||||
Symmetrical Structure = Limited Transpositions
|
||||
|
||||
Suppose we were to build an E Augmented triad. This chord is spelled E<>G?<3F>B?. However, these are the exact same notes as C Augmented (C<>E<EFBFBD>G?). In fact, C Augmented in first inversion (C+/E) is identical to E Augmented in root position. As a result, augmented triads don<6F>t have an identifiable root, as far as the ear is concerned. How can this be? Well, it<69>s similar to the fact that a chromatic scale doesn<73>t produce or imply any identifiable tonic note.
|
||||
|
||||
How to Spell Augmented Triads
|
||||
|
||||
Perhaps you<6F>re wondering why some of these augmented triads are spelled as such? One might protest, <20>Is it really necessary to spell B Augmented as B<>D#<23>F??? (Note, the ?? symbol represents <20>double-sharp<72>). Why not spell it B<>D#<23>G?<3F> The answer has to do with what we mean when we use the words <20>triad<61> and <20>root.<2E> Remember, triad does not mean a chord with 3 notes<65>that<61>s a frequent misconception. For example, a sus chord like Gsus4 (G<>C<EFBFBD>D) is not a triad, even though it contains 3 notes. Instead, the term triad means a 3-note chord that can be arranged as a stack of 3rds (Think: Root<6F>3rd<72>5th). Since Gsus4 cannot be arranged as a stack of 3rds, it is not a triad. However, it still has a root<6F>the note G. The root is the fundamental note upon which a chord structure is built. Sus4 chords use the structure 1<>4<EFBFBD>5.
|
||||
|
||||
So why can<61>t B Augmented be spelled B<>D#<23>G? Actually, in one sense it can, and in another it cannot. The notes B<>D#<23>G are still a triad because they can be stacked in 3rds. For example, if you rearrange the notes in the order G<>B<EFBFBD>D#, then you have a stack of 3rds with a clear root-position triadic shape. However, B is no longer the root! The root of G<>B<EFBFBD>D# is the note G, and that chord is named G Augmented.
|
||||
|
||||
So, is there a difference between G Augmented and B Augmented? The sound is identical when they are arranged with the same note on bottom. However, they come from different Harmonic Minor Scales. For example, G Augmented is the ?+ chord of E minor, whereas B Augmented is the ?+ chord of G? minor. In modern practice, most arrangers opt to spell augmented chords in a manner that is easiest to read.
|
||||
|
||||
Triad Pairs (Intermediate)
|
||||
|
||||
Professional jazz musicians frequently improvise by drawing on a melodic device known as triad pairs. To improvise with triad pairs, jazz pianists select two complimentary triads from a common scale and then create melodies that alternated back and forth between these triadic shapes.
|
||||
|
||||
Generally speaking, pianists prefer to pair adjacent triads from their source scale. This way, the triad pair will not have any common tones. In other words, one triad pair typically contains 6 unique notes. If you were to choose non-adjacent triads from the source scale, the resulting common tone(s) will reduce your total number of notes.
|
||||
|
||||
Let<EFBFBD>s consider an example of triad pairs to bring this concept into sharp focus. For this illustration, we<77>ll create a triad pair with two augmented chords: C Augmented (C<>E<EFBFBD>G?) and D Augmented (D<>F?<3F>A?). These two triads are adjacent chords drawn from the C Whole Tone Scale (C<>D<EFBFBD>E<EFBFBD>F?<3F>G?<3F>A?).
|
||||
|
||||
The first step to improvise with triad pairs is to practice <20>blocking<6E> the selected pair through each inversion. This familiarizes your hand with the shapes that you<6F>ll be alternating between when improvising with the selected triad pair. Therefore, we<77>ll start by playing C+ and D+ in root position. Then, we<77>ll continue to ascend through each inversion. Afterward, it<69>s a good idea to practice playing the triad pair in descending blocks too.
|
||||
|
||||
Source Scale for the Dominant 7(?13) Sound
|
||||
|
||||
You may be wondering where this voicing comes from? Notice that when we resolve A?7(?13) to D?6/9, our melodic line includes the ?9 and the ?9. In this case, the source scale for A?7(?13) is the A? Altered Scale, which is technically spelled as A?<3F>B??<3F>C?<3F>D??<3F>E??<3F>F?<3F>G?<3F>A?. However, that is a nightmare to try to read! Therefore, it<69>s much more helpful to think of the parent scale enharmonically as the G? Altered Scale, which is G?<3F>A<EFBFBD>B<EFBFBD>C<EFBFBD>D<EFBFBD>E<EFBFBD>F?. Do you see the C Augmented triad (C<>E<EFBFBD>G?) contained within the scale? Since this specific example is uses the Altered Scale, the chord symbol A?7alt is also appropriate here. If you are not yet familiar with the Altered Scale, be sure to check out our Quick Tip on The Altered Scale<6C>The Complete Guide.
|
||||
|
||||
In other cases, a Dominant 7(?13) chord symbol does not necessarily imply a fully altered sound. In fact, since this particular voicing only contains 4 notes (A?<3F>C<EFBFBD>E?<3F>G?), it<69>s impossible to pin down a specific source scale or parent scale without a musical context. For example, all of the following scales produce the Dominant 7(?13) sound.
|
||||
|
||||
Mixolydian?13 Scale: 1<>2<EFBFBD>3<EFBFBD>4<EFBFBD>5<EFBFBD>?6<>?7
|
||||
Phrygian Dominant Scale: 1<>?2<>3<EFBFBD>4<EFBFBD>5<EFBFBD>?6<>?7
|
||||
Altered Scale: 1<>?2<>?3<>?4<>?5<>?6<>?7
|
||||
Whole Tone Scale: 1<>2<EFBFBD>3<EFBFBD>?4<>?5<>?6
|
||||
|
||||
|
||||
et<EFBFBD>s find our C Augmented upper structure triad in each scale built on the root of A?. The notes of C+ are underlined for you.
|
||||
|
||||
A? Mixolydian?13 Scale: A?<3F>B?<3F>C<EFBFBD>D?<3F>E?<3F>F?<3F>G?
|
||||
A? Phrygian Dominant Scale: A?<3F>B??<3F>C<EFBFBD>D?<3F>E?<3F>F?<3F>G?
|
||||
G? Altered Scale: G?<3F>A<EFBFBD>B<EFBFBD>C<EFBFBD>D<EFBFBD>E<EFBFBD>F?
|
||||
A? Whole Tone Scale: A?<3F>B?<3F>C<EFBFBD>D<EFBFBD>E<EFBFBD>F?
|
||||
|
||||
Why is this important? There are two reasons. First, you want to be sure to associate the UST ?+ voicing with each potential chord symbol, which includes V7(?13), V7(?5) and V7alt. Secondly, when you are improvising, if you see a V7(?13) chord symbol, just know that it doesn<73>t always represent the same scale, so a little detective work is in order. You could choose any of the scales shown above. However, a good rule of thumb is to look to the melody to supply the harmonic context, as we did in the example above.
|
||||
|
||||
C Augmented UST Over Other V7(?13) Chords
|
||||
|
||||
Earlier, we discussed the symmetrical structure of augmented triads and examined how each augmented triad shape has three unique spellings. Since C Augmented has two other spellings, it should come as no surprise then that it can serve as a UST for two additional V7(?13) chords. If fact, the roots of the three V7(?13) chords that share C+ as an UST outline an augmented triad themselves. In other words, C+ works as a UST for C7(?13), E7(?13) and A?7(?13). Moreover, it<69>s not even necessary to change the spelling of the UST.
|
||||
|
||||
C Augmented UST Over Other V7(?13) Chords
|
||||
|
||||
Earlier, we discussed the symmetrical structure of augmented triads and examined how each augmented triad shape has three unique spellings. Since C Augmented has two other spellings, it should come as no surprise then that it can serve as a UST for two additional V7(?13) chords. If fact, the roots of the three V7(?13) chords that share C+ as an UST outline an augmented triad themselves. In other words, C+ works as a UST for C7(?13), E7(?13) and A?7(?13). Moreover, it<69>s not even necessary to change the spelling of the UST.
|
||||
|
||||
Augmented USTs for Lydian Dominants
|
||||
|
||||
We can also use Augmented USTs to voice the Lydian Dominant sound. We get these brilliant and uplifting dominant chords from the Lydian Dominant Scale. This scale uses the scale degrees 1<>2<EFBFBD>3<EFBFBD>?4<>5<EFBFBD>6<EFBFBD>?7.
|
||||
|
||||
Let<EFBFBD>s begin by considering the D Lydian Dominant Scale. This scale is D<>E<EFBFBD>F?<3F>G?<3F>A<EFBFBD>B<EFBFBD>C?<3F>D. Do you see the C Augmented triad (C<>E<EFBFBD>G?) contained in this scale? Since C+ naturally occurs in this scale, we can use it as an upper structure triad to voice the Lydian Dominant sound, just like we did for the Dominant 7(?13) sound. We simply need to add a D7 chord shell in the left hand.
|
||||
|
||||
You might ask, <20>But wait, won<6F>t this sound the same as the Dominant 7(?13) voicing?<3F> No, because the relationship of the augmented triad to the root of the dominant 7th chord is different, as we<77>ll soon see.
|
||||
|
||||
C Augmented UST Over Other Dominant 9(?11) Chords
|
||||
|
||||
Of course, there are two other Lydian Dominant chords that share C Augmented as and upper structure. They are G?9(?11) and B?9(?11). Notice that the roots of these related Lydian Dominants outline an augmented triad: G?<3F>B?<3F>D.
|
||||
|
||||
Let<EFBFBD>s play an example using G?9(?11), shown below. Notice, for this chord, the C Augmented upper structure is not spelled quite correctly, enharmonically speaking. Technically, the 7th of G?7 is the note F?, not E?. However, it is much easier to read this voicing by spelling the right hand as a C+ upper structure and the left hand as a Root+3rd chord shell.
|
||||
|
||||
Since the C Augmented triad is built on the #4 of G?7, we can call this a UST #?+. However, what key has G?7 as a 5-chord? How about C? major<6F>yuck! Therefore, we<77>ll spell this Lydian Dominant enharmonically as F?9(?11) and we<77>ll resolve it to B major. However, our UST is not #?+ anymore. It is now a UST ??+. This is a minor detail, but one worth noting.
|
||||
|
||||
We have one more Lydian Dominant chord that can use C Augmented as and upper structure. Let<65>s play our augmented UST for B?9(?11).
|
||||
|
||||
Augmented USTs for Minor-Major 7th Chords
|
||||
|
||||
We can also the augmented triad as a UST for Minor-Major 7th Chords. Jazz pianists frequently substitute minor-major 7th chords in place of regular minor 7th chords, especially in contexts in which the minor chord is not a 2-chord. For example, pianists sometimes play a I<>? as the final chord of a minor 2-5-1 progression. In addition, jazz pianists frequently use inner voice movement to create voice leading from R??7??7??6. This melodic gesture passes through a minor triad, a minor-major 7th chord, a minor 7th chord and a minor 6th chord, all with the same root (see example below).
|
||||
|
||||
Let<EFBFBD>s play Am(maj7) using a C Augmented UST. Our right hand will play C<>E<EFBFBD>G? while our left hand plays an open 5th with the notes A and E. Since our right is playing the ?7 (the note G?), we must be sure to not play the ?7 in our left hand (the note G?). However, you can play the ?6 in the left hand if you want.
|
||||
|
||||
313
Books/Music/Theory/Basic Music Thoery For Beginners.txt
Normal file
313
Books/Music/Theory/Basic Music Thoery For Beginners.txt
Normal file
@@ -0,0 +1,313 @@
|
||||
|
||||
Basic Music Theory for Beginners <20> The Complete Guide
|
||||
|
||||
This basic music theory guide looks at fundamental concepts musicians use to understand, analyze, and create music.
|
||||
desk with laptop and sheet music
|
||||
What is Music Theory?
|
||||
|
||||
|
||||
|
||||
Music theory is a practice musicians use to understand and communicate the language of music. Musical theory examines the fundamentals of music. It also provides a system to interpret musical compositions. Music theory is a great tool for electronic and pop musicians to elevate tracks.
|
||||
|
||||
|
||||
|
||||
For example, basic music theory defines the elements that form harmony, melody, and rhythm. It identifies compositional elements such as song form, tempo, notes, chords, key signatures, intervals, scales, and more. It also recognizes musical qualities such as pitch, tone, timbre, texture, dynamics, and others.
|
||||
How to Learn Music Theory?
|
||||
|
||||
Music theory is a complex and extensive subject. There are several practices, disciplines, and concepts.
|
||||
|
||||
Best to learn music fundamentals first before exploring advanced music theory. The building blocks that form musical compositions include:
|
||||
|
||||
Harmony
|
||||
Melody
|
||||
Rhythm
|
||||
|
||||
Solidly understanding these three core elements will help you learn basic music theory.
|
||||
What Is Harmony in Music?
|
||||
|
||||
Harmony is when multiple notes or voices play simultaneously to produce a new sound. The combined sounds in harmonies complement one another and sound pleasing.
|
||||
|
||||
Chords and chord progressions are examples of harmony. A chord has three or more notes that play at the same time. The chords and chord progressions in a piece of music support or complement the melody.
|
||||
|
||||
Combining vocal parts also creates harmony. The combined voices of a choir are a perfect example. The multiple voices that make up a choir blend to make a harmonious sound.
|
||||
|
||||
However, not all harmonies are pleasing to our ear. There are two main types of harmony: dissonant and consonant .
|
||||
|
||||
Dissonant harmony adds notes that do not sound pleasant when played together. The result adds tension and makes the chord sound unstable. This tension releases by resolving to consonant chords. Dissonant interval examples are seconds, sevenths, and ninths.
|
||||
Consonant harmony sounds stable and pleasing. All the notes in a consonant chord have intervals that play nicely together. Constant chords also transition smoothly with one another in a progression. Consonant interval examples are unison, thirds, fifths, and octaves.
|
||||
|
||||
Musicians combine consonant and dissonant harmonies to make the music more exciting and intriguing.
|
||||
What Is Melody in Music?
|
||||
|
||||
Melody is a succession of notes or voices arranged into a musical phrase. A song<6E>s melody is often the most memorable and recognizable part.
|
||||
|
||||
Melodies can be created with instruments or vocals. They have two or more notes in a sequence that sound musically pleasing. Most compositions consist of multiple melodies that repeat.
|
||||
|
||||
The two primary elements of a melody are pitch and rhythm :
|
||||
|
||||
Pitch is the audio vibration produced by an instrument or voice. It<49>s how high or low a note will sound. Arranging these pitches in a series creates a melody.
|
||||
Rhythm or duration is the length each pitch will sound. These durations are divided into beat divisions like whole notes, half notes, quarter notes, triplets, etc.
|
||||
|
||||
Melodies also have two types of melodic motion: conjunct or disjunct .
|
||||
|
||||
Conjunct motion is when notes move by whole or half steps. Conjunct is also the most natural and comfortable to play and sing. There are shorter leaps between notes.
|
||||
Disjunct motion has larger leaps between notes. Large interval leaps between notes can make the melody difficult to play or sing. Disjunct motion is also less memorable and smooth sounding.
|
||||
|
||||
Musicians combine conjunct and disjunct motion to give melodies more variation and interest.
|
||||
What Is Rhythm in Music?
|
||||
|
||||
Rhythm is an essential element of music with more than one meaning. For example:
|
||||
|
||||
Rhythm is a recurring movement of notes and rests (silences) in time. It<49>s the human perception of time.
|
||||
Rhythm also describes a pattern of strong and weak notes or voices that repeat throughout a song. These patterns can be created with drums, percussion, instruments, and vocals.
|
||||
|
||||
The basic elements that comprise musical rhythm include:
|
||||
|
||||
Beat <20> A repeating pulse that underlies a musical pattern
|
||||
Meter <20> A specific pattern of strong and weak pulses
|
||||
Time Signature <20> The number of beats per measure
|
||||
Tempo (BPM) <20> Indicates how fast or slow a piece of music plays
|
||||
Strong and Weak Beats <20> Strong beats are the downbeats, and weak beats are the offbeats
|
||||
Syncopation <20> Rhythms that accent or emphasize the offbeats
|
||||
Accents <20> Refers to the intensity or emphases placed on notes
|
||||
|
||||
Understanding rhythm will help you create great harmonies and melodies.
|
||||
|
||||
Also, the rhythm section or pulse propels a piece of music. It acts as the rhythmic backbone for other musical elements.
|
||||
The Benefits of Music Theory: Why Study Music Theory?
|
||||
|
||||
Learning basic music theory is essential for enhancing creativity and developing musical awareness. It<49>s a challenging but rewarding set of skills to learn.
|
||||
|
||||
Knowing how music works will make the music production process easier and help you become an effective music producer.
|
||||
|
||||
Is learning music theory required? No. However, you can benefit from learning some aspects of music theory.
|
||||
|
||||
For example, learning basic music theory will:
|
||||
|
||||
Improve your musical development
|
||||
Help you understand how music works
|
||||
Help you break through creative blocks
|
||||
Make it easier to build chord progressions and melodies
|
||||
Help you make informed composition decisions
|
||||
Help you achieve expression and evoke emotion
|
||||
Improve your critical listening skills
|
||||
Speed up your workflow
|
||||
Improve your musical form skills
|
||||
Make it easy to communicate with other musicians
|
||||
Deepen your appreciation for music
|
||||
Improve your improvisation skills
|
||||
Improve your song arrangement skills
|
||||
Help you discover new creative possibilities
|
||||
|
||||
Note : Musical theory is not a set of rules or guidelines you must follow. It<49>s only a tool to help you understand and explain how music works.
|
||||
The Fundamentals of Music Theory (Music Theory for Dummies)
|
||||
|
||||
This basic music theory for beginner<65>s guide examines the core music fundamentals. It also provides insight into the basic building blocks of music that form harmony, melody, and rhythm.
|
||||
Musical Notes and Intervals
|
||||
|
||||
Let<EFBFBD>s start this music theory for beginner<65>s guide by going over harmony and melody. This section describes all the available notes and the specific relationships between them.
|
||||
A piano keyboard with the letters of the alphabet on it
|
||||
The Music Alphabet
|
||||
|
||||
Notes are the building blocks for all music. The musical alphabet consists of seven letters: A, B, C, D, E, F, G . Each note has a unique pitch.
|
||||
The 12 Keys of Music
|
||||
|
||||
There are 12 notes on the piano keyboard: A, A#/B?, B, C, C#/D?, D, D#/E?, E, F, F#/G?, G, G#/A? .
|
||||
|
||||
The same 12 notes repeat upwards and downwards in octaves.
|
||||
White Keys
|
||||
|
||||
The white keys on a piano play the <20>natural<61> notes in a scale: A, B, C, D, E, F, G .
|
||||
|
||||
Playing only white keys places you in either the key of C major or A minor.
|
||||
Black Keys
|
||||
|
||||
The black keys on a piano play the <20>flat<61> and <20>sharp<72> notes in a scale: A#/B?, C#/D?, D#/E?, F#/G?, G#/A? .
|
||||
|
||||
Each note has a symbol: ? for flat and # for sharp. Playing a combination of white and black keys allows you to write in all available key signatures.
|
||||
Intervals
|
||||
|
||||
An interval is a distance between two notes. There are several intervals. Measure these intervals by the number of half steps, whole steps, and their position in the scale.
|
||||
|
||||
A half step interval is one semitone
|
||||
A whole step interval is two semitones
|
||||
Two half steps make a whole-step
|
||||
|
||||
Intervals are also the foundation of both harmony and melody. Playing two or more notes at the same time creates harmonic intervals (chords). Playing single notes in a sequence makes melodic intervals (melodies).
|
||||
|
||||
Furthermore, we describe intervals by number (distance) and prefix (quality). The interval number represents the number of half-steps between two notes. These numbers are 1st (unison), 2nd, 3rd, 4th, 5th, 6th, 7th, and 8th (octave) .
|
||||
|
||||
Lastly, intervals have using a prefix to describe their quality. The five interval qualities are major (M), minor (m), perfect (P), augmented (A), and diminished (d) .
|
||||
Octaves
|
||||
|
||||
Octaves are the next highest or lowest pitch of the same note. The interval between a note and a note double its frequency is an octave. For example, an octave up from C1 on a piano is C2. An octave down would be C0.
|
||||
|
||||
There are 12 semitones in the octave. These pitches repeat in the same order throughout the range of human hearing.
|
||||
Key Signatures
|
||||
|
||||
Key signatures tell you what notes in a scale are sharp (?) or flat (?). There are twelve key signatures, each derived from the twelve available notes.
|
||||
|
||||
Key signatures also help identify the key of a song, which is the tonal center. For example, a song in the key of A minor uses notes from the A minor scale.
|
||||
Music Scales and Modes
|
||||
|
||||
Musical scales form the building blocks of music. Understanding musical scales and their functions is essential when learning basic music theory.
|
||||
|
||||
This section looks at the two most common scales, their scale degrees, and the seven music modes.
|
||||
A table showing the key of a song
|
||||
Music Scales
|
||||
|
||||
A music scale is a set of notes within an octave arranged by their pitch. The ascending or descending interval relationships among the note pitches define each scale. Moreover, the notes from a scale form melodies and harmonies.
|
||||
|
||||
There are several types of scales. However, the two main types are the major scale and the minor scale. You can build both major and minor scales from any note. How you use them depends on the pattern of intervals you use.
|
||||
Major Scales
|
||||
|
||||
There are twelve possible natural major scales. Natural major scales are bright, uplifting, and happy sounding.
|
||||
|
||||
The seven notes in all major scales follow the same interval pattern: W-W-H-W-W-W-H (whole-whole-half-whole-whole-whole-half) .
|
||||
Minor Scales
|
||||
|
||||
Natural minor scales are dark, sad, and emotional sounding. The seven notes in all minor scales follow the same interval pattern: W-H-W-W-H-W-W (whole-half-whole-whole-half-whole-whole) .
|
||||
|
||||
There are twelve possible natural minor scales. In addition, there are three variations of the minor scale: natural, harmonic, and melodic.
|
||||
Scale Degrees
|
||||
|
||||
Each note of a scale has a specific name related to its function, called a scale degree. The name is the function, and a number indicates its position on the scale.
|
||||
|
||||
There are seven scale degrees. These names apply to all major and minor scales. Learning more about these functions takes us into advanced music theory. For now, it<69>s good to know the names:
|
||||
|
||||
1st <20> Tonic
|
||||
2nd <20> Supertonic
|
||||
3rd <20> Mediant
|
||||
4th <20> Subdominant
|
||||
5th <20> Dominant
|
||||
6th <20> Submediant
|
||||
7th <20> Leading Tone
|
||||
|
||||
Music can create and release tension. The function of a scale degree relates to the amount of tension created. It also helps you decide what note(s) should follow to resolve the tension.
|
||||
|
||||
Moreover, remembering the different pitches in major and minor scales is difficult. Referring to the steps of the scale by numbers rather than notes makes it easier to remember.
|
||||
Music Modes
|
||||
|
||||
|
||||
|
||||
Musical modes are scales derived from a parent scale. There are seven music modes.
|
||||
|
||||
|
||||
|
||||
Each mode is a slight variation of a scale. They use all the same notes and interval patterns as the parent scale.
|
||||
|
||||
The main difference is the root note used to build the scale. Starting a scale on a different note defines the tonal center, giving it distinct melodic characteristics.
|
||||
|
||||
The seven musical modes are:
|
||||
|
||||
I <20> Ionian (major scale)
|
||||
ii <20> Dorian (major scale starting on the 2nd degree)
|
||||
iii <20> Phrygian (major scale starting on the 3rd degree)
|
||||
IV <20> Lydian (major scale starting on the 4th degree)
|
||||
V <20> Mixolydian (major scale starting on the 5th degree)
|
||||
vi <20> Aeolian (natural minor scale or major scale starting on the 6th degree)
|
||||
vii <20> Locrian (major scale starting on the 7th degree)
|
||||
|
||||
Learning musical modes goes beyond basic music theory and is more advanced. However, getting familiar with these terms and basic functions is helpful.
|
||||
Counterpoint
|
||||
|
||||
Counterpoint is the relationship between two or more melody lines played at the same time. These melodies or voices work together to create pleasant-sounding harmonies.
|
||||
|
||||
The melodies that create counterpoint are dependent on each other to create harmony. However, they are independent in rhythm and contour.
|
||||
Chords and Chord Extensions
|
||||
|
||||
Chords are the harmonious building blocks of music. They evoke emotion and provide the foundation for creating melodies.
|
||||
|
||||
Knowing how to build chords and how they interact with each other is essential when learning music theory. This section looks at basic chord types, chord extensions, and inversions.
|
||||
Music Producer Playing Mini Keyboard
|
||||
Photo by Toan Nguyen
|
||||
Musical Chords
|
||||
|
||||
A chord is a combination of two or more notes played at the same time. They<65>re built off a single starting note called the root.
|
||||
|
||||
You can create chords from all twelve notes. There are also four basic types of chords in music:
|
||||
|
||||
Major <20> Has a major third and a perfect fifth above the root
|
||||
Minor <20> Has a minor third and a perfect fifth above the root
|
||||
Diminished <20> Has a minor third and a diminished fifth above the root
|
||||
Augmented <20> Has a major third and an augmented fifth above the root
|
||||
|
||||
The chords and chord progressions in a piece of music support or complement the melody.
|
||||
Triad Chords
|
||||
|
||||
The most basic chords are triads. A triad is a chord made of three notes. Triads have a root note, a third (four semitones above the root), and a perfect fifth (seven semitones above the root).
|
||||
|
||||
Triads are also the foundation for more complex chords. For example, you can create seventh and ninth cords by adding notes above a tried.
|
||||
Seventh Chords
|
||||
|
||||
A seventh chord adds a note above the basic triad. Seventh chords have a root note, a third, a perfect fifth, and a seventh.
|
||||
|
||||
For example, a C major seventh has the notes: C<>E<EFBFBD>G-B. There are also five main types of seventh chords: major, minor, dominant, diminished, and half-diminished.
|
||||
Major Chords
|
||||
|
||||
Major chords have a root note, a major third, and a perfect fifth. A chord with these three notes alone is a major triad.
|
||||
|
||||
For example, a C major triad has the notes: C-E-G. You can also add notes to build more complex chords.
|
||||
Minor chords
|
||||
|
||||
Minor chords have a root note, a minor third, and a perfect fifth. A chord with these three notes alone is a minor triad.
|
||||
|
||||
For example, a C minor triad has the notes C-E?-G. You can also add notes to build more complex chords.
|
||||
Diminished Chords
|
||||
|
||||
Diminished chords sound tense, dissonant, and dramatic. They have a root note, minor third, and a diminished fifth (six semitones above the root).
|
||||
|
||||
For example, a C diminished triad has the notes: C-E?-G?.
|
||||
Augmented Chords
|
||||
|
||||
Augmented chords sound dissonant, unsettling, and mysterious. They have a root note, major third, and an augmented fifth (eight semitones above the root).
|
||||
|
||||
For example, a C augmented triad has the notes: C<>E<EFBFBD>G#.
|
||||
Chord Extensions
|
||||
|
||||
|
||||
|
||||
Chord extension s are notes added to the basic triad beyond the seventh. These notes extend into the next octave. There are four chord extensions: the 9th, 11th, and 13th .
|
||||
|
||||
|
||||
|
||||
Extended chords create a richer, more harmonically complex sound than basic major and minor triads. They also provide additional voice leading possibilities, which makes chord progressions sound more interesting.
|
||||
Chord Inversions
|
||||
|
||||
Chord inversions are variations of the same chord. Transposing the bottom note in a chord to the next octave creates an inversion.
|
||||
|
||||
There are two main chord inversions: first inversion and second inversion .
|
||||
|
||||
First Inversion <20> Transposes the root note up one octave. The third of the triad becomes the bass note.
|
||||
Second Inversion <20> Transposes the inverted triad again. The fifth of the triad becomes the bass note.
|
||||
|
||||
Chord inversions add variation, excitement, and smoother transitions in chord progressions. The more notes a chord has, the more possible inversions.
|
||||
Chord Progressions
|
||||
|
||||
A chord progression or a harmonic progression is an ordered series of chords. Chord progressions support both the melody and the rhythm. They also provide the foundation for creating harmony and melody.
|
||||
|
||||
Moreover, the key determines the chords used in a progression. A progression can also consist of major and minor chords.
|
||||
Roman Numeral Analysis
|
||||
|
||||
Roman numerals indicate the chords in a progression. They identify the musical key and the root note for each chord. For example, <20>IV<49> means the chord is built on the fourth degree of a scale.
|
||||
|
||||
Uppercase Roman numerals represent major chords, while lowercase numerals represent minor chords. For example, a chord progression in the key of C major would look like I-vi-IV-V (C-Am-F-G).
|
||||
|
||||
Delving deeper into this topic goes beyond basic music theory. However, it helps to introduce this numerical system.
|
||||
Voice Leading
|
||||
|
||||
|
||||
|
||||
Voice leading is the linear movement between melodic lines or voices to create a single musical idea. This technique focuses on the smooth movement of notes from one chord to the next using common sounding tones.
|
||||
|
||||
|
||||
|
||||
Voice leading also minimizes the vertical and horizontal transitions between notes in a chord progression or melody. These smaller moves sound more natural and pleasing.
|
||||
|
||||
When creating a chord progression, use harmonically related chords. They can share similar notes or have inversions to make the stepwise motion smoother. For example, a C major chord and an A minor chord both have the notes E and C.
|
||||
Conclusion
|
||||
|
||||
Music theory will give you a deeper understanding of music. But it<69>s also essential to remember musical theory is not hard rules. It<49>s a tool to help you create, understand, and communicate music.
|
||||
|
||||
There are several ways to practice music theory. Try applying the concepts in this guide to your workflow.
|
||||
|
||||
90
Books/Music/Theory/Modal_Scale_Reference.txt
Normal file
90
Books/Music/Theory/Modal_Scale_Reference.txt
Normal file
@@ -0,0 +1,90 @@
|
||||
TITLE: Modal Scale Reference
|
||||
DOMAIN: Music Theory
|
||||
CONCEPTS: Modes, scales, Dorian, Phrygian, Lydian, Mixolydian, Aeolian, Locrian, Ionian, intervals, note spelling
|
||||
CONTENT TYPE: Reference
|
||||
---
|
||||
|
||||
The notes in the C Ionian scale are C D E F G A B.
|
||||
The notes in the C# Ionian scale are C# D# F F# G# A# C.
|
||||
The notes in the D Ionian scale are D E F# G A B C#.
|
||||
The notes in the D# Ionian scale are D# F G G# A# C D.
|
||||
The notes in the E Ionian scale are E F# G# A B C# D#.
|
||||
The notes in the F Ionian scale are F G A A# C D E.
|
||||
The notes in the F# Ionian scale are F# G# A# B C# D# F.
|
||||
The notes in the G Ionian scale are G A B C D E F#.
|
||||
The notes in the G# Ionian scale are G# A# C C# D# F G.
|
||||
The notes in the A Ionian scale are A B C# D E F# G#.
|
||||
The notes in the A# Ionian scale are A# C D D# F G A.
|
||||
The notes in the B Ionian scale are B C# D# E F# G# A#.
|
||||
The notes in the C Dorian scale are C D D# F G A A#.
|
||||
The notes in the C# Dorian scale are C# D# E F# G# A# B.
|
||||
The notes in the D Dorian scale are D E F G A B C.
|
||||
The notes in the D# Dorian scale are D# F F# G# A# C C#.
|
||||
The notes in the E Dorian scale are E F# G A B C# D.
|
||||
The notes in the F Dorian scale are F G G# A# C D D#.
|
||||
The notes in the F# Dorian scale are F# G# A B C# D# E.
|
||||
The notes in the G Dorian scale are G A A# C D E F.
|
||||
The notes in the G# Dorian scale are G# A# B C# D# F F#.
|
||||
The notes in the A Dorian scale are A B C D E F# G.
|
||||
The notes in the A# Dorian scale are A# C C# D# F G G#.
|
||||
The notes in the B Dorian scale are B C# D E F# G# A.
|
||||
The notes in the C Phrygian scale are C C# D# F G G# A#.
|
||||
The notes in the C# Phrygian scale are C# D E F# G# A B.
|
||||
The notes in the D Phrygian scale are D D# F G A A# C.
|
||||
The notes in the D# Phrygian scale are D# E F# G# A# B C#.
|
||||
The notes in the E Phrygian scale are E F G A B C D.
|
||||
The notes in the F Phrygian scale are F F# G# A# C C# D#.
|
||||
The notes in the F# Phrygian scale are F# G A B C# D E.
|
||||
The notes in the G Phrygian scale are G G# A# C D D# F.
|
||||
The notes in the G# Phrygian scale are G# A B C# D# E F#.
|
||||
The notes in the A Phrygian scale are A A# C D E F G.
|
||||
The notes in the A# Phrygian scale are A# B C# D# F F# G#.
|
||||
The notes in the B Phrygian scale are B C D E F# G A.
|
||||
The notes in the C Lydian scale are C D E F# G A B.
|
||||
The notes in the C# Lydian scale are C# D# F G G# A# C.
|
||||
The notes in the D Lydian scale are D E F# G# A B C#.
|
||||
The notes in the D# Lydian scale are D# F G A A# C D.
|
||||
The notes in the E Lydian scale are E F# G# A# B C# D#.
|
||||
The notes in the F Lydian scale are F G A B C D E.
|
||||
The notes in the F# Lydian scale are F# G# A# C C# D# F.
|
||||
The notes in the G Lydian scale are G A B C# D E F#.
|
||||
The notes in the G# Lydian scale are G# A# C D D# F G.
|
||||
The notes in the A Lydian scale are A B C# D# E F# G#.
|
||||
The notes in the A# Lydian scale are A# C D E F G A.
|
||||
The notes in the B Lydian scale are B C# D# F F# G# A#.
|
||||
The notes in the C Mixolydian scale are C D E F G A A#.
|
||||
The notes in the C# Mixolydian scale are C# D# F F# G# A# B.
|
||||
The notes in the D Mixolydian scale are D E F# G A B C.
|
||||
The notes in the D# Mixolydian scale are D# F G G# A# C C#.
|
||||
The notes in the E Mixolydian scale are E F# G# A B C# D.
|
||||
The notes in the F Mixolydian scale are F G A A# C D D#.
|
||||
The notes in the F# Mixolydian scale are F# G# A# B C# D# E.
|
||||
The notes in the G Mixolydian scale are G A B C D E F.
|
||||
The notes in the G# Mixolydian scale are G# A# C C# D# F F#.
|
||||
The notes in the A Mixolydian scale are A B C# D E F# G.
|
||||
The notes in the A# Mixolydian scale are A# C D D# F G G#.
|
||||
The notes in the B Mixolydian scale are B C# D# E F# G# A.
|
||||
The notes in the C Aeolian scale are C D D# F G G# A#.
|
||||
The notes in the C# Aeolian scale are C# D# E F# G# A B.
|
||||
The notes in the D Aeolian scale are D E F G A A# C.
|
||||
The notes in the D# Aeolian scale are D# F F# G# A# B C#.
|
||||
The notes in the E Aeolian scale are E F# G A B C D.
|
||||
The notes in the F Aeolian scale are F G G# A# C C# D#.
|
||||
The notes in the F# Aeolian scale are F# G# A B C# D E.
|
||||
The notes in the G Aeolian scale are G A A# C D D# F.
|
||||
The notes in the G# Aeolian scale are G# A# B C# D# E F#.
|
||||
The notes in the A Aeolian scale are A B C D E F G.
|
||||
The notes in the A# Aeolian scale are A# C C# D# F F# G#.
|
||||
The notes in the B Aeolian scale are B C# D E F# G A.
|
||||
The notes in the C Locrian scale are C C# D# F F# G# A#.
|
||||
The notes in the C# Locrian scale are C# D E F# G A B.
|
||||
The notes in the D Locrian scale are D D# F G G# A# C.
|
||||
The notes in the D# Locrian scale are D# E F# G# A B C#.
|
||||
The notes in the E Locrian scale are E F G A A# C D.
|
||||
The notes in the F Locrian scale are F F# G# A# B C# D#.
|
||||
The notes in the F# Locrian scale are F# G A B C D E.
|
||||
The notes in the G Locrian scale are G G# A# C C# D# F.
|
||||
The notes in the G# Locrian scale are G# A B C# D E F#.
|
||||
The notes in the A Locrian scale are A A# C D D# F G.
|
||||
The notes in the A# Locrian scale are A# B C# D# E F# G#.
|
||||
The notes in the B Locrian scale are B C D E F G A.
|
||||
0
Books/Music/Theory/extracted_book.txt
Normal file
0
Books/Music/Theory/extracted_book.txt
Normal file
68
Chartwell.py
68
Chartwell.py
@@ -83,7 +83,7 @@ import torch
|
||||
# -------------------------
|
||||
# Knowledge base selection
|
||||
# -------------------------
|
||||
BOOK_DIR = 'Books/SongWriting' # just a string
|
||||
BOOK_DIR = 'Books/Accounting' # just a string
|
||||
book_files = []
|
||||
|
||||
for f in Path(BOOK_DIR).rglob('*'):
|
||||
@@ -584,6 +584,19 @@ def truncate_at_sentence(text, max_chars):
|
||||
return truncated[:last_period + 1] if last_period > 0 else truncated
|
||||
|
||||
|
||||
# -------------------------
|
||||
# Determimne if the question is asking for a creative or factual response
|
||||
# -------------------------
|
||||
def is_creative_request(question):
|
||||
triggers = {
|
||||
"suggest", "write", "complete", "finish", "rhyme", "next line",
|
||||
"come up with", "give me", "idea for", "open", "start", "begin",
|
||||
"chorus", "verse", "bridge", "hook", "lyric", "lyrics",
|
||||
"continue", "follow", "what comes", "how might", "how would"
|
||||
}
|
||||
q_lower = question.lower()
|
||||
return any(t in q_lower for t in triggers)
|
||||
|
||||
# -------------------------
|
||||
# Ask question
|
||||
# -------------------------
|
||||
@@ -600,10 +613,8 @@ def ask_question(question, show_sources=False, filter_term=None):
|
||||
print(chunk[:300])
|
||||
print("--- End chunks ---\n")
|
||||
|
||||
# context = " ".join(top_chunks)[:level_cfg["context_len"]]
|
||||
context = truncate_at_sentence(" ".join(top_chunks), level_cfg["context_len"])
|
||||
|
||||
# Build conversation history string
|
||||
history_text = ""
|
||||
if conversation_history:
|
||||
history_text = "Previous conversation:\n"
|
||||
@@ -612,31 +623,42 @@ def ask_question(question, show_sources=False, filter_term=None):
|
||||
history_text += f"A: {exchange['answer']}\n"
|
||||
history_text += "\n"
|
||||
|
||||
prompt = (
|
||||
f"You are a helpful research assistant. "
|
||||
f"Answer the question using ONLY the provided context. "
|
||||
f"Be direct and concise. "
|
||||
f"Only say 'I don't know' if the context contains absolutely nothing relevant. "
|
||||
f"Do not reference outside sources. "
|
||||
f"Do not repeat or echo the conversation history in your answer. "
|
||||
f"Do not include labels, separator lines, or notes in your answer. "
|
||||
f"Stop immediately after answering, ending on a complete sentence."
|
||||
if is_creative_request(question):
|
||||
prompt_instruction = (
|
||||
"You are a creative songwriting assistant. "
|
||||
"Use the provided context as inspiration and technique guidance. "
|
||||
"Generate original creative suggestions. "
|
||||
"Be concise. Do not reproduce the context. "
|
||||
"End your response with a single period."
|
||||
)
|
||||
else:
|
||||
prompt_instruction = (
|
||||
"You are a helpful research assistant. "
|
||||
"Answer using ONLY the provided context. "
|
||||
"Be direct and concise. Never repeat the context or instructions. "
|
||||
"Never echo the question. End your answer with a single period."
|
||||
)
|
||||
|
||||
if history_text:
|
||||
prompt += f"HISTORY:\n{history_text}\n"
|
||||
|
||||
prompt += (
|
||||
f"CONTEXT:\n{context}\n\n"
|
||||
f"QUESTION: {question}\n\n"
|
||||
f"ANSWER:"
|
||||
)
|
||||
|
||||
with lm_model.chat_session():
|
||||
response = lm_model.generate(prompt, max_tokens=level_cfg["max_tokens"])
|
||||
with lm_model.chat_session(system_prompt=prompt_instruction):
|
||||
user_message = (
|
||||
f"{history_text}"
|
||||
f"CONTEXT:\n{context}\n\n"
|
||||
f"QUESTION: {question}\n\n"
|
||||
f"ANSWER:"
|
||||
)
|
||||
response = lm_model.generate(
|
||||
user_message,
|
||||
max_tokens=level_cfg["max_tokens"]
|
||||
)
|
||||
|
||||
answer = response.strip()
|
||||
|
||||
# Strip any runaway stop markers and everything after them
|
||||
stop_markers = ["###", "####", "END OF ANSWER", "Final Answer", "STOP"]
|
||||
for marker in stop_markers:
|
||||
if marker in answer:
|
||||
answer = answer[:answer.index(marker)].strip()
|
||||
|
||||
conversation_history.append({
|
||||
"question": question,
|
||||
"answer": answer
|
||||
|
||||
38
Scales.py
Normal file
38
Scales.py
Normal file
@@ -0,0 +1,38 @@
|
||||
NOTES = ['C', 'C#', 'D', 'D#', 'E', 'F', 'F#', 'G', 'G#', 'A', 'A#', 'B']
|
||||
|
||||
MODE_PATTERNS = {
|
||||
'Ionian': [2,2,1,2,2,2,1],
|
||||
'Dorian': [2,1,2,2,2,1,2],
|
||||
'Phrygian': [1,2,2,2,1,2,2],
|
||||
'Lydian': [2,2,2,1,2,2,1],
|
||||
'Mixolydian': [2,2,1,2,2,1,2],
|
||||
'Aeolian': [2,1,2,2,1,2,2],
|
||||
'Locrian': [1,2,2,1,2,2,2],
|
||||
}
|
||||
|
||||
def build_scale(root, pattern):
|
||||
idx = NOTES.index(root)
|
||||
scale = [NOTES[idx]]
|
||||
for step in pattern[:-1]:
|
||||
idx = (idx + step) % 12
|
||||
scale.append(NOTES[idx])
|
||||
return ' '.join(scale)
|
||||
|
||||
lines = [
|
||||
"TITLE: Modal Scale Reference",
|
||||
"DOMAIN: Music Theory",
|
||||
"CONCEPTS: Modes, scales, Dorian, Phrygian, Lydian, Mixolydian, Aeolian, Locrian, Ionian, intervals, note spelling",
|
||||
"CONTENT TYPE: Reference",
|
||||
"---",
|
||||
""
|
||||
]
|
||||
|
||||
for mode, pattern in MODE_PATTERNS.items():
|
||||
for root in NOTES:
|
||||
scale = build_scale(root, pattern)
|
||||
lines.append(f"The notes in the {root} {mode} scale are {scale}.")
|
||||
|
||||
with open('Books/Music/Theory/Modal_Scale_Reference.txt', 'w') as f:
|
||||
f.write('\n'.join(lines))
|
||||
|
||||
print("Done.")
|
||||
Reference in New Issue
Block a user