Acumatica Segments Coder Customisation

Segmented keys are one of those Acumatica features that look purely cosmetic until a client's chart of accounts needs to encode a company code, a department, and a natural account all inside one field with validated, independently-configurable segments. The Coder infrastructure that backs Inventory IDs, Subaccounts, and any custom segmented key you build yourself is more capable than most developers realize the first time they need to customize it.

Coder: a validated, segmented string, not just a formatted one

A segmented key in Acumatica (configured on screens like Segmented Keys, CS202000, for Subaccount or Inventory ID, or built for a custom entity) is a string composed of independently validated segments, each with its own length, its own value set (free text, a lookup against another table, or a fixed list), and its own separator character. The critical distinction from a plain formatted string: each segment is independently queryable and independently subject to security and validation rules, which is what lets a subaccount like 100-410-KE support "restrict this role to department 410 only" without parsing the string yourself.

Segmented Key: SUBACCOUNT
  Segment 1: COMPANY   (3 chars, validated list)
  Segment 2: DEPT      (3 chars, validated list, lookup to Department)
  Segment 3: REGION    (2 chars, free text)

  Example value: 100-410-KE

Wiring a DAC field to a segmented key

On the DAC side, a segmented key field uses AcctSubAttribute or, for custom segmented entities, a generated attribute class Acumatica builds when you define the key through Segmented Keys, and applying it is what gives the field its segment-aware editor control, its per-segment validation, and its combination-level security:

[PXDBString(30, IsUnicode = true)]
[PXUIField(DisplayName = "Subaccount")]
[SubAccount(typeof(GLTran.branchID))]      // segmented-key aware attribute
public string SubID { get; set; }
public abstract class subID : PX.Data.BQL.BqlString.Field<subID> { }

Custom segmented keys you define yourself get a generated attribute the same way, tied to the segmented key ID you configured, and applying that attribute to a custom DAC field gets you the combination-box editor and validation for free, without writing a custom edit control from scratch.

Combination-level restriction is the feature people actually want

The reason clients ask for segmented keys instead of a plain lookup field is almost always combination-level access control: restrict certain users to certain segment value combinations, not just to individual segment values in isolation. A user might be allowed department 410 in company 100, but not department 410 in company 200, a rule that is meaningless if department and company are just two unrelated fields rather than segments of one validated key with combination rules configured against it.

Building your own segmented key for a custom entity

Beyond Subaccount and Inventory ID, you can define an entirely new segmented key for a custom DAC through the same Segmented Keys infrastructure, useful when a client needs a custom "Project Code" or "Asset Tag" field with the same validated, combination-aware behavior as the built-in ones rather than reinventing segment parsing by hand. Define the key, its segments, and their value sources on the Segmented Keys screen, then apply the generated attribute to your custom field, the same pattern as any built-in segmented field, which is the part developers unfamiliar with Coder tend to miss, assuming segmented keys are a fixed platform feature rather than something you can extend to your own entities.

Segment length changes after data exists are expensive

Changing a segment's length or adding a new segment to a key that already has live data is not a free configuration change, existing values need to be reformatted to the new structure, and any code, GI, or report that assumed the old fixed positions (substring-based parsing outside the Coder API, for instance) breaks silently. I have inherited more than one instance where a developer bypassed the segmented-key API and did direct string-splitting against a subaccount value in a report, and a later segment-length change broke that report without anyone connecting the two changes for weeks. Always resolve segment values through the Coder-aware BQL fields or the segmented key API, never through positional string manipulation, specifically so a future segment structure change does not require hunting down every place someone assumed today's fixed widths.

Wrapping up

Segmented keys exist to give a composite value independently validated, independently securable pieces, and the combination-level access control is usually the actual business requirement hiding behind what looks like a formatting request. Wire custom fields to Coder-generated attributes rather than hand-building segment parsing, test restriction groups with a genuinely restricted user across every screen and GI that touches the key, and treat segment structure changes on live data as a real migration, not a quick configuration tweak.