ShowMgr connects the work being managed to the people, equipment, facilities and services needed to perform it. Projects, orders, elements, bookings and actuals each have a distinct role in that model.
Core records and relationships
| Record | Purpose | Main relationships |
|---|---|---|
| Master project | Groups related projects where a higher-level hierarchy is used | Projects |
| Project | Organizes related work | Master project, associated order identity and related orders |
| Order | Defines a unit of work with a class, status and dates | Project, parent order, bookings and commercial records |
| Element | Represents a bookable requirement or a specific person, item, facility or service | Category, type, generic identity and specific identity |
| Booking | Plans an element against an order | Order, element, quantity, dates, status and planned financial values |
| Actual | Records work or usage against a booking | Booking, actual dates and units, financial values, approval and billing information |
| Record | Related record | Logical relationship |
|---|---|---|
| Master project, where used | Project | Higher-level grouping |
| Project | Order | Related units of work |
| Order | Booking | Planned elements for the work |
| Element | Booking | Bookable requirement or assignment |
| Booking | Actual | Recorded work or usage against a booking |
A workflow uses the hierarchy appropriate to the work. Project grouping and parent-order relationships organize work at different levels. Bookings connect elements to orders, and actuals connect recorded work to those bookings.
Application identifiers
The application models use the following identity and relationship properties. The external API has its own payload names, described in the integration article.
| Model | Properties | C# types |
|---|---|---|
| Order |
order_id, project_id, parent_id, order_class_id, order_status_id
|
int |
| Booking |
booking_id, order_id, generic_element_id, specific_element_id; element_id
|
int for the first four properties; Int64 for element_id
|
| Actual |
actual_id, booking_id, order_id
|
int |
| Project |
project_id, order_id, master_project_id
|
int |
| Master project | master_project_id |
long |
Property types describe the model's representation. Workflow requirements are defined separately by the operation and configuration. For example, an order's project association is nullable in the persistence model even though the order application model represents project_id as an integer.
IDs, numbers and names serve different purposes
An order ID identifies a record. The order number and name identify it to users. Projects and other records have similar distinctions. Use the identifier required by the interface when joining data or maintaining an integration mapping.
Keep instance and client context with record identifiers. Do not join records by display name: different records can have the same name, and a name can change without changing the record's identity.
A response can contain information from several records
A booking response can include its order name, project name and actual totals. These fields provide context for displaying the booking. The underlying relationships remain separate: changing an order's name is an order operation, while changing a booking's dates is a booking operation.
When tracing information across modules, identify the owning record and follow its relationship IDs. This keeps operational changes, reporting joins and integration updates aligned with the correct data.