Invoice Payment Means

Documentation Index

Fetch the complete documentation index at: https://docs.wellapp.ai/llms.txt

Use this file to discover all available pages before exploring further.

​

API operations

​

Data model

​

Attributes

​

Relationships

​

System-computed

• id is generated via gen_random_uuid() PostgreSQL function, set as the column defaultRaw in the MikroORM entity definition. It is unique and stable for the lifetime of the row, including after soft-delete.
• created_at is set exactly once on INSERT via MikroORM onCreate: () => new Date(). It is never updated after creation.
• updated_at is set on INSERT (onCreate: () => new Date()) and refreshed on every UPDATE (onUpdate: () => new Date()). Because onCreate is present, updated_at is never null after row creation; the column is declared nullable in the DDL (timestamptz null) to allow the optional TypeScript type, but the onCreate hook ensures it is populated on insert.
• deleted_at is null on active rows. Setting it to a non-null timestamp constitutes a soft-delete. Hard DELETE is never used; the junction row is retained for audit and historical query purposes. The partial index idx_invoice_payment_means_invoice_active (WHERE deleted_at IS NULL) is maintained to optimize hot Hasura array_relationship traversals on the invoice_pk column while excluding soft-deleted rows from the index.
• Three indexes are maintained on the table: idx_invoice_payment_means_invoice (invoice_pk, full) and idx_invoice_payment_means_payment_means (payment_means_pk, full) were added in Migration20260415150000_invoice_payment_means_and_transactions_indexes. The partial index idx_invoice_payment_means_invoice_active (invoice_pk, WHERE deleted_at IS NULL) was added later in Migration20260506140000_perf_indexes_round7 during a hot-path performance round. All three are declared via @Index decorators on the entity class.
• The entity is a pure junction table with no workspace_pk column of its own. Tenant isolation is enforced transitively: Hasura RLS on the invoice or payment_means parent tables scopes access, and application-layer queries always join through the parent entity carrying the workspace predicate.
• The entity has no workspace-direct FK by design (it is scoped through its Invoice parent). It is registered in allEntities in database/entities/index.ts.
• The records root invoice_payment_means exposes composites via composites.yml: invoice.composite_total_amount_currency (display_type: currency_amount, source_fields: invoice.invoice_id, invoice.grand_total, invoice.local_currency) and payment_means.composite_payment_means_summary (display_type: payment_means_summary) and payment_means.company.composite_logo_name (display_type: company_logo_name). These composites are read-only, pipeline-resolved at query time by the composite-reconstructor.

​

Example

{
  "data": {
    "type": "invoice_payment_means",
    "id": "c3e8a1f2-6d47-4b3e-9a12-0f8b7c2d5e94",
    "attributes": {
      "created_at": "2025-11-04T09:22:10.000Z",
      "updated_at": "2025-11-04T09:22:10.000Z",
      "deleted_at": null
    },
    "relationships": {
      "invoice": {
        "data": {
          "type": "invoice",
          "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
        }
      },
      "payment_means": {
        "data": {
          "type": "payment_means",
          "id": "f9e8d7c6-b5a4-3210-fedc-ba9876543210"
        }
      }
    }
  }
}