Интеграция мобильного приложения с 1С по API. Задаем правильные вопросы бизнесу. Определяем механику обмена

Довольно часто мне прилетают задачи по интеграции 1С и мобильных приложений (далее МП). И всякий раз постановка задачи выглядит одинаково. Вот, практически, типовая постановка:

«Нужно из 1С передавать в приложение данные о номенклатуре, а обратно загружать заказы»

Продвинутые клиенты или те, кто пришел от разработчиков МП добавляют:

«Будем использовать REST API».

Для клиента все выглядит очевидно и буднично: потребность сформирована – давайте делать. Логично, что тут же появляется запрос на «хотя бы примерную» оценку. На деле, конечно, все не так просто. Уже первые уточняющие вопросы, заставляют клиента задуматься о множестве нюансов, влияющих на работу будущего решения и его архитектуру.

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

Оставив в стороне базовые технические вопросы выбора способа передачи данных (HTTP|FTP) и формата их передачи (XML|JSON), сфокусируемся на вопросах бизнес-логики. Решение будем внедрять на функционале HTTP-сервисов платформы 1С.

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

Методы для работы с каталогом товаров

1. Метод для получения из 1С полного каталога товаров. Необходимо вернуть полное дерево каталогов и подкаталогов с их содержимым.
2. Метод для получения изменений по ценам в каталоге. Передаем временной срез (дату + время) и получаем номенклатурные позиции и их цены, которые изменились с этого момента.
3. Метод для получения остатка по товарам. Передаем идентификатор товара (-ов) – получаем остаток. Будет вызываться часто, при добавлении товара в корзину.

Методы для работы с клиентами (контрагентами)

1. Метод для проверки существования клиента по номеру телефона. Передаем номер телефона получаем либо статус отсутствия клиента в учетной системе, либо необходимую информацию по нему: наименование, адреса, номера телефонов и т.п.
2. Метод для добавления/обновления информации по клиенту. Передаем номер телефона и обновленные данные ФИО, адреса доставки, номера телефонов и т.п.

Методы для работы с заказами и статусами

1. Метод для передачи заказов в 1С. Передается клиент, набор позиций, их количество и стоимость. Может передаваться информация об оплате заказа и т.д. Метод возвращает ID заказа в учетной системе.
2. Метод для запроса статусов из 1С. Нужен, чтобы пользователи МП знали, в каком состоянии их заказ. Обычно это что-то типа: принят, подтвержден, в пути, доставлен. И еще есть статус оплаты: оплачен/не оплачен. Когда в 1С статус меняется, об этом должно узнать приложение.

Сформировав такой перечень методов, мы можем отдать его не ознакомление клиенту. Обычно уже на данном этапе у него возникает множество мыслей, идей или вопросов.

Далее стоит разобраться с каждым методом конкретно и превратить этот предварительно утвержденный набор в полноценную API-документацию, тем самым положив начало разработке.

Метод для получения из 1С полного каталога товаров

Getnomenclature (GET)

Зачастую в 1С содержится неликвидный товар, а также товар, который давно снят с продаж или просто непопулярный. Кроме этого, в 1С могут фигурировать внутренние услуги, которые не нужно видеть пользователям МП. Поэтому при проектировании этого метода полезно задать заказчику следующие вопросы:

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

Ответы на эти вопросы помогут вам понять, какие объекты вам нужно будет дополнительно заложить в ваше решение. Будет ли это отдельный регистр «Номенклатура МП» или же будет дополнительный флаг в справочнике «Выгрузка разрешена». А может быть потребуется реализовывать специальные механики заполнения регистров, удобные пользователям. Это актуально, когда в базе большой перечень номенклатуры и заполнить регистр для выгрузки руками нереально.

Вопрос про единицы измерения покажет, насколько сложно будет формировать заказы покупателей, если требуется передавать в МП разные единицы измерений.

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

Тогда логично задать следующие вопросы:

• Есть ли у вас номенклатурные позиции, которые необходимо демонстрировать в приложении особым образом, например, «горячие предложения» или «товар недели»?
• Требуется ли формировать в МП альтернативные названия позиций номенклатуры для маркетинговых целей или достаточно обычного наименования?

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

Метод для получения изменений по ценам в каталоге

Getprices (GET)

В решениях 1С существует возможность задавать разные типы цен для номенклатурных позиций. Очевидно, что нам стоит узнать у заказчика, какие типы цен мы будем показывать в 1С. Это могут быть сразу все типы цен, конкретный их перечень или только один тип, например «Розничные». Кроме того, надо подумать, а может ли клиент МП купить товар со скидкой? Как будет формироваться эта скидка?

Вот список полезных вопросов для клиента:

• Какие типы цен будем отображать в МП для обычных товаров? А для акционных?
• Будут ли скидки при покупке в МП? По какому принципу назначаются скидки?
• Что делаем с товарами, на которые забыли установить цены? Скрываем?

Метод для получения остатка по товарам

Getremnants (GET)

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

Все это необходимо учитывать при проектировании методов API. Здесь будет уместным задать бизнесу следующие вопросы:

• Какие склады будем использовать для передачи остатков в мобильное приложение?
• Передаем совокупный остаток или в разрезе складов?
• Передаем в МП только свободные остатки или все остатки, включая резервы?

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

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

Тут стоит определиться вот с чем:

1. Как часто будет происходить обмен информацией по остаткам? Если мы будем обновлять остатки раз в минуту, тем самым поддерживая их актуальность, то повесим систему. Если реже – пользователи МП не получат достоверной картины и могут заказать отсутствующий товар.
2. Будем ли мы показывать пользователям МП точные остатки или нам будет достаточно условных признаков типа: «Много», «Есть», «Мало», «Отсутствует»? Такой подход избавит нас от необходимости частого обмена, но в случае, если мы подберем неправильный интервал актуализации данных, то рискуем нарваться на непонимание пользователей, которые будут пытаться заказать раскупленный товар из категории «Много».

Какие подходы можно предложить бизнесу, чтобы соблюсти баланс между лояльностью пользователей МП и их удобством и не угробить систему на обменах?

Можно предложить такой алгоритм:

• Раз в сутки МП получает обновленные данные по остаткам из 1С по всем номенклатурным позициям. Такой запрос можно делать ночью, чтобы минимизировать влияние обмена на систему.
• Не показывать пользователям реальные остатки, установив числовые критерии для показа обезличенных «Много», «Есть», «Мало» или подобных им.
• При выборе конкретных товарных позиций в заказ делать в 1С запрос для подтверждения реальных остатков по ним и показывать результат в МП. Точечные запросы не потребуют той же нагрузки на систему, как полный обмен.
• Собирать статистику в МП по тем товарам, которые не оказались в наличии.

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

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

Метод для проверки существования клиента по номеру телефона

Getclient (GET)

Понятно, что никто не будет тащить в мобильное приложение клиентов из 1С. Обычно это не требуется, но все же стоит, на всякий случай, этот вопрос прояснить. Однако, перед аналитиком/программистом стоит не менее серьезный вопрос о том, как синхронизировать пользователя приложения с клиентами 1С.

Для этого следует задать следующие вопросы:

• Как мы будем сопоставлять пользователей МП с клиентами из 1С: по телефону, емэйлу, ИНН как-то еще?
• Будут ли телефоны/емэйлы пользователей МП проходить верификацию (подтверждение по СМС или «пройдите по ссылке»)?

В случае сопоставления клиентов по их номерам телефонам (самое частое и очевидное сопоставление на практике) вам, как бизнес-аналитику, следует исследовать вопрос о том, как хранятся телефоны в 1С.

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

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

Для устойчивости идентификации обычно реализуют комбинированный поиск клиента: как по номеру телефона в справочнике клиентов, так и по телефонам контактных лиц.

Кроме того, следует утвердить с разработчиками МП то, в каком формате будут предоставляться телефоны. В моей практике самое лучшее сопоставление происходит, когда телефон передается без служебных символов (плюсов, скобочек, дефисов) и начинается с кода страны («7» для России), а не с «8».

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

Вопрос про верификацию контактных данных позволит вам оценить степень безопасности обмена и предупредить о рисках вашего клиента. Бывают случаи, когда бизнес не задумывается об этом и/или хочет сэкономить на услугах разработчиков. Достаточно одного аргумента, чтобы бизнес изменил свое мнение:

«Представьте, что будет, если какой-нибудь шутник под вашим телефонным номером сделает заказ на все позиции товаров в вашей системе. Они все буду забронированы и ваши отгрузки встанут. Пока разберетесь в ситуации – упустите прибыль».

Метод для добавления/обновления информации по клиенту

Getclient (PUT)

Проблемы с идентификацией клиента не заканчиваются особенностями хранения контактных данных. Зачастую, в клиентских базах (особенно в больших и старых) существуют одинаковые номера контактных лиц для разных контрагентов.

Такое бывает, когда условная Мария Витальевна сначала работала с нашей компанией через ООО «Звездочка», а потом перешла в «ИП Зачуханов». В этом случае она будет существовать как контактное лицо Мария Витальевна, привязанная к двум контрагентам. Не трудно догадаться, что по ее номеру телефона будут находиться сразу 2 контрагента.

Что делать? Во-первых, будучи хорошим аналитиком или программистом, предупредить об этом клиента. Во-вторых, предложить двойную идентификацию по связке телефон + емэйл. От всех подобных ситуаций это не будет панацеей, но круг поиска сузит.

В-третьих, согласовать план действий с бизнесом, ответив на главный вопрос:

Что делать в ситуациях, когда найдено несколько клиентов? На кого оформлять заказ?

Метод для передачи заказов в 1С

Addorder (POST)

Отправка сформированных заказов в 1С – кульминация нашего успеха и возросшая прибыль клиента. Что важно предусмотреть на данном этапе? Какие вопросы задать?

• Сможет ли клиент в мобильном приложении оплатить заказ? Если сможет, то нужно ли формировать документы оплаты в 1С?
• Нужно ли по результатам передачи заказа в 1С формировать реализацию? Какие-либо другие документы?
• Нужно ли ставить товар в резерв? На каком складе (-ах)? По какому принципу ставить в резерв, если складов несколько?
• От имени какой организации оформляем документы?
• Создаем ли договор для новых клиентов? Или работаем без договора (если позволяет используемая конфигурация)?
• С каким статусом приходит заказ в 1С, если используем статусную систему?
• Делаем ли какие-либо уведомления клиенту или ответственным менеджерам о появлении нового заказа в системе?

Пожалуй, этих вопросов будет вполне достаточно, чтобы ваш объем работы вырос от «просто создаем заказ» до «нужна полноценная система прослеживаемости сделки».

Метод для запроса статусов из 1С

Changestatus (POST)

Очень часто, в целях удобства пользователей, бизнес желает показывать статусы заказа в мобильном приложении. Для этого надо обеспечить передачу информации о статусах по мере их изменения.

Тут есть 2 пути:

1. Путь первый. Клиент заходит в мобильное приложение, переходит к своему заказу и видит обновленный статус. Запрос статуса от 1С происходит в момент обращения пользователя к своему заказу. Делается это для того, чтобы снизить нагрузку на систему и не тревожить ее большим количеством запросов к 1С. Кроме того, преимущества данного подхода заключаются в том, что за то время, когда пользователь не обращался к заказу, в 1С могло смениться несколько статусов, в то время как мы получаем только конечный, т.е. опять же экономим технические ресурсы и оптимизируем количество транзакций. Необходимости получать все промежуточные статусы у нас в данном случае нет.
2. Второй подход заключается в том, что мы «насильно» передаем все статусы из 1С по мере их обновления. Это бывает необходимо, когда уведомления пользователей о смене статусов происходят на стороне сервера мобильного приложения. В этом случае сервер МП должен периодически дергать наше АПИ по всем заказам с незавершенным циклом.

Это не является оптимальным решением, поэтому здесь требуется создать АПИ-метод на стороне сервера МП с тем, чтобы из 1С осуществлять подключения к нему и передавать обновленный статус в момент его изменения.

А теперь сформулируем полезные вопросы бизнесу:

• Какие статусы будет проходить заказ в 1С? Часто используемые: принят, подтвержден, в пути, доставлен.
• В какие моменты будет происходить изменение статусов? По наступлению каких событий? Например: свалился заказ в 1С – принят. Оформили отгрузку – подтвержден. Распечатали документы на доставку – в пути. Поставили галку «Доставлен» - установился статус «Доставлен».
• Будет ли 1С уведомлять мобильное приложение, если в 1С появилась информация об оплате заказа?
• Какая система будет отправлять уведомления пользователям об изменении статусов – 1С или мобильное приложение?

Вот, пожалуй, и все чем я хотел бы поделиться с вами на текущий момент. Как видите, даже такой, казалось бы, «типовой» вопрос как интеграция мобильного приложения с 1С изобилует разного рода тонкостями и множеством возможных подходов к реализации. При этом очень много зависит от того, какие именно задачи стоят перед бизнесом и какие из них мы примем во внимание, а от чего откажемся.

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

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

Вы – заказчик и у вас есть потребность в интеграции мобильных приложений с 1С? Создавайте проект на портале и привлекайте к решению этой задачи наших лучших разработчиков и аналитиков!