# Domain A high-level, functional description of the domain entities and their relationships. ## Entities ### Order `Orders` are the backbone of your operation as they describe distinct tasks that need to be executed within the context of an optimization. An `Order` has properties describing when and where it should be executed. It also has requirements and constraints that describe what *resources* are suitable for executing the task. `Orders` come in three types, based on the type of activity and optimization: * `PICKUP`: A *pickup* task for your company * `DELIVERY`: A *delivery* task for your company * `PICKUP_DELIVERY`: A task consisting of both a *pickup* and *delivery* activity. ### Location `Locations` are reusable entities that describe a single `Location` where an activity might be executed. They allow for reuse of these properties across `Orders` which simplifies managing the `Location`-specific properties of your `Orders` by providing as single point of responsibility. Multiple `Locations` can be created for the same geographical location, ie: for modelling distinct business cases in the same building or business centre. `Locations` can heavily impact the `Orders` in a planning: they can include time windows, timings and even additional requirements and constraints. ### Transport Request [Deprecated] `TransportRequests` describe an administrative grouping of `Orders`, this entity is not used in the optimization but can be used to steer it using `Conditionals`. Reason for deprecation: the additional grouping has mostly caused confusion as it has no effect while planning. It was often hard to get a second meaningful `Business ID` which resulted in a 1:1 mapping of this concept. This is not intended to be an alternative to a bulk operation. ### Company `Companies` can be linked to a `TransportRequest` to identify its client, this enables you to steer the optimization using `Conditionals`. Currently, cannot be used on the order level, only through a transport-request. ### Conditional `Conditionals` describe rules for modifying your `Orders`. These rules can target any of the previous entities, enabling you to model your specific business case optimally. Any specific knowledge your planners have, but that can not be represented in your source systems, can find a suitable place here. ## Consolidation The *consolidation* process takes all the previously described entities into account to create a `Consolidated Order`. Through this process it is possible to modify opening hours for all deliveries at a certain location, temporarily increase timings when there are road works, always add requirements to orders matching your predicates, and much more. The `Consolidated Order` cannot be directly managed through the APIs, however, it is included in the domain visualization due to its importance. ### Triggers `Orders` are consolidated when: * they are first created, or * they have a future execution **and** any of its inputs change (eg: the `Order` itself, its `Location`, a `Conditional`, ...) ### Categories [Deprecated] Categories are no longer recommended, there are two ways of organising orders using a single plangroup or multiple labels. For more info see the orderbook topic `How to organise orders for use in the planning`. ## Entity Relationships ![Domain Overview](/assets/domain.20f7f500ee64f699087561a04896d77397fcae4b733b89adefc73acd760bae28.74cdc1ec.png)