Parties

The chapter advances the argument that managing a party well means first understanding what it represents and how it fits into the organisation's structure, then the interface that governs its lifecycle. It begins by establishing what a party is in What is a Party?, then shows that a party's type and status are themselves configurable lookups with their own windows in Party types and statuses. From there it surveys the body of records in The Parties window before narrowing to a single record in Party Details and its five tabs — General, Identifiers (where the ten schemes a party can carry turn out to be a configurable lookup in their own right), Contact Information, Hierarchy (where the house-root rule introduced early in the chapter finally gets its screen), and Provenance. It then turns to changing a record under audit — Editing, Deleting, and Party history — culminating in reverting to an earlier version, the point at which the bitemporal audit trail does its work. The Conclusion draws these steps together and names what is deliberately still missing.

A party is an internal legal entity participating in financial transactions — the organisation's own top-level entity and each of its subsidiaries, branches, and other group-structure members. See the Tenants chapter's Parties section for the conceptual model this chapter builds on: the house/counterparty distinction, the administrative system party, and how a user's position in the party hierarchy determines their data visibility. This chapter does not repeat that model; it picks up from it to document the Qt interface for managing individual party records.

A party is, first and foremost, a stand-in for a real legal entity — a registered company, a bank, a branch — and real legal entities are notoriously hard to identify consistently: the same organisation can appear under different names, registration numbers, and codes across different jurisdictions, counterparties, and vendor systems, with no single authority reconciling them all.

Because no single identifier scheme covers every counterpart a party might need to be recognised by, a party can carry more than one — see Identifiers below for the full set of schemes OreStudio recognises, including the LEI and BIC schemes GLEIF publishes.

Every party carries a full name (its official registered legal name) and a short code (a brief mnemonic used elsewhere in the system for quick reference), both of which participate in the party's natural key alongside its surrogate id. A party also carries a codename — a globally unique, immutable, human-readable identifier (adjective_noun, e.g. swift_falcon) auto-generated on creation and used internally as the party's per-party message-queue prefix and scheduled-job namespace; it plays no role in the Qt UI and is not user-editable.

A party's type classifies what kind of entity it is (e.g. Corporate), chosen from the tenant's configured party types, and its status tracks where it sits in its own operational lifecycle (e.g. Active), chosen from the tenant's configured party statuses — both shown as colour-coded badges once selected. A party also carries a business center — an FpML business center code identifying the entity's primary location, the same code list documented in the Business Centres chapter.

A party's type and status are not fixed enumerations built into OreStudio; they are themselves tenant-configured reference-data lookups, each with its own list and detail window under the Reference Data menu, alongside the Party Types and Party Statuses entries. Both follow the same small shape — a Code (the value stored against the party), a Name (the label shown in the combo and, once selected, on the colour-coded badge), an optional Description, and a Display Order controlling where the value falls in the combo's drop-down list — plus the standard Provenance tab described in Provenance below.

Editing, deleting, and history for party type and party status records follow the same pattern described later in this chapter for the party record itself — a change reason on save, a soft close on delete, and a full version history with revert. Because both lookups are shared across every party (and, for status, every counterparty too — see the Counterparties chapter), changing a code or renaming a value here is immediately visible wherever that type or status is displayed.

With type and status established as configurable lookups in their own right, the rest of this chapter turns to the interface OreStudio provides for the party record itself — starting with the Parties window, which lists every party in the tenant.

Open the Parties window from the Reference Data menu. It lists all parties defined in the tenant, one row per party, each row carrying the short code, full name, party type, status, business center, version, last modifier, and when the record was last recorded.

The list is paginated; use the page controls at the bottom right to navigate. The toolbar buttons reload the list and open the add, edit, delete, and history actions. Double-clicking a row opens the Party Details dialog.

The Party Details dialog has five tabs — General, Identifiers, Contact Information, Hierarchy, and Provenance. The three action buttons at the bottom — Delete, Close, and Save — apply to the party as a whole.

To edit a party, open it in the Party Details dialog, make your changes, and click Save. Before the record is written, ORE Studio prompts for a change reason — the same Change Reason Required dialog shown in the Currencies chapter, and not repeated here. Select a Reason from the drop-down and add optional Commentary, then confirm. Every save creates a new version; the previous version is never overwritten.

To delete a party, open it and click Delete. ORE Studio asks for confirmation before the record is closed off. Deletion is a soft close — the record's history is preserved and remains visible in the History dialog.

To view the full change history, open the details dialog and click the history icon in the title bar, or right-click the row and choose History.

Pick the two versions to compare from the Compare drop-downs on the right. The All Fields / Only Changes toggle switches between showing every field and showing only the fields that differ between the two selected versions. The Revert button reinstates any historical version as a new version, preserving the full audit chain — the old version is never rewritten.

The chapter set out to show that managing a party well follows from understanding what it represents and how it fits into the organisation's structure, and it has traced exactly that path. A party is an internal legal entity identified by a short code and full name, carrying a type and status, and sitting beneath a parent party in a single corporate hierarchy tree — with the sole exception of the tenant's own house root; the Parent Party combo's No Parent choice exists precisely for that one narrow exception, with the database rejecting any second attempt to use it. Building on that, the Qt interface took the record from the list view through its General, Identifiers, Contact Information, Hierarchy, and Provenance tabs, and through the editing, deleting, and history workflows, where reverting to an earlier version demonstrated the same bitemporal audit trail described in the Reference Data chapter. The shell's provision party command covers bulk/GLEIF onboarding (see Hierarchy above), but general-purpose shell/CLI commands for adding, editing, deleting, or viewing the history of an individual party are not yet implemented — tracked separately rather than glossed over here. See the Counterparties chapter for the external-facing mirror of this one.

• Tenants — the multi-tenant, multi-party conceptual model (house vs counterparty, the system party, hierarchy-based data visibility) this chapter assumes and builds on.
• Reference Data — the shared data quality and audit framework this chapter builds on.
• Currencies — the template chapter this one mirrors, including the Change Reason Required dialog.
• Counterparties — the external-facing mirror of this chapter.
• Business Centres — the business center a party links to, and the country flag a contact record may carry.
• Temporal Composite Entity Versioning — the architecture behind the Identifiers and Contact Information child tables.