Repository Docs & Knowledge Base

Consolidated Spensara documentation repository (722 Markdown & architecture documents in ../repository)

Built Word Documents (.docx): Spensara Overview (.docx) Capability Assessment (.docx) Brink POS Ingestion Analysis (.docx) The Borg Ingestion Architecture (.docx)

Branches (328)

Branch-specific documentation across extract-raw-xml, feature-fleet-import, kds_cdc_improvments, life-cycle, and tenat-admin.

branches/life-cycle/warehouse-model/docs/features/ETL/warehouse-data/curated-model/pos_tenders.md 10,855 bytes · Updated Oct 23, 2026 10:44 AM EDT

Raw File

curated.pos_tenders

Purpose

This table stores tender master configuration from the POS. It defines how payment methods behave operationally, how they print, validate, authorize, round, and interact with drawers or processors.

It is primarily reference data used to interpret transaction tenders rather than a transactional fact table.

Warehouse design assessment

DW fit: Good payment-method dimension, but it should favor conformed payment attributes over vendor-specific tender flags.
Cross-client contract: Payment methods must map into shared business categories such as cash, card, gift card, loyalty, house account, or external wallet.
IDs vs business values: id, usernumber, and cardtype help with integration, but business consumers need tender_name, payment_family, and payment_family_name.
AI and business usability: AI agents need readable payment categories so they can explain customer behavior and channel preference without interpreting many one-character flags.
Recommended extensions: Add tender_key, source_system, source_tender_id, payment_family, payment_family_name, is_digital, is_cash_equivalent, and processor_name when available.

Detailed modeling guidance

Recommended role: Keep this table as the conformed payment-method dimension with one row per canonical tender or payment instrument.
Key differences from a stronger curated model: The model should emphasize business payment families and de-emphasize source-specific operational control flags.
What is already useful: Tender names, cash-like behavior, card indicators, and activity flags already support meaningful analysis.
What should move later to serving: Payment-mix summaries, customer payment personas, and business narratives belong in serving.

Curated contract columns

Column	Type	Monitor status	Purpose	Monitor rationale
`id`	`INTEGER`	Available for future monitors	Tender identifier in the POS source.	Join key for enriching payment subtype codes with readable tender behavior if current monitors expand. Potential monitors: customer-churn-risk, customer-profiles, identify-high-value-customers, segment-customers.
`usernumber`	`INTEGER`	Available for future monitors	User-visible tender number in the POS.	Useful for operator cross-reference, not for current monitor scoring. Potential monitors: customer-profiles.
`name`	`VARCHAR(10)`	Available for future monitors	Short tender name shown to operators.	Readable tender labels can improve customer payment-preference outputs. Potential monitors: customer-churn-risk, customer-profiles, identify-high-value-customers, segment-customers.
`cash`	`VARCHAR(1)`	Available for future monitors	Flag indicating whether this tender behaves as cash.	Can classify payment methods into cash-like behavior for customer payment analysis. Potential monitors: customer-profiles, segment-customers.
`gcert`	`VARCHAR(1)`	Available for future monitors	Flag indicating gift certificate support.	Could help future classification of non-standard payment behavior. Potential monitors: customer-profiles.
`change`	`VARCHAR(1)`	Available for future monitors	Flag indicating whether this tender can issue change.	Useful for classifying cash-like tender behavior in future analysis. Potential monitors: customer-profiles.
`reportas`	`INTEGER`	Available for future monitors	Reporting classification code for the tender.	Can normalize tender families if future customer payment analysis is expanded. Potential monitors: customer-profiles, segment-customers.
`house`	`VARCHAR(1)`	Available for future monitors	Flag indicating house-account behavior.	Can identify house-account payment patterns if customer profiles expand. Potential monitors: customer-profiles.
`active`	`VARCHAR(1)`	Available for future monitors	Flag indicating whether the tender is active.	Useful for future filtering of valid tender types when enriching payment data. Potential monitors: customer-profiles.
`tips`	`VARCHAR(1)`	Available for future monitors	Flag indicating whether the tender supports tips.	Adds semantics to tender types and could enrich customer spend profiles. Potential monitors: customer-profiles, identify-high-value-customers.
`cardtype`	`INTEGER`	Available for future monitors	Card type classification code.	Can enrich payment-method segmentation if future tender enrichment is added. Potential monitors: customer-profiles, segment-customers.
`fcurrncyid`	`INTEGER`	Available for future monitors	Foreign currency identifier.	Could support future currency-aware payment analysis. Potential monitors: customer-profiles.
`accntrcvbl`	`VARCHAR(1)`	Available for future monitors	Flag indicating accounts-receivable behavior.	Can classify special payment flows if customer payment analysis expands. Potential monitors: customer-profiles.
`cashcard`	`VARCHAR(1)`	Available for future monitors	Flag indicating cash-card behavior.	Can help classify hybrid payment behavior in future enrichment. Potential monitors: customer-profiles.
`ischeck`	`VARCHAR(1)`	Available for future monitors	Flag indicating check tender behavior.	Can enrich payment-method classification if future tender enrichment is added. Potential monitors: customer-profiles.
`external`	`VARCHAR(1)`	Available for future monitors	Flag indicating external processor or external payment behavior.	Can distinguish processor-routed payments in future segmentation. Potential monitors: customer-profiles.
`debit`	`VARCHAR(1)`	Available for future monitors	Flag indicating debit-card behavior.	Useful for tender-family classification in future customer payment analysis. Potential monitors: customer-profiles, segment-customers.
`giftcard`	`VARCHAR(1)`	Available for future monitors	Flag indicating gift-card behavior.	Can classify stored-value tenders for future customer payment profiles. Potential monitors: customer-profiles, segment-customers.
`iscredtcrd`	`VARCHAR(1)`	Available for future monitors	Flag indicating credit-card behavior.	Useful for grouping card-based payment behavior in future enrichment. Potential monitors: customer-churn-risk, customer-profiles, identify-high-value-customers, segment-customers.
`roundactiv`	`VARCHAR(1)`	Available for future monitors	Flag enabling rounding for this tender.	Could matter for exact paid-amount interpretation in future payment analysis. Potential monitors: customer-profiles.
`roundto`	`DOUBLE PRECISION`	Available for future monitors	Rounding increment.	Could matter for exact paid-amount interpretation in future payment analysis. Potential monitors: customer-profiles.
`roundmthd`	`INTEGER`	Available for future monitors	Rounding method code.	Could matter for exact paid-amount interpretation in future payment analysis. Potential monitors: customer-profiles.
`ebt`	`VARCHAR(1)`	Available for future monitors	Flag indicating EBT behavior.	Can classify benefit-style tender behavior in future payment segmentation. Potential monitors: customer-profiles, segment-customers.
`ebttype`	`INTEGER`	Available for future monitors	EBT subtype code.	Can refine tender-family classification in future enrichment. Potential monitors: customer-profiles.
`tdrsurch`	`INTEGER`	Available for future monitors	Tender surcharge identifier.	Could influence net payment economics in future analyses. Potential monitors: customer-profiles.
`disloyalty`	`VARCHAR(1)`	Available for future monitors	Flag disabling loyalty behavior for this tender.	Could explain why some tenders correlate differently with loyalty-linked customers. Potential monitors: customer-churn-risk, customer-profiles.
`iscampus`	`VARCHAR(1)`	Available for future monitors	Flag indicating campus-payment behavior.	Can classify special payment ecosystems in future enrichment. Potential monitors: customer-profiles.
`tender_key`	`BIGINT`	Recommended extension	Stable warehouse key for the tender entity.	Recommended to create one canonical payment-method identifier across clients and source systems.
`source_system`	`VARCHAR(100)`	Recommended extension	Canonical name of the source platform that produced the tender row.	Recommended to preserve lineage in the shared curated schema.
`source_tender_id`	`VARCHAR(199)`	Recommended extension	Original tender identifier from the source platform.	Recommended to support source-to-curated traceability and troubleshooting.
`payment_family`	`VARCHAR(100)`	Recommended extension	Standardized payment family code such as cash, card, wallet, loyalty, or house account.	Recommended to normalize payment analysis across clients with different tender catalogs.
`payment_family_name`	`VARCHAR(255)`	Recommended extension	Readable business name of the standardized payment family.	Recommended to make payment analysis easier for AI agents and business users.
`is_digital`	`BOOLEAN`	Recommended extension	Canonical flag indicating whether the tender is a digital payment method.	Recommended to simplify payment-channel segmentation without decoding many source flags.
`is_cash_equivalent`	`BOOLEAN`	Recommended extension	Canonical flag indicating whether the tender behaves like cash in analysis.	Recommended to standardize payment grouping across source systems.
`processor_name`	`VARCHAR(255)`	Recommended extension	Readable payment processor or external provider name when available.	Recommended to add more business context to payment-method analysis.
`tenant_key`	`BIGINT`	Recommended extension	Stable warehouse key for the tenant, brand, or client that owns the tender configuration.	Recommended because shared curated reference data should preserve explicit client context.
`tenant_name`	`VARCHAR(255)`	Recommended extension	Readable tenant, brand, or client name associated with the tender.	Recommended to improve cross-client reporting and AI usability.
`effective_from_utc`	`TIMESTAMP`	Recommended extension	UTC timestamp from which the current tender version is valid.	Recommended to support payment-method history and point-in-time analysis.
`effective_to_utc`	`TIMESTAMP`	Recommended extension	UTC timestamp until which the current tender version is valid.	Recommended to support history-preserving dimensional modeling.
`is_current`	`BOOLEAN`	Recommended extension	Canonical flag indicating whether the row is the current tender version.	Recommended if this table evolves into a slowly changing dimension.