DYCE Work Order Business Rules

1. Introduction

Purpose

The authoritative reference for how Work Orders, Work Order Lines, and Time Recordings behave and constrain each other. It states what is allowed, what is forbidden, and — where it isn't obvious — why.

Audience

Developers and integrators implementing or debugging work order behaviour across DYCE Connect, Business Central, and connected systems (Jira, Azure DevOps).

Scope

These rules are platform-agnostic: they hold regardless of the interface used. Rules that apply to only one system are tagged (Jira) etc.

How to read this document

Almost every rule is a guard over the same small state. So the document is built bottom-up:

• §3 State defines what a work order is — the data every rule operates on.
• §4 Invariants are the properties that are always true. They are stated once and referenced by name everywhere else; the big one is the Structural Lock.
• §5 Operations is the working reference: every mutation you can perform, each in the same shape — Guard (when it is blocked or required), Effect (what changes), and Why where it isn't obvious. You look up the operation you're about to do.
• §6–8 cover invoicing behaviour, reservation, and quick-reference tables.

Rules are named, not numbered. (Earlier versions numbered them X.Y; that index is preserved in the appendix for historic reference only.)

2. Glossary

Term	Abbreviation	Definition
Work Order	WO	A discrete unit of work that can be tracked, budgeted, and billed
Billing Work Order	BWO	The work order that serves as the aggregation point for billing. Time and costs from related work orders roll up to this level
Sub-Work Order	Sub-WO	A work order that references a different work order as its BWO
Project	-	Container for planned work, linked to a Customer (technical name in BC: "Job")
Project Task	PT	A unit of work within a Project (technical name in BC: "Job Task")
Project Planning Line	PPL	A budget allocation line within a Project Task. Exists in two types: Budget (planned) and Billable (actual)
Project Ledger Entry	PLE	A record created when posting and/or invoicing time recordings
Work Order Line	WOL	A record that links a work order to a Project Planning Line, defining what budget is available for that work order
Time Recording	TR	A record of actual time spent on work
Activity	-	The type of work being performed (e.g. consulting, development, testing). Derived from the Time & Travel Model
Budget Type	-	A work order setting controlling how strictly work order lines are enforced: "Open" or "Project"
Service Billing Type	-	How a work order line is invoiced: "Time & Material", "Budget", or "Fixed Price"
Organisation	-	External representation of a Customer in service management systems (e.g. Jira Service Management)
Asset	-	Linkable representation of Customers, Contracts, or Projects in external systems

3. State — what a Work Order is

Every rule below is a function over this state.

Customer
  └── Project
        └── Project Task (PT)
              └── Project Planning Line (PPL)   ← the budget

Work Order
  ├── Billing Work Order   → itself, or one other WO (the BWO)
  ├── Budget Type          → Open | Project
  ├── Customer / Project    (owned by the BWO — see BWO Ownership)
  ├── Work Order Lines     → each links the WO to one PPL
  └── Time Recordings      → each records effort against a PPL; status Open|Released|Posted

A work order is a discrete work package. Its Billing Work Order is either itself (a standalone/billing WO) or another work order it bills through (making it a Sub-WO). A billing group is one BWO plus the Sub-WOs that point at it.

Work order lines link the WO to Project Planning Lines, defining the budget it may consume. Time recordings capture actual effort against a PPL and move through three statuses:

Status	Meaning	Editable	Deletable
Open	Draft / not yet approved	Yes	Yes
Released	Approved for billing, quantity calculated	No (re-open only)	No
Posted	Financially processed, ledger entries created	No (cancel only)	No

Each step is a stronger financial commitment and removes flexibility.

Budget Type

The Budget Type sets how strictly recordings are bound to the work order's lines:

• Open — flexible. A recording may use any PT/PPL of the WO's Project; if its PPL has no line yet, a line is auto-created. For reactive work where budget isn't known upfront (support tickets, ad-hoc requests).
• Project — strict. A recording may only use PT/PPLs that already have a work order line; lookups are filtered to those, and with no lines the PT/PPL fields are disabled. For planned work with pre-allocated budget (implementation projects, sales orders). Can only be set once a Customer and Project are assigned.

4. Invariants

Properties that are always true. Stated once here; referenced by name throughout §5.

BWO Ownership

The BWO owns the Customer, Project, and Budget Type for its whole billing group. A Sub-WO mirrors these three fields from its BWO and cannot override them directly; changing them on the BWO cascades to every Sub-WO. This keeps a billing group billable as a unit — one Customer, one Project, one enforcement mode across it.

BWO Lines

Work order lines live on the BWO. The BWO holds the master set; a Sub-WO's lines are a subset, each referencing its BWO master line. A Sub-WO can never hold a line absent from its BWO — it cannot claim budget the BWO didn't allocate. Assigning a BWO line to a Sub-WO is a deliberate act, never automatic.

Flat Hierarchy

A work order's BWO is itself or exactly one real BWO — never deeper, never a loop.

Configuration	Allowed
WO-01 → WO-01 (self)	Yes
WO-01 → WO-02, WO-01 → WO-03 (one level)	Yes
WO-01 → WO-02 → WO-03 (two levels of indirection)	No (nesting)
WO-01 → WO-02, WO-02 → WO-01	No (loop)

A BWO in use by Sub-WOs must be its own BWO (a corollary of the two-level limit). Deeper hierarchies complicate billing; loops would present the same recording twice in Project Billing.

The Structural Lock

Existing time recordings prevent you from restructuring a work order out from under them. It governs four operations: Change the Billing Work Order, Change Customer or Project, Delete a work order, and Delete a work order line.

Once recordings exist, the changes that would orphan or misroute them — or remove the budget they hang on — are blocked. Strength depends on Budget Type and the most advanced status among the recordings, checked across the whole billing group (rows below are the most advanced status present):

Time recording status	Open budget	Project budget
None	allowed	allowed
Open	allowed	blocked
Released / Posted	blocked	blocked

One operation is stricter than the table: Delete a work order line is blocked by any recording in both budget types — because an Open recording can't be released without its line, if Work Order Posting enabled = Yes. The table governs the other three.

Why it exists: Released and Posted recordings were approved and posted under a specific Customer, Project, and billing aggregation; the gated operations would route them somewhere they were never approved, or cut them off from the budget line that carries their Quantity to Invoice. With Budget Type = Project the binding is total — recordings must use the work order's Customer, Project, and lines — so even an Open recording freezes the structure. With Budget Type = Open no such binding exists (recordings may deviate from the header), so only Released/Posted recordings, which carry financial commitment, lock anything.

5. Operations

Each operation lists its Guard (when blocked or required), Effect (what changes), and Why where it isn't obvious.

5.1 Work Orders

Create a work order

• Effect (universal, both systems) — a work order created with no billing-work-order reference becomes its own BWO (standalone); one created with a reference becomes a Sub-WO of that BWO. Either way it's ready to carry lines and recordings.
• (Jira) Just-in-time + auto-BWO. This is how Jira derives that reference. Work orders are created only when needed — triggered by a recording against a work item, or a budget assigned to a work item. On creation the hierarchy is walked up (task → story → epic) to the first parent matching the configured "Billing Work Order Type": that parent becomes the BWO; if no work item above matches, the work order becomes its own BWO. (Other systems supply the reference directly rather than deriving it this way.)
• (Jira) Existing work orders preserve their BWO. Auto-BWO assignment runs only at creation. The work-item hierarchy keeps arriving on later syncs, but for a work order that already exists it is not re-applied — so an automatic process can't clobber a BWO a user set manually. After creation, only an explicit BWO change moves the BWO.

Change the Billing Work Order

(change which WO this one bills through)

• Guard (always) — three independent blocks; all must be clear:

  1. Not a BWO in use. A work order serving as a BWO for others can't change its BWO (it would orphan its Sub-WOs).
  2. Target is a real BWO. The target must be its own BWO, preserving the Flat Hierarchy.
  3. Not locked by recordings (Structural Lock) — blocked once a Project-mode WO has any recording, or an Open-mode WO has a Released/Posted recording.

  Changing the BWO has two starting points, which differ in how the lines are handled:

  • Moving a Sub-WO to a different BWO. Its lines aren't its own — they reference the old BWO's master lines (BWO Lines) — so the move drops them all. A line that carries a recording can't be dropped (Delete a work order line), so the move is additionally blocked while any of its lines has a recording, even an Open one.
  • Demoting a standalone BWO to a Sub-WO. Its lines are its own masters: recording-free lines are deleted, recording-bearing lines are kept.

• Effect (either way) — Customer, Project, and Budget Type are inherited from the new BWO (BWO Ownership); the inherited Project change behaves like Change Customer or Project. Non-posted recordings now bill through the new BWO.

Change Customer or Project

• Guard — two independent blocks:
  1. Not locked by recordings (Structural Lock) — Budget Type Project: blocked once any recording exists in the billing group (no automatic retargeting in Project mode yet — recordings must be moved or deleted first). Open budget: never blocked — Customer/Project may be set, cleared, or changed at any time.
  2. Project needs a Sell-to Customer. A Project can only be selected if it has one (otherwise it can't be invoiced).
• Effect
  • On a BWO, the change cascades to all Sub-WOs (BWO Ownership); Sub-WO Customer/Project are read-only and can only change this way (or by changing the Sub-WO's BWO).
  • Changing/clearing the Customer clears the Project; if the new Customer has exactly one active Project (Status ≠ Complete), it is selected automatically. Selecting a Project sets the Customer; clearing the Customer clears the Project.
  • Changing the Project updates recordings without a PT to the new Project automatically. Recordings with a PT would lose their PT/PPL/Activity, so the user must fix them; until then they can't be released or invoiced, and the old WOL they still reference can't be deleted (it shows red).
• Why — in Project mode the recordings are bound to the WO's Customer/Project, so any change would instantly invalidate them; in Open mode no such binding exists, so the change is always safe and is the supported way to correct an error.

Change Budget Type

• Guard
  • Open → Project: a Customer and Project must be set, and every existing recording must have a PPL matching a work order line. If some don't, the system offers to auto-create the missing lines; declining aborts the change.
  • Project → Open: always allowed — relaxing constraints can't invalidate data.
• Effect — on a BWO, the Budget Type cascades to all Sub-WOs (BWO Ownership); a Sub-WO can't change its Budget Type directly.

Delete a work order

• Guard — two independent blocks; both must be clear:
  1. No dependent Sub-WOs. A work order serving as the BWO for others can't be deleted (it would orphan them) — first delete or reassign all Sub-WOs.
  2. Not locked by recordings (Structural Lock) — Project budget: blocked once any recording exists; Open budget: blocked only while Released/Posted recordings exist (deletable when only Open recordings exist).
• Why — deleting a work order with committed recordings would lose approved, financially recorded work.

5.2 Work Order Lines

Add a work order line (on a BWO)

• Guard — two independent blocks:
  1. On a BWO only. Lines are created on the BWO, never directly on a Sub-WO (BWO Lines).
  2. PPL unique per work order. A PPL may appear in at most one line per work order; adding one already present is rejected (prevents double-counting and the need to pick a line when recording).
• Effect — the line now exists on the BWO, available to assign to Sub-WOs as a separate, deliberate step (BWO Lines).

Assign a line to a Sub-WO

• Guard — only lines that exist on the parent BWO can be selected ("Get Work Order Line"); you cannot create a new line directly on a Sub-WO (BWO Lines).
• Effect — the Sub-WO line references its BWO master line.

Delete a work order line

• Guard — blocked while any time recording references (WO, PPL) — any status, either budget type (Structural Lock, strict form). An Additional Service line is protected the same way.
• Effect
  • Deleting a BWO line cascades: the matching lines on all Sub-WOs are deleted too (Sub-WOs must not keep phantom references to removed budget).
  • Deleting a Sub-WO line removes it from that Sub-WO only; it stays on the BWO and other Sub-WOs.
• Why — an Open recording can't be released without its line; Released/Posted recordings carry financial history that must be preserved. (Stricter than Delete a work order, which allows an Open-only Open-budget WO to be deleted.)

5.3 Time Recordings

Record time (create)

• Guard / behaviour by Budget Type
  • Open: the recording must use the WO's Customer and Project (if filled). If the WO has no Customer/Project, the first recording carrying them sets them on the WO, and other empty recordings are auto-completed. A recording whose PPL has no line auto-creates the line.
  • Project: the recording must use a PT/PPL that matches an existing work order line, or it can't be saved. If a Sub-WO has any line of its own, the recording must use one of those; only a Sub-WO with no lines of its own falls back to the BWO's lines.
• Effect
  • Selecting a PT pre-fills the recording's Activity from the matching line's default (still changeable).
  • An Additional Service may be selected whether or not its line exists yet — saving auto-creates the line (both budget types).
  • (Jira / Azure DevOps) Customer/Project (and more) can be assigned from Space, Organization, Customer, Asset; a recording using such an assignment creates the WO with the assigned information.
• Why — Open mode minimises setup for reactive work; Project mode guarantees all time is trackable against pre-allocated budget. Customer/Project carry financial implications (Time & Travel Model, Bill-to, surcharges), so a recording can't deviate from the WO's once set.

Change the work order on a recording

• To a Project-budget WO — Customer/Project update to match; the existing PT/PPL/Activity are validated against the new WO's lines and cleared if invalid (the user must pick valid ones).
• To an Open-budget WO — Customer/Project update only if they were empty; if the new WO has exactly one line and the recording's PT/PPL/Activity are empty, they're auto-filled.

Clear the work order on a recording

• Effect — Customer, Project, PT, PPL, and Activity are all preserved; only the work order association is removed (the work performed is still valid).

Release

• Guard — a recording with a WO and PPL can't be released unless a matching work order line exists; releasing without one errors. (In Open mode the line was already auto-created when the recording was saved, so this is a safety net.) A Sub-WO without its own line releases through the BWO's lines.
• Effect — status Open → Released; the billable duration is added to "Quantity to Invoice" — on the work order line when the recording has a work order, or on the PPL (Budget) when it has none — with Time & Travel model rounding applied.
• Why — release is the approval step; the Quantity to Invoice has to live on a line.

Post

• Effect — status Released → Posted, and the financial records are written:
  • Project Ledger Entries (Usage) are created, saving the WO and BWO No.
  • PPLs (Billable) are created/updated; with Work Order Posting on, one PPL (Billable) is created per BWO and PPL (Budget) — multiple Sub-WOs on the same PPL under one BWO aggregate into it (billing aggregates at the BWO level).
  • Quantity to Invoice transfers from the work order lines / PPL (Budget) to the PPL (Billable); Sales Order lines update if applicable.
• After posting — the Structural Lock holds the structure: no BWO change, no Customer/Project change on a Project-budget BWO, no deletion of lines used by posted recordings. (Open-budget Customer/Project stays changeable; posted recordings keep their Project and their ledger entries are unaffected.) These records are corrected by Cancel, never by mutating what they point to.

Cancel (a posted recording)

• Effect — negative Project Ledger Entries (Usage) and negative PPL (Billable) entries are created (from the positive ones); the recording returns to Open and the cancelled quantity becomes available budget again. Keeps a complete audit trail.

6. Service Billing Type

The Service Billing Type on a PPL determines how its budget is consumed and invoiced.

	Time & Material	Budget	Fixed Price
Reserved Quantity vs budget	may exceed; not updated by posting	may exceed; not updated by posting	may exceed; not updated by posting
Invoicing ceiling	none — all billable time is invoiced	PPL (Budget) quantity is a hard cap	the PPL (Budget) quantity, invoiced in full on completion
Posting beyond budget	PPL (Budget) auto-increases; Sales lines follow	allowed, but not invoiced past the cap	allowed, but only the budgeted quantity is invoiced
Quantity to Invoice	calculated on release (sum of billable duration)	up to the cap	whole quantity on completion; no partial invoicing

• Time & Material — ongoing work; the customer pays for actual effort.
• Budget — a maximum cap; the customer pays up to a limit.
• Fixed Price — deliverable-based; a fixed amount regardless of effort, invoiced on completion. Recordings track effort but don't drive invoicing quantity.

7. Budget Reservation

A work order line can reserve budget exclusively for its work order.

• An empty Reserved Quantity means the work order shares the budget with all others (e.g. multiple work orders for workshops/trainings); releasing recordings then locks budget via Quantity to Invoice, first come first served.
• A set Reserved Quantity is locked to the work order and limited by the selected quantity — except Time & Material, which may grow (Software Changes, Change Requests).
• The Reserved Quantity is invoiced by the work order that reserved it.
• Reserved Quantities may sum to more than the actual budget; the Available Quantity is then highlighted red.

8. Quick Reference

Valid BWO configurations

WO-A	A's BWO	WO-B	B's BWO	Valid?
WO-01	WO-01	-	-	Yes (standalone)
WO-01	WO-02	WO-02	WO-02	Yes (simple hierarchy)
WO-01	WO-02	WO-03	WO-02	Yes (siblings under one BWO)
WO-01	WO-02	WO-02	WO-03	No (nesting)
WO-01	WO-02	WO-02	WO-01	No (loop)

Budget Type comparison

Aspect	Open	Project
PPL selection when recording	any valid PPL of the Project	only PPLs that have a work order line
Auto-create work order lines	Yes	No
Delete WOL — no recording	Yes	Yes
Delete WOL — Open recording	No	No
Delete WOL — Released/Posted	No	No

WOL deletion is blocked by any recording in both modes (the strict form of the Structural Lock).

Structural Lock at a glance

What recordings block, by budget type and the most advanced recording status present (whole billing group). Governs: Change BWO, Change Customer/Project, Delete WO, Delete WOL.

Time recording status	Open budget	Project budget
None	allowed	allowed
Open	allowed¹	blocked
Released / Posted	blocked	blocked

¹ Except Delete a work order line, blocked by any recording in both modes.

Time Recording status transitions

      ┌─────────────────────────────────┐
      │                                 │
      ▼                                 │
   [Open] ──release──► [Released] ──post──► [Posted]
      ▲                     │                  │
      │                     │                  │
      └────────reopen───────┘                  │
      │                                        │
      └─────────────cancel─────────────────────┘

Entity relationships

Customer (1) ◄─────── (N) Project (1) ◄─────── (N) Project Task
                                                        │
                                                        ▼
                                              Project Planning Line
                                                        │
                                                        ▼
Work Order (N) ◄────────────────────────────────► Work Order Line
     │
     ▼
Billing Work Order (self or other WO)

9. Planned Future

Not yet enforced.

Milestone-based invoicing (needs further product discovery) — recordings can be posted without triggering automatic invoicing; invoicing is held until a milestone condition is met (e.g. work order marked complete); work in progress (WIP) is tracked during the hold.

Addendum: Synchronization

Mechanism, not a business rule — but it shapes how the rules above must be emitted across systems, so it's recorded here.

Work order data synchronizes between systems (Connect, BC, Jira). A change is not one atomic transaction: the originating system emits it as a sequence of single-field operations, each carrying the entity's full state, and the receiver runs its own business-rule checks on each operation as it arrives. Two properties keep that safe:

• Ordered replay. Because the receiver acts on each operation in turn, order matters and every intermediate state must be valid on its own. The originator must sequence operations so the receiver's re-derived state matches with nothing of its own left to emit. Examples: lines must be created before Budget Type changes Open → Project; a Customer must be set before a Project; a WOL is deleted only after its recordings have moved to the new Project.
• Single origin. A change a system received and applied — and any further change its own logic produced while applying it — must never be emitted back. The receiver accepts the incoming change as authoritative by design and applies it without reflecting it to the sender. This is exactly where re-running local logic on receive is dangerous: a side effect of applying a received change can look like a fresh local change and get re-emitted — that reflected change is an echo, and a defect. The one legitimate back-flow is BC stamping the WO No. it assigned onto an inbound work order create — that No. genuinely originates in BC, so emitting it is this rule, not an exception.

Both systems keep enforcing their business-rule checks on receive — a received change must still be valid on arrival — but they do not replay side effects that modify data. The cascades, prunes, and auto-created lines a change implies are computed by the originating system and arrive as their own operations; re-deriving those data mutations on the receiver is exactly what creates an echo.

What syncs: synchronization is driven by tracked data changes, not a curated list of triggers — every create, update, or delete of a synced entity is captured and propagated. Connect → BC is audit-driven (an ordered SyncService); BC → Connect goes through a tracking table. (In Jira a work item only becomes a work order once it is touched, but that is Jira's just-in-time creation — see Create a work order — not the Connect↔BC sync trigger.)

Appendix: Legacy rule-number index

Historic reference only — do not use these numbers in new work. Earlier versions of this document numbered rules X.Y. That catalog has been replaced by the named invariants and operations. This table maps each old number to where its content now lives, so old citations (in other documents or code) can be found and migrated. New cross-references should point at the invariant or operation by name.

Old rule	Now in
4.1 Two-level max	Flat Hierarchy
4.2 No loops	Flat Hierarchy
4.3 No nesting	Flat Hierarchy
4.4 BWO change gated	Change the Billing Work Order
4.5 Valid configurations	Valid BWO configurations
5.1 Sub inherits Customer/Project	BWO Ownership
5.2 Sub can't override	BWO Ownership · Change Customer or Project
5.3 Cascade to Sub-WOs	BWO Ownership · Change Customer or Project
5.4 Customer/Project gated	Change Customer or Project
5.5 Customer change clears Project	Change Customer or Project
5.6 Project requires Customer	Change Customer or Project
5.7 Projects without Customers	Change Customer or Project
5.8 Changing Project / recordings	Change Customer or Project
6.1 BWO holds master set	BWO Lines
6.2 Create doesn't copy	Add a work order line
6.3 Delete BWO line cascades	Delete a work order line
6.4 Sub selects from BWO lines	Assign a line to a Sub-WO
6.5 Delete Sub-WO line	Delete a work order line
6.6 PPL once per WO	Add a work order line
6.7 WOL deletion gated	Delete a work order line
6.8 Additional Services auto-create lines	Record time
7.1 Open behaviour	Budget Type · Record time
7.2 Project behaviour	Budget Type · Record time
7.3 Open → Project	Change Budget Type
7.4 Project → Open	Change Budget Type
7.5 Budget Type cascades	BWO Ownership · Change Budget Type
7.6 Sub can't change Budget Type	BWO Ownership · Change Budget Type
8.1 Status lifecycle	§3 State
8.2 Project requires matching line	Record time
8.3 Project Sub-WO without lines	Record time
8.4 Open auto-completes Customer/Project	Record time
8.5 Open limits to WO Customer/Project	Record time
8.6 Open auto-creates lines	Record time
8.7 Change WO on recording → Project	Change the work order on a recording
8.8 Change WO on recording → Open	Change the work order on a recording
8.9 Clear WO preserves fields	Clear the work order on a recording
8.10 Activity defaults from line	Record time
8.11 Released/Posted blocks changes	Structural Lock
9 Budget Reservation	§7 Budget Reservation
10.1 Time & Material	§6 Service Billing Type
10.2 Budget	§6 Service Billing Type
10.3 Fixed Price	§6 Service Billing Type
11.1 Just-in-time creation	Create a work order
11.2 Automatic BWO assignment	Create a work order
11.3 Existing WOs preserve BWO	Create a work order
11.4 BWO with Sub-WOs can't be deleted	Delete a work order
11.5 WO deletion gated	Delete a work order
12.1 What releasing does	Release
12.2 Line required for release	Release
12.3 What posting does	Post
12.4 PPL (Billable) per BWO	Post
12.5 Posting locks the hierarchy	Post · Structural Lock
12.6 Cancellation reopens recordings	Cancel
13.1 Operations sent separately	Sync
13.2 Intermediate states valid	Sync
13.3 Sync triggers	Sync
13.4 Order of operations	Sync