Odpowiedź po rozwiązaniu problemu optymalizacji trasy zawierająca trasy przebyte przez każdy pojazd, przesyłki, które zostały pominięte, oraz łączny koszt rozwiązania.
| Zapis JSON | 
|---|
{ "routes": [ { object (  | 
            
| Pola | |
|---|---|
routes[] | 
              
                 
 Trasy obliczone dla każdego pojazdu; i-ta trasa odpowiada i-temu pojazdowi w modelu.  | 
            
requestLabel | 
              
                 
 Kopia   | 
            
skippedShipments[] | 
              
                 
 Lista wszystkich pominiętych przesyłek.  | 
            
validationErrors[] | 
              
                 
 Lista wszystkich błędów weryfikacji, które udało nam się wykryć niezależnie. Zobacz wyjaśnienie „WIELE BŁĘDÓW” dotyczące komunikatu   | 
            
metrics | 
              
                 
 Dane o czasie trwania, odległości i użytkowaniu tego rozwiązania.  | 
            
OptimizeToursValidationError
Opisuje błąd lub ostrzeżenie napotkane podczas weryfikowania elementu OptimizeToursRequest.
| Zapis JSON | 
|---|
{
  "code": integer,
  "displayName": string,
  "fields": [
    {
      object ( | 
              
| Pola | |
|---|---|
code | 
                
                   
 Błąd weryfikacji jest definiowany przez parę ( Inne pola (poniżej) zawierają więcej informacji o błędzie. WIELU BŁĘDÓW: jeśli wystąpiło wiele błędów, proces weryfikacji próbuje zwrócić kilka z nich. Podobnie jak w przypadku kompilatorów, jest to proces niedoskonały. Niektóre błędy weryfikacji są „krytyczne”, co oznacza, że powodują zatrzymanie całego procesu weryfikacji. Dotyczy to m.in. błędów  Stabilność: rozwiązania  PRZEDŁOŻENIE: lista wszystkich par (kod, nazwa): 
  | 
              
displayName | 
                
                   
 Wyświetlana nazwa błędu.  | 
              
fields[] | 
                
                   
 Kontekst błędu może mieć wartość 0, 1 (w większości przypadków) lub większą liczbę pól. Na przykład pierwszy odbiór pojazdu 4 w ramach dostawy 2 można wykonać w ten sposób: Pamiętaj jednak, że moc zbioru funkcji   | 
              
errorMessage | 
                
                   
 Zrozumiały dla człowieka ciąg tekstowy opisujący błąd. Wartości  STAŁOŚĆ: niestabilna: komunikat o błędzie powiązany z danym   | 
              
offendingValues | 
                
                   
 Może zawierać wartości pól. Nie zawsze jest to możliwe. Nie należy się na niego w żaden sposób opierać. Należy go używać tylko do ręcznego debugowania modelu.  | 
              
FieldReference
Określa kontekst błędu weryfikacji. FieldReference zawsze odnosi się do danego pola w tym pliku i ma taką samą strukturę hierarchiczną. Możemy na przykład określić element 2 w elementach startTimeWindows pojazdu 5 za pomocą:
name: "vehicles" index: 5 subField { name: "endTimeWindows" index: 2 }
Jednak pomijamy elementy najwyższego poziomu, takie jak OptimizeToursRequest lub ShipmentModel, aby nie zaśmiecać wiadomości.
| Zapis JSON | 
|---|
{ "name": string, "subField": { object (  | 
              
| Pola | |
|---|---|
name | 
                
                   
 Nazwa pola, np. „pojazdy”.  | 
              
subField | 
                
                   
 W razie potrzeby zagnieżdżone pole podrzędne.  | 
              
Pole unii  
  | 
              |
index | 
                
                   
 Indeks pola, jeśli jest powtarzany.  | 
              
key | 
                
                   
 Klucz, jeśli pole jest mapą.  | 
              
Dane
Zbiorcze wskaźniki, zagregowane dla wszystkich tras.
| Zapis JSON | 
|---|
{
  "aggregatedRouteMetrics": {
    object ( | 
              
| Pola | |
|---|---|
aggregatedRouteMetrics | 
                
                   
 Dane zagregowane na trasach. Każde dane to suma (lub wartość maksymalna w przypadku obciążeń) wszystkich pól   | 
              
skippedMandatoryShipmentCount | 
                
                   
 Liczba pominiętych przesyłek obowiązkowych.  | 
              
usedVehicleCount | 
                
                   
 Liczba wykorzystywanych pojazdów. Uwaga: jeśli trasa pojazdu jest pusta, a   | 
              
earliestVehicleStartTime | 
                
                   
 Najwcześniejszy czas uruchomienia używanego pojazdu, obliczany jako minimum dla wszystkich używanych pojazdów w okresie  Sygnatura czasowa w formacie UTC „Zulu” zdefiniowanym w dokumencie RFC 3339, z dokładnością do nanosekund i maksymalnie 9 miejsc po przecinku. Przykłady:   | 
              
latestVehicleEndTime | 
                
                   
 Najpóźniejszy czas zakończenia dla używanego pojazdu, obliczony jako maksymalny dla wszystkich używanych pojazdów  Sygnatura czasowa w formacie UTC „Zulu” zdefiniowanym w dokumencie RFC 3339, z dokładnością do nanosekund i maksymalnie 9 miejsc po przecinku. Przykłady:   | 
              
costs | 
                
                   
 Koszt rozwiązania z podziałem na pola żądania związane z kosztami. Klucze są ścieżkami proto w odniesieniu do danych wejściowych OptimizeToursRequest, np. „model.shipments.pickups.cost”, a ich wartości to łączny koszt wygenerowany przez odpowiednie pole kosztu, zsumowany dla całego rozwiązania. Inaczej mówiąc, costs[„model.shipments.pickups.cost”] to suma wszystkich kosztów odbioru w ramach rozwiązania. Wszystkie koszty zdefiniowane w modelu są tutaj szczegółowo raportowane, z wyjątkiem kosztów związanych z atributem TransitionAttributes, które od 1 stycznia 2022 r. są raportowane tylko w sposób zagregowany. Obiekt zawierający listę par   | 
              
totalCost | 
                
                   
 Całkowity koszt rozwiązania. Suma wszystkich wartości na mapie kosztów.  |