Named Groups on Document References

Named Groups on Document References

Your support desk imports free-typed document references from emails and CSV exports — strings like INV-2025-00042/L3, crm - 2024 - 00007, or whole lists such as INV-2025-00100..00105, ORD-2023-00001. You are building the parser that turns this mess into structured, canonical data — and a search over it that treats end-user input as text, never as syntax.

Requirements

The starter ships a table named "Parsed Doc Reference" — the in-memory buffer your parser fills. Keep its fields and key exactly as shipped; the grading tests read it directly:

• "Entry No." — Integer, the primary key
• "Document Type" — Code[10]
• "Document Year" — Integer
• "Start No." — Integer
• "End No." — Integer
• "Line No." — Integer
• Canonical — Text[50]

Complete the codeunit named "Doc Reference Parser" with three public procedures:

procedure TryParseReference(Reference: Text; var ParsedRef: Record "Parsed Doc Reference"): Boolean
procedure ParseList(InputText: Text; var ParsedRef: Record "Parsed Doc Reference"): Integer
procedure CountReferencesMatching(InputText: Text; Needle: Text): Integer

The reference grammar

Normalization comes first: remove every whitespace character (spaces, tabs, line breaks — wherever they appear, even inside a segment) and convert to uppercase. The compacted text must then consist of, in its entirety:

• TYPE — 2 to 5 letters A–Z
• a literal -
• YEAR — exactly 4 digits
• a literal -
• START — 1 to 8 digits
• optionally a literal .. followed by END — 1 to 8 digits
• optionally a literal /L followed by LINE — 1 to 4 digits
• and nothing else — no extra characters before, between, or after the pieces listed

Value rules, checked on top of the shape: digit segments may carry leading zeros; the decimal values of START, END and LINE must each be at least 1; and END must not be below START. A reference that breaks any shape or value rule is invalid.