Key Concepts

Job

A Job is the core unit of work in JobNext. It represents the contract your organisation (the contractor) has been awarded by a customer, together with the activities required to deliver it and the terms and conditions that govern delivery. A Job carries its delivery plan, costs, billing, documents and approvals end-to-end. 

A Job contains a sequence of activities to fulfil the client’s requirements. This sequence is modelled as the Work Breakdown Structure (WBS) of the Job. 

Client’s Requirement

The client (owner) specifies requirements that must be executed under the contract. In JobNext, these are captured in a hierarchy of BOQs (Bills of Quantity). Each BOQ line describes an activity, the quantity and the unit of measure. BOQs can have parent/child relationships, forming a tree of BOQs representing the full scope of client-requested work.

For instance the following BOQs describe a requirement for Earthwork Excavation.

Here the lowest level of BOQs i.e. 1.1.1 and 1.1.2 are the specific client requirements categorized under 1.1 which in turn is categorized under 1.

Execution Activities

JobNext provides a standardised library of execution activities organised as Parent Package → Parent Scope Group → Scope Group → Scope. This library represents the capabilities your organisation can perform. When a Scope from this library is added to a Job, it becomes a Job Scope (i.e., the concrete activity to be delivered for that Job).

The hierarchy above represents a set of standardized activities that forms the capabilities of the contracting organization with the Scope being the actual activity that maybe executed in any Job. When a Scope is added to a Job then this becomes a Job Scope.

Thus more generally speaking a Job is a collection of Job Scopes each of which represent the set of activities that the contracting organization must perform in order to fulfill the client's requirements. Each Job Scope is a Scope that maybe categorized in terms of a Parent Package, Parent Scope Group and Scope Group. The client's requirement on the other hand is modeled in terms of BOQs.

In short: a Job is a collection of Job Scopes (what the contractor will do) that together satisfy the client’s BOQs (what the client asked for). 

Subcontractor Tasks

Where work is delivered by subcontractors, activities are typically planned in two levels: Work Group and Work Order Item. A Job Scope can be broken down into one or more Work Groups, each containing Work Order Items that the subcontractor executes. The Subcontractor Execution Strategy (set during Job planning) determines how Work Groups and Work Order Items are defined for each Job Scope.

For instance if a Job Scope is “Exterior Painting” - it maybe broken down into 3 Work Groups and Each Work Group further subdivided into Work Order Items.

The Subcontractor Execution Strategy determines the Work Groups and Work Order Items that constitute a Job Scope. These decisions are typically taken at the time of creating the Job Project Plan.

Additional Key Concepts (For Technical Users & Developers)

1) Organisational Structure (Business Units & Accounting Centres)

Why it matters: Approvals, visibility and reporting are driven by where a Job “sits” in your organisation.

• Business Unit (BU): Stored on Jobs (e.g., omni_job_master.bu_id). Many transactions inherit BU from the Job.
  
  

• Accounting Centre (AC): Used to route approvals and reporting lines. Approval rules include AC-based and BU-based entries (see tables like omni_approval_ac_based, omni_approval_bu_based and lists in omni_approval_list).
  
  

What users do in the UI

• When creating a Job, select the BU; approvals and visibility follow from this choice.

2) Parties (Customers & Vendors)

Why it matters: Every commercial document is anchored to a Party.

• Customers live in omni_customer_master; Vendors live in omni_vendor_master.

• Transactions reference the party (e.g., omni_invoice_header for customer billing; omni_purchase_order_header and omni_work_order_header for vendors).

What users do in the UI

• Pick the Customer when raising a Job or Invoice.

• Pick the Vendor when raising a Purchase Order (PO) or Work Order (WO).

3) Currencies (Job Currency vs Display/Base Currency)

Why it matters: A Job’s commercial docs run in its Job Currency.

• Commercial headers carry a currency code (e.g., omni_purchase_order_header.job_currency, also present on Work Orders, Invoices, etc.).

• Currency settings are kept in omni_currency_master (code, description, decimals).

• Reports may show Job Currency and a base/display currency side-by-side (depending on report design).
  
  

What users do in the UI

• Confirm Job Currency when creating Jobs and POs/WOs.

• Finance teams align reporting currency via report parameters.

4) Document Lifecycle & Status

Why it matters: Documents move through a standard lifecycle; status controls what you can do next.

Common fields (visible across many headers):

• Draft/Created → Submitted → Approved/Rejected → (optionally) Certified → Posted/Closed
  
  

• Columns such as approved_by, approved_on, approval_comments, certified_by, certified_on, and certified_amount appear on headers like omni_invoice_header, omni_purchase_order_header, omni_work_order_header.
  
  

• Line-level and voucher-level posting creates accounting entries (see Voucher Entries below).

What users do in the UI

• Use the Approve/Reject actions in the document page or approvals queue.
  
  

• Posting rules are enforced by role and document status.

5) Attachments & the Document Library (DMS)

Why it matters: Every critical document (POs, WOs, Invoices, Job docs) can carry files.

• Core files are stored as DMS Documents (omni_dms_document) and linked from business documents via IDs (e.g., omni_invoice_header.dms_document_id) or attachment columns.
  
  

• Many headers also have an attachment URL field for quick links (e.g., omni_invoice_header.attachment).
  
  

What users do in the UI

• Add attachments on the document form (Invoice/PO/WO/Job page).
  
  

• Open attachments from the listing or the document’s Attachments tab.

6) Masters vs Transactions

Why it matters: Masters define the “catalogue”; transactions record execution.

• Masters (examples):
  omni_scope_master (capability catalogue), omni_uom_master (units of measure), omni_currency_master (currencies), party masters (omni_customer_master, omni_vendor_master).

• Transactions (examples):
  omni_job_scope (scopes applied to a Job), omni_purchase_order_header / …_details, omni_work_order_header / …_details, omni_invoice_header, and accounting lines in omni_account_voucher_entry.

What users do in the UI

• Keep Masters tidy (Scopes/UoMs/Currencies/Parties) for clean data entry.
  
  

• Create Transactions against a specific Job and Party.

7) “Reference Links” in Finance (How entries point back)

Why it matters: Finance audit trails must point to the originating document.

• omni_account_voucher_entry contains the ledger movement lines and includes link-back fields like job_id, party_id, plus ref_id and ref_type to indicate the source object (e.g., the specific Invoice/PO/WO line or header).
  
  

• This is how reports can drill from a ledger line to its originating Job document.

What users do in the UI

• Use document drill-downs in finance reports to view the source document.
  
  

• Ensure mapping is set by using standard actions (approve/post) rather than manual edits.

8) IDs, Codes & UIDs (Stable Linking)

Why it matters: Objects have friendly codes for humans and stable IDs/UIDs for systems.

• Numeric IDs (e.g., job_id, invoice_id) are internal keys.
  
  

• User-visible codes (e.g., job_code, po_code, wo_code, invoice_code) appear in the UI and reports.
  
  

• GUID UIDs (e.g., job_uid, invoice_uid, document_uid) are used for robust cross-system links and APIs.
  
  

What users do in the UI

• Search by code in listings; tech users can also search by ID/UID when debugging.

9) Notes, Remarks & Narration (Context in the record)

Why it matters: Free-text fields capture nuance that numbers can’t.

• You’ll see notes, remarks, and narration across headers and lines (e.g., omni_account_voucher_entry.narration, omni_invoice_header.notes).
  
  

• These are indexed for search where configured and also appear in audit logs.
  
  

What users do in the UI

• Add clarifying notes during approval or posting to aid downstream reviewers and auditors.
  
  

10) People, Attendance & Payroll (at a glance)

Why it matters: For clients using HR/Payroll modules, a few fields explain most behaviours.

• People: omni_staff_master includes Date_Of_Joining and resignation_date which drive counts like active headcount and month-end totals.
  
  

• Attendance: Monthly finalisation lands in omni_staff_attendance_finalized (unique per staff, month, year, part_run_number)—these values power dashboards and payroll computations.
  
  

• Payroll: Allowances/deductions feed into payroll SPs and voucher posting; finance drill-downs still follow the Reference Links concept above.
  
  

What users do in the UI

• HR submits attendance; approvers finalise months; payroll runs from the finalised dataset.
  
  

11) Audit & Traceability (Who did what, when)

Why it matters: Trust the data by knowing its history.

• Most tables carry inserted_by / inserted_on and updated_by / updated_on stamps; some also have soft-delete markers like is_deleted, deleted_on, deleted_by (e.g., in the DMS).
  
  

• Approval and workflow actions are logged (e.g., omni_approval_* tables, approval logs).
  
  

What users do in the UI

• Hover history/info icons (where available) on records to view action logs; check Audit or History tabs on key documents.
  
  

12) Roles & Permissions (Who can see or do what)

Why it matters: Access and actions are controlled via roles.

• Roles live in the platform (DNN); JobNext maps them to actions and approval levels (see approval setup tables above).
  
  

• A user’s role determines what menus, jobs, approvals and actions they can access.
  
  

What users do in the UI

• Admins assign roles in Admin → Security Roles; Approvals Setup then maps those roles to BU/AC/Job-based rules.

13) Naming Conventions & Search Tips

Why it matters: Consistent naming makes search and reporting painless.

• Prefer meaningful codes (e.g., JOB-2025-A012, PO-AE-000245), agreed per BU.
  
  

• Use the list page search to find by code; use date filters and status chips to narrow quickly.
  
  

• For deep debugging, search by ID (shown in the detail page URL or a “more info” panel).