motors пишет:serd пишет:motors пишет:
Сделайте в проге, что бы была возможно без валидности маршрута можно было обязательное посещение промежуточного склада.
К сожалению описание вами задачи не точное. Уточните, пожалуйста
- как именно по вашему должна вести себя система
- для чего необходима такая такая доработка и каковы схемы использования
- кто именно будет пользоваться этой функцией и можно ли пообщаться с этим человеком
- какова потенциальная выгода от ее введения (в объектах/удобстве и т.п.)
Спасибо.
-система проста, - для чего необходима - какова потенциальная выгода:
сбор товара не в одном месте, соответсвенно что бы привезти весь товар клиенту, необходимо посетить несколько складов (промежуточных) для этого необходим функционал, выбор обязательного посещения "промежуточных складов" (по умолчанию можно выставить 1-2-3.... промежуточных склада и выбрать по умолчанию их адреса, геозоны, теги...)
- кто именно будет пользоваться этой функцией и можно ли пообщаться с этим человеком - можно со мной.
serd пишет:Сделайте добавление заявок В МАРШРУТ не только с разовых! но и с ПОСТОЯННЫХ заявок
Вы имеете в виду, что в уже идущий маршрут необходимо добавить возможность вставлять ПОСТОЯННУЮ заявку. Уточните, пожалуйста, какое ваше видение времени, которое будет в таком случае использоваться для заявки (из самой заявки, система вместо него подставит свое и т.п.). А также что делать, если маршрут например через сутки/двое - тогда необходимо знать еще и какую дату подставлять.
из самой заявки система пусть ставит куда угодно, где, как сейчас происходит, идет ручное перетаскивание добавленной заявки в уже существующий маршрут. После чего диспетчер и сам решит, в какой последовательности курьеру посетить ПОСТОЯННУЮ заявку.
Давайте немного по-другому. В системе и в жихни склад - немного разные вещи. На данный момент склад в системе - такой же заказ только со специальными признаками и логикой поведени. Его задача - держать зоны ответственности и набор юнитов (привязку). Плюс он докидывается в маршрут автоматом.
То, что описываете вы - всего-лишь промежуточные заявки, а чем они являются в реальной жизни системе все-равно. Да - цепочка поставки (в том числе и составные грузы) - это отлично. Но логистика не предназначена для этого, поэтому пока нет более широкого видения приложения, ваше предложение не будет реализовано. Вероятно после ввода новых признаков заказов вашу задачу будет решить проще, как и добавление постоянных заявок в планирование вместе с новыми (разовыми). Следите за релизами.
Тем не менее - предложение занесено в список пожеланий. Спасибо за ваше участие.
motors пишет:Доброе утро, нужно бы еще добавить поле в заявках, как (стоимость доставки), бывают случаи, где клиент платит за доставку. И соответственно в отчетах должно отображаться итог, колонка стоимость доставки.
Еще момент. Если возможность привязывать к заявкам учетку, а именно кто создал заявку. У нас несколько учеток, и бывают случаи, где курьер не понимает, кто именно создал заявку.
предложение выводить имя диспетчера занесено в список пожеланий по проекту. Ваше мнение будет отражено там в качестве просьбы аналогичного функционала. Тем не менее - как и в предыдущем случае задам вопрос - для чего именно это необходимо? Какую именно проблему призвано решать? Допустим - есть несколько диспетчеров. Есть маршруты, назначенные курьеру, у них есть порядок, следование и т.д. Что именно он будет делать с информацией о том, какой именно диспетчер их назначил?
Про стоимость доставки - почему не добавить ее к стоимости заказа? В задачу логистики не входит - диверсифицировать затраты, доходы, сводить сальдо и прочее. По сути вы просите поле, которое будет использоваться крайне редко, но при этом утяжелит интерфейс.
maxim_prm пишет:Подскажите можно ли как то при импорте заявок быстро выявить адреса которые не определились, а особенно определились неправильно?
Здравствуйте, Максим. Такие заявки определятся в океане. Можно перетащить руками или откорректировать в списке.
motors пишет:Товарищи программисты, если я Вас еще не так сильно достал своими идеями и т.п., но у меня очередная просьба, которую, думаю, многие одобрят.
Нужен статус по каждой заявке, плюсом в мобильное приложение доп функцию для курьера, где он будет нажимать определенную кнопочку, уведомив диспетчера о том, что он взял оплату за товар по данной заявке....
Таким образом выставлен изначально статус - НЕ ОПЛАЧЕНО. Когда курьер берет деньги, он в заявке в мобильном приложении выставляет оплатил.... Статус у диспетчера меняется ОПЛАЧЕНО. Если есть возможность, то и подсветить зеленый цветом.
Соответственно и в отчетах будет отображаться что оплачено, что нет.
Настолько точный микроконтроль в планах не обозначен, однако новых статусов с вводом дополнительных признаков мы обязательно добавим. Возможно даже через месяц-два. Надеемся, что после их ввода вы сможете обозначить точней ваши пожелания.
M2Max пишет:Возник вопрос, в планировании выбираем несколько заявок с указанными в них разными типами т/с, указываем дату жмем далее, появляется список машин подходящих по типам т/с в заявках, выбираем все машины, далее и все заявки прикрепляются только к одной машине, а предполагалось что появятся несколько маршрутов с соответствующими типами т/с в заявке и в авто, такое возможно сделать?
Здравствуйте. Список - это всего лишь фильтр (для удобства вам показываются только объекты с подходящим типом). Опции распределения заявок указываются отдельно - пользователь самостоятельно решает, какие критерии выбрать и использовать. Тип объектов в распределении мы пока не учитываем, гораздо важней сколько именно объект может увезти, а также попадает ли он при этом в "окно" доставки.
M2Max пишет:И второй вопрос, возможно ли как-то заставить распределять последовательность заявок в маршруте по указанному в них приоритету?
На данный момент приоритет учитывается при распределении, но важней - время и расстояние. Т.е. нарушение приоритета имеет меньший штраф, чем нарушение окна доставки или вместимости объекта.
