Автоматизация курьерских служб: опасности управления логистикой в 1С

В последнее время я наблюдаю бум 1С-решений в области автоматизации логистики.

В интернете развелось огромное количество умельцев, которые прикручивают сервисы геокодирования и маршрутизации от Яндекс, Гугл и OpenStreetMap к типовым или самописным конфигурациям, выдавая это за «программу для управления логистикой в 1С».

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

Объясню свою позицию. Все специфичные для подобных решений «логистические» примочки для 1С, такие как:

• показ карты города в интерфейсе программы,
• отображение точек на этой карте,
• прокладка маршрутов между точками с их последующим наглядным отображением,

невозможны без использования так называемого API.

API – это способ связи между приложениями. Соединительная ткань для доступа к чужим ресурсам. В данном случае речь идет о связи 1С с любыми картографическими сервисами, которые предоставляют возможность автоматического прокладывания маршрутов и осуществляют преобразования адресов объектов в их координаты на карте или спутниковом снимке и наоборот.

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

Не надо быть мегалогистом семи пядей во лбу, чтобы понимать, что нельзя построить оптимальный маршрут исключительно возможностями 1С.

На сегодняшний день картографические ресурсы для построения оптимальных маршрутов во всеобщее интернет-пользование могут предоставить всего несколько компаний в России. Но такое ли оно всеобщее, каким его представляют себе (или вам!) горе-разработчики 1С, продающие вам кота в мешке?

Как регулируется использование API для нужд управления логистикой?

Вот что нам говорит соглашение об условиях использования сервиса «API Яндекс.Карты».

Таким образом, согласно пункту 2.3.2 ресурсы API «Яндекс.Карт» не могут использоваться в тех случаях, когда с вас за это берут деньги.

Обратим также внимание на пункт 2.3.9.3 того же соглашения из раздела «Ограничения».

Этот пункт говорит нам о том, что для целей управления логистикой использование API-карт неправомерно!

При этом чисто технически можно обмануть систему и прикрутить Яндекс API для использования в приложениях по маршрутизации заказов, но вы должны знать следующее:

• Яндекс забанит вас, когда число запросов к API превысит 25 000. В этом случае карта перестанет работать до конца суток с момента нарушения, а любые вычисления будут заблокированы. Таким образом, ваше приложение станет бессмысленным, так как вы больше не сможете распределять заказы по курьерам и строить для них оптимальные маршруты!
• Суточный лимит запросов кончится, когда вы зададите около 150 точек на карте, обозначите области ответственности 10 курьеров и попробуете все это маршрутизировать. При этом возможна ситуация, когда ваш оператор ошибется и ему придется проделывать какую-то операцию заново. В этом случае вы не сможете получить удовлетворяющий вас результат в принципе даже для этой задачи, так как лимит будет вычерпан.

А можно ли использовать API правомерно и на каких условиях?

Конечно можно. В этом случае вы сможете выбрать любое нужное число запросов к API. И не будете ограничены следующими условиями, о которых говорит нам Яндекс:

• Карта должна быть размещена на сайте или в приложении, которые сможет увидеть любой человек: без платной регистрации и получения особых прав. Например, карта не должна попасть во внутреннюю сеть компании или на сайт, который доступен только по приглашениям.
• API не будет использоваться для управления транспортом или мобильными сотрудниками.
• Полученные от API данные должны быть отображены на карте с логотипом Яндекса. Вы не можете изменять или сохранять их.

А вот и обещанные коммерческие условия:

Впрочем, как гласит народная мудрость:

«Волков бояться – с ручными расчетами и прочей нудной мегалогистикой запариться».

Потому задавайте своим разработчикам правильные вопросы и не ведитесь на подобные ответы:

И мой чек-лист вам в помощь.

Как проверить законность использования методов API для целей управления логистикой в 1С?

1. Спросите у продавца решения, какие карты (API-сервисы) используются для расчета оптимальных маршрутов в его приложении.
2. Узнайте об ограничениях, которые накладывает данный сервис на использование своего API в продукте, который он собирается продать вам.
3. Попросите лицензионный договор на приобретаемый продукт. Внимательно изучите его. Ищите пункты о том, как правообладатель используемых сервисов разрешает вашему продавцу использовать API в своем решении. Нет такого пункта? – Вы покупаете кота в мешке.
4. Осведомитесь, заключено ли соглашение между разработчиком и сервисом. Если такого соглашения нет, будьте готовы к тому, что вы не только отдадите деньги за покупку решения, но и заплатите правообладателю за использование API, когда он наложит ограничения на ваш продукт.

При этом, скорее всего, денег за кота в мешке, ой, простите, за пупермегалогистику вам уже не вернут…

Ну а такие и им подобные пункты договоров я оставлю на закуску.

Когда увидите такой пункт договора, попросите Лицензиара еще раз предоставить вам соглашение между ним и сервисом о безвозмездной технической возможности использовать картографию :)

Ах, да! Ну и, конечно, будьте морально готовы к тому, чтобы выложить круглую сумму за нормальное лицензионное техническое решение по оптимизации вашей логистики – оно обязательно окупит себя.