...
- всю разработку и проверку алгоритмов, рекомендуется производить на тестовой среде https://testdev2.logistprokurs-log.suru/ (все данные, необходимые для доступа к ней, находятся в статье);
- тестовая среда доступна как для запросов API, так и для интерактивного использования - все результаты работы механизмов интеграции можно проверять в интерфейсе вживую;
- для ознакомления с методами API без написания какого-либо кода, можно использовать интерактивную "песочницу", совмещенную с подробной документацией https://testdev2.logistprokurs-log.suru/api/docs/ui/index;
- все вопросы по реализации, использованию API или уточнению алгоритмов, можно задавать в службу технической поддержки support@logistprosupport@kurs-gk.suru;
- после отладки алгоритмов на тестовой среде, необходимо:
- зарегистрировать личный кабинет компании на портале ЛогистПро (если личный кабинет ранее не был создан);
- запросить ключ доступа к API в службе технической поддержки support@logistprosupport@kurs-gk.suru;
- создать в личном кабинете уникального пользователя, которым будет осуществляться вход в систему со стороны приложения (мы не рекомендуем использовать для этих целей учетные записи реальных пользователей);
- изменить настройки своей системы интеграции, указав базовую точку входа https://lk.logistprokurs-log.suru/api/v1/, полученный API Key и логин/пароль специального пользователя.
- при необходимости внешнего контроля своего сервиса интеграции, вы можете настроить регулярную проверку времени активности сервисной учетной записи в разделе Настройки интеграции.
Базовый алгоритм взаимодействия с сервисом
...
- передать на сервер учетные данные пользователя и API Key, вызовом метода POST /api/v1/account/login;
- из заголовков полученного ответа, сохранить значение cookie .AspNet.ApplicationCookie;
- передавать сохраненное значение cookie и API Key со всеми последующими вызовами.
Авторизацию можно принудительно производить один раз за сессию (период работы робота) или только в случае получения кода 401 в ответ на вызов любого метода.
| Note | ||
|---|---|---|
| ||
Не рекомендуется производить авторизацию непосредственно перед вызовом каждого метода - это бесполезно и не дает гарантии успешной авторизации. |
Публикация Запросов на перевозку
- робот находит новые сущности во внутренней системе (например, необработанные заказ-наряды в 1С);
- для каждой из них, создает запрос на перевозку, передавая в метод POST /api/v1/tender/create необходимые данные;
- если во внутренней системе не хранится часть данных, необходимых для создания (например, справочники юр.лиц, контрагентов, подрядчиков), то их можно предварительно получить вызовом GET /api/v1/tender/create;
- при выставлении на торги мы рекомендуем устанавливать следующие параметры:
- длительность торгов в районе часа-полутора (параметры "StartDate" и "EndDate");
- автоматический минимальный шаг торгов (параметр "MinStepReq": "Auto");
- публично видимое лучшее предложение, чтобы перевозчики не торговались вслепую, а реально снижали стоимость (параметр "IsPublicBestOffer": true; или не передавать эти параметры и система автоматически запустит торги с рекомендованными значениями);
- выставить стартовую цену торгов (параметр "InitCost").
В противном случае перевозчики склонны завышать цену предложения по перевозке.
- в ответ получает идентификатор созданного запроса и сохраняет их для дальнейшей синхронизации во внутренней системе (например в том же документе 1С).
| Info |
|---|
Пример создания запроса с минимальным набором параметров можно найти в статье Как создать свой первый Запрос на перевозку. |
Опрос статусов торгов
После публикации новых запросов, робот может опросить текущее состояние ранее созданных торгов.
Это можно реализовать двумя способами:
...
Если запрос находится в статусе "Просрочен" (параметр Status=Overdue) и у него есть действующее лучшее предложение (параметр BestProposal не пуст), то необходимо завершить торги принятием предложения.
Для этого необходимо:
- получить идентификатор лучшего предложения из параметра BestProposal.Id;
- подставить идентификатор в URL метода POST /api/v1/propose/{id}/confirm и выполнить его.
...
Если запрос находится в статусе "Просрочен" (параметр Status=Overdue), но у него нет действующих предложений (параметр ProposalsCount=0 и BestProposal пуст), то робот может принять решение о продлении торгов с изменением стартовых данных для повышения привлекательности у перевозчиков.
Для этого необходимо:
- вызвать метод POST /api/v1/tender/{id}/start (предварительно подставив на место {id} идентификатор запроса);
- передавая в него следующие параметры:
- EndDate - новое время окончания торгов;
- InitCost - новая стартовая цена (обычно ставится выше предыдущей);
- Type=Hot - изменение типа торгов на "горящие" (первый же, сделавший предложение, забирает перевозку - используется для экстренного распределения).
...
После завершения торгов запрос переходит в статус "На согласовании"=Approving. После предоставления перевозчиком данных согласования запрос приобретает статус "Согласован"=Completed.
Данные согласования могут быть получены из детальной информации запроса и сохранены во внутреннюю систему для дальнейшей обработки (например, контроля очередности погрузки или оформления пропусков).
Для этого необходимо:
- вызвать метод GET /api/v1/tender/{id}/start (предварительно подставив на место {id} идентификатор запроса);
- получить данные из полей BestProposal.Driver и BestProposal.Vehicle.
Статус "Согласование просрочено"=ApproveOverdue означает, что перевозчик не успел предоставить данные согласования за установленный срок, что может являться основанием для срыва перевозки или перевыставления ее на новые торги.
Перевыставление отказных перевозок
...