Stage 3: Code Format Design

Highest-impact decision in the early Playbook. After transactions post, format changes require data conversion. Prefer decide all eight out of the box. "Defer to default" is allowed. Unused datatypes with no transactions (for example deferred EM) can still change later without conversion.

phase_key: code_format_design

What this stage accomplishes

• The team understands the stakes: reporting impact, conversion risk after post, and when deferral is safe.
• The eight required datatype masks are designed and approved (or explicitly deferred to default where allowed).
• Sibling vocabulary (JC / EM cost types) is clear so "cost code" language does not collide with equipment cost code.
• Soft patterns for GL, Job, and Phase are framed by company size and tracking depth (with proper mask notation).
• Separators and master ID separation rules are clear so imports and firms do not collide.
• Formats are ready as evidence for Core Configuration handoff.

Typical work / artifacts

Eight required masks

Key	Meaning
bGLAcct	GL Account
bJob	Job / Contract (ONE format for both; always the same)
bPhase	Phase (job cost category)
bEquip	Equipment Number
bCat	Equipment Category
bCostCode	Equipment Cost Code (DEFAULT MASK: 10LN; most clients use simple numbers like 100 / 200 / 300 or thousands)
bMatlCat	Material Categories
bPhone	Phone Number

Evidence of completion is active code-format rows with a non-empty input mask for each required datatype (or an explicit defer-to-default where the process allows).

Siblings, not masks (vocab only)

• JC cost type: labor / material / sub / owned equip / rented equip / other / burden (standard IDs 1–7)
• EM cost type: parts / labor / depreciation / fuel

Other ERPs often call Vista's phase a "cost code." In Vista, cost code means equipment cost code. Keep that distinction sharp. bPhase is Phase (job cost category), not "Phase Code (Cost Code)."

Mask alphabet / hard rules (TUDS validates)

• R = right-justified; L = left-justified; N = no separator (NOT "required")
• Last part MUST end in N
• Other parts end in ., -, or N
• Widths: 1R / 1L through 10R / 10L

Recommend different separators by datatype so codes do not collide visually (for example GL ., jobs -).

GL (bGLAcct)

• Part 1 = base account (natural). 4-digit vs 5-digit natural is mainly what users want plus room to expand. Small companies that rarely add/change accounts and have enough space: 4-digit is perfectly fine. 5-digit is nicer for larger companies that need more space and more accounts spread throughout. Users select from lists. 6 is ok.
• Hard cap: 6 parts (base + parts 2–6). Practical max ~4 (maybe 5). Parts 5–6 are rare (crazy). Beyond that is over-engineering.
• Parts 2+ = dept / division / location (or combos) for how they present financials. Same base = same natural account. Digit widths should match how they are structured and what they want to grow into. Example: a 5R.2R.2RN client wanting locations is restricted to 0–9 on a 1-digit location; a 3-digit part gives ~1000 options. 2-digit parts limit more than 3-digit.
• Soft pattern: smaller companies 5R.2RN often works; larger often 5R.3RN and may use parts 3–4.
• Multi-company: keep base meanings identical across companies for consolidation.
• Balance sheet is usually base-only. Exceptions sometimes include AR, AP, cost / billings in excess.

Change pain: In a test company, if you don't care about existing data/setup, change the format, fix/re-import GL accounts, update setup, back out old GL. Live with real transactions: you cannot ignore those transactions → larger data conversion.

Docs line: do NOT over-engineer. Build for financial presentation and a GAAP-clean COA.

Job / Contract (bJob)

• Job = cost side; Contract = revenue side. Every job points to a contract. Many jobs can point to one contract.
• Roughly 10 characters. Common shapes: 6-3 or 7-2. Year-prefix examples like 26-0001. Optional branch digit or letter.
• Choosing clean 6-3 vs year prefix is personal preference. Year prefix (e.g. 260001 for first 2026 job) is mainly visual recognition and report sortability for that year's sequence; you also get sequential numbering without the year. Year only indicates when the job started (a multi-year job still shows the start year). Some clients care; many don't.
• Soft pattern: smaller clients often plain 6-3, or simple year+sequence. Larger clients or ones that track job revenue/cost by branch/department may use a prefix unique to location or department (e.g. letter A/B/C per department so ownership is obvious). You can build that logic to make things easier; do not force logic.
• Soft preference: do not overload logic. Encoding dept / branch (A / B / C leading) is common and ideal. Customer-in-job is rare but a client call. Do not overthink before knowing the system.
• Changing job/contract format in a test company is OK; you just lose any test jobs that exist. Same general code-format change concept as GL: test is recoverable; live posted work needs conversion thinking.

Phase (bPhase)

Cost category (CSI-style trades). Sibling = cost type.

• Shorter phase masks are for clients that don't track much at the job-cost level. Examples: five phases (100/200/300/400/500), or ~20 phases reused across hundreds of jobs. Volume can still be high; they just do the same types of work.
• More general contractors doing more trades lean to a 6R-3R-4RN style format. First part is typically the CSI code. Second part can be used for a sub-phase type concept or a change-order type concept.
• CSI look = 2.2.2 when wanted.
• Todd default for docs: 6R-3R-4RN (flexible / expandable; not required to be CSI; 6R allows fewer digits via right-justify).
• Also seen: flat 6 characters, or coarse 100 / 200 / … / 1000.
• Format change rule matches other Stage 3 masks: test company is recoverable; live posted jobs need conversion thinking.

Equipment

• Number (bEquip): up to 10 chars; typically numeric; often 10LN; separators uncommon.
• Category (bCat): every equip has one. Example mask 2R-3R-N. Series grouping (50 trucks, 51 backhoes…). Categories drive job costing rates. T&M can add billing rates at category and/or individual equip.
• Cost code (bCostCode): cost buckets (brakes, tires, oil…). Sibling cost type groups them. DEFAULT 10LN.

Material categories (bMatlCat)

Decide format now or accept default. Internal inventory is NOT required. Material codes can be reference / unit costs / PO vendor-material helpers without stocked inventory balances.

EM / IN masks when deferred

If equipment and inventory are deferred (or those modules are not in scope and have no transactions), locking equipment and material masks in Stage 3 is optional. With no setup and (most importantly) no transactions for those datatypes, those formats can be changed later without risk of breaking anything. At a general level it is good to decide a format if possible, but optional. Do not force a decision just to force it. Defaults for those masks are very capable even when a client later implements EM/IN.

Separators and master IDs

Separators themselves are not needed for import purposes. Example: with a 5R.2RN GL format, importing account 10000 lets the system add the period and trailing part spaces. Do not over-worry separators for imports.

Vendor and customer numbers: important rule is separation so they never collide. Vendors often start at 10000, or some clients use 100000 for more future flexibility (size-dependent). Customers are typically four digits starting at 1000 unless they need to exceed 9999. That separation exists because Project Management has "firms," and firms cannot be duplicated. You cannot have the same number as both customer and vendor.

Employee numbers: most clients use four-digit and sequence up; can start at five-digit or six-digit (about six-digit max) depending on how far they want to go / keep sequential. Some clients just start at employee 1, 2, 3 and sequence up.

Phone (bPhone)

Vista hard rule: one format per database (~12–14 character capacity).

• US: 3.3.4 with a . vs - decision.
• Canada: likely NA-style.
• AU: Todd untested (open flag).

:::note Open flag AU phone format is untested. Treat as open until validated. :::

Also reinforce process investment

Same Onboarding/Kickoff mindset applies here: do not treat code formats as a chance to clone a broken legacy structure. Prefer redesign now; after posts, format changes need conversion.

Connection to Company Tracker / Vista

Formats are stored as code-format evidence used downstream in Vista setup. There is no separate Company Tracker milestone sync panel in this stage. Masks must exist before Core Configuration work depends on them. HQ group sharing decisions wait for Stage 4: Core Configuration.

Exit / moves to next stage

Code Format Design is complete when all required masks are approved (or deferred where allowed) and handoff into Core Configuration is confirmed. The implementation then moves to Core Configuration.

In the product

In Mission Control, complete the Code Format Design workspace (and the full code-format page when designing masks). For step-by-step UI, see Complete the Code Format Design Stage. For shell navigation and exports, see Run the Implementation Playbook.