--- metadata: - name: generator content: Diplodoc Platform v5.19.6 alternate: - https://docs.routeq.com/doc/en/vrp/properties-of-orders.md - https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md title: RouteQ – sipariş öznitelikleri --- > **Documentation Index:** Fetch the complete configuration index at https://docs.routeq.com/doc/tr/llms.txt # Sipariş özellikleri RouteQ’da siparişler, bir veya daha fazla aracın sınırlamaları göz önünde bulundurarak en uygun sırayla ziyaret ettiği noktaları temsil eder. Siparişlerin belirlenmesi için `locations` istek alanı kullanılır. “Sipariş = `location`” ilkesi çoğu depodan teslimat durumu için geçerlidir. Ancak genel olarak bir rota planlama hizmeti açısından `location`, belirli bir eylemin gerçekleştirilmesi gereken noktadır. Şu durumlarda `locations` içinde siparişlerinizden daha fazla nokta bulunacaktır: - [pickup & delivery](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#pickup-and-delivery) ([delivery_to_any](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#delivery-to-any)) kullanılıyorsa; - [Başlangıç depodan değil](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles-depot.md#vehicle-start-at) veya [bitiş depoda değil](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles-depot.md#return-to-depot) atanmışsa (bu durumda `locations` öylesine başlangıç veya bitiş noktaları eklenir); - siparişiniz RouteQ’daki siparişle aynı değilse, yani siparişiniz planlama hizmetine yüklendiğinde bölünüyorsa veya birleştiriliyorsa. Örneğin: - sipariş çok büyük (herhangi bir aracın kapasitesini aşıyor); - sipariş [birbirleriyle uygunsuz yük kalemi](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#order-incompatibility) içeriyor; - sipariş birkaç noktaya teslimat/noktadan teslim alma şeklindedir. ## Sipariş tanımlayıcısı {#order-id} `id` alanında belirtilen benzersiz sayısal veya satır içi tanımlayıcı zorunlu bir sipariş özniteliğidir. Tanımlayıcı bir istek kapsamında benzersiz olmalıdır. Eğer `id` girilmemişse verilerin Excel’den yüklenmesi ve görevin rota oluşturma işlemine gönderilmesi sırasında bu 1, 2, 3… olarak doldurulur. Sipariş için `id` görülmüşse depoya ait `id` değerinin de belirtilmesi (veya sipariş `id` değeri için 0’ın belirtilmemesi, çünkü bu değer depo için ayrılmıştır) önerilir. Sipariş numarasına ek olarak muhasebe sisteminizden başka sipariş öznitelikleri de belirtebilirsiniz: - `ref` – ek sipariş numarası. Bazı durumlarda alanlar şu şekilde kullanılır: `id` Muhasebe sisteminden gelen dâhili bir tanımlayıcıyla doldurulur (tüm çalışma sayfası için benzersizdir), `ref` – kullanıcıların alışık olduğu belge numarası (benzersiz olmayabilir); - `title` – alıcının adı; - `description` – teslimat noktasının tanımı (örneğin adres); - `comments` – sipariş notu. Bu alandaki bilgiler, [Takip](https://docs.routeq.com/doc/tr/delivery/interface/orders.md#order-card)’teki sipariş kartının ilgili alanlarına ve Yandex Courier uygulamasına yüklenir. Açıklama metnine ek olarak açıklamada bir bağlantı da gönderebilirsiniz ve kurye bunu uygulamadan açabilir. {% note alert "Uyarı" %} `ref`, `title`, `description` ve `comments` alanları bilgi amaçlıdır ve rotalar optimize edilirken kullanılmaz. {% endnote %} ## Sipariş koordinatları {#order-coordinates} Sipariş teslimat noktası [WGS84](https://en.wikipedia.org/wiki/World_Geodetic_System#WGS84) sistemden öğrenilebilir. Siparişin teslimi için koordinatların park veya durak noktasına uygun olması gerekir. Sisteminizde sipariş noktası adres olarak belirtilmişse [coğrafi kodlama](https://yandex.com/dev/maps/geocoder/) (serbest biçimli adresi coğrafi koordinatlara dönüştürme) işlemi gerçekleştirmek gerekli. Koordinatlarını belirlemek için `point.lat` ve `point.lon` alanları kullanılır. Koordinatların yerinin değiştirilmediğinden ve diğerlerinden çok farklı değerde koordinatların bulunmadığından emin olmak önemlidir (kural olarak bu hatalı coğrafi kodlamaya işaret eder – rota oluşturma sırasında böyle bir adres diğer siparişlerden çok uzağa düşebilir ve böyle bir sipariş hiçbir rotaya dâhil edilmez). Siparişin koordinatlarını belirlemek için `location.point` alanı kullanılır. İyi rota oluşturma sonuçları elde etmek için doğru koordinatlar çok önemlidir. Coğrafi kodlayıcı yanlış girilen veya adresle ilgisi olmayan bilgiler içeren adresleri doğru şekilde tanıyamayabilir. Bu nedenle adreslerin sisteminizde nasıl göründüğüne ve saklandığına dikkat etmek önemlidir: - Müşteriler sitedeki formda adres belirtiyorsa, adres girişi doğrulamasını etkinleştirmeniz önerilir (örneğin, [Yandex doğrulaması](https://yandex.ru/dev/maps/jsbox/2.1/input_validation/)). - Adreslerin şirket çalışanları tarafından girilmesi durumunda giriş sürecinin düzenli yapılması önerilir. Sıkça olarak adres tek bir satır olarak giriliyor ve teslimat penceresine ilişkin yorumlar ve bilgiler aynı alanda saklanıyor. Coğrafi kodlama sırasında daha az hata ve tanıma sorunu ortaya çıkması için en azından adresi diğer verilerden ayırmak gerekir. {% include [warehouse-null-coords-processing](_includes/null-coords-processing-92555f6bb287.md) %} ## Sipariş türü {#order-type} Tür `type` anında belirtilir. Olası değerler: - `delivery` – teslimat noktası (varsayılan değer). - `pickup` – gönderinin alınacağı nokta. Sadece bu tür noktalar için (ikisinden biri) şu alanlar mevcuttur: - [delivery_to](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#pickup-and-delivery) – `delivery` türünde benzersiz nokta; - [delivery_to_any](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#delivery-to-any) – `drop_off` türünde benzersiz olmayan nokta; - `drop_off` – [delivery_to_any](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#delivery-to-any) senaryosunda gönderi indirme noktası. - `garage` – [başlangıç noktası depodan değil](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles-depot.md#vehicle-start-at) veya [bitiş noktası depoda değil](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles-depot.md#return-to-depot). - `anchor` – bir [dorsenin](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles.md#coupling) uzun süre bırakılabileceği ve aktarılabileceği nokta. - `parking` – bir [dorsenin](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles.md#coupling) sadece bir siparişin indirilmesi sırasında bırakılabileceği nokta. - `rest_place` – mola bu zamanı dinlenmek için uğranabilecek nokta (bkz. [Mola yeri](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles-rest-schedule.md#rest-place) bölümü). - `courier` – kuryenin mevcut konumu; sadece ek planlama için kullanılır (bkz. [Periyodik ek planlama](https://docs.routeq.com/doc/tr/vrp/additional-planning.md) bölümü). ## Sipariş ağırlığı {#order-weight} Teslimattaki her sipariş için ağırlık belirtilebilir. Ağırlığın belirtilmesi zorunlu değildir ancak araçların aşırı yüklenmesini önlemek açısından önerilir. Siparişin ağırlığını belirlemek için `shipment_size` alanı kullanılır (özniteliklerden birini belirtmek yeterlidir): - `shipment_size.weight_kg` – kilogram cinsinden ağırlık veya hacimsel ağırlık. - `shipment_size.volume_cbm` – metreküp cinsinden sipariş hacmi. `volume_cbm` alanı tanımlanmamışsa sipariş hacmi sipariş boyutlarının çarpımı olarak hesaplanır: - `shipment_size.volume.width_m` – siparişin metre cinsinden genişliği; - `shipment_size.volume.depth_m` – siparişin metre cinsinden uzunluğu; - `shipment_size.volume.height_m` – siparişin metre cinsinden yüksekliği; - `shipment_size.units` – paket sayısı (palet, kutu, fıçı). Sipariş ağırlığı belirtilirken araçların yükleme kapasitesinin de belirtilmesi gerekmektedir. Özellikle dara ağırlığı ile ilgili bilgilerin rota oluşturma sonuçları üzerinde önemli bir etkisi olabileceği durumlarda, siparişin brüt ağırlığının ve hacminin istekte belirtilmesi önerilir. Planlama aşamasında brüt ağırlık bilgisi açıkça bilinmiyorsa, bunun taşınan gönderilerin özelliklerine göre hesaplanması önerilir. Örneğin, paletli bir gönderinin ortalama ağırlığı 800 kg, paletin kendi ağırlığı 20 kg, siparişte net ağırlık 500 kg olarak belirtilmiş ise ve planlama sırasında gönderinin depoda nasıl toplanacağı bilinmiyorsa, bu durumda sipariş rota oluşturmaya girilirken ağırlığı şu şekilde belirtilebilir: `500 kg + 20 kg * (500/800)`= `512,5 kg`, gönderi birimlerinin sayısı – beklenen brüt ağırlığın paletin ortalama ağırlığına oranı olarak: `512,5/800`yani `0,64` palet. Bu seçenek, böyle yaklaşık bir hesaplamaya yönelik olası yaklaşımlardan yalnızca bir tanesidir. Sipariş, her biri kendi boyutlarına sahip birkaç farklı parçadan oluşuyorsa, siparişin nihai özelliklerini belirtmek gerekir: toplam ağırlık, toplam hacim, toplam birim sayısı. Sipariş boyutları olarak maksimum boyutlar belirtilebilir (eğer bu planlama için önemliyse). {% cut "Daha fazla bilgi" %} Örneğin, bir siparişin farklı boyutlarda ve ağırlıklarda olan üç ayrı parçadan oluştuğunu varsayalım: #| ||**Parça No.** | **Birim sayısı** | **Boyutlar, m** | **Her birimin ağırlığı, kg**|| ||1 | 50 | 0,1x0,1x0,1 | 2|| ||2 | 10 | 0,2x0,2x0,2 | 3|| ||3 | 1 | 1x0,5x0,1 | 50|| |# Siparişin nihai özellikleri: - toplam ağırlık – `50 * 2 + 10 * 3 + 50 = 180`; - toplam hacim – `50 * (0,1 * 0,1 * 0,1) + 10 * (0,2 * 0,2 * 0,2) + 1 * (1 * 0,5 * 0,1) = 0,18`; - birim sayısı – `50+10+1 = 61`; - sipariş boyutları – `max(0,1; 0,2; 1) * max(0,1; 0,2; 0,5) * max(0,1; 0,2; 0,1) = 1 * 0,5 * 0,2`. {% endcut %} {% note alert "Uyarı" %} Siparişteki birimlerin ağırlığı, hacmi veya sayısı aracın maksimum kapasitesini aşıyorsa, bu sipariş planlama sırasında dağıtılmamış siparişlere dâhil edilecektir – RouteQ’da sipariş bölünmez bir birim olarak kabul edilir (siparişin bölünmesinin ayrıca yapılandırıldığı durumlar hariç; daha fazla bilgi için [Siparişleri bölme](#split-parts) bölümüne göz atın). Muhasebe sisteminde büyük siparişler varsa bunları RouteQ’ya yükleme aşamasında birkaç siparişe bölmek gerekir. {% endnote %} **Örnek** Bir kurye [kargo bölmesi kapasitesi](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles.md#vehicle-capacity) 10 metreküp (`capacity.volume.width_m` = 2, `capacity.volume.depth_m` = 2,5 ve `capacity.volume.height_m` = 2) olan bir araçla iki siparişi teslim ediyor. Birinci sipariş için hacim `shipment_size.volume_cbm` = 5 olarak belirleniyor. İkinci sipariş için hacim tanımlanmadığından bu değer `shipment_size.volume.width_m`= 2, `shipment_size.volume.depth_m` = 2 ve `shipment_size.volume.height_m` = 1 boyutlarından hesaplanıyor. Her iki sipariş de araca sığıyor. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/42bfe5d7-8d1a884b-8955ad2a-d299f703) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/42bfe5d7-8d1a884b-8955ad2a-d299f703) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#42bfe5d7-8d1a884b-8955ad2a-d299f703) ### Kullanıcı ölçüm birimleri {#custom-units} Belirtilen ağırlık, hacim (boyutlara göre hesaplanır) ve paket sayısı birimlerine ek olarak, RouteQ’da siparişte kullanıcı ölçü birimleri belirtme ve [aracın](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles.md#capacity-custom-units) kapasitesini bu ölçü birimlerine göre sınırlama imkânı mevcuttur. Böyle bir ihtiyaç, kullanılan ölçülere (ağırlık, hacim, paket sayısı) ek olarak aşağıdakilerin de gerekli olması durumunda ortaya çıkabilir: - her kuryenin değeri N para birimini aşmayacak tutarda gönderi taşımasını sağlamak için sipariş tutarı atamak ve kurye tarafından taşınan siparişlerin toplam ücretini sınırlamak; - her kuryenin taşıdığı sipariş sayısını sınırlandırmak. Bu durumda her sipariş için kullanıcı ölçü birimi = 1 belirtebilir ve buna göre her araç için bu sipariş sayısına göre bir sınırlama atanabilir; - kurye başına düşen belirli sipariş sayısını sınırlamaya ilişkin başka bir mantık uygulamak. Örneğin, kesinlikle geç kalınmaması gereken VIP müşteriler varsa, bu siparişlerin mücbir sebeplerden dolayı yerine getirilmeme riskini azaltmak için her kuryenin 2’den fazla VIP siparişe sahip olmaması yönünde bir kural belirtilebilir. Kullanıcı ölçü birimi iki parametre ile belirtilir: - `shipment_size.custom..name` – kullanıcı ölçü biriminin adı; - `shipment_size.custom..size` – siparişin, kullanıcı ölçüm birimine göre büyüklüğü. Varsayılan olarak `shipment_size.custom..size` = 0. Birden fazla kullanıcı ölçü birimi belirtilebilir ve bunlara istediğiniz adı verebilirsiniz. {% note alert "Uyarı" %} [Araç](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles.md#capacity-custom-units)’taki kullanıcı ölçü birimi adı, sipariş için belirtilenle eşleşmelidir. {% endnote %} Kullanıcı parametresi `price` (sipariş tutarı) için Excel dosya sayfalarını doldurma örneği: {% list tabs %} - Orders Sipariş tutarı #| ||`shipment_size.custom.0.name` | `shipment_size.custom.0.size`|| ||`price` | 100|| |# - Vehicles Siparişlerin toplam tutarı #| ||`capacity.custom.0.name` | `capacity.custom.0.size`|| ||`price` | 1000|| |# {% endlist %} **Örnek 1** Örnekte gönderi birimlerinin ağırlığı, hacmi ve sayısı gösterilmektedir. Ayrıca sipariş tutarı ve taşınan siparişlerin toplam ücreti ile ilgili araç sınırlaması da `location.shipment_size.custom.0` ve `vehicle.capacity.custom.0` parametreleri kullanılarak atanır. Ağırlık, hacim ve paket sayısına göre kullanımları küçük olmasına rağmen, her biri 1 sipariş taşıyan 2 araç olduğu görülüyor, bunun nedeni bu siparişlerin tutarının araç için belirlenen limite yakın olmasıdır. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/3fe69cbc-20f9a319-3b43374a-7d8def6a) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/3fe69cbc-20f9a319-3b43374a-7d8def6a) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#3fe69cbc-20f9a319-3b43374a-7d8def6a) **Örnek 2** Örnek 1’dekiyle aynı ancak ek olarak kuryenin götürebileceği maksimum sipariş sayısı belirtilmiştir. Limit `location.shipment_size.custom.1` ve `vehicle.capacity.custom.1` parametreleri kullanılarak tanımlanır. Her araç artık en fazla 5 sipariş taşıyabilir. Üç araçtaki sipariş sayısının değiştiği görülüyor. Artık 1 siparişi yalnızca 1 araba taşıyor ve toplam tutar limiti nedeniyle siparişler artık eklenemiyor. Geri kalan araçlarda toplam tutar açısından maksimum kullanım elde edildi fakat sipariş sayısındaki sınırlamaya uyumak da mümkün oldu. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/c9b6b1ab-96f9ef28-8ae9e7db-29daf4c5) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/c9b6b1ab-96f9ef28-8ae9e7db-29daf4c5) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#c9b6b1ab-96f9ef28-8ae9e7db-29daf4c5) ## Sipariş boyutları {#order-dimensions} Sipariş oluşturulurken sadece ağırlığını ve hacmini değil, aynı zamanda boyutlarını da dikkate almak gerekebilir. Örneğin kargo bölmesi 1x1x1 metre olan bir araca 2x0,5x0,5 metre ölçülerindeki bir kutuyu – hacim hesabıyla uygun olsa bile – sığdırmak mümkün olmaz. {% include [order-weight-example](_includes/order-weight-example-5d2d29187dad.md) %} RouteQ’da taşınan gönderinin türünü belirtmek için `location.shipment_size.volume.type` parametresi kullanılabilir. Olası değerler: - `bulk` – dökme. Sipariş oluşturulurken boyutlar dikkate alınmaz. Varsayılan olarak kullanılır. - `rigid` – katı. Sipariş oluşturulurken boyutlar dikkate alınır ancak yük istendiği gibi yerleştirilebilir (yani herhangi bir yüzü araç zeminine dayanabilir). - `fixed_bottom` – katı, sabit tabanlı. Sipariş oluşturulurken gönderi ters çevrilemez (sabit ölçü – `height`) ancak döndürülebilir (yükün belirli bir yüzü araç zeminine dayanmalıdır). {% note alert "Uyarı" %} Sipariş boyutlarının kontrolü her sipariş için ayrı ayrı gerçekleştirilir. Hacim olarak uygun ancak boyut olarak sığmayan birden fazla sipariş bir araca atanabilir. Örneğin hacmi 1x1x1 olan bir gönderi bölmesine 0,6x0,6x0,6 ölçülerinde 2 sipariş yerleştirilebilir. {% endnote %} **Örnek 1** Kargo bölmesi boyutu 1x1x1 metre olan bir araç, 2x0,5x0,5 metre boyutlarında bir sipariş teslim etmektedir. Boyutlar varsayılan olarak dikkate alınmadığından, sipariş araca sığıyor. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/ea95dcf7-56715bc9-ae0afd68-def436be) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/ea95dcf7-56715bc9-ae0afd68-def436be) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#ea95dcf7-56715bc9-ae0afd68-def436be) **Örnek 2** Örnek 1’dekiyle aynı ancak sipariş “katı” olduğu için otomobile sığmıyor. Sonuç olarak sipariş teslim edilmiyor. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/dc311222-3e17439a-4afb0f00-d5266bdd) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/dc311222-3e17439a-4afb0f00-d5266bdd) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#dc311222-3e17439a-4afb0f00-d5266bdd) ### Siparişin araçtaki yönü {#order-orientation-in-vehicle} `rigid` veya `fixed_bottom` türündeki siparişlerin araç eksenine göre yönünü belirlemek için `location.shipment_size.volume.align` alanı kullanılır. Varsayılan değer `align` = `all_axes` şeklindedir ve siparişler kesinlikle araç eksenine paralel olarak yerleştirilmelidir. Ancak bazen gönderiyu araca belirli bir açıda yerleştirmek daha uygundur. Bu senaryoyu desteklemek için `align` = `height` değeri kullanılır. Yön `type` ve `align` değerlerinin kombinasyonuna bağlıdır. Olası seçenekler aşağıda sıralanmıştır: #| ||`align`/`type` | `rigid` | `fixed_bottom`|| ||`all_axes` | Sipariş herhangi bir eksene göre 900 döndürülebilir ancak her zaman kasa eksenlerine tam paralel şekilde yerleştirilir. | Sipariş 900 döndürülebilir ancak tabanı** değişmez, yani araç kasasının tabanında durur.|| ||`height` | Herhangi bir yüzün araç kasasının tabanında kalması, yani yüksekliğin* kargo bölümünün yüksekliğine paralel olması koşuluyla, sipariş istendiği gibi döndürülebilir. | Tabanın** değişmemesi, yani araç kasasının tabanında durması koşuluyla, sipariş istendiği gibi döndürülebilir.|| |# \* `shipment_size.volume.height_m` parametresi – siparişin metre cinsinden yüksekliği. ** Parametrelerde ifade edilen ve genişlik x uzunluk olarak belirlenen yüz: - `shipment_size.volume.width_m` – siparişin metre cinsinden genişliği; - `shipment_size.volume.depth_m` – siparişin metre cinsinden uzunluğu. **Örnek 1** Planlama görevinde 0,4x3,2x1 m ölçülerinde bir sipariş ve kargo bölmesi 2x3x1,5 m olan bir araç var. Burada `location.shipment_size.volume.type` = `fixed_bottom` olarak belirtilmiş – siparişin döndürülmemesi gerekiyor. Yön (`location.shipment_size.volume.align`) belirtilmemiş, gönderi aracın eksenine paralel yerleştirilmelidir. Sonuç olarak siparişin uzunluğu kasa uzunluğundan fazla olduğu için sipariş araca sığmamaktadır. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/f1bc446-8916a0ee-27d6a128-517fd013) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/f1bc446-8916a0ee-27d6a128-517fd013) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#f1bc446-8916a0ee-27d6a128-517fd013) **Örnek 2** Örnek 1’dekiyle aynı ancak `location.shipment_size.volume.align` = `height`, gönderi herhangi bir açıda döndürülebilir. Algoritmanın çözümü sonucunda gönderi kasa içerisine çapraz olarak yerleştirilir ve sipariş teslim edilir. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/287f83a8-b9a0b92d-e3766760-f9425df3) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/287f83a8-b9a0b92d-e3766760-f9425df3) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#287f83a8-b9a0b92d-e3766760-f9425df3) ## Sipariş zaman aralığı {#order-time-window} Tüm siparişlerde bir zaman aralığı belirtilmiş olmalıdır. Bu, aracın veya kuryenin sipariş adresine ulaşması gereken zaman aralığıdır. Zaman aralığını belirlemek için `time_window` alanı kullanılır. {% include [warehouse-tw-formats](_includes/tw-formats-1f195c4b77e0.md) %} Zaman aralığının türüne bağlı olarak, kurye siparişe kesinlikle belirtilen aralıkta (**katı** pencere) ulaşır veya ek bir cezayla pencereyi ihlal edebilir (**esnek** pencere). {% include [warehouse-hard-window](_includes/hard-window-175aabca27f5.md) %} Belirli bir zamana kadar teslimat yaparken, özellikle zaman aralığı katı ise, aynı üst ve alt zaman sınırlarına sahip bir pencere belirtilmesi önerilmez. Örneğin, siparişin kesinlikle saat 09.00’da teslim edilmesi gerekiyorsa, algoritma `9:00:00 – 9:00:00` değerini aynen işleyecektir ancak pratikte sürücü böyle bir siparişe daha erken ulaşacaktır. Bu nedenle zaman aralığının örneğin `8:30:00 – 9:00:00` gibi daha gerçekçi bir aralıkta belirtilmesi önerilir. Siparişlerin zaman aralıkları ne kadar daha dar olursa, bu siparişleri belirtilen zaman aralıkları içinde yerine getirmek için o kadar daha fazla araca ihtiyaç duyulacaktır (diğer koşulların eşit olduğunu varsayarsak). Bu nedenle zaman aralığının, belirtilen noktaya gerçekte varış olasılığını mümkün olduğu kadar doğru yansıtması gerekir. {% note alert "Uyarı" %} Bir zaman aralığının tutturulup tutturulmadığı belirlenirken hizmet süresi dikkate alınmaz. Örneğin zaman aralığı `10:00 – 16:00` olarak atanmışsa ve hizmet sürüsü 30 dakikaysa, siparişe 15.59’da varılması zamanında sayılır. {% endnote %} ### Sipariş çoklu zaman aralığı {#order-multiple-time-windows} RouteQ’da gerekirse birden fazla zaman aralığı belirleyebilirsiniz. Bu, şu durumlarda kullanılır: - teslimat sırasında teslimat noktasının çalışmasında bir kesinti varsa (örneğin teslimatın 9 ila 12 veya 15 ila 18 arasında yapılması gerekir); - birkaç günlük bir rotada teslimat günlerinden birinde ancak belirtilen saatte (örneğin 9’dan 18’e kadar) teslimat yapmak gerekiyorsa. `time_windows` alanında `time_window` ögeler dizisi belirtilir. Sipariş olası pencerelerden birinde yerine getirilecek ve API yanıtının `used_time_window` alanı, kullanılan zaman aralığıyla ilgili bilgileri içerecektir. Her zaman aralığı için haricî bir katı pencere (`hard_time_window`) atayabilirsiniz. {% note alert "Uyarı" %} `time_window` pencereleri birbiriyle çakışmamalıdır. Örneğin aynı anda hem 09.00-12.00 hem 11.00-14.00 saatleri arasında pencere belirtilemez. {% endnote %} **Örnek 1** İki siparişin `time_windows.0.time_window` = `9:00 – 12:00` ve `time_windows.1.time_window` = `15:00 – 18:00` (Excel açıklaması formatı) olmak üzere iki zaman aralığında teslim edilmesi gerekiyor. Siparişler ilk zaman aralığında teslim edilir. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/9dc1b545-60cc0bc8-cce0f8e7-54afc7d4) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/9dc1b545-60cc0bc8-cce0f8e7-54afc7d4) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#9dc1b545-60cc0bc8-cce0f8e7-54afc7d4) **Örnek 2** İki gün içinde saat 8 ila 15 arasında 20 siparişin teslim edilmesi gerekiyor. Sipariş pencereleri göreceli formatta kaydedilmiştir: ilk gün için – `08:00:00 – 15:00:00`, ikinci gün için – `1.08:00:00 – 1.15:00:00`. Bu durumda [depo zaman aralığının](https://docs.routeq.com/doc/tr/vrp/properties-of-depot.md#depot-time-window) de göreceli formatta yazıldığını ve gerekli tarihlerin her ikisini de içerdiğini not edin. [Cмены работы автомобиля](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles-routes.md#shifts) her iki gün için de belirtilmelidir. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/34515e6-9a58e51f-b478f7ba-c52be082) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/34515e6-9a58e51f-b478f7ba-c52be082) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#34515e6-9a58e51f-b478f7ba-c52be082) ## Sipariş zaman aralıklarını ihlal etme cezaları {#penalties-time-window-violation} Sipariş teslimatının planlanabildiği ancak teslimatın belirtilen zaman aralığından daha erken veya daha geç gerçekleşmesi durumunda bu ceza rotanın toplam ücretine eklenir. {% note info "Not" %} Bu davranış sadece **esnek** bir zaman aralığı tanımlandığında mümkündür. **Katı** pencere ihlal ediliyorsa bu durumda sipariş otomatik olarak teslim edilmedi olarak işaretlenir ve tüm rotaların dışında bırakılır. {% endnote %} Zamanında gerçekleştirilmeyen teslimat için ceza atanması, daha az önemli siparişlerin aleyhinde olmasına rağmen en önemli siparişlerin gecikmeden teslim edilme olasılığını artırır. Siparişlerin zamanında teslimatını yönetmek için RouteQ’da aşağıdaki nesneler kullanılabilir: - `location.penalty.early` – zaman aralığından daha erken gerçekleştirilen teslimatlar için uygulanacak cezayı belirtir; - `location.penalty.late` – zaman aralığından daha geç gerçekleştirilen teslimatlar için uygulanacak cezayı belirtir; - `location.penalty.out_of_time` – zaman aralığından daha erken veya daha geç gerçekleştirilen teslimatlar için uygulanacak genel cezayı belirtir. Eğer `location.penalty.early` ve `location.penalty.late` atanmıyorsa o zaman `location.penalty.out_of_time` değerleri kullanılır (yani `early` ve `late` `out_of_time` ögesini geçersiz kılma işlevi görür). Her nesne iki alandan oluşur: - `fixed` – zamanında gerçekleştirilmeyen teslimat sabit cezası; - `minute` – zamanında gerçekleştirilmeyen teslimatta her dakika için uygulanan ceza. Eğer `location.penalty.early` veya `location.penalty.late` için sadece bir değer atanmışsa (`fixed` veya `minute`), o zaman ikincisi `location.penalty.out_of_time` ögesinden alınır. Örneğin sadece `location.penalty.late.fixed` atanmış olabilir. Bu durumda siparişte geç kalınması hâlinde her dakika için ceza olarak `location.penalty.out_of_time.minute` kullanılacaktır. {% note info "Not" %} Yukarıdaki alanlar, kullanıcıların sipariş teslimatı önceliklerini tanımlarken başlangıç değerleri olarak kullanılması önerilen varsayılan değerler içerir. Şüpheniz varsa doğru katsayıları belirlemek için RouteQ analistleriyle iletişime geçin. {% endnote %} **Örnek** Aşağıdaki örnekte siparişlerin erken ve geç teslimi için farklı cezalar içeren bir istek yer almaktadır. Lütfen unutmayın: tüm siparişlerde `location.hard_window` = `false`. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/eba6bf99-5869af34-2d5a9fed-bbecb712) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/eba6bf99-5869af34-2d5a9fed-bbecb712) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#eba6bf99-5869af34-2d5a9fed-bbecb712) ## Sipariş teslimatında hizmet süresi {#order-service-duration-delivery} Rotalar planlanırken her sipariş için hizmet süresinin (hizmet verilen süre) belirtilmesi gerekir. Şu parametreler mevcuttur (saniye cinsinden verilir): - `service_duration_s` – siparişi alıcıya teslim etme süresi. - `shared_service_duration_s` – belge alıp verme veya park etme süresi. Aynı adrese birden fazla sipariş teslim ediliyorsa bunlar birleştirilebilir ve çoklu sipariş oluşturulabilir. Bu durumda çoklu siparişteki tüm siparişlerin hizmet süresi Toplam{`service_duration_s`} + Maksimum{`shared_service_duration_s`} şeklinde hesaplanır. çoklu siparişteki biri siparişi hariç tutmak ve onun hizmet süresini (`shared_service_duration_s`) ayrı hesaplamak için `location.can_be_merged` = `false` değerini kullanın. Daha fazla bilgi için [Çoklu siparişler](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#multi-orders) bölümüne göz atın. Bazı senaryolarda hizmet süresi hesaplanırken ek parametreler dikkate alınır. Bunlar [Olası lojistik senaryolar](https://docs.routeq.com/doc/tr/vrp/supported-use-cases.md) bölümünde açıklanmıştır (örneğin siparişlerin [çapraz sevkiyatta](https://docs.routeq.com/doc/tr/vrp/supported-use-cases.md#cross-docking) yeniden yüklenme süresi). Ayrıca bir aracın hizmet süresi hesaplanırken [hizmet süresi düzeltmesi](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles.md#service-duration) da belirtilebilir. Varsayılan olarak hizmet süresi sipariş zaman aralığına dahil edilmez. Sipariş penceresi 18.00’e kadar olmasına rağmen kuryenin noktaya 17.59’da vardığı durumlar söz konusu olabilir. Bu gibi durumlardan kaçınmak için `options.penalize_late_service` seçeneğini kullanın. Bu seçenek [gecikme cezasının](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md) servis başlangıç anına kadar mı (varsayılan değer `false`) yoksa servis bitiş anına kadar mı (`true`) uygulandığını belirtir. Yani değer `true` olarak atandığında algoritma hizmet süresini zaman aralığı içinde tamamlamaya çalışacaktır. Kaynak verilerde gerçekçi hizmet süreleri belirtin. Servis için çok fazla zaman ayırırsanız algoritma gerçekte gerekenden daha fazla kurye planlayacaktır. Çok az zaman ayırırsanız elde edilen çözüm çok iyimser olacak ve siparişlerin tesliminde gecikmeler yaşanacaktır. {% note alert "Uyarı" %} Çok sayıda sipariş söz konusu olduğunda, sipariş başına sürede oluşan küçük bir fark bile sonuçta kurye sayısının değişmesine yol açabilir. Örneğin 200 siparişte 2’şer dakikalık hizmet süresi farkı neredeyse bir kuryenin tam bir iş gününe denk geliyor: 200 * 2 dk = 400 dk = neredeyse 7 saat. {% endnote %} Hesaplamada ortalama sürenin kullanılması önemlidir. Örneğin kurye 10 dağıtımdan 9’unda noktada 10 dakika harcarken bir dağıtımda ise 30 dakika harcıyor. Bu durumda ortalama hizmet süresi: (9 * 10 dk + 1 * 30 dk) / 10 = 12 dk. Hizmet süresi değerini seçmek için: - Şu değeri hesaplayın: − * . Sonuçta kuryenin noktalar arasında hareket edebilmesi için makul bir sürenin kalması gerekiyor. - Hizmet süreleri teslimat adreslerine bağlıysa, farklı hizmet sürelerinden oluşan bir dizin oluşturun. Örneğin, aynı perakende zincirinin mağazalarında siparişin alınması farklı zamanlarda gerçekleştiriliyorsa. Dizin RouteQ hizmetinin dışında oluşturulur. - Siparişlerin hacim ve ağırlık özellikleri büyük farklılıklar gösteriyorsa hizmet süresini hesaplamak için bir formül uygulayın. Örneğin her 100 kg için 1 dakika fakat 5 dakikadan az olmamak üzere. Değerlerin açıkça belirtilmesi gerekir, bu nedenle formülün RouteQ hizmeti dışında kullanılması gerekir. Hizmet süresi değerini kontrol etmek için rotalardan gerçekten geçin ve Takip’teki [kurye performans kalitesi](https://docs.routeq.com/doc/tr/delivery/interface/quality-report.md) raporunu kullanın. **Örnek** Örnekte her sipariş için hizmet süresi tanımlanmıştır. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/a0a296d4-80b9efc6-354e65ed-e165934) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/a0a296d4-80b9efc6-354e65ed-e165934) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#a0a296d4-80b9efc6-354e65ed-e165934) ## Depoda sipariş yükleme veya boşaltma hizmet süresi {#order-service-duration-load} Depodaki genel hizmet süresine ek olarak, RouteQ’da ayrı bir siparişin bir araca yüklenme veya yerinden teslim alınan (pickup) bir siparişinin depoda indirilmesi için gereken süreyi belirtebilirsiniz. Bir siparişin yüklenme veya indirilme süresini belirlemek için `location.depot_duration_s` istek alanı kullanılır. Bir depo için toplam bir hizmet süresi atanmışsa bu süre siparişlerin her araca yüklenmesi için gereken toplam süreye eklenecektir. Ek bilgileri [Depodaki hizmet süresi](https://docs.routeq.com/doc/tr/vrp/properties-of-depot.md#depot-service-duration) bölümünde bulabilirsiniz. Çapraz sevkiyat kullanılırken siparişlerin yeniden yüklenme süresi `location.crossdock_service_duration_s` göz önünde bulundurulur. Planlama ile ilgili örnekler [Merkezden dağıtım](https://docs.routeq.com/doc/tr/vrp/supported-use-cases.md#cross-docking) bölümünde ele alınmıştır. **Örnek** Her üç sipariş için depodaki hizmet süresi 5 dakika, depodaki toplam hizmet süresi ise 10 dakikadır. Böylece araç yükleme için 25 dakika harcayacaktır. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/882ca3fa-6a13582-c9044da9-60e88dfc) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/882ca3fa-6a13582-c9044da9-60e88dfc) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#882ca3fa-6a13582-c9044da9-60e88dfc) ## Siparişin depoda hazır olma zamanı {#order-time-depot-ready} Varsayılan olarak, siparişlerin bir depodan teslimatı planlanırken, bunların sevkiyata hazır olduğu varsayılır. Ancak bu durum her zaman geçerli olmayabilir (örneğin siparişler gün içinde hazırlanıyorsa). Bu gibi durumlarda siparişin hazır olma zamanı dikkate alınmalıdır. Sıkça olarak kuryeler depodan birkaç sefer yaparak siparişleri hazır oldukça alır (bu plan için [kuryenin birden fazla sefer gerçekleştirme](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles-routes.md#vehicle-max-runs) seçeneğini etkinleştirmek gerekir). Siparişin hazır olma zamanı `depot_ready_time` alanında belirlenir. Bu alan sadece `pickup` siparişlerle ilişkilendirilmemiş `delivery` türündeki siparişler için (yani sadece depodan teslimatlar için) kullanılabilir. `depot_ready_time` tarihi ve saati, zaman aralıklarını tanımlarken kullanılan formatla aynı şekilde belirtilir. Değer örnekleri: - `10:15` - `2020-09-06T13:15:00+03:00` (6 Eylül 2020, 13.15 GMT+3 saat dilimi) - `2020-09-06T10:15:00Z` (6 Eylül 2020, 10.15 UTC saat dilimi) **Örnek** Örnekte, her birinin hazır olma saati (09.00, 10.00, 12.00 veya 14.00) olarak belirtilmiş 10 siparişin teslimatı gerçekleştirilmektedir. Sonuç olarak kuryenin rotasındaki seferler `depot_ready_time` dikkate alınarak oluşturulur. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/d342f013-1c3824a1-f7eaa2a3-c84aee6) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/d342f013-1c3824a1-f7eaa2a3-c84aee6) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#d342f013-1c3824a1-f7eaa2a3-c84aee6) ## Siparişin depodan alınabileceği en son zaman {#depot-expiring-time} Genelde siparişler deponun zaman aralıkları dâhilinde herhangi bir zamanda depodan alınabilir. Ancak siparişin belirli bir zamanı aşmadan alınması gerekiyorsa `depot_expiring_time` parametresini kullanın. Bu parametre cezaya tabi olmayan katı bir sınırlama atar. `depot_expiring_time` tarihi ve saati, zaman aralıklarını tanımlarken kullanılan formatla aynı şekilde belirtilir. {% include [order-time-depot-ready-example-values](_includes/example-values-ec82ecbafe5f.md) %} Sipariş elleçlenmeye alındıktan sonra, araca [yüklenmesi](#order-service-duration-load) için zamana`depot_duration_s` ihtiyaç olabilir. Depodaki toplam [hizmet](https://docs.routeq.com/doc/tr/vrp/properties-of-depot.md#depot-service-duration) süresi `depot.load_service_duration_s` de eklenir. **Örnek** Örnekte 4 siparişin teslimatı gerçekleştirilmektedir. 1. ve 2. siparişler kırılgandır ve özel paketleme gerektiriyor. Elleçlemeden önce ambalajlar, vardiyası saat 13.00’te biten bir çalışan tarafından kontrol ediliyor. 3. ve 4. siparişler saat ancak 14.00’te gönderiye hazır hâle geliyor. Sonuç olarak kuryenin rotasındaki seferler `depot_expiring_time` ve `depot_ready_time` dikkate alınarak oluşturulur. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/81e1e766-3ad46c18-d72993fd-1dfde022) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/81e1e766-3ad46c18-d72993fd-1dfde022) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#81e1e766-3ad46c18-d72993fd-1dfde022) ## Teslim alma ve teslimat {#pickup-and-delivery} Genel olarak siparişler depoda bir araca yüklenerek alıcıların adreslerine teslim edilir. Müşterinin adresinde bir sipariş teslim alıp daha sonra bunu başka bir adrese teslim etmek gerekiyorsa ((pickup & delivery)) sipariş türünün belirlenmesi gerekir. Siparişin koordinatlarını belirlemek için şu değerlere sahip `location.type` alanı kullanılır: - `pickup` – adresten sipariş teslim alma. - `delivery` – siparişi adrese teslim etme (varsayılan değer). `pickup` türündeki siparişlerin teslimatları şu şekilde gerçekleştirilebilir: - **belirtilen adrese** – `location.delivery_to` alanında `delivery` türündeki siparişin tanımlayıcı belirtilmelidir; - **belirtilen adreslerden birine** – `location.delivery_to_any` alanında `drop_off` türündeki siparişlerin tanımlayıcıları belirtilmelidir, bkz. [Uygun lokasyonlardan birine teslimat](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#delivery-to-any); - **belirtilen depolardan birine** – depoların tanımlayıcıları `location.depot_id` alanında belirtilmelidir, bkz. [Siparişi depoya bağlama](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#linking-order-depot). Sipariş mevcut rotada teslim edilecektir; - **herhangi bir depoya** – bu durumda `location.depot_id` alanı boş bırakılmalıdır. Şu koşullardan en az birinin karşılanması durumunda sipariş mevcut rotadaki depoya teslim edilecektir: - `location.pickup_must_reach_depot` = `true` işareti etkinse, bkz. [Yerinden alınan siparişinin depoya teslimatı](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#pickup-must-reach-depot); - son teslimat zamanı `location.delivery_deadline` atanmışsa, bkz. [Yerinden alınan (pickup) siparişin depoya teslimatı](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#order-time-depot-delivery); - yerinden teslim alınan (pickup) siparişe sahip kuryenin rota sonunda mutlaka depoya dönmesi gerekiyorsa (`vehicle.return_to_depot` = `true`). Yukarıdaki koşullardan hiçbiri karşılanmıyorsa, pickup sipariş kuryede kalacak ve bir sonraki rotada depoya teslim edilecektir. Birkaç noktadan birine teslimat mümkünse siparişin tam olarak nereye teslim edildiği API yanıtından öğrenilebilir – `drop_off` sipariş veya depo için, teslim edilen siparişlerin tanımlayıcıları `delivered_orders` alanında listelenmektedir. **Örnek** Birinci kurye vardiya sonunda depoya dönmelidir – onun için `vehicle.return_to_depot` = `true`. Bu kurye tüm pickup siparişleri alır. `vehicle.return_to_depot` = `false` değeri atanmış ikinci kurye ise uzak siparişlerle ilgilenir ve vardiyasını uygun bir noktada tamamlar. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/48cbff0c-8e134cc9-8d282bbf-ec820827) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/48cbff0c-8e134cc9-8d282bbf-ec820827) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#48cbff0c-8e134cc9-8d282bbf-ec820827) {% note alert "Uyarı" %} Eğer `pickup` türündeki siparişlerin her zaman depoya dönmesi gerekiyor ve planlamada `vehicle.return_to_depot` = `false` ve `vehicle.return_to_depot` = `true` değerleri atanmış araçlar kullanılıyorsa bu durumda `location.delivery_to` alanının da doldurulması gerekir. Aksi hâlde sipariş araçta kalabilir. {% endnote %} Teslim alma ve teslimat sırasını dikkate almak için [location.in_lifo_order](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#order-reception-and-delivery) parametresi kullanılmalıdır. İstekte hem normal siparişler hem teslim alma/teslimat siparişleri mevcutsa RouteQ teslim alma ve teslimat siparişlerinin harmanlanmasını desteklemektedir. Aracın yeterli taşıma kapasitesine sahip olması ve bu şekildeki bir rotanın daha avantajlı olması durumunda, bir siparişin teslim alınması ve başka bir adrese teslimatı esnasında araya başka siparişlerin alınmasına da izin verilmektedir. Siparişin teslim alındıktan hemen sonra teslim edilmesi gerekiyorsa siparişleri `options.location_groups.solid` = `true` seçeneğiyle gruplandırma işlevinden yararlanın. Bir adreste birden fazla (`pickup`) gönderi teslim alma siparişinin bulunması hâlinde, teslim alma işleminin nadir durumlarda birden fazla araç veya kurye tarafından gerçekleştirilebileceğini lütfen unutmayın. Böyle bir bölüştürme toplam teslimat ücretinin azaltılması açısından haklı görülebilir. ## Teslim alma ve teslimat sırası {#order-reception-and-delivery} `location.in_lifo_order` parametresi siparişlerin alınma ve teslim edilme sırasını dikkate alarak rota oluşturmaya yardımcı olur. “Lifo” kısaltması İngilizce “last in, first out” ifadesinden gelir ve “son giren ilk çıkar” anlamına gelir. Bu parametre yükleme ve yük indirme sırasının önemli olduğu [pickup/delivery](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#pickup-and-delivery) sipariş çiftleri için kullanılabilir. Varsayılan olarak `location.in_lifo_order` = `false`. Örneğin bir araç bir sandalyeyi, bir koltuğu ve bir yatağı üç adresten alıp başka üç adrese taşıyor. Eşyaları aynı sırayla yükleyip boşaltırsanız, sandalyeyi boşaltmak için önce yatağı, ardından koltuğu ve ancak sonunda en dipteki sandalyeyi çıkarmanız gerekecek; ardından bir sonraki adrese gitmek için koltuğu ve yatağı tekrar yüklemeniz gerekecek. Ek yükleme ve indirme döngülerinin ek zaman ve çaba gerektireceği açıktır. Gereksiz ücretlerden kaçınmak için yükleme ve yük indirme sırasını önceden planlamak faydalı olacaktır: 1. Yatağı yükle. 1. Koltuğu yükle. 1. Sandalyeyi yükle. 1. Sandalyeyi indir. 1. Koltuğu indir. 1. Yatağı indir. Bu prosedür “lifo” (“son giren ilk çıkar”) prensibine uygundur. Bu prensibe uymak için, teslim alma ve teslimat sırasının önemli olduğu tüm siparişlerde `location.in_lifo_order` = `true` değeri belirtilmelidir. {% note alert "Uyarı" %} `pickup`/`delivery` sipariş çiftinde `location.in_lifo_order` alanındaki değerinin aynı olması gerekir. {% endnote %} **Örnek 1** Bu örnekte 6 teslimat noktası mevcut. 1. noktadan 4. noktaya, 2. noktadan 5. noktaya, 3. noktadan 6. noktaya birer sipariş taşınması gerekiyor. Sıra önemli değil, bu nedenle rota noktaları sırasıyla birbirine bağlıyor: 1 → 2 → 3 → 4 → 5 → 6. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/9975d310-310a5688-c96f54d4-14265b3b) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/9975d310-310a5688-c96f54d4-14265b3b) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#9975d310-310a5688-c96f54d4-14265b3b) **Örnek 2** Örnek 1’dekiyle aynı ancak tüm noktalar için `location.in_lifo_order` = `true` değeri belirtilmiş bulunuyor, Bu nedenle rota noktaları “lifo” prensibine göre bağlıyor: 1 → 2 → 3 → 6 → 5 → 4. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/8dea2dd3-4339725f-b5f882c0-64fa193f) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/8dea2dd3-4339725f-b5f882c0-64fa193f) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#8dea2dd3-4339725f-b5f882c0-64fa193f) ## Uygun lokasyonlardan birine teslimat {#delivery-to-any} Bazen bir siparişin birkaç adresten birine teslim edilmesi gerekebilir. Örneğin, bir siparişin üçüncü taraf bir lojistik şirketinin herhangi bir terminaline teslim edilmesi gerektiğinde ve rotaya daha tercih edilir bir teslimat adresinin dâhil edilmesi gerektiğinde. Bu durumda `pickup` sipariş türü kullanılır; bunun özellikleri için [Teslim alma ve teslimat](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#pickup-and-delivery) bölümüne göz atın. `delivery_to_any` alanına `drop_off` türündeki siparişlerin tanımlayıcıları veya gönderinin götürülebileceği depolar virgülle ayrılmış şekilde girilir. Drop_off siparişler için ağırlık ve hacim belirtilmesine gerek yoktur. Siparişin tam olarak nereye teslim edildiği API yanıtından öğrenilebilir – `drop_off` sipariş veya depo için, teslim edilen siparişlerin tanımlayıcıları `delivered_orders` alanında listelenmektedir. {% note info "Not" %} `delivery_to_any` değeri sadece pickup siparişler için belirtilebilir. Depo tanımlayıcılarının `delivery_to_any` alanında belirtilmesi sadece API aracılığıyla planlama yapılırken mümkündür. {% endnote %} Drop_off siparişler için [hizmet süresi](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#order-service-duration-delivery) belirtebilirsiniz. Pickup sipariş için drop_off’ta belirli bir aktarma zamanı belirtmeniz gerekiyorsa bu pickup siparişin `depot_duration_s` alanı yardımıyla yapılır. Rota optimizasyonunun bir sonucu olarak birkaç pickup sipariş tek bir drop_off’la teslim edilebilir. **Örnek 1** Aşağıdaki örnekte 2 pickup sipariş ve 2 `drop_off` sipariş bulunmaktadır. Her pickup için her iki `drop_off` sipariş `delivery_to_any` alanında belirtilmektedir. Drop_off siparişler için hizmet süresinin 3 dakika olduğunu lütfen unutmayın. Burada pickup siparişlerden birinde `depot_duration_s` değeri 30 dakikadır. Drop_off’ta toplam gönderi indirme süresi 33 dakikadır. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/981b0641-e486660b-6b1b713e-c5e6c5c4) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/981b0641-e486660b-6b1b713e-c5e6c5c4) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#981b0641-e486660b-6b1b713e-c5e6c5c4) **Örnek 2** Aşağıdaki örnekte 3 pickup sipariş, 1 `drop_off` sipariş ve 2 depo var. Burada `pickup_1` ile `pickup_2` herhangi bir depoya götürülebilirken, `pickup_3` sadece `drop_off` lokasyonuna götürülebilir. Planlamanın sonucunda kurye `pickup_3` siparişini `drop_off` lokasyonuna, `pickup_1` ve `pickup_2` siparişlerini ise `Depot 1` deposuna götürecektir. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/987718d1-c4020e91-777b6662-52217af) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/987718d1-c4020e91-777b6662-52217af) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#987718d1-c4020e91-777b6662-52217af) ## Gönderinin olası konumlardan birinde teslim alınması {#pickup-from-any} Bazen teslim edilecek gönderi seçtiğiniz herhangi bir noktadan alınabilir. Örneğin başka bir noktaya götürülmesi gereken ürün birkaç depoda bulunuyorsa. Bu durumda `delivery` siparişi için `pickup_from_any` özelliği kullanılır. `pickup_from_any` parametresi `true` olarak belirtilmiş `delivery` türündeki bir siparişte mutlaka birkaç `pickup` sipariş bağlanmış olmalı. Bağlantı `pickup` siparişteki `delivery_to` alanında atanır. Rota planlarken bu `pickup` siparişlerden herhangi biri seçilebilir, diğerleri göz ardı edilir. `pickup` siparişin seçilmesi rota ücretinin optimizasyonuna dayalı olarak gerçekleştirilir. Tüm `pickup` ve bağlı `delivery`’nin aynı ağırlığa sahip olması gerektiğini unutmayın. Varsayılan olarak `pickup_from_any` parametresi `false` değerine eşittir. **Örnek** Örnekte, `delivery`’nin `pickup_from_any` değerine eşit oldu 2 sipariş `true` tanımlanmıştır. Bu siparişlerin her biriyle 2 sipariş `pickup` ilişkilidir. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/d1c1d39c-eabf4a96-4f838429-e7f01d4) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/d1c1d39c-eabf4a96-4f838429-e7f01d4) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#d1c1d39c-eabf4a96-4f838429-e7f01d4) ## Siparişi depoya bağlama {#linking-order-depot} Siparişi depoya bağlama özelliğini şu durumlarda kullanın: - `delivery` sipariş sadece belirli depolarda mevcutsa; - `pickup` siparişin belirli depolardan birine getirilmesi gerekiyorsa. Bunun için `depot_id` alanında siparişin mevcut olduğu birkaç deponun `id` bilgilerini virgülle ayırarak belirtin. Sipariş herhangi bir depoda mevcutsa bu değeri boş bırakın. Aynı şey `pickup` siparişler için de geçerlidir. Şu durumlarda depoya bağlamaya gerek yoktur: - [gönderinin uygun noktalardan birinde teslim alınması](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#pickup-from-any) (`pickup_from_any`); - [“Teslim alma ve teslimat” senaryosunun uygulanması](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#pickup-and-delivery) (`pickup & delivery`). Gönderinin teslim alınması veya teslim edilmesi için hangi deponun seçildiği, API yanıtındaki rota parametrelerde görüntülenebilir: - Depoya teslim edilen siparişlerin tamamlayıcıları o depoya ait `delivered_orders` alanında belirtilir. - Depoda teslim alınan siparişlerin tamamlayıcıları o depoya ait `picked_orders` alanında belirtilir. **Örnek** Üç depo, üç sipariş ve üç araç verilmiştir. Her araç kendi deposundan başlar. Siparişlerin depolara `location.depot_id` aracılığıyla bağlantısı: - 1 numaralı sipariş depolara bağlı değildir. Herhangi bir depodan teslim edilebilir. - 2 numaralı sipariş 1 ve 2 numaralı depolara bağlıdır. Bu sipariş listelenen iki depodan birinden teslim edilebilir. - 3 numaralı sipariş 3 numaralı depoya bağlıdır. Belirli bir depoda yer almaktadır. Sonuç olarak, algoritma iki rota hesaplamıştır: 1. Bir kurye, 2 numaralı depodan 1 ve 2 numaralı siparişleri işlemektedir. 1. Başka bir kurye 3 numaralı depodan 3 numaralı siparişi işler. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/76959c0f-b5ae891d-f4220c54-2a22dd54) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/76959c0f-b5ae891d-f4220c54-2a22dd54) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#76959c0f-b5ae891d-f4220c54-2a22dd54) ## Yerinden alınan (pickup) siparişin depoya teslimatı {#pickup-must-reach-depot} Bir pickup siparişinin depoya teslim edilmesi gerekiyorsa, bu sipariş hem mevcut rotada (kurye iş gününün sonunda depoya dönüyorsa) hem de bir sonraki rotanın başında (kurye sabah depodan işe çıktığında) teslim edilebilir. Daha fazla bilgi için [Gönderilerin depoya toplanması](https://docs.routeq.com/doc/tr/vrp/supported-use-cases.md#collection-to-depot) senaryosuna göz atın. Siparişin depoya mevcut rotada teslim edilmesi gerekiyorsa `pickup_must_reach_depot` = `true` değerini atayın (varsayılan olarak bu değer `false`). `pickup_must_reach_depot` alanı için şu sınırlamalar söz konusu: - `pickup_must_reach_depot` = `true` değeri sadece pickup siparişler için belirtilebilir; - `pickup_must_reach_depot` = `false` değerine sadece `depot_id` alanı atanmamışsa, yani siparişin herhangi bir depoya teslimatı mümkünse izin verilir. Eğer `depot_id` alanında bir veya birkaç depo belirtilmişse o zaman pickup sipariş `pickup_must_reach_depot` değerine bakılmaksızın mevcut rotadaki bu depolardan birine teslim edilecektir. Görevde depoya teslim edilmesi gereken pickup siparişler varsa ((`location.pickup_must_reach_depot` = `true`)) ancak depoya giden kurye yoksa (yani kuryeler ya [depodan başlıyor](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles-depot.md#visit-depot-at-start) ya [rota sonunda depoya dönüyor](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles-depot.md#return-to-depot) ya da [rotanın ortasında depoya uğruyor](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles-depot.md#visit-additional-depot)), o zaman bu planlama görevi çözülemez ve hata verir. **Örnek 1** Kurye, depoya teslim edilmesi gereken 3 pickup sipariş de dâhil olmak üzere 15 sipariş dağıtıyor. Kurye rotaya depodan başlar ancak günün sonunda depoya dönmek zorunda değil ((`return_to_depot` = `false`)). Kurye bu nedenle pickup siparişleri alıyor ve yanında tutuyor; bu siparişler ancak ertesi sabah depoya teslim edilecektir. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/3cd98962-d98fe2a1-6812e5fc-b08767bf) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/3cd98962-d98fe2a1-6812e5fc-b08767bf) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#3cd98962-d98fe2a1-6812e5fc-b08767bf) **Örnek 2** Örnek 1’dekiyle aynı ancak yerinden alınan (pickup) siparişler için `pickup_must_reach_depot` = `true` işareti etkin. Bu nedenle kurye rotanın sonunda bu siparişleri depoya getiriyor. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/51127567-4e6a6ae8-8936fb49-4de2f6be) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/51127567-4e6a6ae8-8936fb49-4de2f6be) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#51127567-4e6a6ae8-8936fb49-4de2f6be) ## Siparişin depoya teslimat zamanı {#order-time-depot-delivery} Bazı durumlarda pickup siparişlerin belirli bir zamanda depoda toplanması gerekebilir. Bu örneğin kurye veya lojistik şirketleri için geçerli bir durum olabilir ve bir siparişin başka bir ulaşım aracıyla (örneğin havaalanına veya araçla başka bir şehre) gönderilmesi gerekebilir – yani belirli genel teslimat sürelerini sağlamak için tüm siparişlerin belirli bir saatten önce toplanması gerekebilir, aksi takdirde bunların ertesi gün gönderilmeleri gerekecektir. Bir pickup siparişin depoya teslim zamanını belirlemek için `delivery_deadline` parametresini kullanın. Bu parametre esnek sınırlamalar belirtiyor, yani ihlal edilmesi durumunda `penalty.delivery_deadline.fixed` veya `penalty.delivery_deadline.minute` cezası uygulanır. Bu parametre sadece `pickup` türündeki siparişlerde farklı davranır. Bu tür siparişlerle nasıl çalışılacağı [Teslim alma ve teslimat](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#pickup-and-delivery) bölümünde ele alınmıştır. {% note alert "Uyarı" %} Varsayılan olarak kurye günde sadece bir sefer gerçekleştirir ve rota kargoları teslim etmek için depoya dönüldüğünde sona erer. Bir kuryenin depoya dönebilmesi ve teslimata devam edebilmesi için `max_runs` parametresini kullanırken 1’den büyük bir değer belirtin. Sefer sayılarının ayarlanması ile ilgili daha fazla bilgi [Günde birkaç sefer](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles-routes.md#vehicle-max-runs) bölümünde mevcuttur. {% endnote %} **Örnek** Aşağıdaki örnekte bir kurye tüm siparişlerin teslimatını gerçekleştiriyor ediyor ve bir siparişi belirtilen zamana kadar (`delivery_deadline`) iade etmek için gün ortasında depoya dönüyor. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/36c9d9ce-205ae226-f91450c2-6d196f6d) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/36c9d9ce-205ae226-f91450c2-6d196f6d) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#36c9d9ce-205ae226-f91450c2-6d196f6d) ## Bir siparişin araçta kalabileceği süreyi sınırlandırma {#transit-time} Rotalar planlanırken bir siparişin araçta kalabileceği süreyi sınırlamak gerekebilir (örneğin dondurulmuş gıdalar veya tıbbi testler teslim edilirken). Bunun için şu iki alandan oluşan `location.transit_time` nesnesi kullanılır: - `limit_s` – saniye cinsinden esnek sınırlama; - `hard_limit_s` – saniye cinsinden katı sınırlama. Sipariş için araçta geçirilen süreye ilişkin kısıtlamalardan birini veya aynı anda her ikisini birden belirtebilirsiniz. Eğer `limit_s` esnek sınırlaması atanmışsa, onun için şu cezalardan en az bir tanesi tanımlanmalıdır: - `location.penalty.transit_time.fixed` – siparişin araçta bulunma süresi açıldığı için sabit ceza; - `location.penalty.transit_time.minute` – belirtilen sınırlamanın aşıldığı her dakika için ceza. Varsayılan olarak cezalar için değerler atanmamıştır. Eğer `hard_limit_s` katı sınırlaması atanmışsa, bu durumda sipariş aşağıdaki koşullardan birinin karşılanması durumunda tüm rotalardan hariç tutulacaktır: - sipariş sınırlama ihlal edilmeden teslim edilemiyorsa; - siparişin teslimatı, yerine getirilmeme cezasından daha pahalıdır. Sınırlama şu senaryolarda desteklenmektedir: - [Bir depodan teslimat](https://docs.routeq.com/doc/tr/vrp/supported-use-cases.md#delivery-from-depot) - [Gönderilerin depoya toplanması](https://docs.routeq.com/doc/tr/vrp/supported-use-cases.md#collection-to-depot) - [Gönderinin olası konumlardan birinde teslim alınması](https://docs.routeq.com/doc/tr/vrp/supported-use-cases.md#pickup-from-any) - [Uygun lokasyonlardan birine teslimat](https://docs.routeq.com/doc/tr/vrp/supported-use-cases.md#delivery-to-any) {% note info "Not" %} Bu sınırlama [bağlantı noktaları](https://docs.routeq.com/doc/tr/vrp/supported-use-cases.md#trailer) ve [çapraz sevkiyat](https://docs.routeq.com/doc/tr/vrp/supported-use-cases.md#cross-docking) içeren senaryolarda kullanılamaz. {% endnote %} **Örnek** Örnekte 8 sipariş mevcut olup bunlar için atanan değerler `transit_time.limit_s` = 3600 ve `transit_time.hard_limit_s` = 5600 şeklindedir. Planlamanın sonucunda 2 siparişte siparişin arabada kalabileceği süreye ilişkin esnek sınırlama ihlal edilmiş bulunuyor. 1 sipariş daha katı sınırlandırmayı ihlal etmeden teslim edilemediği için dağıtılmayanlar listesine düşüyor. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/6587be50-62831487-8e9d276e-6cc68d3e) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/6587be50-62831487-8e9d276e-6cc68d3e) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#6587be50-62831487-8e9d276e-6cc68d3e) ## Çoklu siparişler {#multi-orders} Rota planlanırken birden fazla siparişin tek bir adrese, örneğin bir apartmana veya iş merkezine teslim edilmesinin gerekli olduğu zamanlar olabilir. Bu tür siparişler otomatik olarak bir veya daha fazla çoklu sipariş olarak birleştirilebilir. Birleştirilen siparişlerin yakınlığı `options.multiorder_radius_m` parametresi ile belirlenir (varsayılan değer 1 m). Çoklu siparişler oluşturulurken sadece koordinatlar değil aynı zamanda siparişlerin zaman aralıkları ve siparişler arasındaki bağlantılar da dikkate alınır ([pickup&delivery](#pickup-and-delivery) çifti ve grup olarak birleştirme). Siparişlerin çoklu siparişlerde birleştirilmesi yalnızca çözüm ölçümlerinin iyileştirildiği durumlarda ve ayrıca araç veya kurye kapasitesi, siparişlerin etiketlerle uyumluluğu gibi diğer sınırlamaların ihlal edilmemesi durumunda gerçekleştirilir. bir siparişin başka bir siparişle birleştirilmesini yasaklamak için bu siparişe `location.can_be_merged` = `false` değerini belirtin (varsayılan olarak bu parametre `true`’dur). {% note info "Not" %} Aynı adreste bulunan tüm siparişlerin tek bir çoklu siparişte birleştirilmesini garantilemek istiyorsanız `options.merge_multiorders` = `true` seçeneğinden yararlanın. Ancak bazı durumlarda bu işlem planlama sonuçlarını kötüleştirebilir. Bu seçeneği sadece bir adrese teslim edilecek siparişlerin araç kapasitesinden önemli ölçüde daha az olması ve bunların tek bir araçla teslim edilebileceğinden emin olmanız durumunda kullanmanızı öneririz (diğer sınırlamalar göz önüne alınarak). {% endnote %} Varsayılan olarak, siparişler birleştirilip çoklu sipariş olarak servis edildiğinde belgelerin teslim edilme veya park etme süresi böyle bir sipariş grubu için bir kez hesaplanır. Bir çoklu siparişte müşterinin birden fazla siparişi varsa, müşteriye ayrılan hizmet süresi ortak olabilir. Çoklu siparişin hizmet süresini belirlemek için aşağıdaki parametreler kullanılır: - `location.shared_service_duration_s` – belge verme veya park etme süresi. Hesaplama için çoklu siparişte birleştirilen tüm siparişler arasındaki maksimum değer alınır. - `location.service_duration_s` – siparişi teslim etme süresi. - `location.client_service_duration_s` – çoklu siparişte bir müşteriye servis sunma süresi. Hesaplama için bu parametrenin bir müşterinin siparişleri arasındaki maksimum değeri alınır. Müşterinin tamamlanması için `location.client_id` parametresi kullanılır. Algoritma, bu işlem çözümü daha kötü hâle getirmiyorsa (örneğin farklı zaman aralıklarına ve aynı `client_id` tanımlayıcısına sahip ikisi barışın birleştirilmesi çözümü daha kötü hâle getirebilir) aynı `client_id` tanımlayıcısına sahip siparişleri bir çoklu sipariş olarak birleştirir. Farklı adreslerde bulunan normal siparişlerde hizmet park etme süresi `location.shared_service_duration_s` müşteriye ayrılan hizmet süresi `location.client_service_duration_s` her sipariş ayrı ayrı dikkate alınır. Çoklu siparişlerde hizmet park etme süresi `location.shared_service_duration_s` sadece bir kez dikkate alınır. Aynı `client_id` değerine sahip siparişlerde müşteriye ayrılan hizmet süresi `location.client_service_duration_s` çoklu siparişteki ortalama değer olarak alınır; farklı `client_id` değerine sahip siparişlerde ise toplanır. `can_be_merged` = `false` değerine sahip siparişlerde belge teslim etme veya park etme süresi `shared_service_duration_s` ayrı olarak dikkate alınır. Çoklu siparişlerde bu süreyi her sipariş için ayrı ayrı dikkate almak istiyorsanız, `options.wait_in_multiorders` = `false` bekleme seçeneğini devre dışı bırakın. **Örnek 1** Örnekte, aynı zaman aralıklarına ve farklı teslimat zamanlarına sahip 3 sipariş tanımlanmıştır. Çoklu sipariş birleştirme seçeneği etkinleştirilir. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/cebdd3ea-954caba8-440a26ee-748332f8) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/cebdd3ea-954caba8-440a26ee-748332f8) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#cebdd3ea-954caba8-440a26ee-748332f8) **Örnek 2** Örnekte tek bir çoklu sipariş olarak birleştirilmiş 4 sipariş tanımlanmıştır. 1. ve 3. siparişler birinci müşteriye, 2. ve 4. siparişler ise ikinci müşteriye aittir. Çoklu siparişin servis zamanı (API yanıtında `total_service_duration_s` parametresi) şu değerlerden oluşur: - `shared_service_duration_s` – 100 saniye, siparişler için toplam zaman. - `service_duration_s` – 600 saniye, her sipariş için teslimat süresi. - `client_service_duration_s` ilk müşteri için – 300 saniye (1. ve 3. sipariş için maksimum değer). - `client_service_duration_s` 2 müşteri için – 400 saniye (2. ve 4. sipariş için maksimum değer). Sonuç olarak çoklu siparişin hizmet süresi `100 + 4*600 + 300 + 400 = 3200` saniye olarak belirlenir. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/8d6b0e20-a90192ab-c7fa20cc-3b337f46) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/8d6b0e20-a90192ab-c7fa20cc-3b337f46) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#8d6b0e20-a90192ab-c7fa20cc-3b337f46) **Örnek 3** Örnek 2’dekiyle aynı ancak 1. sipariş için `can_be_merged` = `false` belirtilir. bu durumda 1. sipariş için hizmet süresi `100 + 600 + 100 = 800` saniye iken, 2., 3. ve 4. siparişleri içeren çoklu siparişin hizmet süresi `100 + 3*600 + 300 + 400 = 2600` saniyedir. Toplam hizmet süresi `total_service_duration_s` – 3400 saniye. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/9442a436-e313e727-b68e661c-ef363340) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/9442a436-e313e727-b68e661c-ef363340) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#8d6b0e20-a90192ab-c7fa20cc-3b337f46) ## Siparişleri bölme {#split-parts} Rotalar planlanırken bir siparişin birden fazla parçaya bölünmesi ve bu parçaların farklı araçlarla taşınması gerektiği durumlar ortaya çıkabilir. Bunlar dökme gönderi veya paletli gönderi şeklindeki siparişler olabilir. Siparişi parçalara bölmek için `locations` nesnesinde şu parametreleri belirtin: - `can_be_split` – sipariş parçalara bölünebilir (sadece `delivery` ve `pickup` türündeki siparişler için). Varsayılan değer `false`. - `max_split_parts` – siparişin bölünebileceği maksimum parça sayısı. - `quant` – bölünmüş parçanın minimum boyutu; bu şu, formatta atanır: - `"quant": 0.25` – sipariş payına karşılık gelir. Bu örnekte minimum parça siparişin dörtte birine karşılık gelir. - `"quant": {"weight_kg": 2.5}` – minimum parçanın büyüklüğünü `weight_kg`, `units` veya `volume_cbm` olarak belirtir. Bu örnekte minimum parça 2,5 kilograma eşittir. Bir siparişin parçalara bölünmesinde kalan varsa, bu kalan `quant` değerinde daha az olabilir. Mevcut seferde aracın tamamını kaplayacak kısmı siparişten ayırmak için `locations.split_parts_must_fill_whole_vehicle` = `true` parametresini kullanın (varsayılan değer `false`). Bu durumda da kalan bir kısım olabilir. Bir seferde farklı siparişlerden kalan birkaç parça taşınabilir. {% note info "Not" %} `split_parts_must_fill_whole_vehicle` = `true` ise ayrılabilen kısmın minimum ölçüsü `quant` belirtilmez. {% endnote %} [Elde edilen çözümle çalışmada](https://docs.routeq.com/doc/tr/vrp/interface-result.md) veya [haritada](https://docs.routeq.com/doc/tr/vrp/interface-mvrp-map.md) hangi siparişlerin bölünmüş olduğunu kontrol edebilirsiniz: bölünmüş siparişlerde **Sipariş numarası** alanında sipariş parçasının numarası belirtilir. `split_orders_percentage` ölçümünde bölünmüş siparişlerin payını göreceksiniz. {% note alert "Uyarı" %} Bölünmüş siparişler içeren çözümlerde lojistikçi çalışma panelinde manuel düzeltmeler yapılamamaktadır. Bölünmüş siparişler içeren çözümler Takip için dışa aktarılamıyor. {% endnote %} Siparişin farklı bölümlerinin varış sürelerini sınırlayabilirsiniz. Bunun için `locations.max_time_between_visits_s` parametresinde izin verilen maksimum süreyi saniye cinsinden belirtin. Bu parametre, ihlal edilmesi durumunda cezaların uygulandığı bir esnek sınırlamayı tanımlamaktadır: - `locations.penalty.time_between_visits.fixed` – belirlenen sınırlamanın aşılması durumundaki sabit ceza; - `locations.penalty.time_between_visits.minute` – belirtilen sınırlamanın aşıldığı her dakika için ceza. Bölünebilecek maksimum sipariş oranını sınırlamak için `options.max_split_orders_percentage` parametresini kullanın. İhlal edilmesi durumunda cezaların uygulandığı bir esnek sınırlamayı tanımlamaktadır: - `options.penalty.split_orders_percentage.fixed` – belirlenen sınırlamanın aşılması durumundaki sabit ceza; - `options.penalty.split_orders_percentage.per_percent` – belirtilen sınırlamanın aşıldığı her yüzde için ceza. **Örnek 1** Her biri 1000 kg’lık 6 siparişin 1500 kg kapasiteli 4 araçla teslim edilmesi gerekiyor. Siparişler ikiye bölünerek parçalar hâlinde teslim edilebilir ancak parça sayısı toplam sipariş sayısının %50’sini geçemez. Sınırlamanın ihlali durumunda sabit para cezası uygulanır. Planlamanın sonucunda siparişlerden 2 tanesi ikiye bölünerek farklı araçlarla teslim edilir. Ceza `max_split_orders_percentage_penalty` = 0. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/c98a4977-39960d6f-934ed96d-2c2071f5) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/c98a4977-39960d6f-934ed96d-2c2071f5) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#c98a4977-39960d6f-934ed96d-2c2071f5) **Örnek 2** Depodan şantiyeye 50 metreküp hacimli 1 siparişin teslim edilmesi gerekiyor. 5, 7,5 ve 10 metreküp kapasiteli 3 araç mevcut olduğundan sipariş parça parça teslim edilecektir. Her parçanın minimum boyutu 5 metreküptür. Her araç 3 sefer gerçekleştirebilir. Planlamanın sonucunda sipariş 7 parçaya bölünecektir. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/ec07258b-7e4647c-a71db3d7-38b32f55) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/ec07258b-7e4647c-a71db3d7-38b32f55) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#ec07258b-7e4647c-a71db3d7-38b32f55) **Örnek 3** 20 paletlik bir siparişin depodan mağazaya teslim edilmesi gerekiyor. Sadece tek sefer yapabilen 19 palet kapasiteli 1 araç mevcuttur. Planlamanın sonucunda siparişin 19 paletlik kısmı teslim ediliyor ve 1 palet teslim edilmemiş kalıyor. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/b55b8c78-c7353fe0-f031786f-c2ea8943) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/b55b8c78-c7353fe0-f031786f-c2ea8943) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#b55b8c78-c7353fe0-f031786f-c2ea8943) **Örnek 4** 1500 kg ve 2200 kg ağırlığındaki 2 siparişin 1000 kg taşıma kapasiteli bir araçla teslim edilmesi gerekmektedir. Parametre `split_parts_must_fill_whole_vehicle` = `true`, bu nedenle siparişler 1000 kg’lık parçalara bölünecek ve kalan bir kısım olacaktır. Planlamanın sonucunda siparişlerden kalan kısım bir seferde teslim edilecektir. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/9444afb-794f7ca9-d8bb72a-eae54995) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/9444afb-794f7ca9-d8bb72a-eae54995) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#9444afb-794f7ca9-d8bb72a-eae54995) ### Siparişin bir bölümünü teslim etmeme cezası {#split-parts-penalty} Bir sipariş parçalara bölündüğünde bir veya daha fazla parça teslim edilmeden kalabilir. Teslim edilmeme cezasının (`penalty.drop`) siparişin teslim edilmeyen kısmının büyüklüğüne göre hesaplanması için cezanın sabit ve değişken kısımlarını belirtebilirsiniz: `penalty.drop.fixed` ve `penalty.drop.scaled`. Ceza şu formüle göre hesaplanır: `penalty.drop.fixed + order_ratio * penalty.drop.scaled`; burada `order_ratio` – siparişin teslim edilmeyen kısmıdır (oranıdır). Cezanın sadece sabit veya sadece değişken kısmı belirtilebilir. **Örnek** 2000 kg ağırlığında bir siparişin teslim edilmesi gerekiyor. Sipariş 250 kg’lık parçalara bölünebilir. Sadece 1 sefer yapabilen 1500 kg kapasiteli 1 araç mevcuttur. Siparişin bir bölümünün teslim edilmemesinin sabit cezası 1.000.000 birim ve değişken cezası 200.000 birimden hesaplanır. Planlamanın sonucunda siparişin 500 kg’lık kısmı (siparişin 1/4’ü) teslim edilmemiştir. Ceza 1.000.000 + (200 000 * 0,25) = 1.050.000 birimdir. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/49e3c79d-5d393752-4026ef42-9a48acca) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/49e3c79d-5d393752-4026ef42-9a48acca) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#49e3c79d-5d393752-4026ef42-9a48acca) ### Siparişleri bölme hizmet süresi {#split-parts-service-time} Bölünen bir siparişin hizmet süresi şu yollardan biriyle atanabilir: - büyüklüğüne bakılmaksızın, siparişin her bir parçası için sabit bir süre olarak; - siparişin teslim edilen kısmının boyutuna (oranına) bağlı olarak. Burada `service_duration_s`, `shared_service_duration_s`, `client_service_duration_s`, `depot_duration_s` ve `crossdock_service_duration_s` parametreleri `fixed` ve `scaled` alanlı yapılar olarak atanır. {% note info "Not" %} `parking_service_duration_s` parametresi `fixed` ve `scaled` alanlı bir yapı olarak atanamaz ve her zaman sabit bir sayı olarak atanır. {% endnote %} Parçalara bölünebilen bir siparişin hizmet süresinin hesaplanma parametreleri şu ögeleri içeren bir `service_durations` yapısında birleştirilebilir: - `location` – `service_duration_s` parametresine uygundur; - `stop` – `shared_service_duration_s` parametresine uygundur; - `client` – `client_service_duration_s` parametresine uygundur; - `depot` – `depot_duration_s` parametresine uygundur; - `crossdock` – `crossdock_service_duration_s` parametresine uygundur; - `parking` – `parking_service_duration_s` parametresine uygundur. `parking` hariç olmak üzere, bu ögelerden her biri sayı olarak veya `fixed` ve `scaled` alanlarını içeren bir yapı olarak atanabilir – bu durumda karşılık gelen hizmet süresi aşağıdaki formülle hesaplanır: `fixed + order_ratio * scaled`; burada `order_ratio` – siparişin teslim edilen kısmıdır (oranıdır). {% note info "Not" %} `service_durations` yapısı kullanıldığında ilgili `service_duration_s`, `shared_service_duration_s`, `client_service_duration_s`, `depot_duration_s`, `crossdock_service_duration_s` ve `parking_service_duration_s` parametrelerinin ayrıca belirtilmesi gerekli değildir. {% endnote %} API yanıtında `service_durations` yapısının içeriği değişmeden kalır: sabit ve değişken kısım olarak belirtilen alanlar yapı olarak; sayı olarak belirtilen alanlar ise sayı olarak çıkarılır. Hizmet süreleri `service_durations` yapısı olmadan atanmışsa, bu durumda API yanıtındaki `crossdock_service_duration_s` ve `depot_duration_s` parametreleri istekte olduğu gibi kalır. Geriye kalan parametreler, elde edilen çözümde ilgili siparişin gerçek hizmet süresine karşılık gelen bir sayı olarak çıkarılır. Bu durumda örneğin [çoklu sipariş olarak birleştirme](#multi-orders) veya [çarpan](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles.md#service-duration) `service_duration_multiplier` gibi başka parametreler de nihai değeri etkileyebilir. **Örnek 1** 600 kg kapasiteli bir araç 2100 kg ağırlığındaki bir siparişi teslim ediyor. Sipariş 300 kg’dan az olmayan parçalara bölünebilir. Sonuç olarak araç 4 sefer gerçekleştirir: 600 kg yüklü üç sefer (siparişin 2/7’si) ve 300 kg yüklü bir sefer (siparişin 1/7’si). Sipariş için şunlar verilmiştir: - sipariş hizmet süresi `service_duration_s` sabit kısmı 600 sn ve değişken kısmı 70 sn (her 300 kg için 10’ar sn) şeklindedir; - depoda yükleme süresi `depot_duration_s` sabit kısmı 300 sn ve değişken kısmı 140 sn (her 300 kg için 20’şer sn) şeklindedir. Toplam hizmet süresi (600 + 20 + 300 + 40) * 3 + (600 + 10 + 300 + 20) = 3810 sn olarak hesaplanır. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/ca499211-bbfbc834-6a30297-2a7a7c74) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/ca499211-bbfbc834-6a30297-2a7a7c74) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#ca499211-bbfbc834-6a30297-2a7a7c74) **Örnek 2** Örnek 1’dekiyle aynı ancak hizmet süresi `service_durations` yapısında atanmıştır. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/f10fb72c-63a0c351-d00bd8e2-b500bf6a) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/f10fb72c-63a0c351-d00bd8e2-b500bf6a) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#f10fb72c-63a0c351-d00bd8e2-b500bf6a) ## Siparişi yerine getirmeme cezaları {#penalties-not-delivering} RouteQ isteğinde her sipariş için siparişin yerine getirilmemesi durumunda bir ceza tanımlayabilirsiniz. Yeterli araç veya kurye yoksa bazı siparişler tüm rotalardan hariç tutulabilir. Örneğin diğerlerinden çok uzakta bulunan bir siparişin yerine getirilmesi diğer siparişler için birkaç saatlik gecikmeye neden olacaksa, böyle bir sipariş yerine getirilmemiş bir sipariş olarak rotaların dışında tutulabilir. {% note info "Not" %} RouteQ’nun yanıtında Yerini getirilmeyen siparişler ayrı bir `dropped_locations` alanında yer alacaktır. {% endnote %} Siparişin atanmış bulunan araçlardan hiçbiri için planlanamaması durumunda bu ceza rotanın toplam ücretine eklenir. Bir siparişin rotalardan birine dâhil edilememesinin birçok nedeni olabilir, örneğin: - siparişin ağırlığı atanmış bulunan araçlardan herhangi birinin taşıma kapasitesini aşıyor; - siparişlerin toplam ağırlığı, araçların toplam taşıma kapasitesini aşıyor, dolayısıyla ilave seferler söz konusu olsa bile siparişler teslim edilemiyor. Dolayısıyla her hâlükârda dağıtılmamış siparişler kalır; - mevcut sipariş belirtilen araçların hiçbirine uygun değil veya belirli bir sipariş grubuna uygun araçların taşıma kapasitesi bu siparişlerini hepsini alamayacak kadar küçük; - siparişi belirtilen katı zaman aralığı içinde teslim etmek mümkün değil; - sürücü vardiyalarındaki katı sınırlamalar göz önüne alındığında siparişlerin teslim edilmesi mümkün değil; - katı ve dar bir depo penceresi ve araç depoya dönüş parametreleri atanmış bulunuyor – sonuç olarak sistem depoya geri dönüş planlıyor ancak siparişleri teslim etmeye zaman yok; - siparişin koordinatları yanlış ve bunun sonucunda sipariş diğer siparişlerden coğrafi olarak uzak bir konuma düşüyor ve sistem bu siparişi yerine getirme imkânı bulamıyor; - karmaşık bir görevin “low” rejiminde planlanması. Genel olarak bir sipariş için 50 birim, başka bir sipariş için ise 5 birim ceza atanmışsa, 50 birim cezalı sipariş daha önemli sayılacak ve planlanan rotahlara dâhil edilme olasılığı daha yüksek olacaktır. Bir siparişi teslim etmeme cezasını belirlemek için RouteQ’da `location.penalty.drop` alanı kullanılmaktadır. {% note info "Not" %} Bu alanın varsayılan değer büyüklüğünün varsayılan olarak 1000000 olduğunu lütfen unutmayın. Bu alanın değiştirilmesi, sadece dağıtılmamış siparişlerin ortaya çıkmasının beklendiği senaryolarda gereklidir. Önceliklerin kontrol edilmesi için benzer veya daha yüksek bir değerin kullanılması ve 0 değerinin kullanılmaması önerilir. Şüphe duyarsanız doğru katsayıları belirlemek için RouteQ analistleriyle iletişime geçin. {% endnote %} ## Siparişin araçlara uygunluğu {#order-vehicle-compatibility} Bir siparişi RouteQ isteğinde oluştururken, bu siparişi yerine getirmesi gereken araca bir gereksinimler listesi atamak mümkündür. Sipariş etiketlerini (gerekli araç özellikleri) tanımlamak için `location.required_tags` alanı kullanılır. Araç ve sipariş uygunluğu kurallarından herhangi birinin karşılanması durumunda siparişin araca uygun olduğu kabul edilir. Uygunluk kuralları araçlar tanımlanırken belirtilir. Uygunluk kuralları ile ilgili daha fazla bilgi için [Araç etiketleri](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles.md#tags) bölümüne göz atın. Sipariş aracı veya kuryesi ile ilgili zorunlu olmayan ancak arzu edilen gereksinimler varsa (örneğin kuryenin önerilen yeterlilik düzeyi, alıcının teslimatın belirli bir kurye tarafından gerçekleştirilmesi yönündeki tercihi vb.), bunlar `location.optional_tags` alanında belirtilir. Daha fazla bilgi için [İsteğe bağlı etiketler](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles.md#optional-tags) bölümüne göz atın. **Örnek** Örnek 4’te siparişlerin sıcaklık gereksinimlerine riayet edilerek taşınması gerekiyor – `location.required_tags` alanında `Buzdolabı` etiketi kullanılıyor. Ayrıca ikisi sipariş için hidrolik arka kapak liftli araç gerekli – bu siparişlerin `location.required_tags` alanında iki etiket belirtilir: `Buzdolabı`, `Hidroport`. Bu siparişler `vehicle.tags` alanında uygun değerlere sahip olan 1. araç için uygundur: `Buzdolabı`, `Hidroport`. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/4644f3f-1dc6e18a-cbf72b97-317d066) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/4644f3f-1dc6e18a-cbf72b97-317d066) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#4644f3f-1dc6e18a-cbf72b97-317d066) ## Sipariş uygunsuzluğu {#order-incompatibility} Araçta aynı anda bulunmaması gereken türde siparişler taşımanız gerekiyorsa RouteQ bir veya birden fazla uygunsuz sipariş türü tanımlamanıza imkân verir. RouteQ’da önceden tanımlanmış sipariş türü yoktur. Aşağıdakiler uygunsuz türler olarak kullanılabilir: - Açık nedenlerden dolayı bir sefer kapsamında aynı araçta taşınamayan uygunsuz gönderiler. - Çeşitli gönderi alıcılarının kendi aralarındaki uygunsuzluğu. Örneğin: rakiplerin mallarının farklı araçlara dağıtılması, siparişlerin belirli müşteri türlerine göre ayrıştırılması. Siparişin türünü belirlemek için `location.load_types` alanı kullanılır. Gerekiyorsa her sipariş için birden fazla tür belirtebilirsiniz. Uyumsuz siparişlerin belirtilmesi için `options.incompatible_load_types` alanı kullanılır; bu alan Excel’de [Incompatible_order_types](https://docs.routeq.com/doc/tr/vrp/excel-fill-guide.md#incompatible-order-types) çalışma sayfasında atanır. Bu alanda uygunsuz türlerin listesini belirtebilirsiniz; en az bir uygunsuz tür içeriyorlarsa, planlama sırasında siparişler farklı araçlara dağıtılır. [Belirli bir araçta sipariş uygunsuzluğu](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles.md#incompatible-load-types) atamak için `vehicle.incompatible_load_types` parametresini kullanın; bu parametre aracın özelliklerinin dikkate alınmasına imkân tanır. {% note info "Not" %} Sipariş uygunsuzluğu katı bir sınırlamadır, yani otomatik rota oluşturma sırasında ihlal edilemez. Örneğin bir nokta için birden fazla sipariş atanmışsa ve bunlar uygunsuzsa, algoritma bunları farklı araçlar için planlayacaktır. Sipariş uygunsuzluğu türlerinin kullanılması optimal olmayan rotaların oluşturulmasına neden olabilir. Bu nedenle sadece pratikte zorunlu kural mahiyetinde olan gerçekten önemli sınırlamaların gerilmesi mantıklıdır. {% endnote %} **Örnek 1** Aynı araç filosuyla her kimyasalları, gıda ürünleri ve çiçek taşınırken `location.load_types` alanında ilgili siparişler için gönderi türü `chemicals`, `food`, `flowers` olarak belirtilmelidir. Ev kimyasallarının hiçbir zaman gıda ürünleriyle veya çiçeklerle aynı araçta bulunmamasını ancak çiçeklerin ve gıda ürünlerinin birlikte taşınabilmesini sağlamak için şu uygunsuzluk kurallarını atayın: #| ||**type** | **incompatible_load_types**|| ||chemicals | food, flowers|| |# Örnekte 3 sipariş oluşturuyoruz ve her bir siparişe bu 3 türden birini atıyoruz. Algoritma sonuç olarak 2 rota planlanmış oluyor. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/85f3ba3d-d2d21923-9f4062f6-a9445d96) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/85f3ba3d-d2d21923-9f4062f6-a9445d96) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#85f3ba3d-d2d21923-9f4062f6-a9445d96) **Örnek 2** Örnekte 4 sipariş belirtilmiş olup gönderi uygunsuzluğu atanmış bulunuyor ve coğrafi bölgelere göre uygunsuzluk da belirtilmiştir. Sonuç olarak tüm siparişler birbiriyle uygunsuzdur ve aynı noktaya 2 sipariş gönderilmesine rağmen algoritma 4 rota planlamaktadır. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/a7295536-d973d05-bdea554c-eede66bd) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/a7295536-d973d05-bdea554c-eede66bd) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#a7295536-d973d05-bdea554c-eede66bd) ## Yoğunluk seçeneklerini açma ve kapatma {#grouping-options} `location.use_in_proximity` seçeneği rota yoğunluğunu belirleyen `options.proximity_factor` ve `options.global_proximity_factor` ögelerini devreden çıkarıyor. Varsayılan olarak `location.use_in_proximity` = `true`, yani yoğunluk seçenekleri tüm siparişler için geçerlidir. Kural olarak teslimat noktalarının yoğunluğu şehir merkezine doğru artıyor ve kenar semtlere doğru azalıyor. Bu nedenle değişikliklere esnek bir şekilde yanıt verebilmek için merkez bölgelerde gruplandırılmış rotalar oluşturmak, ulaşım araçlarını verimli kullanmak için ise kenar semtlerde ve taşrada uzun mesafeli rotalar oluşturmak faydalı olacaktır. Bunun için, ek olarak gruplandırılması gerekmeyen banliyö siparişlerinde `use_in_proximity` alanında `false` değerini belirtmek gerekiyor. **Örnek 1** 40 siparişin teslim edilmesi gerekiyor. Yoğunluk seçenekleri tüm siparişlerde geçerlidir. Algoritma üç araç için esnek ve kompakt rotalar oluşturuyor. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/5ecf5652-b97ffb71-d93387cd-84ca7852) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/5ecf5652-b97ffb71-d93387cd-84ca7852) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#5ecf5652-b97ffb71-d93387cd-84ca7852) **Örnek 2** Örnek 1’dekinin aynısı ancak Moskova Çevre Yolu dışındaki siparişler için `use_in_proximity` alanında `false` değeri belirtildiği için bunlar gruplandırmaya dâhil edilmiyor. Sonuç olarak algoritma “uzun mesafeli” siparişleri birleştiriyor ve üç yerine iki araç için rota sunuyor. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/4d5e3c9c-15b05f4-77a351ab-2fe62b76) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/4d5e3c9c-15b05f4-77a351ab-2fe62b76) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#4d5e3c9c-15b05f4-77a351ab-2fe62b76) ## Siparişlerin önceliklendirilme sırası {#sequence-order} Bazı siparişlerin diğerlerinden önce tamamlanması gerekiyorsa `sequence_order` parametresini kullanarak öncelik atayabilirsiniz. {% note alert "Uyarı" %} Öncelikler rota kapsamında aracın tüm seferlerinde sıralı düzende uygulanır. Ancak tüm planlama çerçevesinde, bir rotadaki daha düşük öncelikli bir siparişin, başka bir rotadaki daha yüksek öncelikli bir siparişi göre daha erken yerine getirilmesi mümkündür. {% endnote %} Farklı önceliklere sahip siparişlerin olduğu durumlarla ilgili örnekler: - Önce belgelerin alınması, ardından bunların başka bir noktada imzalanması ve sonra geri gönderilmesi gerekiyor. - Araçta buzdolabı bulunmadığından öncelikle özel sıcaklık rejimine sahip ürünlerin teslim edilmesi gerekiyor. - Öncelikle uzak noktalardaki siparişlerin veya VIP müşterilerin siparişlerini, sonra da diğer siparişleri yerine getirmek gerekiyor. Parametre değeri negatif olmayan bir tam sayı olabilir. Siparişler artan `sequence_order` sırasıyla işleme alınır. Buna göre, takip eden her seferdeki `sequence_order` değer bir öncekinden daha az olmamalıdır. Eşit önceliğe sahip siparişler rastgele sırayla yerine getirilir. Önceliği olmayan siparişler herhangi bir sırayla ve rotada herhangi bir yerde işleme alınabilir. **Örnek** Örnekte 3 sipariş mevcut: önceliği 1 olan 1. sipariş, önceliği 2 olan 2. sipariş ve önceliği olmayan 3. sipariş. Buna göre kurye 1. siparişi 2. siparişten önce yerine getirmek zorunda; 3. sipariş ise herhangi bir zamanda yerine getirilebilir. Planlamanın sonucunda şu sipariş sırası seçenekleri mevcuttur: - 1\. sipariş → 2. sipariş → 3. sipariş - 1\. sipariş → 3. sipariş → 2. sipariş - 3\. sipariş → 1. sipariş → 2. sipariş [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/d740cb48-b6f8ef93-d0c726be-e5753752) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/d740cb48-b6f8ef93-d0c726be-e5753752) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#d740cb48-b6f8ef93-d0c726be-e5753752) ### Planlan rotalardaki öncelikler {#sequence-order-planned} [Planlanan rotadaki](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles-routes.md#planned-route) siparişleri sıralaması öncelik sırasını takip etmiyorsa siparişler `sequence_order` ögesine uygun sırada işlenir. İstisna: `vehicles.fixed_planned_route` parametresinin değeri `true` olarak belirlenmişse planlanan rotanın optimize edilmesi gerekmiyorsa. Bu durumda çözüm `sequence_order` önceliği tarafından belirtilen sıralamayı ihlal ediyorsa yerine getirilemez (`UNFEASIBLE`) olarak addedilecektir. **Örnek** Örnekte 4 sipariş ve 1 kurye bulunmaktadır. Siparişler `vehicles.planned_route` alanında düz sırada kaydedilmiş bulunuyor: 1 → 2 → 3 → 4. Siparişler `sequence_order` alanında ters sırada kaydedilmiş bulunuyor: 4 → 3 → 2 → 1. Planlanan rota burada tutturulmuş değil, `vehicles.fixed_planned_route` = `false`. Sonuç olarak siparişler öncelik sırasına göre sıralanır. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/7d7f7674-bb3fa96f-e129f58f-11bc3086) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/7d7f7674-bb3fa96f-e129f58f-11bc3086) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#7d7f7674-bb3fa96f-e129f58f-11bc3086) ### Sabit rotalardaki öncelikler {#sequence-order-fixed} [Rotanın sabit kısmı](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles-routes.md#visited-locations) öncelik sırasını ihlal ediyorsa, o zaman çözümün yerine getirilemez ((`UNFEASIBLE`)) olduğu kabul edilecektir. Aksi hâlde rotanın sabit kısmından sonra yerine getirilmesi gereken siparişlerin `sequence_order` değerinin, sabit rotadaki siparişler arasındaki maksimum `sequence_order` değerinden daha az olmaması gerekir. **Örnek** Örnekte 4 sipariş ve 1 kurye bulunmaktadır. `vehicles.visited_locations` alanında verilen siparişler: 2, 4, 3. 2. ve 4. siparişlerin önceliği 1, 1. ve 3. siparişlerin önceliği 2’dir. Sonuç olarak ilk önce rotanın sabit kısmındaki siparişler yerine getirilir: 2 → 4 → 3 → 1. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/83f8e42d-f653609b-f6a25277-54fcb9b3) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/83f8e42d-f653609b-f6a25277-54fcb9b3) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#83f8e42d-f653609b-f6a25277-54fcb9b3) ### Çoklu siparişlerdeki öncelikler {#sequence-order-multi} `options.merge_multiorders` seçeneği aynı adrese sahip siparişleri – sadece bu siparişlerin aynı (`sequence_order`) yerine getirilme önceliğine sahip olması durumunda – [çoklu sipariş](https://docs.routeq.com/doc/tr/vrp/properties-of-orders.md#multi-orders) olarak birleştirir. Burada `sequence_order` olmaması farklı bir değerle belirtilir. Aynı adrese sahip birkaç sipariş için farklı öncelik değerleri belirtilmişse, bu siparişlerin mutlaka çoklu sipariş olarak birleştirilmesi gerekmez (ancak böyle bir çözüm daha optimal ve belirtilen sınırlamalar göz önüne alındığında mümkünse, bunlar birleştirilebilir). **Örnekler** Örneklerde her biri 8 sipariş kapasiteli 2 kurye bulunmaktadır. Çoklu sipariş olarak birleştirme seçeneği etkin durumda. Toplam 12 sipariş mevcut: - Birinci grup – aynı öncelik ve adreslere sahip 4 sipariş. - İkinci grup – aynı adrese sahip 4 sipariş fakat 2 sipariş aynı önceliklere sahip ve 2 sipariş için öncelik yok. - Üçüncü grup – farklı önceliklere sahip 4 sipariş; bunlardan sadece 2 tanesi aynı adrese sahiptir. **Örnek 1** Üçüncü grupta 3-A ve 3-E siparişleri aynı adreslere sahiptir. Sonuç olarak sadece birinci ve ikinci gruptaki siparişler birleştirilir. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/47dbb501-5e8daf36-7708ff51-11422c67) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/47dbb501-5e8daf36-7708ff51-11422c67) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#47dbb501-5e8daf36-7708ff51-11422c67) **Örnek 2** Üçüncü grupta 3-A ve 3-C siparişleri aynı adreslere sahiptir. Sonuç olarak 3-A ve 3-C siparişleri de tek bir çoklu sipariş olarak birleştirilir. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/8f32a55b-5143b40d-3baee413-2e599ab8) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/8f32a55b-5143b40d-3baee413-2e599ab8) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#8f32a55b-5143b40d-3baee413-2e599ab8) ## Rota optimizasyonu için ek sipariş parametreleri {#custom-value} Bazen bir rotayı optimize etmek için bazı özel sipariş parametrelerinin hesaba katılması gerekir. Örneğin bir kuryenin belirli bir siparişi yerine getirme karşılığında elde ettiği kazanç veya siparişin iş süreçleri açısından değeri. Görevlerde bu tür parametreleri hesaplamak için ek `custom_value`sayısal alan kullanılır. `custom_value` değerleri toplanır ve [gelişmiş ücret ayarlarında](https://docs.routeq.com/doc/tr/vrp/properties-of-vehicles-cost.md#custom-route-cost) değişken, anahtar kelimeye göre ulaşılan `total_custom_value` değerine kaydedilir. **Örnek** Yemek dağıtımı servisinde kuryelere sadece siparişi müşteriye teslim etmeleri karşılığında ödeme yapılır ve siparişleri almak için restorana gidilmesi karşılığında herhangi bir ücret alınmaz. Kuryenin vardiya başına en az 12 sipariş teslim etmesi şirketin çıkarınadır. Bu senaryonun gerçekleşmesi için `delivery` türündeki siparişlerde aynı `custom_value` = 1 değeri belirtilir, `pickup` türündeki siparişler değilse bu alanın değeri 0’a eşittir. Araç kullanım ücreti aşağıdaki formülle belirtilir: `1000 + 100 * duration_h + 100 * max(0, 12 – total_custom_value)`. Burada kurye 12’nin altında sipariş teslim ederse, teslim edilmeyen her sipariş için arabanın ücreti 100 birim artacaktır. Ücretin yüksek olması şirket açısından aracın optimal şekilde kullanılmadığı anlamına gelecektir. Örnekte 1. kurye 1,74 saatte sadece 4 sipariş teslim ediyor, dolayısıyla onun rotası için `total_custom_cost` çözüm ücreti `1000 + 174 + 800 = 1974` birimdir. 2. kurye 4,16 saatte 12 sipariş teslim ediyor ve onun rotası için çözüm ücreti `1000 + 416 = 1416` birimdir. [API isteği (JSON)](https://courier.yandex.ru/vrs/api/v1/log/request/3640382-f7bc14b4-3a0f882f-a3022621) ⋅ [API yanıtı](https://courier.yandex.ru/vrs/api/v1/result/3640382-f7bc14b4-3a0f882f-a3022621) ⋅ [Haritada aç](https://yandex.com/courier/mvrp-map#3640382-f7bc14b4-3a0f882f-a3022621) {% include [warehouse-feedback](_includes/feedback-b2774f1f09f5.md) %}