Предложения по доработке Logistics

Здравствуйте всем  , хотелось бы здесь передать слова клиентов (существующих и новых ) а именно что приложение Logistics может и должна  быть более гибкой системой  . Сегодня я прочитал почти все ветки по доработке Logistics и составили небольшой список предложений и надеемся что они попадут на стол разработчиков ))) Некоторые из них взаимосвязанные :

1)Возможность сохранить предварительный маршрут без Т.С. В таком случае после сравнения всех Маршрутов  можно будет назначить объект по разным  критериям (экономичность, габариты , знания водителя той или иной местности, покрытие дороги и т.д.)

2)Возможность удалять одну  или несколько сразу заявок  из готового маршрута с Автоматическим его перерасчетом .
  А при подтверждении  удалении  заявки/заявок можно было выбирать опцию обратно в список или удалить совсем ?

3) Автоматический пересчет маршрута после всех изменений (добавление новой заявки, удаление из маршрута и т.д.)

4) В идеале хотелось бы иметь возможность в файле экспорта готового Маршрута получить еще один столбец с указанием имени
водителя закрепленным к заявке и к Т.С. 

5)Возможность задать в настройках планирование минимальное время остановки/стоянки Т.С. в точку разгрузки для того чтобы
заявка считалось посещенной вне зависимости от статуса .

Мы предполагаем что очень много задач ,наверное, можно решить  путем интеграции ,но часто мы сталкиваемся с тем что программисты
не являются частью компании клиента и требуют сумасшедших  бюджетов для реализации проектов. Другая ситуация когда клиент  попросту не имеет необходимость интегрировать и желает работать только в интерфейсе приложении , для таких случаев мы обозначили
все эти  предложения .
Спасибо за внимание  , надеемся на позитивный ответ .

Доброго дня, коллеги.

Столкнулись с такой проблемой: нужно распределить 102 заявки по машинам с учетом грузоподъемности последних. Всего в автопарке 10 машин. Если я выбираю все 10 - количество предложенных маршрутов варьируется от 5 до 9 (см. скриншоты).

Причем 5 маршрутов - это далеко не первый вариант, который предлагает приложение.

То есть экспериментально выяснили, что возможно распределить на 5 машин все 102 заявки. Далее если я вручную выбираю 5 машин, то заявки (в большинстве случаев) распределены без опозданий и превышений по тоннажу.

Вывод: приложение при первом расчете не предлагает оптимальное (минимальное) количество маршрутов, когда выбираются все доступные объекты (при выключенной опции "Задействовать оптимальное количество объектов", которая, как мы знаем, влияет только на критичное время опоздания). Клиент вынужден много раз пересчитывать маршруты, чтобы узнать минимальное количество машин, на которое можно без опозданий и превышений распределить заявки. При этом можно было бы предположить, что при росте количества объектов, может быть, уменьшается совокупный пробег? Нет, вот несколько примеров (пробег округлён до целых):
6 маршрутов - 3255 км
8 маршрутов - 3971 км
5 маршрутов - 2855 км

Приложение позиционируется как инструмент, позволяющий вовремя доставить заказы при минимизации пробега и количества используемых объектов - и мы обещаем это клиентам. В итоге к нам обращаются вот с такими претензиями.

При обращении на суппорт получили такой ответ (цитирую лишь часть длинной переписки):

и

и

Доставить быстро - это  отлично, но 10 заявок можно развести десятью машинами в кратчайшие сроки и без использования Logistics - где здесь оптимизация?

Из описания приложения на сайте:

Под выделенными утверждениями перевозчики понимают уменьшение пробега и количества задействованных машин, что влечет за собой снижение затрат на топливо, обслуживание автопарка и зарплаты водителей.
Если приложение не ставит перед собой целью сокращение издержек, то, вероятно, стоит пересмотреть его описание, чтобы не вводить пользователей в заблуждение. Или же описать, какие именно издержки в данном случае подразумеваются.

Судя по активности в теме (точнее практическое отсутствие реакции разработчиков и бизнес-аналитиков) мы понимаем, что проект не развивается.
Но очень просим хотя бы пофиксить такую странную логику работы приложения, иначе "оптимизация" останется красивым словом в описании...

Заранее спасибо за помощь.

Надо не забывать, что Логистикс - приложение для компаний с достаточно малым объемом перевозок и "легкими" процессами планирования. В приложении нет вариативности настройки планирования и распределения, алгоритм прост как валенок.

Для компаний, в которых нужно учитывать различные алгоритмы, множество факторов по водителям, ТС, складам, трассам и доп. условиям, нужно что-то типа Maxoptra.

Спасибо Mars за  быстрый и развернутый ответ . Да я буду на Телематике и буду рад знакомству и общению с вами . До скорой встречи.
А что касается других логистических программ , мы еще в поиске , как будет что-то яснее обязательно поделимся со всеми .

Добрый день.

Основная цель - минимизация времени а ни пробега. И количество машин. А вот забивать под завязку хоть и не цель, но получается как следствие оптимизации. Однако получить 100% идеальный результат не представляется возможным т.к. мы должны выдать результат в разумных временных рамках. Алгоритм использует разные методы предсказания, но остается фактор случайности. Поэтому есть возможность сравнить варианты и подредактировать.
Проект не заброшен, разработка продолжается, в том числе алгоритма распределения

mabu речь про время работы объекта, т.е. общей длительности маршрута (как в навигаторах). Например, если есть дорога по которой можно быстрее проехать, хоть она и длиннее, алгоритм выберет её. Выбираются кратчайшие по времени маршруты и последовательности посещения, и упираясь в грузоподъемность, тем самым оптимизирует и её. Дополнительно заботиться о грузоподъемности нет необходимости, всё упирается скорее в вычислительные ресурсы при большом количестве заявок/объектов

Добрый день.
Клиент хочет получать письмо на почту или смс когда водитель меняет статус заявки или пишет комментарий к ней. Это возможно?

Здравствуйте, RP24telecom.

Можно настроить получение уведомлений для вашего клиента по sms или электронной почте по следующим событиям:

1) Заявка выполнена;
2) Время до прибытия заявки;
3) Заявка в пути;
4) Расстояние до места доставки;
5) Cоздание маршрута;
6) Отмена маршрута; 
7) Изменение контактной информации клиента;
8) Прикрепление к заявке файлов;
9) Удаление файлов из заявки;
10) Изменение параметров заявки;
11) Превышение времени доставки;
12) Превышение время разгрузки;
12) Отклонение от маршрута;
13) Пропуск заявки;
14) Отсутствие статуса;
15) Внесение в маршрут изменений.

Соответственно, если отвечать именно на ваш вопрос, то подобных типов уведомлений нет. Есть уведомление только о переведении заявки в статус "Выполнен".

Здравствуйте, spamergoroda!

Мы подумаем, каким образом можно улучшить интерфейс мобильного приложение Logistics, чтобы упростить вызов окна со списком сторонних навигаторов и координатами в точку на маршруте. И я дам вам дополнительный ответ, сможем ли мы это сделать и когда.

Подскажите, пожалуйста, что вы имеете в виду под "метку, которую создали в приложении"? Метка - это следующая заявка или что-то другое?

darkpal
Вы абсолютно правы: оптимизация маршрутов, которые состоят из нескольких или многих точек, - это одна из самых сложных задач в программировании, когда перебираются тысячи вариантов, чтобы в итоге выдать один, самый правильный на основе настроек маршрута.

В то же время сейчас обратная связь о том, что вам неясна логика распределения заявок, выглядит немного голословной: пришлите, пожалуйста, на support@gurtam.com или mars@gurtam.com данные УЗ, по которую вы говорите, маршрут, который вы оптимизировали или список заявок, который вы распределяли. Мы сможем посмотреть и дать вам более развернутый ответ, почему распределение сработало именно так в вашем конкретном случае.

Для того чтобы разобраться в результате оптимизации, по которому вы прислали скриншот, пришлите, пожалуйста также данные УЗ (логин и пароль).

Допишу в эту тему что описанные случаи возникают когда ставится галочка "Задействовать оптимальное количество объектов" в настройках распределения. Считаю что ее название вводит в заблуждение, т.к. действует с точностью до наоборот. Оптимальное, т.е. минимальное кол-во объектов будет задействовано при ее снятии. Эту галочку добавили по просьбе людей которым как раз важна скорость доставки, т.е. не экономить на объектах

Ответил тут
https://forum.gurtam.com/viewtopic.php? … 96#p174796