Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. всю разработку и проверку алгоритмов, рекомендуется производить на тестовой среде https://testdev2.logistprokurs-log.suru/ (все данные, необходимые для доступа к ней, находятся в статье);
  2. тестовая среда доступна как для запросов API, так и для интерактивного использования - все результаты работы механизмов интеграции можно проверять в интерфейсе вживую;
  3. для ознакомления с методами API без написания какого-либо кода, можно использовать интерактивную "песочницу", совмещенную с подробной документацией https://testdev2.logistprokurs-log.suru/api/docs/ui/index;
  4. все вопросы по реализации, использованию API или уточнению алгоритмов, можно задавать в службу технической поддержки support@logistprosupport@kurs-gk.suru;
  5. после отладки алгоритмов на тестовой среде, необходимо:
    1. зарегистрировать личный кабинет компании на портале ЛогистПро (если личный кабинет ранее не был создан);
    2. запросить ключ доступа к API в службе технической поддержки support@logistprosupport@kurs-gk.suru;
    3. создать в личном кабинете уникального пользователя, которым будет осуществляться вход в систему со стороны приложения (мы не рекомендуем использовать для этих целей учетные записи реальных пользователей);
    4. изменить настройки своей системы интеграции, указав базовую точку входа https://lk.logistprokurs-log.suru/api/v1/, полученный API Key и логин/пароль специального пользователя.
  6. при необходимости внешнего контроля своего сервиса интеграции, вы можете настроить регулярную проверку времени активности сервисной учетной записи в разделе Настройки интеграции.

Базовый алгоритм взаимодействия с сервисом

...

  1. передать на сервер учетные данные пользователя и API Key, вызовом метода POST /api/v1/account/login;
  2. из заголовков полученного ответа, сохранить значение cookie .AspNet.ApplicationCookie;
  3. передавать сохраненное значение cookie и API Key со всеми последующими вызовами.

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

Note
titleВнимание!

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

Публикация Запросов на перевозку

  1. робот находит новые сущности во внутренней системе (например, необработанные заказ-наряды в 1С);
  2. для каждой из них, создает запрос на перевозку, передавая в метод POST /api/v1/tender/create необходимые данные;
    1. если во внутренней системе не хранится часть данных, необходимых для создания (например, справочники юр.лиц, контрагентов, подрядчиков), то их можно предварительно получить вызовом GET /api/v1/tender/create;
    2. при выставлении на торги мы рекомендуем устанавливать следующие параметры:
      • длительность торгов в районе часа-полутора (параметры "StartDate" и "EndDate");
      • автоматический минимальный шаг торгов (параметр "MinStepReq": "Auto");
      • публично видимое лучшее предложение, чтобы перевозчики не торговались вслепую, а реально снижали стоимость (параметр "IsPublicBestOffer": true; или не передавать эти параметры и система автоматически запустит торги с рекомендованными значениями);
      • выставить стартовую цену торгов (параметр "InitCost").
        В противном случае перевозчики склонны завышать цену предложения по перевозке.
    3. в ответ получает идентификатор созданного запроса и сохраняет их для дальнейшей синхронизации во внутренней системе (например в том же документе 1С).
Info

Пример создания запроса с минимальным набором параметров можно найти в статье Как создать свой первый Запрос на перевозку.

Опрос статусов торгов

После публикации новых запросов, робот может опросить текущее состояние ранее созданных торгов.
Это можно реализовать двумя способами:

...

Если запрос находится в статусе "Просрочен" (параметр Status=Overdue) и у него есть действующее лучшее предложение (параметр BestProposal не пуст), то необходимо завершить торги принятием предложения.
Для этого необходимо:

  1. получить идентификатор лучшего предложения из параметра BestProposal.Id;
  2. подставить идентификатор в URL метода POST /api/v1/propose/{id}/confirm и выполнить его.

...

Если запрос находится в статусе "Просрочен" (параметр Status=Overdue), но у него нет действующих предложений (параметр ProposalsCount=0 и BestProposal пуст), то робот может принять решение о продлении торгов с изменением стартовых данных для повышения привлекательности у перевозчиков.
Для этого необходимо:

  1. вызвать метод POST /api/v1/tender/{id}/start (предварительно подставив на место {id} идентификатор запроса);
  2. передавая в него следующие параметры:
    1. EndDate - новое время окончания торгов;
    2. InitCost - новая стартовая цена (обычно ставится выше предыдущей);
    3. Type=Hot - изменение типа торгов на "горящие" (первый же, сделавший предложение, забирает перевозку - используется для экстренного распределения).

...

После завершения торгов запрос переходит в статус "На согласовании"=Approving. После предоставления перевозчиком данных согласования запрос приобретает статус "Согласован"=Completed.
Данные согласования могут быть получены из детальной информации запроса и сохранены во внутреннюю систему для дальнейшей обработки (например, контроля очередности погрузки или оформления пропусков).
Для этого необходимо:

  1. вызвать метод GET /api/v1/tender/{id}/start (предварительно подставив на место {id} идентификатор запроса);
  2. получить данные из полей BestProposal.Driver и BestProposal.Vehicle.

Статус "Согласование просрочено"=ApproveOverdue означает, что перевозчик не успел предоставить данные согласования за установленный срок, что может являться основанием для срыва перевозки или перевыставления ее на новые торги.

Перевыставление отказных перевозок

...