DYCE Work Order Business Rules
1. Introduction
Purpose
This document serves as the authoritative reference for the business rules governing work orders in DYCE. It describes what is allowed, what is forbidden, and explains why these rules exist.
Audience
- Developers implementing work order functionality across platforms
- Consultants configuring and supporting DYCE installations
- Architects designing integrations with external systems
Scope
These rules apply regardless of the platform or interface being used—whether Business Central, DYCE Connect, Jira, or any other integrated system. The rules are platform-agnostic and represent the core business logic that must be enforced consistently everywhere.
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 that controls how strictly work order lines are enforced: "Open" or "Project" |
| Service Billing Type | - | Defines 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. Foundational Concepts
Before diving into the rules, it's important to understand how the key entities relate to each other.
The Project Hierarchy
Customer
└── Project
└── Project Task
└── Project Planning Line (Budget)
A Customer is the billable party. Each Customer can have multiple Projects. A Project contains Project Tasks representing units of work. Each Project Task has Project Planning Lines that define the budget—how much time or money is allocated for specific types of work. Note if Sell-To and Bill-To Customer deviate from each other, the Sell-To will be used of everything but the invoice.
The Work Order Structure
Work Order
├── Work Order Lines (→ link to Project Planning Lines)
├── Time Recordings
└── Billing Work Order (self-reference or parent reference)
A Work Order represents a discrete work package. It can have Work Order Lines that link it to Project Planning Lines, defining what budget is available. Time Recordings are created against work orders to track actual effort. Every work order has a Billing Work Order—either itself or another work order that serves as the billing aggregation point.
The Billing Relationship
The BWO relationship creates a simple hierarchy for billing purposes:
- Multiple work orders can share the same BWO
- All time recordings from Sub-WOs roll up to the BWO for invoicing
- The BWO determines the Customer, Project and Budget Type for all its Sub-WOs
4. Billing Work Order Hierarchy Rules
The BWO hierarchy is deliberately simple to avoid complexity in billing aggregation. These rules prevent circular dependencies and ensure clear billing paths.
Rule 4.1: Two-Level Maximum
A work order can reference at most one level of indirection to its BWO.
| Configuration | Allowed |
|---|---|
| WO-01 → WO-01 (self) | Yes |
| WO-01 → WO-02 (one level) | Yes |
| WO-01 → WO-02 → WO-03 (two levels) | No |
Why this rule exists: The BWO provides the tasks and the Sub-WOs can be used to organize it. From a invoicing point of view, there is no need for more level. Deeper hierarchies would complicate the billing process.
Rule 4.2: No Loops
A work order cannot reference a BWO that directly or indirectly references it back.
| Configuration | Allowed |
|---|---|
| WO-01 → WO-02, WO-02 → WO-02 | Yes |
| WO-01 → WO-02, WO-02 → WO-01 | No |
| WO-01 → WO-02, WO-02 → WO-03 | No |
Why this rule exists: Loops would corrupt the releasing, posting and invoicing process. The same time recording would be presented twice in Project Billing (Approval).
Rule 4.3: No Nesting of BWOs
A work order that is used as a BWO by other work orders cannot itself reference a different BWO.
In other words: If WO-02 is the BWO for WO-01, then WO-02 must be its own BWO (WO-02 → WO-02).
Why this rule exists: This is a corollary of the two-level rule. If a BWO could reference another BWO, you would have three or more levels, violating Rule 4.1.
Rule 4.4: BWO Cannot Be Changed When In Use
If a work order is currently serving as the BWO for other work orders, its own BWO reference cannot be changed.
Why this rule exists: Changing the BWO of a parent would orphan or incorrectly re-parent all the Sub-WOs that depend on it, potentially corrupting billing relationships.
Rule 4.5: Valid BWO Configurations
| WO | BWO | Valid? | Description |
|---|---|---|---|
| WO-01 | WO-01 | Yes | Self-referencing (standalone) |
| WO-01 | WO-02, WO-02 = WO-02 | Yes | WO-01 is a Sub-WO of WO-02 |
| WO-01 | WO-02, WO-02 = WO-03 | No | Would create nesting |
| WO-01 | WO-02, WO-02 = WO-01 | No | Creates a loop |
5. Customer and Project Rules
The BWO serves as the source of truth for Customer and Project information. This ensures billing consistency across all related work orders.
Rule 5.1: Sub-WO Inherits Customer and Project
A Sub-Work Order automatically inherits the Customer and Project from its Billing Work Order.
When you set the BWO on a work order, the Customer and Project fields are automatically updated to match the BWO's values. (WO use the Sell-To Customer of the Project.)
Why this rule exists: All work billed under a single BWO must go to the same Customer and Project. Allowing different values would break the billing aggregation.
Rule 5.2: Sub-WO Cannot Override Customer or Project
The Customer and Project fields on a Sub-work order are read-only and cannot be changed directly.
To change the Customer or Project of a Sub-WO, you must either:
- Change it on the BWO (which cascades to all Sub-WOs), or
- Change the Sub-WO to reference a different BWO (or itself)
Why this rule exists: Prevents accidental inconsistencies where Sub-WOs could have different billing targets than their BWO.
Rule 5.3: Changes Cascade from BWO to Sub-WOs
When the Customer or Project is changed on a BWO, the change automatically propagates to all Sub-WOs.
Why this rule exists: Maintains consistency across the entire billing hierarchy.
Rule 5.4: Blocking Changes with Released/Posted Time
The Customer or Project on a BWO cannot be changed if any time recordings (on the BWO or any Sub-WO) have status Released or Posted.
This applies to the entire BWO hierarchy—if any Sub-WO has released time, the BWO's Customer/Project is locked.
Why this rule exists: Released and Posted time recordings have financial implications. Changing the Customer or Project would invalidate the billing context of already-processed time recordings.
Rule 5.5: Customer Changes Clear the Project
When the Customer is changed or cleared on a BWO:
- The Project is automatically cleared
- If the new Customer has only one active Project (Status ≠ Complete), that Project is automatically selected
Why this rule exists: Projects belong to Customers. A Project from the old Customer is invalid for the new Customer.
Rule 5.6: Project Requires a Customer
Selecting a Project sets the Customer. Clearing the customer clears the Project.
Why this rule exists: Projects are always owned by a Customer. Selecting a Project without a Customer would create orphaned data.
Rule 5.7: Projects Without Customers Cannot Be Selected
A Project that has no Sell-to Customer defined cannot be selected for a work order.
Why this rule exists: Such Projects cannot be invoiced, making them invalid for work order assignment.
5.8. Changing the Project
Changing the Project updates all time recordings without a PT.
- In time recordings without a PT the new Project will automatically be set.
- In time recordings with a PT, changing the Project would clear the PT, PPL and Activity.
- The time recordings must be updated by the user to avoid losing data or having incomplete time recordings.
- If the time recordings are not updated, they cannot be released and invoiced.
- When the time recordings updated by the user, the old WOL will be removed. As long as the time recording refers to the old WOL it cannot be deleted and will be highlighted in red.
Why this rule exists: It must be possible to change the Customer and Project of a WO in order to correct an error.
6. Work Order Line Rules
Work order lines connect work orders to Project budgets (PPL). They define what budget is available for a work order to consume.
Rule 6.1: BWO Holds the Master Set
The Billing Work Order contains the master set of work order lines. Sub-Work Orders can only reference lines that exist on their BWO.
A BWO can have work order lines that no Sub-WO uses, but a Sub-WO cannot have a work order Line that doesn't exist on its BWO.
Why this rule exists: The BWO represents the total budget allocation and is used for invoicing. Sub-WOs represent how that budget is distributed. A Sub-WO cannot claim budget that wasn't allocated at the BWO level.
Point Completely Reworked in BC --> Must be implemented til mid April
Rule 6.2: Creating Lines on BWO does not copy to Sub-WOs
When a new work order line is created on a BWO, it is not automatically copied to all Sub-WOs.
The WOL can manually be assigned to the Sub-WO. The links back to the original BWO line works via the BillingWorkOrderLineId reference.
Why this rule exists: Assigning WOL corresponds to assigning a budget, which is a concious decision. Automatically assigning WOL to Sub-Wo would for the user to delete them from all Sub-Wo, they are not intended for.
Rule 6.3: Deleting Lines from BWO Cascades
When a work order line is deleted from a BWO, the corresponding lines on all Sub-WOs are automatically deleted.
Why this rule exists: If the master budget allocation is removed, Sub-WOs should not retain phantom references to non-existent budget.
Rule 6.4: Sub-WO Can Only Select from BWO Lines
On a Sub-WO, the "Get work order Line" action only shows work order lines that exist on the parent BWO.
You cannot create new work order lines directly on a Sub-WO. You can only select existing lines from the BWO.
Why this rule exists: Maintains the master/subset relationship between BWO and Sub-WO budgets.
Rule 6.5: Deleting Lines from Sub-WO Does Not Affect BWO
Deleting a work order line from a Sub-WO only removes it from that Sub-WO. The line remains on the BWO and other Sub-WOs.
Why this rule exists: A Sub-WO may not need all the work order lines available from its BWO. Removing it from one Sub-WO shouldn't affect others.
Rule 6.6: Each PPL Can Only Appear Once per Work Order
A Project Planning Line can only be used in one work order line per work order.
If you try to add a PPL that's already assigned to the work order, the system prevents it.
Why this rule exists: Prevents double-counting of budget and the need for the user to select a WOL in the time recording.
Rule 6.7: Deletion Blocked by Time Recordings
A WOL cannot be deleted, if a time recording has been created for the WO and PPL (WOL). The ability to delete a work order line depends on the existence of related Time Recordings. If is a time recording exists, the WOL must not be deleted.
| Time Recording Exists | Can Delete a Work Order Line? |
|---|---|
| No | Yes |
| Yes | No |
Why this rule exists: Open time recordings cannot be released without the WOL, which is why its deletion is prevented. Released and posted time recordings have financial implications that must be preserved.
7. Budget Type Behavior
The Budget Type setting controls how strictly the system enforces work order line constraints during time recording.
Rule 7.1: Budget Type "Open" Behavior
When Budget Type = Open:
- If the WO does not have a customer/ project, the first time recording will set them.
- Time recordings must use the Customer and Project of the WO.
- Time recordings can use any Project Task and Project Planning Line from the work order's Project
- If a time recording uses a PPL not already in the work order lines, a new work order line is automatically created
- The lookups "promote" existing work order lines (show them first) but don't restrict selection
Why this mode exists: Flexibility for reactive work where budget allocation isn't known upfront (e.g., support tickets, ad-hoc requests).
Rule 7.2: Budget Type "Project" Behavior
When Budget Type = Project:
- Can only be set, if a Customer and Project have been assigned.
- Time recordings can ONLY use Project Tasks and PPLs that match existing work order lines
- The lookups are filtered to show only valid PT and PPL (and Activities) from work order lines
- If a work order has no work order lines, time recording fields for PT/PPL are disabled/ do not allow an entry
Why this mode exists: Control for planned work where budget is pre-allocated and must be strictly tracked (e.g., implementation projects possibly based on a sales order).
Rule 7.3: Changing from Open to Project
When changing Budget Type from Open to Project, the system validates:
- A Customer and Project must already be set
- All existing time recordings must have a PPL that matches a work order line
- If time recordings exist without matching work order lines, the system offers to auto-create the missing lines
- If the user declines auto-creation, the change is aborted
Why this rule exists: You cannot switch to strict mode if existing data would become invalid. The system either fixes the data or prevents the change.
Rule 7.4: Changing from Project to Open
Changing Budget Type from Project to Open is always allowed. No validation is required because Open mode is less restrictive than Project mode.
Why this rule exists: Moving to a less restrictive mode cannot create invalid data.
Rule 7.5: Budget Type Cascades to Sub-WOs
When the Budget Type is changed on a BWO, the change applies to all Sub-WOs as well.
Why this rule exists: The Budget Type affects restrictions on which budget can be used for time recordings. All work orders in a billing hierarchy must use the same mode for consistent budget tracking.
Rule 7.6: Budget Type Cannot Be Changed on Sub-WO
A Sub-work order cannot change its Budget Type directly. It is inherited from the BWO.
Why this rule exists: Prevents inconsistencies where different work orders in the same hierarchy have different budget enforcement rules.
8. Time Recording Rules
Time Recordings capture actual work performed. Their behavior varies based on work order configuration and recording status.
Rule 8.1: Status Lifecycle
Time Recordings progress through three statuses:
Open → Released → Posted
| Status | Meaning | Can Edit? | Can Delete? |
|---|---|---|---|
| Open | Draft, or not yet approved | Yes | Yes |
| Released | Approved for billing, quantity calculated | No (only re-open) | No |
| Posted | Financially processed, ledger entries created | No (only cancel) | No |
Why this exists: The lifecycle represents progressive financial commitment. Each step reduces flexibility as the data becomes more financially significant.
Rule 8.2: Budget Type = Project Requires Matching Work Order Line
When a work order has Budget Type = Project, a time recording MUST have a Project Planning Line that matches one of the work order's lines.
If no matching work order line exists, the time recording cannot be saved.
Why this rule exists: In Project mode, all time must be trackable against pre-defined budget allocations.
Rule 8.3.: Budget Type = Project in Sub-WO does not Require Work Order Lines
When a work order, which is not its own BWO has Budget Type = Project and no WOL, a time recording MUST have a Project Planning Line that matches one of the BWO's work order lines.
If the Sub-WO has a WOL, the time recording must use that WOL. IF the Sub-WO has no WOL, it uses the WOL of the BWO.
Why this rule exists: Limiting a Sub-WO to a PPL is a conscious decision, enacted by adding the WOL, instead of having deleting the WOL every time.
Rule 8.4: Budget Type = Open Auto-Completes Customer and Project in the WO
When a work order has Budget Type = Open and Customer and Project are empty, the first time recording with a Customer and Project will set the Customer and Project in the WO. All time recordings without a Customer or Project will automatically be auto-completed.
In Jira and Azure DevOps Customer and Project can amount other things be mapped based on Space, Organization, Customer and Asset. Time recordings will use the mapping information, if the WO has no Project or WOL. Creating a time recording will create the WO with the mapped information.
Why this rule exists: Minimize the administrative overhead, by utilizing mapping.
Rule 8.5: Budget Type = Open limits Time Recordings to the Project (& Customer) of the WO
When a work order has Budget Type = Open and Customer and Project are filled, the time recordings have to use that Customer and Project.
If the Customer and Project in a WO are filled, the time recordings do not allow to select a different Customer or Project.
Why this rule exists: Customer and Project have financial implications like T&T Model, Bill-to Customer, Surcharge Model, etc.. Releasing and invoicing time recordings from different Projects in the same WO is very impracticable.
Rule 8.6: Budget Type = Open Auto-Creates Work Order Lines
When a work order has Budget Type = Open and a time recording uses a PPL not in the work order lines, a new work order line is automatically created.
If it's the last time recording using that PPL and it's deleted (or the PPL is changed), the auto-created work order Line is automatically removed.
Why this rule exists: Open mode allows flexible budget allocation without manual administration.
Rule 8.7: Changing Work Order on Time Recording (to Budget Type = Project)
When changing the work order on a time recording to one with Budget Type = Project:
- Customer and Project are updated to match the new work order
- The existing Project Task, PPL, and Activity are validated against the new work order's lines
- If invalid, these fields are cleared and the user must select valid values. (WO with Budget Type = Open auto-create WOL, which means, that all WOL should exist.)
Why this rule exists: The time recording must conform to the new work order's budget constraints.
Rule 8.8: Changing Work Order on Time Recording (to Budget Type = Open)
When changing the work order on a time recording to one with Budget Type = Open:
- Customer and Project are only updated if they were empty
- If the new work order has exactly one work order line and the time recording's PT/PPL/Activity are empty, they are auto-filled
Why this rule exists: Open mode is flexible, so existing values are preserved unless they need initialization.
Rule 8.9: Clearing Work Order Preserves Fields
When the work order is removed from a time recording, the Customer, Project, Project Task, PPL, and Activity fields are preserved.
Why this rule exists: Removing the work order doesn't invalidate the actual work performed—it just removes the work order association.
Rule 8.10: Activity Defaults from Work Order Line
If a work order line has a default Activity defined, it is automatically populated when the user selects the corresponding Project Task—but can be changed.
Why this rule exists: Reduces data entry while maintaining flexibility for exceptions.
Rule 8.11: Released/Posted Time Blocks Structural Changes
When Released or Posted time recordings exist on a work order (or its Sub-WOs):
- Customer cannot be changed
- Project cannot be changed
- BWO cannot be changed
- WOL cannot be deleted, if there is a TR regardless of its status
Why this rule exists: Financial commitments have been made. Structural changes would invalidate those commitments.
9. Budget Reservation
A work order Line can reserve a budget exclusively for a work order.
- If the reserved Quantity is empty, the WO shares the budget with all other WOs (e.g. multiple WOs for workshops and trainings). Releasing time recordings locks the budget by setting quantity to invoice. First come first served.
- The Reserved Quantity is locked for the work order and limited by the selected quantity except for Time & Material (e.g. Software Changes, Change Requests)
- The Reserved Quantity will be invoiced by the work order it has been reserved in.
- The sum of Reserved Quantities can exceed the actual budget. The Available Quantity will be highlighted in red.
10. Service Billing Type Rules
The Service Billing Type on a Project Planning Line determines how the budget is consumed and invoiced.
Rule 10.1: Time & Material
When Service Billing Type = Time & Material:
- The Reserved Quantity can exceed the a Available Budget.
- The Reserved Quantity is increased when postiing time recordings exceeding it. (The Original Quantity saves the initially set Reserved Quantity.)
- The quantity to invoice of the PPL (Budget) can exceed the quantity of the PPL (Budget)
- The quantity in the PPL (Budget) automatically increases when the posted time recroding/ quantity to invoice exceeds the quantity of the PPL (Budget)
- Sales lines are updated along with the PPL (Budget)
- There is no upper limit. All billable time recordings are going to be invoiced.
- Quantity to Invoice is calculated automatically, when releasing time recordings (sum billable duration)
Why this exists: For ongoing work where the customer pays for actual effort, not a fixed amount.
Rule 10.2: Budget
When Service Billing Type = Budget:
- The Reserved Quantity can exceed the a Available Budget but will not be updated, when posting time recordings.
- The quantity in the PPL (Budget) represents a fixed ceiling
- Posted time recordings can exceed the budgeted quantity but are not invoiced once the limit has been reached
- The total budget invoiced/ to be invoiced cannot exceed the quantity in the PPL (Budget)
Why this exists: For work with a maximum cap—the customer pays up to a limit, not beyond.
Rule 10.3: Fixed Price
When Service Billing Type = Fixed Price:
- The Reserved Quantity can exceed the a Available Budget but will not be updated, when posting time recordings.
- The entire quantity is invoiced when the work is complete
- Partial invoicing is not supported
- Posted time recordings can exceed the budgeted quantity but only the quantity of the PPL (budget) can be invoiced.
- Time recordings track effort but don't drive invoicing quantities
Why this exists: For deliverable-based work where the customer pays a fixed amount regardless of actual effort. The work is invoiced on completion.
11. Work Order Lifecycle Rules
work orders are created on-demand and have specific constraints on modification and deletion.
Rule 11.1: Just-in-Time Creation in Jira
Work orders are created only when needed, not preemptively. Creation is triggered by:
- A time recording is made against a work item (in integrated systems e.g. Jira)
- A budget is assigned to a work item
Why this rule exists: Minimizes data storage, keeps the system clean, and ensures only business-relevant work orders exist.
Rule 11.2: Automatic BWO Assignment (New Work Orders) in Jira
When a new work order is created:
- If it has no parent work item → BWO = itself
- If it has a parent work item → Traverse up the hierarchy to find a parent matching the configured "Billing Work Order Type"
- If a matching parent is found → BWO = that parent
- If no matching parent is found → BWO = itself
Why this rule exists: Automates the most common billing structure (time on tasks rolls up to stories/epics).
Rule 11.3: Existing Work Orders Preserve BWO
When hierarchy information is sent to the backend for an existing work order, the BWO is NOT automatically changed. This prevents automatic processes from overriding manual BWO assignments.
Why this rule exists: Users may have manually set the BWO for specific billing needs. Automatic updates shouldn't override intentional configurations.
Rule 11.4: BWO with Sub-WOs Cannot Be Deleted
A work order that is serving as the BWO for other work orders cannot be deleted. First, all Sub-WOs must either be deleted or reassigned to a different BWO.
Why this rule exists: Deleting a BWO would orphan all its Sub-WOs, creating invalid data.
Rule 11.5: Work Order Cannot Be Deleted with Time Recordings
A work order cannot be deleted if it has any time recordings (regardless of status).
Why this rule exists: Time recordings represent work performed. Deleting the work order would lose that history.
12. Releasing and Posting Rules
Releasing and posting are the financial processing steps that move time recordings from draft to billable.
Rule 12.1: What Releasing Does
When a time recording is released:
- Status changes from Open to Released
- The billable duration is added to "Quantity to Invoice" on the work order Line (if Work Order Posting enabled) or PPL (Budget) (without work order or WO Posting disabled)
- Rounding from the T&T Model is applied to the Quantity to Invoice
Why this exists: Releasing is the approval step. Someone has verified the time recording is accurate and should be billed.
Rule 12.2: Work Order Line Required for Release (with Work Order)
A time recording with a work order and PPL cannot be released unless a matching work order line exists. If no matching work order line exists, the system either:
- Blocks the release with an error, or
- Offers to create the missing work order line automatically If the Sub-WO does not have a WOL, the WOLs of the BWO are used to release the time recordings.
Why this rule exists: The Quantity to Invoice is stored on the work order line. Without one, there's nowhere to track the invoice quantity.
Rule 12.3: What Posting Does
When time recordings are posted:
- Status changes from Released to Posted
- Project Ledger Entries (Usage) are created (PLE Usage) The PLE Usage save the WO and BWO No.
- Project Planning Lines (Billable) are created or updated
- If *Work Order Posting is enabled, a PPL (Billable) per BWO is created. The PPL Billable saves the BWO No.
- The Quantity to Invoice is transferred from work order lines/PPL Budget to the PPL Billable
- Sales Order lines are updated if applicable
Why this exists: Posting creates the actual financial records that feed into invoicing.
Rule 12.4: Posted Time Creates PPL Billable per BWO
When time recordings with work orders are posted, one PPL (Billable) is created per Billing Work Order and PPL (Budget) combination. Multiple Sub-WOs using the same PPL under the same BWO will aggregate into the same PPL (Billable).
Why this rule exists: Billing aggregates at the BWO level, not the individual work order level.
Rule 12.5: Posting Locks the Work Order Hierarchy
After time is posted on a work order (or its Sub-WOs), structural changes are blocked:
- Cannot change Customer or Project on BWO
- Cannot change the BWO relationship
- Cannot delete work order lines used by posted time recordings
Why this rule exists: Posted time recordings have created financial records. Structural changes would make those records inconsistent.
Rule 12.6: Cancellation Reopens Time Recordings
When posted time recording is cancelled:
- Negative Project Ledger Entries (Usage) are created
- Negative PPL (Billable) entries are created (or existing ones reduced) The negative PPL Billable are created based on the positive PPL Billable.
- Time recording status returns to Open
- The cancelled quantity becomes available budget again
Why this rule exists: Allows correction of errors while maintaining a complete audit trail.
13. Synchronization Rules
Work order data synchronizes between multiple systems. These rules ensure data consistency during synchronization.
Rule 13.1: Operations Are Sent Separately
Synchronization sends individual field changes as separate operations, not atomic transactions. For example, changing both Customer and Project sends two separate update operations. Each operations includes all fields of the work order (Customer & Project).
Why this rule exists: Different systems have different transaction models. Separate operations ensure compatibility and sending the complete information ensure data integrity.
Rule 13.2: Intermediate States Must Be Valid
The system must accept intermediate states during multi-operation synchronization. Examples
- When changing Budget Type from Open to Project, the work order lines must be created before the Budget Type is changed—the sync may send these as separate operations.
- When changing the Project in the work order, the WOL can only be deleted, after the time recordings have been switched to the new Project.
Why this rule exists: If intermediate states caused failures, sync would break constantly.
Rule 13.3: Sync Triggers for Work Orders
Synchronization to the backend is triggered by:
- Time recording creation or modification in Jira in a Work Item
- Budget assignment or modification in Jira of a Work Item
- Manual BWO change
- Explicit sync request
- Manual creation or modification in Connect and BC
Work items without these triggers remain only in the source system.
Why this rule exists: Just-in-time sync keeps the backend focused on business-relevant data.
Rule 13.4: Order of Operations Matters
Certain operations must occur in a specific order:
- Work order lines must exist for the time recordings before Budget Type can be changed from Open to Project
- Project must be set before work order lines can be created
- Customer must be set before Project can be selected
Why this rule exists: Each operation validates against existing data. Wrong order creates validation failures.
14. Planned Future Rules
The following rules are planned for future implementation and are not yet enforced.
Milestone-Based Invoicing (Needs further Product Discovery)
Work orders will support milestone-based invoicing:
- Time recordings can be posted without triggering automatic invoicing
- Invoicing is held until milestone conditions are met (e.g., work order marked complete)
- WIP (Work in Progress) tracking during the hold period
Appendix: Quick Reference
Allowed BWO Configurations
| WO-A | WO-A's BWO | WO-B | WO-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 same 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 in TR | Any valid PPL | Only from Work Order Lines |
| Auto-create Work Order Lines | Yes | No |
| Delete Work Order Line (no TR) | Yes | Yes |
| Delete Work Order Line (Open TR) | Yes | No |
| Delete Work Order Line (Released TR) | No | No |
| Delete Work Order Line (Posted TR) | No | No |
Time Recording Status Transitions
┌─────────────────────────────────┐
│ │
▼ │
[Open] ──release──► [Released] ──post──► [Posted]
▲ │ │
│ │ │
└────────reopen───────┘ │
│ │
└─────────────cancel─────────────────────┘
Entity Relationship Summary
Customer (1) ◄─────── (N) Project (1) ◄─────── (N) Project Task
│
│ (1)
▼
(N)
Project Planning Line
│
│ (N)
▼
(N)
Work Order (N) ◄────────────────────────────────► Work Order Line
│
│ (N)
▼
(1)
Billing Work Order (self or other WO)