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 訊息的「MULTIPLE ERRORS」說明。在此情況下，當 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) 組合，因為新錯誤會隱藏舊錯誤。例如，請參閱「多個錯誤」。
displayName

string

錯誤顯示名稱。
fields[]

object (FieldReference)

錯誤內容可能涉及 0 個、1 個 (大多數情況) 或更多欄位。舉例來說，如要參照車輛 #4 和貨件 #2 的首次取件，可以執行以下操作：

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

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

string

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

穩定性：不穩定：與特定 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

欄位名稱，例如「vehicles」。
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

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