The Resources API provides the resources necessary to create a planning.
- Delete Transport Resource by business id
Conundra Resources API (1.27.2)
Shift Schedule
ShiftSchedules can be used to describe the recurring pattern for an Employee's availability. They do not trigger availabilities themselves, but can be used to generate availabilities according to this schedule, through the application's user interface.
Providing ShiftSchedules enables planners to do long-term planning using the Employee Overview in the UI, since this allows us to predict when an Employee should be available.
Availability
Availabilities define a specific time range during which an Employee is available to execute tasks. These can either be derived from a ShiftSchedule (via the user interface) or created on an ad-hoc basis.
When an Availability is created or updated, it triggers a consolidation process that generates a snapshot of the corresponding Employee at that moment, referred to as an AvailableEmployee. This snapshot accounts for relocations (managed through the user interface) and Unavailabilities, ensuring a single source of truth for the Employee's status at that point in time.
Any modifications to this AvailableEmployee snapshot activate an algorithm that evaluates potential ResourceCombinations involving the Employee's Availability. During this evaluation, potential TransportResources are assessed. If the heuristic identifies that a specific ResourceCombination would enhance the overall solution's fitness, it is either created or updated.
- Mock serverhttps://developer.conundra.eu/_mock/apis/resource-management/resources-api/transport-resource/{business_id}
- Resources API Productionhttps://api.conundra.eu/resource-management/v1/transport-resource/{business_id}
Transport Resource is retrieved
A TRACTOR is a pulling unit, a TRAILER a cargo unit and a TRUCK is both a pulling and cargo unit.
List of requirements the Employee must fulfill to be allowed to use this TransportResource.
Capabilities this TransportResource provides to the ResourceCombination.
List of requirements the Employee must fulfill, which will be provided as capabilities to the ResourceCombination.
List of capabilities which will be provided to the ResourceCombination, if the Employee has matching driver_skills.
List of capabilities which will be disabled on the resulting ResourceCombination. For example: A TRACTOR with a faulty electric plug, can not be used with a TRAILER that exposes a capability which requires this plug.
These capacities mirror the Order Book capacities.
The business_id of another TransportResource on the same location that should be coupled with this one no matter what. This is known as a fixed coupling.
By using this you can indicate that a tractor should always be coupled with a specific trailer (or the other way around). There is no need to specify the linking in both directions. This overwrites all requirements and as such could lead to seemingly invalid situations, but this is at the discretion of the planner.
The start_location where this TransportResource is based.
Either address information or geo point must be provided. The resolved information will be read only and be filled out after resolving.
Either a home_base or a start_location must be provided.
Conceptually the same as start_location, but with centralized address management.
Either a home_base or a start_location must be provided.
Optional, internal reference (eg: fleet number, ...) for the TransportResource.
Custom data is an extendable hashmap of key-value pairs for client usage. These values have no meaning in the context of Resource Management, but can be used to enrich the data in OptiFlow with relevant information for the end users.
Keys should not be blank nor contain periods.
Labels provided by the TransportResource for its Combination.
Flag to indicate whether a TransportResource can be used for creating ResourceCombinations. When set to true, all future ResourceCombinations will be removed.
[EXPERIMENTAL] Technical characteristics of this TransportResource.
{ "business_id": "tractor-1", "type": "TRACTOR", "license_plate": "1-ABC-987", "requirements": [ "driving license CE" ], "capabilities": [ "big bag" ], "required_capabilities": [ "cooling compressor" ], "skilled_capabilities": [ "sideloading" ], "cant_do": [ "adr-transport" ], "capacities": [ { … } ], "linked_resource": "trailer-1", "start_location": { "name": "Conundra", "address_line": "Voordries 41b", "city": "Oosterzele", "zip_code": "9860", "country_code": "BE", "geo_point": { … } }, "home_base": { "business_id": "depot-1" }, "reference": "fleet-reference-47", "custom_data": { "shop_manager": "John Smith" }, "labels": [ "Transport-resource-label-A" ], "inactive": false, "cost": { "per_kilometer": 0.9, "per_hour": 46.8, "fixed": 213 }, "characteristics": { "maximum_allowed_weight": 3500 }, "route_settings": { "direct_trips": false } }
Home Base [EXPERIMENTAL]
A Home Base is a reusable address that is used to specify the location of Employees or Transport Resources. Instead of specifying a full address for each of these, the user can create a single reusable HomeBase and assign it to all.
Updates to an assigned HomeBase are propagated to all future resources using it.
Forecast [EXPERIMENTAL]
A forecast is the expected the number of shifts that will be required on the given day and location. They is used in the context of capacity planning: a difference in the forecast and the available shifts can indicate ue in the planning. The provided forecasts are only used to show to the end user and are not taken into account for any of the calculations made by the application.
Deployment [EXPERIMENTAL]
Endpoints used for managing Deployments. A Deployment represents the actual assignment of an Employee to one or more TransportResources for a specific time period and location. External deployments can be created to represent work assignments that are managed outside of the Resource Management system. Releasing or unreleasing routes in PTV OptiFlow also manages Deployments. These Deployments are managed internally by Resource Management and cannot be modified by this API.
Actual
Actuals capture the worked hours for an Employee during a completed work shift. This data is used to provide insights into actual worked hours compared to contractual hours, and also helps steer the optimization algorithm towards creating a balanced work week that fulfills contractual hours without significant undershooting or overshooting.
By their nature, Actuals should always represent completed work shifts and therefore should always be in the past, adding Actuals that end in the future could lead to undesired behaviour.