Internal NuGet package containing the shared Billing database table models used by Dream Consistency products and product control planes.
| Package ID | DreamConsistency.BillingTables |
|---|---|
| Current Version | 1.0.0 |
| Target Framework | .NET Standard 2.1 |
| NuGet Feed | https://nuget.dreamconsistency.com/v3/index.json |
| Bitbucket Repository | DreamConsistency.BillingTables |
| Default Release Branch | master |
| Jenkins Job | DreamConsistency - Packages / DreamConsistency.BillingTables - NuGet Release |
DreamConsistency.BillingTables provides a shared, versioned C# persistence contract for
Dream Consistency Billing databases.
The package allows Hestino, Legislator, and future Dream Consistency products to use the same Billing database concepts without copying financial table/entity definitions between repositories.
Dream Consistency separates persistence responsibilities into distinct logical contracts.
| Contract | Responsibility | Examples |
|---|---|---|
DreamConsistency.RealmTables |
Current control, identity, product-access, subscription and commercial state. | Tenants, accounts, subscriptions, plans, prices, entitlements, markets and Realms. |
DreamConsistency.ManagementTables |
Operational execution, operational state and Management history. | Operations, steps, attempts, packages, usage snapshots, imports and audit. |
DreamConsistency.BillingTables |
Financial documents and financial transaction state. | Invoices, payments, allocations, credit notes, refunds and billing runs. |
| Product Tenant Tables | Actual product business data. | Hestino menus and locations; Legislator cases and documents. |
The Billing table contract is shared while physical Billing databases remain isolated per product.
Hestino and Legislator therefore share the Billing persistence model without sharing the same physical database.
| Consumer | Status | Usage |
|---|---|---|
Hestino.Management.Api |
Primary consumer | Hestino billing persistence, invoice generation, payment recording and billing-run processing. |
Legislator.Management.Api |
Planned evolution | Shared Billing persistence contract for Legislator. |
| Future Dream Consistency product services | Future | Reusable Billing persistence without product-specific financial schema duplication. |
Billing tables follow the same Dream Consistency identifier conventions used by Realm, Management, and product database contracts.
An ID is the primary identifier of a concrete table row.
A RefID identifies a concrete referenced record. It may represent either a local physical
foreign key or a logical reference to a record in another Dream Consistency database.
RefID values intentionally do not have physical database foreign-key constraints.
Referential consistency across independent database boundaries is enforced by the application/service layer.
A UUID identifies a stable catalog or system concept that must remain recognizable across
database instances, environments, deployments, and products.
RefID; stable catalog/system concepts use UUID.
Dream Consistency database tooling adds the following common fields programmatically to Billing tables:
These fields may therefore not be manually represented in the MySQL Workbench model.
Catalog and definition tables have stable UUIDs. Runtime, financial document, transaction, and history tables normally use only their row ID and required references.
| Package | Version | Purpose |
|---|---|---|
DreamConsistency.EntityManager |
1.0.0 |
Shared entity mapping infrastructure used by Billing table models. |
DreamConsistency.BillingTables through NuGet.
Do not use relative ProjectReference paths to separately checked-out Dream Consistency repositories
in CI or production projects.
Version 1.0.0 contains the shared Billing persistence areas described below.
The package source on master remains the final source of truth for exact C# class definitions.
| Table | Type | Purpose |
|---|---|---|
INF_BillingSchemaVersions |
Operational metadata | Tracks Billing database schema and contract versions applied to the physical database. |
DOC_DocumentPartyTypes |
Catalog / UUID | Defines stable Billing document party roles such as Issuer and Customer. |
INV_InvoiceStatuses |
Catalog / UUID | Defines invoice document lifecycle states such as Draft, Issued and Void. |
INV_Invoices |
Financial document | Stores invoice header data, tenant ownership, document number, currency snapshot, totals, billing period and lifecycle timestamps. |
INV_InvoiceItems |
Financial document detail | Stores billed lines including source references, sequence, description, quantity, unit price, tax snapshot and final monetary values. |
INV_InvoiceParties |
Historical snapshot | Stores Issuer and Customer identity/address snapshots exactly as required by the invoice document. |
| Table | Type | Purpose |
|---|---|---|
PAY_PaymentStatuses |
Catalog / UUID | Defines the lifecycle of a payment, including Pending, Succeeded, Failed and Cancelled. |
PAY_PaymentMethods |
Catalog / UUID | Defines generic payment methods such as Bank Transfer, Card, Cash and Direct Debit independently of payment providers. |
PAY_Payments |
Financial transaction | Represents one concrete customer payment, including tenant, amount, currency snapshot, payment method, status and external reference. |
PAY_PaymentAllocations |
Financial allocation | Allocates portions of payments to invoices and supports partial payments, multiple payments per invoice and one payment across multiple invoices. |
| Table | Type | Purpose |
|---|---|---|
CRN_CreditNoteStatuses |
Catalog / UUID | Defines credit note document lifecycle states such as Draft, Issued and Void. |
CRN_CreditNotes |
Financial document | Represents a credit note associated with an original invoice and stores number, tenant, currency snapshot, totals, reason and lifecycle timestamps. |
CRN_CreditNoteItems |
Financial document detail | Stores individual credit note lines and may reference the original invoice item being corrected. |
CRN_CreditNoteParties |
Historical snapshot | Stores Issuer and Customer party snapshots belonging to the credit note document. |
| Table | Type | Purpose |
|---|---|---|
PAY_RefundStatuses |
Catalog / UUID | Defines refund lifecycle states such as Pending, Succeeded, Failed and Cancelled. |
PAY_Refunds |
Financial transaction | Represents money returned against a previously successful payment and may optionally reference a related credit note. |
| Table | Type | Purpose |
|---|---|---|
RUN_BillingRunStatuses |
Catalog / UUID | Defines aggregate billing-run lifecycle states such as Pending, In Progress, Succeeded, Partially Succeeded, Failed and Cancelled. |
RUN_BillingRunItemStatuses |
Catalog / UUID | Defines individual billing candidate outcomes such as Pending, In Progress, Succeeded, Skipped and Failed. |
RUN_BillingRuns |
Operational billing state | Represents a batch billing process for a defined billing period and may optionally reference a Management operation. |
RUN_BillingRunItems |
Operational billing detail | Tracks the processing result of each subscription candidate and the invoice produced by successful processing. |
The following Billing tables use stable UUID identities and are treated as shared catalog/definition tables:
Business logic must use stable UUID constants rather than human-readable names as machine identifiers.
Issued financial documents must remain reproducible even when Realm data changes later.
Invoice and credit note data therefore contains persisted snapshot values such as:
An invoice belongs to a Tenant. Product/subscription provenance is stored at item level where appropriate.
Draft invoices may exist without a final invoice number or issue timestamp. The final document number is assigned when the invoice is issued according to the product Billing service's numbering rules.
Payments and invoices have a many-to-many financial relationship.
The model therefore does not store a direct Invoice_RefID on PAY_Payments.
Values such as allocated amount, unallocated amount, invoice paid amount and invoice outstanding amount are derived from the financial allocation records instead of being duplicated as independent sources of truth.
Credit notes and refunds represent different financial concepts and are intentionally modeled separately.
| Concept | Meaning |
|---|---|
Credit Note |
Reduces or corrects a previously issued financial obligation without modifying the original invoice. |
Refund |
Represents actual money returned against a previously successful payment. |
Credit note and refund amounts are stored as positive values. Their entity type defines their reducing financial effect.
PAY_Refunds, not by overwriting the original payment status.
A Billing Run represents a batch billing process for a defined billing period.
Each run item represents one Subscription billing candidate and records whether it succeeded, was skipped, or failed and which invoice was produced.
DreamConsistency.ManagementTables.
A Billing Run may therefore optionally hold an external Operation_RefID referencing a Management
OPS_Operations record without introducing a physical cross-database foreign key.
Billing databases intentionally reference Realm and Management records using logical RefID
values without physical cross-database foreign keys.
Add the package to a consuming backend service using the current explicit version:
Or add an explicit package reference:
Import the package namespace and register only the required Billing entity sets in the consuming service transaction context.
1.* are not allowed.
Package releases and physical Billing database schema deployments are separate operations.
When a table-model change requires a database schema change, use the following deployment sequence:
DreamConsistency.BillingTables package version.The package uses Semantic Versioning:
| Version Change | Meaning | Example |
|---|---|---|
PATCH |
Backward-compatible correction that does not break the public Billing table contract. | 1.0.0 → 1.0.1 |
MINOR |
Backward-compatible addition such as a new table class or optional property. | 1.0.1 → 1.1.0 |
MAJOR |
Breaking public-contract or incompatible persistence-model change. | 1.1.0 → 2.0.0 |
master.PUBLISH_PACKAGE disabled.PUBLISH_PACKAGE enabled.RefID for references to concrete records, including logical references across physical databases.PackageReference dependencies rather than sibling-repository relative references.| Version | Date | Change |
|---|---|---|
1.0.0 |
2026-07-27 | Initial stable release of the shared Dream Consistency Billing table contract. Includes Invoices, Payments & Allocations, Credit Notes, Refunds, Billing Runs, document-party snapshots, catalog definitions and Billing schema-version metadata. |
The same Billing persistence contract is intended to support independent product Billing databases.
Future architecture may introduce additional Billing services or centralized orchestration without requiring product databases to share the same physical Billing instance.
A future central Billing component should communicate through stable product/service APIs or events rather than directly depending on internal Hestino or Legislator Realm database schemas.