OptimizeToursResponse

解決導覽最佳化問題後，系統會回應，其中包含每輛車的路線、遭略過的貨物，以及解決方案的總費用。

JSON 表示法 
{
  "routes": [
    {
      object (ShipmentRoute)
    }
  ],
  "requestLabel": string,
  "skippedShipments": [
    {
      object (SkippedShipment)
    }
  ],
  "validationErrors": [
    {
      object (OptimizeToursValidationError)
    }
  ],
  "metrics": {
    object (Metrics)
  }
}
欄位
routes[]

object (ShipmentRoute)

為每輛車計算的路線；第 i 條路線與模型中的第 i 個車輛對應。
requestLabel

string

如果要求中指定了標籤，則為 OptimizeToursRequest.label 的副本。
skippedShipments[]

object (SkippedShipment)

所有跳過的出貨清單。
validationErrors[]

object (OptimizeToursValidationError)

列出可獨立偵測的所有驗證錯誤。查看 OptimizeToursValidationError 訊息的「多重錯誤」說明。在 solvingMode 為 DEFAULT_SOLVE 的情況下，這會加入警告，而非錯誤。
metrics

object (Metrics)

這項解決方案的時間長度、距離和用量指標。

OptimizeToursValidationError

說明驗證 OptimizeToursRequest 時出現的錯誤或警告。

JSON 表示法 
{
  "code": integer,
  "displayName": string,
  "fields": [
    {
      object (FieldReference)
    }
  ],
  "errorMessage": string,
  "offendingValues": string
}
欄位
code

integer

驗證錯誤是由一律存在的組合 (code、displayName) 定義。

這個部分後方的欄位會提供更多錯誤相關資訊。

MULTIPLE ERRORS：如果發生多項錯誤，驗證程序會嘗試輸出其中幾項。與編譯器類似，這個程序不完美。部分驗證錯誤會導致「致命」錯誤，也就是會停止整個驗證程序。以上就是 displayName="UNSPECIFIED" 錯誤等等。部分錯誤可能會導致驗證程序略過其他錯誤。

穩定性：code 和 displayName 應非常穩定。不過，新的代碼和顯示名稱可能會隨著時間而變化，這可能導致指定的 (無效) 要求產生不同的組合 (code、displayName)，因為新的錯誤會隱藏舊一組錯誤。例如「MULTIPLE ERRORS」。
displayName

string

錯誤顯示名稱。
fields[]

object (FieldReference)

錯誤內容可能包含 0、1 (大多數時間) 或多個欄位。舉例來說，參照第 4 號車輛和第 2 批第 2 項取貨方式可按照以下方式完成：

fields { name: "vehicles" index: 4}
fields { name: "shipments" index: 2 subField {name: "pickups" index: 0} }

不過請注意，特定錯誤代碼不會變更 fields 的基數。
errorMessage

string

使用者容易理解的錯誤說明字串。code 和 errorMessage (代碼 !=「UNSPECIFIED」) 之間有 1:1 的對應關係。

穩定性：不穩定：與特定 code 相關聯的錯誤訊息可能會隨時間變更 (希望能更清楚說明)。請改用 displayName 和 code。
offendingValues

string

可能包含欄位的值。但不一定適用於所有情況。請務必不要依賴這項功能，並且只用於手動模型偵錯。

FieldReference

指定驗證錯誤的內容。FieldReference 一律會參照此檔案中的特定欄位，並遵循相同的階層結構。舉例來說，您可以透過以下程式碼，指定車輛 #5 的 startTimeWindows 元素 #2：

name: "vehicles" index: 5 subField { name: "endTimeWindows" index: 2 }

不過，我們會省略 OptimizeToursRequest 或 ShipmentModel 等頂層實體，以免訊息過於擁擠。

JSON 表示法 
{
  "name": string,
  "subField": {
    object (FieldReference)
  },

  // Union field index_or_key can be only one of the following:
  "index": integer,
  "key": string
  // End of list of possible types for union field index_or_key.
}
欄位
name

string

欄位名稱，例如「車輛」。
subField

object (FieldReference)

必要時，可遞迴巢狀子欄位。

聯集欄位 index_or_key。

index_or_key 只能採用下列其中一種設定：
index

integer

欄位的索引 (如果重複)。
key

string

如果欄位是對應，則傳回 鍵。

指標

匯總所有路徑的整體指標。

JSON 表示法 
{
  "aggregatedRouteMetrics": {
    object (AggregatedMetrics)
  },
  "skippedMandatoryShipmentCount": integer,
  "usedVehicleCount": integer,
  "earliestVehicleStartTime": string,
  "latestVehicleEndTime": string,
  "costs": {
    string: number,
    ...
  },
  "totalCost": number
}
欄位
aggregatedRouteMetrics

object (AggregatedMetrics)

按照路徑匯總。每個指標都是所有同名 ShipmentRoute.metrics 欄位的總和 (或負載的最大值)。
skippedMandatoryShipmentCount

integer

略過的強制貨件數量。
usedVehicleCount

integer

使用的車輛數量。注意：如果車輛路線為空白，且 Vehicle.used_if_route_is_empty 為 true，系統會將車輛視為已使用。
earliestVehicleStartTime

string (Timestamp format)

二手車最早的開始時間，計算方式為 ShipmentRoute.vehicle_start_time 中所有二手車的最小值。

RFC3339 世界標準時間「Zulu」格式的時間戳記，精確度達奈秒單位，最多九個小數位數。例如 "2014-10-02T15:01:23Z" 和 "2014-10-02T15:01:23.045123456Z"。
latestVehicleEndTime

string (Timestamp format)

二手車的最新結束時間，計算方式為所有二手車 ShipmentRoute.vehicle_end_time 的最大值。

RFC3339 世界標準時間「Zulu」格式的時間戳記，解析度以奈秒為單位，小數點後最多 9 位。例如 "2014-10-02T15:01:23Z" 和 "2014-10-02T15:01:23.045123456Z"。
costs

map (key: string, value: number)

解決方案的費用，依費用相關要求欄位細分。鍵是相對於輸入 OptimizeToursRequest 的 proto 路徑，例如「model.shipments.pickups.cost」，而值則是相應費用欄位產生的總費用，並在整個解決方案中匯總。換句話說，costs["model.shipments.pickups.cost"] 是解決方案中所有提貨費用的總和。這裡會詳細列出模型中定義的所有費用，但 TransitionAttributes 相關費用除外，因為這類費用自 2022 年 1 月起只會以匯總方式呈報。
totalCost

number

解決方案的總費用。費用對應中所有值的總和。