Customer master

SWAT model supports synchronization, storing, management and automatic hydration of Location Master into the incoming booking. The purpose of the Location Master is to reduce the burden on the consuming application to storing coordinates, timewindows and other Location master related information. On upload, if a booking has a value set in booking.pickup_operations_location or booking.pickup_operations_location set, information from corresponding location will be automatically added to a booking, including:

• Latitude and Longitude
• Name
• Time windows
• Service times
• Additional contraints if any (for example, vehicle type)

Location master is represented by three entities:

• Operations Location
• Operations Location Time windows
• Operations Location Groups

Location master is integrated into the processing pipeline allowing referencing location master objects in booking\orders on upload.

Calculation Parameters

Both OperationsLocation !api and OperationsLocationGroup !api models support a calculation_params object. This object allows you to define specific optimization parameters that are automatically applied when a booking references that location or a location from that group.

These parameters are used to model real-world constraints and operational details, such as:

• Time required to enter or exit a facility (e.g., warehouse, secure compound).
• The service capacity of a location (e.g., how many vehicles can be loaded at once).
• Dynamic service times based on the type and quantity of goods.

Relationship with Compound Zones and Cumulative Limitations

The calculation_params object provides a convenient way to implement the concepts of Compound Zones and Cumulative Limitations at the location level.

• enter_time & exit_time: These fields directly create a Compound Zone. When a vehicle's route includes a location with these parameters set, the specified time is added as a penalty for entering and exiting the location. This is ideal for modeling warehouse docking times or security gate clearance.

• cumulative_limitations: This field models the service capacity of a location, such as the maximum number of vehicles that can be dispatched per hour. It directly implements the Cumulative Limitation constraint for that specific location when it's used as a pickup point.

• service_time & coefficients: These fields allow for sophisticated service time calculations. You can set a fixed per-order service time and add a dynamic component based on the booking.product_kind and its demand.

  When a booking is processed at an operations location with these parameters, the total service time is calculated as follows:

  Total Service Time = service_time.fixed + (booking.demand.cbcm * coefficients[product_kind].cbcm) + (booking.demand.weight * coefficients[product_kind].weight) + ...

  The coefficients object contains keys that match the booking.product_kind. Each product_kind key then contains another object where keys match the demand types (e.g., cbcm, weight) and values are the multipliers for that demand.

  For example, if you have a calculation_params object like this:

  "calculation_params": {
    "service_time": { "fixed": 300 },
    "coefficients": { "AMBIENT": { "cbcm": 0.000018, "weight": 0.01 } }
  }

  And a booking with product_kind: "AMBIENT" and demand: { "cbcm": 500000, "weight": 100 }, the service time will be: 300 + (500000 * 0.000018) + (100 * 0.01) = 300 + 9 + 1 = 310 seconds.

Inheritance and Grouping Logic

Parameters can be set at both the OperationsLocationGroup (area) level and the individual OperationsLocation level.

• If calculation_params are not set on an individual OperationsLocation, they are inherited from the OperationsLocationGroup it belongs to.
• If set at both levels, the settings on the individual OperationsLocation take precedence.

warning

When enter_time or exit_time are set at the OperationsLocationGroup level, all locations belonging to that group are treated as a single compound zone. This means the entry and exit time penalties are applied only once for the entire group of locations within a vehicle's route, not for each individual location.

If you need to apply entry/exit times to each location separately, you must define these parameters on each OperationsLocation object individually.

Also, note that if at least one value for enter_time or exit_time is set, then both must be not null; otherwise, both must be null.

For cumulative_limitations and service_time, the values are simply inherited from the group if they are not explicitly defined at the location level.

By leveraging calculation_params, you can build a rich and accurate model of your operational locations, which simplifies the process of creating bookings and ensures that the optimization engine respects your real-world constraints.