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 (delivery_to_any kullanılıyorsa;

• Başlangıç depodan değil veya bitiş depoda değil 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 içeriyor;

  • sipariş birkaç noktaya teslimat/noktadan teslim alma şeklindedir.

Sipariş tanımlayıcısı

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’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.

Sipariş koordinatları

Sipariş teslimat noktası 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 (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ı).

• 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.

Sipariş türü

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 – delivery türünde benzersiz nokta;

  • delivery_to_any – drop_off türünde benzersiz olmayan nokta;

• drop_off – delivery_to_any senaryosunda gönderi indirme noktası.

• garage – başlangıç noktası depodan değil veya bitiş noktası depoda değil.

• anchor – bir dorsenin uzun süre bırakılabileceği ve aktarılabileceği nokta.

• parking – bir dorsenin 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 bölümü).

• courier – kuryenin mevcut konumu; sadece ek planlama için kullanılır (bkz. Periyodik ek planlama bölümü).

Sipariş ağırlığı

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/800yani 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).

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.

Örnek

Bir kurye kargo bölmesi kapasitesi 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) ⋅ API yanıtı ⋅ Haritada aç

Kullanıcı ölçüm birimleri

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 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.<seri numarası>.name – kullanıcı ölçü biriminin adı;

• shipment_size.custom.<seri numarası>.size – siparişin, kullanıcı ölçüm birimine göre büyüklüğü.

Varsayılan olarak shipment_size.custom.<seri numarası>.size = 0.

Birden fazla kullanıcı ölçü birimi belirtilebilir ve bunlara istediğiniz adı verebilirsiniz.

Kullanıcı parametresi price (sipariş tutarı) için Excel dosya sayfalarını doldurma örneği:

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Sipariş boyutları

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.

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).

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.

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).

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Siparişin araçtaki yönü

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) ⋅ API yanıtı ⋅ Haritada aç

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Sipariş zaman aralığı

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.

Zaman aralığı şu formatlardan birinde belirtilir:

• 07:00:00 – 23:00:00 – zaman aralığı ilgili günde sabah 7’de başlar ve akşam 23’te biter;

• 2019-10-10T07:00:00+03:00/2019-10-10T23:00:00+03:00 – belirli bir tarih ve saat dilimi için zaman aralığı (YYYY-MM-DDThh:mm:ss±hh:mm olarak okunur).

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).

Katı zaman aralıklarını yönetmek için hard_window alanı kullanılır:

• true – zaman aralığı katı olacaktır.

• false – zaman aralığı esnek olacaktır.

Esnek zaman aralığının belirtilmesi durumunda ek olarak bunun ihlali ile ilgili cezalat da atanabilir. Bu özellik Depo zaman aralığını ihlal etme cezaları bölümünde daha ayrıntılı açıklanmıştır.

Ana pencerede izin verilen ihlalleri sınırlamak için esnek bir pencerenin etrafına katı bir pencere tanımlanabilir.

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.

Sipariş çoklu zaman aralığı

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.

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Ö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 de göreceli formatta yazıldığını ve gerekli tarihlerin her ikisini de içerdiğini not edin. Cмены работы автомобиля her iki gün için de belirtilmelidir.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Sipariş zaman aralıklarını ihlal etme cezaları

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.

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.

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Sipariş teslimatında hizmet süresi

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 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 bölümünde açıklanmıştır (örneğin siparişlerin çapraz sevkiyatta yeniden yüklenme süresi). Ayrıca bir aracın hizmet süresi hesaplanırken hizmet süresi düzeltmesi 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 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.

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:

  <Ortalama vardiya süresi> − <Vardiya başına ortalama nokta sayısı> * <Ortalama hizmet süresi>.

  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 raporunu kullanın.

Örnek

Örnekte her sipariş için hizmet süresi tanımlanmıştır.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Depoda sipariş yükleme veya boşaltma hizmet süresi

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 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 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) ⋅ API yanıtı ⋅ Haritada aç

Siparişin depoda hazır olma zamanı

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 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) ⋅ API yanıtı ⋅ Haritada aç

Siparişin depodan alınabileceği en son zaman

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.

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)

Sipariş elleçlenmeye alındıktan sonra, araca yüklenmesi için zamanadepot_duration_s ihtiyaç olabilir. Depodaki toplam hizmet 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) ⋅ API yanıtı ⋅ Haritada aç

Teslim alma ve teslimat

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;

• belirtilen depolardan birine – depoların tanımlayıcıları location.depot_id alanında belirtilmelidir, bkz. Siparişi depoya bağlama. 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ı;
  • son teslimat zamanı location.delivery_deadline atanmışsa, bkz. Yerinden alınan (pickup) siparişin depoya teslimatı;
  • 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) ⋅ API yanıtı ⋅ Haritada aç

Teslim alma ve teslimat sırasını dikkate almak için location.in_lifo_order 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ı

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 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.
2. Koltuğu yükle.
3. Sandalyeyi yükle.
4. Sandalyeyi indir.
5. Koltuğu indir.
6. 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.

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Uygun lokasyonlardan birine teslimat

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 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.

Drop_off siparişler için hizmet süresi 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) ⋅ API yanıtı ⋅ Haritada aç

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Gönderinin olası konumlardan birinde teslim alınması

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) ⋅ API yanıtı ⋅ Haritada aç

Siparişi depoya bağlama

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ı (pickup_from_any);

• “Teslim alma ve teslimat” senaryosunun uygulanması (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.
2. Başka bir kurye 3 numaralı depodan 3 numaralı siparişi işler.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Yerinden alınan (pickup) siparişin depoya teslimatı

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ı 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 ya rota sonunda depoya dönüyor ya da rotanın ortasında depoya uğruyor), 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) ⋅ API yanıtı ⋅ Haritada aç

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Siparişin depoya teslimat zamanı

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 bölümünde ele alınmıştır.

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Bir siparişin araçta kalabileceği süreyi sınırlandırma

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
• Gönderilerin depoya toplanması
• Gönderinin olası konumlardan birinde teslim alınması
• Uygun lokasyonlardan birine teslimat

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Çoklu siparişler

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 ç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).

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) ⋅ API yanıtı ⋅ Haritada aç

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Siparişleri bölme

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.

Elde edilen çözümle çalışmada veya haritada 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.

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) ⋅ API yanıtı ⋅ Haritada aç

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Siparişin bir bölümünü teslim etmeme cezası

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) ⋅ API yanıtı ⋅ Haritada aç

Siparişleri bölme hizmet süresi

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.

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).

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 veya çarpan 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) ⋅ API yanıtı ⋅ Haritada aç

Örnek 2

Örnek 1’dekiyle aynı ancak hizmet süresi service_durations yapısında atanmıştır.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Siparişi yerine getirmeme cezaları

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.

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.

Siparişin araçlara uygunluğu

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 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 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) ⋅ API yanıtı ⋅ Haritada aç

Sipariş uygunsuzluğu

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 ç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 atamak için vehicle.incompatible_load_types parametresini kullanın; bu parametre aracın özelliklerinin dikkate alınmasına imkân tanır.

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Yoğunluk seçeneklerini açma ve kapatma

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) ⋅ API yanıtı ⋅ Haritada aç

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Siparişlerin önceliklendirilme sırası

Bazı siparişlerin diğerlerinden önce tamamlanması gerekiyorsa sequence_order parametresini kullanarak öncelik atayabilirsiniz.

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) ⋅ API yanıtı ⋅ Haritada aç

Planlan rotalardaki öncelikler

Planlanan rotadaki 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) ⋅ API yanıtı ⋅ Haritada aç

Sabit rotalardaki öncelikler

Rotanın sabit kısmı ö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) ⋅ API yanıtı ⋅ Haritada aç

Çoklu siparişlerdeki öncelikler

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ş 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) ⋅ API yanıtı ⋅ Haritada aç

Ö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) ⋅ API yanıtı ⋅ Haritada aç

Rota optimizasyonu için ek sipariş parametreleri

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_valuesayısal alan kullanılır.

custom_value değerleri toplanır ve gelişmiş ücret ayarlarında 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) ⋅ API yanıtı ⋅ Haritada aç

Destek birimine yaz