Добрый день!

УТП для Украины.

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

санкционочкой пользуетесь?

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

(2) Я об этом думал, но вопрос в том что заявки обрабатываются операторами и они не знают какой маршрут надо выбрать. В момент слития агентами заявок, они должны создаваться и в них подставляться правильный маршрут. Например у покупателя 2 маршрута - маршрут №1 и маршрут №2. Если агент №1 набирает заявку, тогда при выгрузке заявки должен подставится маршрут№1 если Агент №2 набивает заявку, тогда должен подставится Маршрут №2

(3) Ты хочешь чтобы типовая конфа сама все это угадала?

(3) до..я хочешь. либо к пользователю гвоздями приколочен маршрут агент№1 = маршрут№1, либо при маршрутизации агент сидит и перебирает маршруты, и на каждый из них вываливается список покрытых маршрутом заявок.

(4) нет конечно! ) как вариант я думал еще ввести справочник оптовых баз и прикрепить агентов к каждой базе и маршрут. Это в принципе позволит подбирать правильный маршрут для каждого агента. Меня смущает, то что случайно можно для покупателя указать несколько маршрутов одной базы, хотя можно это программно не допустить. Но хотел бы услышать другие варианты, чтобы лишний раз не создавать не типовых объектов

еще думал о варианте для каждого покупателя указывать участок (атомарная часть маршрута). Например Поселок №1, город №1, район №1. а в самом маршруте указывать набор утих участков и принадлежность к оптовой базе. В этом случае. Если появится новый маршрут, тога не надо будет его указывать для всех покупателей. Связь будет через Участок.

У меня не УПП, нетленка. Действует примерно такая схема:

Клиент (Пункт доставки) => заявка на доставку => маршрутный лист.

1. Клиент через наш сайт или по телефону делает заявку => Наш сотрудник добавляет документ "Заявка на доставку" (документ содержит информацию "что", "куда", "кому",в какое время и на каком основании вести или оказывать услуги).

Есть справочник "пункты доставки", подчиненный справочнику Контрагентов там вся контактная (адрес, телефоны, контактные лица) и не контактная инфа (договор-основание) по адресу и логистическая инфа (Зона обслуживания, географические координаты)

2. Логисты делают документы "Маршрутный лист" который объединяет несколько заявок (в простейшем случае заявки уже разбиты по "зонам" или "районам обслуживания", но могут быть и корректировки/перекидки туда сюда), машину, экспедитора, водителя, исполнителя услуг. На основании этого документа Кладовщики "грузят машину", т.е. "перемещают товар" в эту машину.

Потом есть еще возврат недоставленых товаров на склад, Документ отчет водителя и т.п.

(9) Написано с пяток различных форм-мастеров для автоматизации всего этого. Возим 1000 адресов в день на 10 газелях. И три мобильных мастера по ремонту.

(9) 100 точек на машину в день? получается одна точка в 15 минут в среднем?

(10) Ну по горячился не много))
три доставки четырехчасовых доставки по 20-30 точек на 10 машин, есть)

(8) т.е у вас нет фиксированных маршрутов, а маршруты динамические в виде маршрутных листов, а в заявке только фиксируется пункт доставки

(12) Да. А в пункте доставки "зона"....

В качестве вашего "фиксированного маршрута" можно предположить нашу "Зона" (Район обслуживания, зона доставки - синонимы).

Например по адресу ул.Республики 1 - зона "Центр".

(12) ну я назвал это УЧАСТОК

(13) Но когда и как фиксируется, что заявка пошла по определенному маршруту?

(15) У нас есть обработка, которая "сортирует" заявки по полю Документ.ЗаявкаНаДоставку.ПунктДоставки.Зона

Сел логист за компьютер и видит что на Зону "Центр" у него 50 заявок на 1.5 газели товара. А смежные зоны Север и Юг - по 20 заявок с товаром на 0.5 газли. Вот он и Отдает Сервер водителю Иванову + 8 точек с центра, Юг Пертрову + 5 точек с центра, остальное на Сидорова.

Предполагается, что Иванов знает Зону Сервер (знает клиентов куда нести, где документы подписывать, как пробочку объехать и т.п.), Петров Юг, а Сидоров Центр.

Ну и с помощью этой обработки формируется документ "Маршрутный лист", который имеет табличную зачать "Заявки" с резквизитом "Заявка на доставку"

(15) в документе Заявка есть ревизит ПунктДоставки

(17) т.е траектория маршрута определяется составом Пунктов Доставки маршрута?

(17) и еще вопрос. Заявка у вас по складу делается? если да то как агент или кто там ее формирует понимает что товар в заявке есть на указанном в заявке складе?

(18) И да и нет... я не понимаю что ты имеешь в виду под "траекторией маршрута"

(19) С заявками у нас проще, у нас один склад. Просто резервируем товар со склада или с плана производства или с планируемой поставки. 99% случаев товар есть в наличии.

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

(0) Старо как мир.Конфигурации с доставкой и работой с маршрутами ещё на 7.7 мною писались в далеком 2004.Интересно, что идеи и терминология (8) полностью совпадает с этим решением.Затем все переписали на 8.0))А до 7.7 прототип работал на Access.

(21) Почти 15 лет назад это делалось в АРМ  доставки,с помощью зонирование карты и назначения водителей на маршрут с учётом тоннажа загрузки машины и прочих деталей...На выходе были маршрутные листы.

(21) Весь этот идеал имеется, проблема в другом:

Задача в общем виде давно известна и давно сформулирована математиками. Это Vechicle Routing Problem и она не имеет эффективных путей решения, не имеет алгоритма с  полиномиальной сложностью гарантирующего на выходе решение хотя бы приближенное к оптимальному.

Я, кстати, диплом на эту тему писал. Но в дипломе программирования было 20%, остальное математика)

Решения типа (23) хороши, они работают, но всегда можно подобрать специальные условия с которыми такие "решатели" не справятся.