Давайте определимся, на чем основываются мои знания про службы доставки:
- У меня есть проект по автоматизации интернет-торговли, который работает не на базе «1С»
- Я работал в компании, которая занималась фулфилментом, то есть оказанием услуг по автоматизации процессов доставки (и не только) для интернет-магазинов. И там все работало на «1С»
- Помимо этого, работал с клиентами в частном порядке, по автоматизации их интернет-магазинов
Теперь давайте рассмотрим, какие конкретно шаги необходимо сделать для интеграции со службами доставки.
Шаг №1. Определиться, с какими службами доставки должен работать интернет-магазин
В отдельной статье я рассказывал о том, как выбрать службу доставки (//infostart.ru/1c/articles/1892807/) и в чем разница между ними. Исходя из того, какие товары вы будете доставлять, его габаритов, географии доставки, скорости и стоимости услуг, вам нужно сделать выбор в пользу той или иной службы.
Шаг №2. Определение желаемого функционала
Обычно под интеграцией со службой доставки подразумевают следующий функционал:
- Отправка заказа в службу доставки. Обычно именно этот функционал является ключевым в интеграции. Именно благодаря нему все данные о заказе моментально попадают в личный кабинет службы доставки, и оператору не приходится при приеме «посылки» от вас вводить все эти данные вручную.
- Печать бланков. Обычно это отдельный метод API для получения печатных форм в формате PDF.
- Отслеживание заказа. После отправки заказа, ему присваивается трек-номер, используя который можно получить информацию о том, где сейчас находится Ваше отправление. Этот же номер можно передать клиенту, чтобы он самостоятельно смог заниматься отслеживанием своего заказа.
- Удаление, Изменение заказа. Это вещь опциональная, далеко не всегда при интеграции необходимо использовать данные методы. Почему? Дело в том, что, как правило, если корректировка и происходит – это вещь довольно редкая, и это при необходимости можно сделать вручную по каким-то штучным заказам.
Шаг №3. Необходимые доработки
- Хранение статусов – для хранения этой информации я бы порекомендовал использовать периодический регистр сведений, где в качестве изменения регистра использовать «Заказ», а в качестве ресурса «Статус». Безусловно, под разные задачи можно расширять состав Изменений и Ресурсов, но основная концепция останется прежней. Сразу хочу заметить – стандартный механизм статусов не подходит для этой задачи. В данном регистре будут храниться как статусы, которые мы будем получать при отслеживании, так и статусы движения заказа, например при отгрузке (собран, отправлен, и т.д.).
- Хранение трек номера – здесь все довольно просто. Трек номер присваивается после отправки заказа в службу доставки по API. Для его хранения я бы использовал непериодический регистр сведений.
- Хранение упаковки (с разными габаритами) – обычно «Упаковка» (с габаритами) вычисляются в зависимости от параметров заказа. Однако бывают случаи, когда для их хранения используется отдельный справочник, и пользователь вручную может задать нужные параметры упаковки для конкретного заказа.
- Хранение веса – для хранения этой информации нет четкой рекомендации. В Шаге №7 я расскажу про расчет веса по разным алгоритмам. Если расчет веса ведется с помощью весов – в «Заказ» придется добавить новый реквизит, если же используется математический или алгоритмический способ – ничего не придется добавлять. Расчет будет производится на основании данных, заполненных в Номенклатуре заказа.
- Хранение названия службы доставки – для этих целей нам понадобиться отдельный справочник и новый реквизит для «Заказа».
- Хранение кода ПВЗ – для этого можно создать отдельный реквизит в заказе. Напомню, что ПВЗ – это буквенно-цифровое обозначение пункта выдачи заказа у разных служб доставки.
Шаг №4. Статусы заказов
Статусы заказа – это очень интересная тема, и сформировать список статусов не получится «наскоком»:
- У каждой службы доставки свой набор статусов, характеризующих движение заказа. Нужно будет выделить общие, для выбранных вами служб доставки. Например: Отправлен, Прибыл в место вручения, Доставлен, Оплачен (только если вы используете наложенный платеж), Возврат. Эти статусы нужно будет отслеживать с помощью регламентного задания и делать соответствующие записи в регистр сведений (если вы решили пойти рекомендованным мною путем) об изменении статуса заказа.
- У Вас будут собственные статусы, характеризующие движение заказа. Например: Подтвержден, Передан на сборку, Собран, Отправлен, и т.д.
Если интернет-магазин будет использовать отображение статусов в личном кабинете, то статусы также будут разделены на «Публичные» и «Не публичные». Из названия понятно, что какие-то статусы мы можем использовать «для внутреннего потребления» и клиент не должен получать информацию о них.
Шаг №5. Отслеживание статуса заказа
Для отслеживания статуса заказа нам нужно будет сделать регламентное задание. Или внешнюю обработку, которая будет выполнять команду отслеживания по расписанию.
Как часто это нужно делать? На мой взгляд, наиболее удобным вариантом будет отслеживание, не реже 2-х раз в день (безусловно, частота может быть увеличена до комфортного для вас значения). Например, утром 9-00 (утром) и в 15-00 (днем). Дело в том, что часто изменение статуса заказа сопровождается отправкой информационных сообщений, соответственно такой подход позволит своевременно уведомлять клиента об изменении статуса заказа.
Шаг №6. Стандартизация адреса
Думаю, ни для кого не секрет, что адрес доставки, который заполняется на стороне сайта, далеко не всегда содержит все необходимые данные. При этом, многие службы доставки требуют раздельного заполнения улицы, номера дома и квартиры и т.д., а многие сайты передают данные одной строкой. А, например, для Почты России обязательно нужен заполненный индекс получателя. Как быть в такой ситуации? Безусловно, есть множество плагинов для сайта, которые позволяют заполнять адрес в удобном для пользователя формате, а также пригодном для дальнейшей работы со службой доставки, но что делать, если нужно делать автоматизацию на стороне 1С, а что-то менять на сайта Вы просто не можете (не имеете компетенций или, может, это вообще не ваша зона ответственности). А проект нужно сделать. Более того, бывают даже ситуации, когда на стороне сайта сделано уже много заказов (предзаказов) с уже «некорректными» адресами.
Для стандартизации адреса существует как минимум два проверенных сервиса:
- Dadata.ru – это сервис, который имеет большое количество сервисов для обработки данных. У этого сервиса есть удобное API, которое позволяет передать ему адрес в виде строки, а на выходе получить уже стандартизированный адрес, разбитый на Индекс, Страну, область, город, дом и номер квартиры. Dadata позволяет сделать в сутки до 10 000 запросов. Для большинства проектов этого более чем достаточно, за превышения лимита придется доплатить, но это вполне приемлемые деньги (точные цифры писать не буду, так как тарифы могут измениться на момент прочтения этой статьи). Главный недостаток этого сервиса – стандартизация только Российских адресов. То есть, если вы делаете доставку по странам СНГ или даже в дальнее зарубежье – нужно будет использовать альтернативный сервис.
- Yandex геокодер – по сути он способен делать все то же, что и Dadata, однако он умеет работать и с зарубежными адресами. Главный минус сервиса – лимиты. Они ограничены 1000 запросов в сутки, что совсем немного. Если же вы захотите перейти на платный тариф – цена будет исчисляться сотнями тысяч рублей (просто на порядок дороже, чем Dadata), что подходит далеко не для каждого проекта.
Обычно, когда используются смешанные направления, то есть как по России, так и международные – выгодно использовать оба этих сервиса, если адрес не распознался Dadata – передаем его на Yandex. Скоро я напишу отдельную статью с примерами работы с обоими сервисами.
Результатом работы обоих сервисов является структура, которая содержит все составляющие адреса в отдельных «ключах» (город, область, улица и т.д.). Оба эти сервиса я проверял уже на протяжении ни одного года, поэтому могу их с уверенностью рекомендовать вам.
Шаг №7. Расчет веса
Для расчета веса существует 2 способа:
- Использование реальных весов, которые будут передавать данные в 1С. Весы, с которыми мне удалось плотно поработать при автоматизации, – это весы Мера (mera-device.ru) и Штрих-М. И те, и другие отлично справлялись со своей работой, в комплекте с драйвером были довольно хорошие примеры для интеграции на разных языках программирования. Один из клиентов, которого я автоматизировал, отправлял более 2 тысяч посылок / бандеролей в день. Изначально комплектовщик собирал заказ, упаковывал, и наносил штрихкод на упаковку, на основании номера заказа. Далее, когда заказ поступал на взвешивание, его нужно было просто положить на весы и отсканировать штрих-код. В результате подобных действий происходили следующие действия:
- Программа считывала вес с весов
- По штрих-коду происходил поиск заказа
- К найденному заказу записывался полученный вес
- Доставка осуществлялась разными службами доставки, поэтому в зависимости от службы доставки происходил нужный алгоритм отправки данных (в службу доставки)
- В результате таких действий заказу был присвоен трек-номер, оставалось только распечатать необходимые документы
- Алгоритмический или математический способ расчета веса. При самом простом варианте, нам нужно знать вес каждой позиции товара, а также упаковки. Путем нехитрых математических операций мы получим вес заказа.
Бывают и более сложные варианты. Например, один из клиентов занимался торговлей колец разного радиуса, формула расчета выглядела следующим образом:
D1 И D2, это внешний и внутренний диаметр кольца
V1 = π * (D1 + (D2 *2) * (D1 + (D2 * 2) * D2 / 4 / 1000000
V2 = π * D1 * D1 * D2 / 4 / 1000000
V = V1 – V2
M = V * P, где P = 1,4
Таким образом, для каждой ситуации необходимо подбирать наиболее подходящий алгоритм. Это зависит как от разнообразия и габаритов товаров, так и от количества заказов.
Шаг №8. Расчет габаритов
Расчет габаритов заказа не всегда простая задача. Бывают, конечно, случаи, когда компания торгует товарами, где довольно просто просчитать размер упаковки или даже он всегда один. Например, если это семена или ювелирные изделия. Я встречал огромное количество разных алгоритмов подбора коробок.
Пример №1 (Продажа колец разного диаметра)
1) У нас есть коробки разных габаритов с разным лимитом по весу:
№1 - 170 * 170 * 100 - min. вес - 0,00000001г, max. вес - 800г
№2 - 300 * 230 * 160 - min вес - 801г, max. вес - 1500г
№3 - 330 * 330 * 130 - min вес - 1501г, max. вес - 3000г
№4 - 550 * 350 * 350 - min вес - 3001г, max. вес - 15000г
2) D1 + (D2*2) = наружный диаметр кольца
Полученное значение должно быть ≥ минимальному из двух параметров коробки (Длине и Ширине)
Например: в заказе есть кольцо со значением D2 = 8мм, D1 = 170, выполняется расчет по формуле D1 + (D2*2). Формула будет иметь вид: 170 + (8 * 2) = 186мм. Так как данный размер не соответствует ни одному из минимальных параметров коробки №1 (170мм * 170мм), то система автоматически должна выбрать следующую по размеру коробку, №2 (300 * 230 * 160)
3) Установить ограничение по максимальному весу, который допустимо поместить в данную коробку исходя из веса каждого кольца. Пример: имеем коробку №1 с размером 170*170*100. Максимальный вес для неё – 800г. Т.е., если вес кольца 35г и количество данных колец по заказу – 30шт, то в данную коробку можно уложить только 23шт. Соответственно, программа определяет, что данные 30шт товара необходимо поместить в коробку №2, т.к общий вес товара > максимального веса для коробки №1 (800г) и ≤ максимальному весу коробки №2 (1500г).
Пример №2 (Доставка семян)
При процедуре взвешивания, которую я описывал в шаге №7, после сканирования, появляется форма выбора размера коробки. Оператор выбирает габариты коробки в соответствии с габаритами сканируемой коробки.
Как видите, в зависимости от направления деятельности, могут кардинально отличаться бизнес-процессы.
Шаг №9. Отправка заказа
Мы прошли все подготовительные параметры и теперь готовы сделать отправку заказа по API в службу доставки.
Перед написанием статьи, я просмотрел модули ранее написанных мной интеграций с разными службами доставки. Думаю, совершенно нелогичным будет вставлять сюда пример кода интеграции с какой-то службой. Во-первых, вероятнее всего, Вы будете работать с другой службой, а во-вторых, код связан со структурой БД, с которой была сделана интеграция.
На сегодняшний день, чаще всего обмен со службами доставки осуществляется в формате JSON или XML. На примере Почты России можно посмотреть структура JSON и запроса:
https://otpravka.pochta.ru/specification#/orders-creating_order
Как видите, если пройти все шаги, с 1 по 8, у нас не будет проблем с отправляемыми данными. Абсолютно все необходимые данные у нас будут.
Заключение
Мы коротко пробежались по основным этапам интеграции со службами доставки. Некоторые темы мы совсем оставили без внимания.
Например:
- Наложенный платеж – отправка заказа по пост. оплате, то есть когда клиент платит при получении. Для некоторых бизнесов это отличный вариант, который здорово повышает доверия клиент и сильно увеличивает количество заказов. Безусловно, этот способ оплаты также сопряжен с большими рисками, а именно возвратом заказа, при этом оплата обратной пересылки ложится на ваши плечи.
- Уведомления – тут действительно большая тема. Суть ее заключается в том, чтобы уведомлять клиента при каждой смене статуса заказа. Как вы понимаете, уведомление можно делать разными способами (мессенджеры, смс, автозвонки или даже эл.почта). Хорошим тоном являются персональные письма, то есть письма, которые содержат персональные данные клиента, иначе это будет похоже на СПАМ.
Для тем, которые я не успел описать – я обязательно сделаю отдельную статью, где уже подробно разберу все важные аспекты.
