ClientPayerConfiguration
One time slice of a client's payer configuration (REQ-CL-004.7-.16): the Beteiligte once, and only the Dienstbereiche that deviate from them. One document per time slice, covering the client's whole payer configuration.
type ClientPayerConfiguration {
clientId: ClientID!
deviations: [ServiceAreaDeviation!]!
expiresAt: Date
id: ClientPayerConfigurationID!
needsReview: Boolean!
parties: ClientPayerParties!
resolvedServiceAreas: [ResolvedServiceArea!]!
reviewNotes: [PayerConfigurationReviewNote!]!
validFrom: Date!
}
Fields
ClientPayerConfiguration.clientId ● ClientID! non-null scalar
The client this slice belongs to. Needed because a slice is also reachable park-wide, through
clientPayerConfigurationsNeedingReview, where the client is not the query's parent.
ClientPayerConfiguration.deviations ● [ServiceAreaDeviation!]! non-null object
Only the Dienstbereiche that answer something differently from the Beteiligte.
ClientPayerConfiguration.expiresAt ● Date scalar
The last date this slice is effective. Null if this is the currently open slice.
ClientPayerConfiguration.id ● ClientPayerConfigurationID! non-null scalar
Unique identifier of this time slice.
ClientPayerConfiguration.needsReview ● Boolean! non-null scalar
True when this slice was migrated from legacy data that could not be mapped cleanly and needs a PDL's attention (#3322 step 3). Always false for a slice a user created.
ClientPayerConfiguration.parties ● ClientPayerParties! non-null object
Everyone who pays, or is billed, in this slice.
ClientPayerConfiguration.resolvedServiceAreas ● [ResolvedServiceArea!]! non-null object
The effective answer for every Dienstbereich that is not statutorily fixed, deviating or not.
ClientPayerConfiguration.reviewNotes ● [PayerConfigurationReviewNote!]! non-null object
Why this slice needs review, one note per irregularity. Empty whenever needsReview is false.
ClientPayerConfiguration.validFrom ● Date! non-null scalar
The date this slice becomes effective. **Always the 1st of a calendar month** — a Kostenträgerwechsel inside a month is not permitted (Product Owner, 2026-09-09). Any other date is rejected.
This is not a convenience: it is what makes Selbstbehalt interval MONTHLY mean the whole
month with no pro-rata share, and what gives every month exactly one valid configuration, so no
"which fund applied on the 17th" question exists.
Slices migrated from the legacy flat records may still carry a mid-month date. Those are never
silently moved — moving one would change a billing period, and therefore money. They are
counted and listed by the read-only ./gradlew firstOfMonthAudit report instead.
Member Of
Client object ● CreateClientPayerConfigurationPayload object ● MoveClientPayerConfigurationValidFromPayload object ● ResetClientPayerServiceAreaDeviationPayload object ● ResidentialPark object ● SaveClientPayerPartiesPayload object ● SaveClientPayerServiceAreaDeviationPayload object