Billing Allocation Flag Configuration and Documentation

There's a need to control how billing allocations are processed and how they're referenced in reporting, and the expectation is that a "Billing Allocation Flag" does this. The trouble is nobody can find it. It isn't visible on the standard billing screens, isn't searchable, and isn't documented. So either it exists somewhere non-obvious, it exists under a different name, or it doesn't exist at all and the behaviour is hardcoded.

Objective

Give users a documented, discoverable way to see and set how billing allocations are handled, and have that setting flow through to reporting consistently.

In scope

  • Locating the existing mechanism (flag, config value, hardcoded rule) that currently governs billing allocation behaviour

  • Surfacing it in the billing screens where users would reasonably look for it

  • Making it searchable

  • Documenting what each value does and where it takes effect

Out of scope (pending the discovery above)

  • Changing the underlying allocation logic itself

  • Anything to do with billing allocation that turns out to be driven by a different setting entirely

Functional requirements

Discovery first. Before scoping the build, engineering confirms what actually controls billing allocation today: a database field, a config setting, a hardcoded rule, or a combination. The answer determines everything below.

Placement. Once identified, the flag appears on the relevant billing configuration screen, at whatever level it actually operates (system, client, contract, or line). Placed where a user would go looking for it, not tucked into an admin screen they'd never open.

Searchability. The field is findable via standard system search and appears in the relevant configuration listings.

Reporting. Reports that reference billing allocations reflect the flag's value, and it's clear from the report which setting was applied.

Permissions. Changing the flag is restricted to appropriate roles, since it affects billing outcomes.

Validation and audit

  • Standard Catch-e confirmation prompts on save

  • Changes to the flag are audited: who, when, old value, new value

  • Changing it shouldn't retrospectively alter allocations that have already been processed. Confirm this.


Acceptance criteria

  • A user can find the Billing Allocation Flag through normal navigation and search, without being told where it is

  • The flag's effect on processing and reporting is documented

  • Setting it produces the expected allocation behaviour

  • Changes are audited

  • Existing processed allocations are unaffected by a change to the setting

Please authenticate to join the conversation.

Upvoters
Status

Planned

Board
💡

Feature Request

Date

2 months ago

Subscribe to request

Get notified by email when there are changes.