The RACs Data Model
The RACS data model extends the existing Maica Client Care data model. It adds a small number of new custom objects and a larger set of new fields on objects that already exist. This article is a reference to the core objects, how they relate, and the key fields and formula fields an administrator needs to understand.
All object and field API names use the maica_cc namespace.
Core objects and relationships
New objects
The solution introduces several new custom objects. The most important are below.
Lump Sum Account
maica_cc__Lump_Sum_Account__c
The financial ledger for a resident's accommodation deposit (RAD, RAC, or bond). One per Service Agreement where a lump sum applies.
Lump Sum Transaction
maica_cc__Lump_Sum_Transaction__c
An individual balance movement against a Lump Sum Account (payment, retention deduction, draw-down, refund, interest). Together the transactions form the audit trail.
Claim Service Classification
maica_cc__Claim_Service_Classification__c
The AN-ACC classification distribution for a service in a claim month, as confirmed by Services Australia.
Accommodation Balance
maica_cc__Accommodation_Balance__c
The monthly accommodation balance record reported to Services Australia for a resident's deposit.
Registered Nurse Supplement Summary
maica_cc__Registered_Nurse_Supplement_Summary__c
The 24/7 registered nurse supplement summary synced from Services Australia.
Registered Nurse Supplement Breakdown
maica_cc__Registered_Nurse_Supplement_Breakdown__c
The line-level breakdown beneath a supplement summary.
Registered Nurse Coverage Check
maica_cc__Registered_Nurse_Coverage_Check__c
The result of a 24/7 registered nurse coverage calculation, used for GPMS entry.
Extended existing objects
RACS adds fields to objects that are already part of Maica. The most important are below.
Funding
The source of truth for the resident's fee arrangement, accommodation arrangement, opt-in outcome, lifetime and financial-year cumulatives, and the subsidy data synced from Services Australia.
Service Agreement
Carries the fee items, the room link, the deposit account link, and a read-only fee arrangement that reads from Funding.
Agreement Item
One per fee. Holds the rate, billing method and frequency, billing dates, and cap control fields the billing engine maintains.
Support Item
Defines the fee type and indexation behaviour that the billing engine reads.
Accommodation
A room or bed, with a capacity, linked to a Location.
Location
An aged care home, holding facility-level attributes such as the accommodation supplement category and the Services Australia service NAPS ID.
Invoice Line Item
Generated by the billing engine, with a source field that records what created it.
Payment
Extended with a RAD Draw-Down source value and a link to the lump sum transaction.
Aged Care Event
Holds the entry, departure, leave, supplement, and opt-in events exchanged with Services Australia. Linked to Funding.
Incident
Extended with SIRS compliance fields.
Setting
Holds the government-published caps, rates, indexation values, and automation toggles.
How the records relate
The Funding record is the centre of a resident's file. Each Service Agreement links to a Funding record, and the resident's Aged Care Event records also hang off Funding. The Service Agreement links down to the resident's Accommodation (their room) and, where a deposit applies, to a Lump Sum Account. Each Lump Sum Account is the parent of its Lump Sum Transaction records. Accommodation records belong to a Location (the home).
Service Agreement to Funding
Lookup
Lump Sum Account to Service Agreement
Lookup (required, Restrict on delete)
Service Agreement to Lump Sum Account
Lookup (Set Null) - the agreement's current deposit account
Lump Sum Transaction to Lump Sum Account
Master-Detail
Accommodation to Location
Lookup
Aged Care Event to Funding
Lookup
Claim Service Classification to Claim Batch
Master-Detail
Registered Nurse Supplement Breakdown to Registered Nurse Supplement Summary
Master-Detail
The Lump Sum Account links to its Service Agreement with a required Lookup that carries a Restrict delete constraint, rather than a Master-Detail relationship. This protects the financial audit trail: Salesforce blocks deletion of a Service Agreement while Lump Sum Accounts still reference it, so the ledger can never be cascade-deleted. This is covered in Architectural Principles.
Key fields and formula fields
The fields below are the ones administrators reference most often. Each has a user-facing description and the help text that appears on the field.
Funding
maica_cc__Fee_Arrangement__c
Picklist
The fee arrangement for this resident. Drives all fee rules on linked Service Agreements. Values are Pre-1 July 2014, 1 July 2014, and Post 1 November 2025. Set at intake and updated automatically when an opt-in is confirmed.
The fee arrangement that applies to this resident. This value drives all fee rules on linked service agreements.
maica_cc__Opt_In_Confirmed__c
Checkbox
Set by automation when an opt-in event is accepted by Services Australia. Never set by users.
Indicates the resident has opted in to the newer arrangements. Set automatically.
Service Agreement
maica_cc__Fee_Arrangement__c
Formula (Text)
A read-only formula that displays the fee arrangement from the parent Funding record. Determines which fee structure, caps, and means testing rules apply to this Service Agreement.
The fee arrangement inherited from the resident's Funding record. Read-only.
Agreement Item
maica_cc__Active_Item__c
Formula (Checkbox)
A read-only formula that evaluates whether the item is currently active, based on the End Date relative to today. The billing engine excludes inactive items.
Whether this fee item is currently active. Calculated from the end date.
maica_cc__Next_Billing_Date__c
Date
The next date the billing engine will process this item. Rolled forward after each successful run.
The next date this fee will be billed. Maintained by the billing engine.
maica_cc__Billing_Status__c
Picklist
The per-item processing state within a billing run (Initialised, Complete, Failed). Cleared after each successful run.
The billing engine's processing state for this item.
maica_cc__Cap_Reached__c
Checkbox
Set by the billing engine when a regulatory cap is hit. Cleared by the financial year reset where only an annual cap was reached.
Indicates a regulatory cap has been reached for this fee.
Lump Sum Account
maica_cc__Current_Balance__c
Currency
The current balance of the resident's lump sum held by the provider. Updated by each transaction. On permanent departure, the remaining balance is refunded within legislated timeframes.
The current balance of the resident's deposit held by the provider.
maica_cc__Cumulative_Retention__c
Roll-Up Summary
The total retention deducted, summed from the positive Deduction Amount on transactions where the type is Retention Deduction. Displays as a positive figure.
Total retention deducted from this deposit.
maica_cc__Cumulative_Draw_Down__c
Roll-Up Summary
The total drawn down, summed from the positive Deduction Amount on transactions where the type is Draw-Down.
Total amount drawn down from this deposit.
Lump Sum Transaction
maica_cc__Amount__c
Currency
The signed value of the movement. Deductions are stored as negative values, consistent with double-entry accounting. This is the authoritative ledger entry for balance mathematics.
The amount of this transaction. Negative for deductions.
maica_cc__Deduction_Amount__c
Formula (Currency)
The absolute, always-positive value of the transaction amount. Used as the source for the cumulative roll-up summaries on the parent account so totals display as positive numbers.
Always-positive version of the transaction amount, used by cumulative totals on the parent account.
The signed maica_cc__Amount__c field is the authoritative figure for balance calculations. maica_cc__Deduction_Amount__c exists only to make cumulative totals display as positive numbers. Do not use the positive mirror for balance arithmetic.
This article covers the key fields. The complete field-by-field configuration, including every new field and its metadata, is maintained in the RACS configuration reference and the billing engine schema specification.
Last updated
Was this helpful?