Мой склад сценарии примеры

В МоемСкладе есть сценарии — это автоматизация тех рутинных операций, которые пользователь делает постоянно.

Сценарии настраиваются один раз, и после этого работают без участия человека: произошло событие, сценарий запустился.

Например, можно автоматически резервировать товары на складе при оплате заказа, или снимать резервы, если оплата не поступила. В мае МойСклад добавил возможность ставить задачи сотрудникам: при выполнении заказа ставить задачу связаться с клиентом через некоторое время для повторной продажи, при создании счетов давать указания на контроль оплаты и отправку документов и так далее.

Все это происходит автоматически после наступления определенной ситуации, а руководитель не тратит время на контроль и рутину.

Пока сценарии работают бесплатно на всех тарифах.

• Инструкция по работе со сценариями
• Инструкция по работе с задачами

«Мой Склад» — многофункциональный сервис, состоящий из инструментов для розничной и оптовой торговли, офлайн и онлайн-коммерции, складского хранения и работы с клиентами. Сегодня мы поговорим именно о последнем пункте – CRM-системе внутри этой платформы.

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

Регистрация в системе «Мой Склад»

Нажмите на кнопку «Начать использовать» или «Регистрация». По клику на любую из них всплывает одна и та же форма, которую вам нужно заполнить. Укажите адрес своей электронной почты, имя и телефон. Последние два пункта не обязательны.

Кликните по кнопке «Регистрация».

Сразу после этого вы попадете в панель управления, а пароль автоматически сгенерируется и будет выслан на ваш E-mail.

Войти в личный кабинет сервиса «Мой Склад»

Личный кабинет состоит из 9 подразделов:

1. Показатели (статистика продаж и действий сотрудников).
2. Закупки (взаимодействие с поставщиками продукции).
3. Продажи (работа с покупателями, показатели прибыльности).
4. Товары (добавление, списание, перемещение и другие операции с товарами).
5. Контрагенты (компании и физические лица, с которыми вы сотрудничаете).
6. Деньги (движения средств, платежи, взаиморасчеты, прибыли и убытки).
7. Розница (действия, связанные с розничной торговлей).
8. Производство (добавление заказов и технологических операций, выпуск карт).
9. Задачи (постановка рабочих задач сотрудникам компании).

Настройка системы «Мой Склад»

Чтобы открыть настройки, кликните по слову «Администратор» в правом верхнем углу. Затем нажмите на пункт «Настройки».

Добавление своей компании

Перейдите к разделу «Справочники». Нас интересует подраздел «Юр. лица». Нажмите на одноименную кнопку для добавления своей компании в систему.

Укажите название своей фирмы и заполните остальные поля.

Нажмите сначала на кнопку «Сохранить», а затем на кнопку «Закрыть».

Добавление сотрудников

Перейдите ко вкладке «Сотрудники». Тут вы можете добавить столько пользователей, сколько предусмотрено активным тарифом. Для этого кликните по кнопке «Сотрудник».

Заполните анкету сотрудника, выберите для него роль в системе, настройте права и нажмите на кнопку «Сохранить».

Обмен данными

В этом разделе у вас есть возможность импортировать товары и остатки, контрагентов, прайс-листы из Excel, а также приемки из электронного документооборота и банковские выписки из 1С. Вы можете экспортировать из системы «Мой Склад» товары и остатки в таблицу Excel и выгрузить данные из 1C:Бухгалтерии.

Здесь же у вас есть возможность синхронизироваться с интернет-магазином. «Мой Склад» поддерживает все популярные CMS и конструкторы сайтов.

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

Раздел «Показатели»

Здесь присутствуют 4 подраздела:

• Показатели.
• Документы.
• Корзина.
• Аудит.

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

В подразделе «Документы» можно увидеть все документы, которые были сформированы через систему.

В «Корзине» хранятся удаленные документы. Срок хранения – 7 дней. В течение этого времени файлы могут быть восстановлены.

Подраздел «Аудит» содержит сведения о действиях администратора и сотрудников. Это своего рода журнал логирования, который ведется системой автоматически.

Раздел «Закупки»

В этом разделе есть 6 подразделов:

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

Для создания заказов, счетов, накладных и других типов документов воспользуйтесь соответствующими кнопками. Заполните формы и сохранитесь.

Раздел «Продажи»

В этом месте пользователи системы взаимодействуют с покупателями. Создают заказы, выставляют счета, управляют отгрузками товаров, оформляют возвраты и т.д.

Перейдите в подраздел «Заказы покупателей». Для создания нового, кликните по кнопке «Заказ».

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

Вернитесь к списку заказов, кликнув по кнопке «Закрыть».

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

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

Счета, отгрузки, отчеты комиссионера, возвраты покупателей и счета-фактуры создаются аналогичным образом.

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

В подразделе «Воронка продаж» отображается простая таблица по статусам, количеству заказов, времени. Тут же можно ознакомиться с процентом конверсии и суммами.

Есть возможность просмотреть данные не только по заказам, но и по контрагентам. А для более точной фильтрации, воспользуйтесь кнопкой «Фильтр». С ее помощью можно отсортировать информацию по ответственным сотрудникам, складам, товарам или группам, договорам, организациям и проектам.

Раздел «Товары»

Здесь есть 10 подразделов:

• Товары и услуги.
• Оприходования.
• Списания.
• Инвентаризации.
• Внутренние заказы.
• Перемещения.
• Прайс-листы.
• Остатки.
• Обороты.
• Сер. номера.

Для создания товара или услуги воспользуйтесь соответствующей кнопкой. Укажите наименование, характеристики, цену. Сохранитесь.

Прочие элементы в данном разделе создаются аналогичным образом. Это касается всех вышеперечисленных пунктов.

Раздел «Контрагенты»

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

Чтобы добавить контрагента или договор, воспользуйтесь одноименной кнопкой.

Заполните данные о добавляемом элементе и сохранитесь.

Раздел «Деньги»

Данный раздел состоит из 4 подразделов:

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

Чтобы добавить платеж, кликните по кнопке «Приход» или «Расход». Выберите один из 2 вариантов: ордер или платеж.

Заполните форму, привяжите платеж и нажмите на кнопку «Сохранить».

Раздел «Розница»

В этом месте создаются точки продаж и отображаются данные о сменах, самих продажах, возвратах товаров, внесениях, выплатах, операциях с баллами, предоплатах и манибэках.

Для создания точки продаж кликните по соответствующей кнопке.

Пропишите все необходимые данные и сохранитесь.

Тут же у вас есть возможность скачать приложение для компьютера или смартфона, с помощью которого сможете использовать онлайн-кассу в соответствии с 54-ФЗ.

Раздел «Производство»

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

Раздел «Задачи»

Чтобы создать задачу, нажмите на кнопку «Задача».

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

Задача будет отображаться во вкладках «Я поручил» и «Все задачи». Их можно также фильтровать по активности и выполнению.

Интеграции в сервисе MoySklad

Чтобы перейти к интеграциям, кликните по слову «Администратор», как это делали ранее для перехода в настройки. Только теперь выберите пункт «Приложения».

Все интеграции разделены по категориям. Давайте вкратце расскажем про каждую из них.

Кассовые программы

Тут есть 6 видов софта для выполнения кассовых операций. Три из них – это «Касса МойСклад». Приложения разработаны для Windows, macOS, Linux, Android и iOS.

Еще три программы представлены сторонними разработчиками, но также предназначаются для решения вопросов с 54-ФЗ.

Мобильные приложения

В этой рубрике есть одно приложение, но для двух разных платформ – iOS и Android.

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

Интеграция с банками

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

E-mail и SMS-рассылки

Эта категория представлена двумя сервисами: UniSender и sendsay. С их помощью можно рассылать электронные письма клиентам, которые занесены в базу CRM-системы.

Звонки

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

Скидки

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

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

Что касается интеграции с 1C, «Мой Склад» предлагает импорт банковских выписок и экспорт в 1C:Бухгалтерию. Эти функции доступны в настройках, подраздел «Обмен данными».

Тарифы «Мой Склад»

Тарифная сетка платформы представлена 4 основными тарифами и одним дополнительным:

1. «Базовый» – до 2 сотрудников, 1000 рублей ежемесячно.
2. «Профессиональный» – до 5 сотрудников, 2900 рублей ежемесячно.
3. «Корпоративный» – до 10 сотрудников, 6900 рублей ежемесячно.
4. «Бесплатный» – не более 1 сотрудника, безвозмездно.
5. «Старт» – 1 сотрудник, 5400 рублей в год (оплата сразу за 12 месяцев).

Для каждого тарифа свои ограничения и возможности.

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

При оплате тарифа от 3 до 12 месяцев вы получаете скидку от 5 до 15%.

Отзыв о платформе «Мой Склад»

Система может быть подключена ко многим «движкам» и конструкторам сайтов.

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

Есть несколько приложений для мобильных устройств, чтобы работать с самой системой «Мой Склад» и онлайн-кассой.

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

Имеется бесплатный тариф и двухнедельный тестовый период для любого из платных пакетов.

Отсутствуют отраслевые сборки, коробочная версия, внутренние чаты для сотрудников. Качество интерфейса на хорошем уровне, Канбан-формата для задач не предусмотрено.

Поддержка и консультации в системе «Мой Склад»

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

Чтобы проконсультироваться с менеджером, позвоните ему или напишите в Skype, на E-mail. Для старта диалога с поддержкой достаточно нажать на кнопку «Чат со специалистом».

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

Также вы можете отправить запрос службе поддержке в виде тикета. Сделать это можно на соответствующей странице. Просто заполните форму, выберите тематику запроса и отправляйте.

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

Меня зовут Андраш. У меня своя студия по заказной разработке ПО для интернета вещей. В нее я вкладываю всего где-то полчаса в неделю, а в свободное время ищу новые сферы деятельности.

Клиент — бренд тату-перчаток Glove.me. У них собственный физический товар с интернет-магазином, складом, небольшим производством, несколькими подрядчиками, и основным каналом общения через инстаграм. Товары продаются через сайт (сайт на Тильде), шоурум и несколько крупных партнерских магазинов и маркетплейсов. Довольно распространенная конфигурация.

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

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

В качестве наглядного примера буду использовать данные Glove.me (с разрешения владельцев).

Ожидание 1 из 7: я буду видеть «всё» о заказах (данные о товарах, доставке, покупателях и т.д.)

Казалось бы, это базовая функция CRM, и она на 100% покрывается Битриксом — в теории. Сложность возникает, если нужно интегрировать Битрикс с Моим.Складом и Тильдой (CMS, которую исторически использовал магазин с тех времен, когда у него было всего несколько позиций).

Можно бесконечно тыкать пальцами, кто виноват, но факт в том, что ни в одном из случаев нет бесшовной, да что там, хотя бы на 80% полной интеграции между Битриксом/Тильдой и Битриксом/Моим.Складом.

Интеграция с Тильдой

В Битриксе есть собственный модуль с товарами — каталог. Если использовать именно его или если сайт сделан на Битриксе, то, наверное, все будет работать нормально. Но в случае с Тильдой, хотя данные и передаются в Битрикс, фиксируются они как текст, товары из Тильды никак не связать с каталогом Битрикса.

В том числе это значит, что, связывая только эти два сервиса, мы не можем управлять ни ценой товара, ни наличием, ни модификациями, вообще ничем. И, конечно, отчетов или фильтров в поиске с этими значениями не построишь.

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

В общем, не самая проработанная интеграция. НО! Говорят Тильда скоро запустит плотную интеграцию, и тогда заживем!

Интеграция с Моим.Складом

Одно из важных дополнительных требований — это возможность видеть остатки и планировать производство. Именно по этой причине мы добавляем к интеграции еще и Мой.Склад. Битрикс тоже не очень хорошо работает с Моим.Складом. «Товары» в Битриксе нельзя бесшовно объединить с «Товарами» в Моем.Складе.

Решение — вбивать повторно данные, которые пришли из Тильды, вручную. «Товары» — через модуль Моего.Склада, а все остальные данные — напрямую в интерфейс Битрикса.

В итоге, автоматизация, вроде есть, но кривая:

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

Ожидание 2 из 7: я смогу видеть данные по моим продажам — по любому параметру

Тем не менее, при условии, что все заполнено корректно, мы можем строить аналитику по продажам.

Ожидание 3 из 7: иметь централизованный кабинет обработки входящих обращений

Все работает, вроде, нормально, пока не начинаются такие неожиданные ошибки, как прочитанные сообщения, которые на самом деле не прочитанные. Или отправленные сообщения, которые на самом деле не отправленные.

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

При выборе стороннего ПО для интеграции с мессенджерами, учтите, что далеко не все приложения предлагают функции, описанные ниже:

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

Ожидание 4 из 7: у меня всегда будет четкое представление о состоянии склада

Мой Склад с этим справляется «на ура». У компании есть несколько складов, в т.ч. виртуальных. Настроив один раз связь между Битриксом и Моим.Складом, вы решаете задачу полностью – именно этот аспект автоматизации не вызывает никаких вопросов.

Реализуешь товар — он уходит из склада. Добавляешь товар на склад — его становится больше. Все довольно просто (после того, как разберешься).

Одна беда — человеческий фактор: люди забывают, пропускают, ошибаются. В любой логистике так. Если бы этого не было, то не проводились бы на каждом складе регулярные инвентаризации. Идеальной картины, скорее всего, у вас не будет никогда.

Ожидание 5 из 7: я смогу видеть актуальное наличие комплектующих для производства

У клиента не только интернет-магазин, но и свое небольшое производство. Для того чтобы произвести единицу товара, нужно определенное количество комплектующих. Например, сетка (измеряется в м²), бирки (измеряются в шт.), размерники (имеют n-ное количество модификаций) и т.д.

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

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

В итоге мы прибегли к костылям:

Шаг 1: фильтруем наличие всех комплектующих и экспортируем файл

Шаг 2: в экспортированном файле копируем колонку с наличием

Шаг 3: вставляем данные о наличии в «нашу эксельку»

Шаг 4: указываем, сколько какого товара нужно заказать

Бинго! Самый быстрый способ увидеть к-во комплектующих, которые нужно заказать, для производства партии товара. (Пишите, кому нужен шаблон такой эксельки, поделимся).

Ожидание 6 из 7: все решения будут удобным для меня и моих сотрудников

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

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

На скриншотах в галерее всего лишь один пример странного поведения мобильного приложения Битрикс.

И я узнавал, это плюс-минус общая тенденция для мелких магазинов. Есть целая категория сотрудников, которым десктопом пользоваться либо неудобно, либо вообще не представляется возможным. Ну и владелец(ица) бизнеса тоже может неприятно удивиться, когда вся красота даже близко не доступна на телефоне.

Ни заказами, ни базой знаний, ни задачами через мобильное приложение Битрикса нормально пользоваться нельзя. Повторюсь: это не они такие уникальные, это весь рынок такой.

Ну и удобство интерфейса что Битрикса, что Моего.Склада — всегда на любителя. Правда здесь тоже нужно сказать, что ни разу мне не приходилось слышать от сотрудников «О! Удобная программа!» — вне зависимости от того, на что переходит компания. Ждите много возмущений по поводу того, как все неудобно, и как это все «стопорит работу».

Ожидание 7 из 7: подрядчики по настройке отлично понимают ПО и мои потребности, и я могу всецело на них положиться

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

Мы с подрядчиками от имени клиентов и от своего имени работаем довольно много. Если говорить про кодинг или зеро-кодинг, то проблем, как правило, три: отcутствие трекинга (коммуникации и задач), как следствие — отсутствие дисциплины (то, что пообещали сделать, не факт, что будет сделано вовремя или вообще), и отсутствие тестирования и отладки.

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

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

Как мы делали поддержку виджетов для приложений в МоемСкладе

Всем привет! В эфире Маркетплейс МоегоСклада. В прошлый раз мы рассказывали о том, как мы запустили маркетплейс приложений в SaaS-сервисе МойСклад. Сегодня продолжим о том, как мы даем возможность приложениям расширять пользовательский интерфейс сервиса. Наверное, многие сталкивались в десктопных приложениях с подобными плагинами, которые при подключении добавляют в приложение какие-то свои кнопочки, пункты меню и даже целые наборы новых окон и диалогов, а также встраивают свои собственные UI-блоки в существующие экраны. А как сделать такое в SaaS-сервисе, UI которого работает в браузере?

Зачем вообще нужно встраивание в UI?

На старте Маркетплейса для приложений общего назначения единственный доступный способ интеграции приложений с МоимСкладом — это интеграция по данным через общее JSON API. Через это API серверные части вендорских приложений могут получать и изменять пользовательские данные. Таким образом, на старте у нас была возможность только интеграции бэкендов приложений и МоегоСклада между собой. Добавить кнопочку или виджет на форму редактирования приложения не могли.

Изначально было очевидно, что этого не достаточно для предоставления конечным пользователям максимального удобства в использовании приложений. С другой стороны, внешним разработчикам и интеграторам приходилось колхозить свои механизмы в UI — у них был выбор или непосредственно встраиваться в HTML веб-приложения МоегоСклада через плагины браузера или делать отдельные интерфейсы (UI) на своей стороне, во многом дублирующие функциональные возможности экранов в МоемСкладе (например, списки документов с фильтрами).

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

В общем, уже на старте было понятно, что UI-плагины — это must have фича, которую надо делать.

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

И вот пришло время занятся UI-плагинами для приложений уже по-серьезному.

Виджеты. Начало

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

Первой фичей мы решили сделать поддержку виджетов на экранах редактирования сущностей и документов. Виджет представляет собой прямоугольный блок в UI, содержимое которого определяется приложением.

Пример виджета на экране редактирования контрагента:

Основной сценарий работы с виджетами выглядит так:

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

2. Пользователь МоегоСклада устанавливает это приложение

3. Пользователь заходит в то место, в которое приложение встраивает свой виджет

4. Система отображает обычный интерфейс МоегоСклада для этого места со встроенным в него виджетом приложения

Из важных технических требований мы определили следующие:

• Изоляция виджетов. Виджеты не должны иметь техническую возможность сломать верстку основной страницы. Как понятно, это ограничивает гибкость встраивания, но зато позволяет оставить за собой (в бОльшей степени) контроль за стабильностью работы UI (очень важно для наших пользователей) и его удобством (UX).

• Отсутствие дергания при загрузке страницы. При открытии экрана с виджетами не должно быть дергания элементов на экране. То есть, например, виджеты должны открываться на экране сразу в нужном размере, а не “скакать” на экране при подгрузке в них кода и контента.

• Однократная загрузка/инициализация кода виджета. Учитывая, что UI МоегоСклада — это SPA, то хотелось бы воспользоваться преимуществами этого и для виджетов: загружать код виджета и строить DOM-дерево виджета один раз за время жизни вкладки браузера, тем самым ускоряя работу UI в целом — по сравнению с полной загрузкой виджета с нуля при очередном открытии формы редактирования документа с виджетом. Тем более, что для наших внутренних компонентов и экранов у нас уже использовался подобный подход с кэшированием.

Как у других?

Для анализа мы выбрали несколько зарубежных SaaS-сервисов (Jira, Salesforce, Zendesk) и несколько наших российских (amoCRM, Битрикс24, InSales). Задача была посмотреть с технической точки зрения как устроено там и учесть этот опыт в нашем решении вопроса.

На что мы обращали внимание при анализе:

1. Что собой представляет само приложение: SPA ли это как у нас или что-то другое?

2. Как устроено взаимодействие виджетов и хост-окна (хост-окном называем родительское окно, куда встраивается iframe с виджетом), как разработчик указывает куда именно встраивать виджет, есть ли SDK для разработчиков (в части встраивания в UI)?

3. Обеспечивается ли изоляция виджетов, откуда загружается код виджетов?

4. Каким образом передается информация о текущем контексте в виджет. Под контекстом понимаем информацию о текущем пользователе, открытом экране и открываемом/редактируемом объекте или объектах.

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

В основном, рассматриваемые системы представляют собой SPA-приложения или “частичные” SPA (“частичные” — это когда, например, в рамках некоторых экранов UI работает без перезагрузки как SPA, но в каких-то случаях навигации по приложению может произойти и полная перезагрузка страницы — хотя внешне бывает сложно отличить полную перезагрузку страницы от частичной). UI МоегоСклада — полноценное классическое SPA. 

Почти везде виджеты сторонних разработчиков работают изолировано внутри iframe’ов. При этом с точки зрения степени изоляции здесь возможны два варианта:

1. Содержимое виджета загружается в iframe с того же домена, что и сам сервис (что обычно требует размещения клиентского кода на серверах сервиса, хотя это не обязательно — можно просто проксировать). И если при этом в атрибуте sandbox iframe’a указать ключевое слово allow-same-origin, то в этом случае есть возможность доступа к DOMу виджета из хост-окна и наоборот. Кто-то из сервисов использует это, например, для передачи контекста открытия виджету через JavaScript-переменную. Нам такой вариант изоляции не подходит (слабоват).

2. Содержимое виджета загружается в iframe с домена вендора (или отсутствует указание allow-same-origin) — в этом случае обеспечивается наиболее полная изоляция, при которой отсутствует доступ к DOM-дереву хост-окна из виджета и наоборот. Это как раз нужный нам уровень изоляции. В этом случае взаимодействие хост-окна с виджетом возможно только сообщениями через postMessage, что, конечно, менее прямолинейно, чем прямые JavaScript-вызовы между хост-окном и виджетом. Тем не менее, если завернуть на стороне виджета вызовы postMessage и прием сообщений в удобное JS SDK — то это не будет практически ничем отличаться от прямых JavaScript-вызовов.

И большинство проанализированных сервисов имеют такое JS SDK. У нас тоже были планы сразу начать делать такое JS SDK и предоставлять вендорам API взаимодействия в его терминах, но ограниченность ресурсов и насущная потребность выкатить виджеты на прод внесли свою корректировку и мы решили начать делать наше API на “голом” postMessage и сериализуемых JavaScript-сообщениях.

На фоне остальных выделяется amoCRM, в котором сторонние виджеты встраиваются непосредственно в DOM-документ хост-окна. При таком подходе, конечно, можно достичь большей гибкости встраивания, но это влечет и соответствующие риски — знающие люди рассказывали нам о случаях, когда виджеты приложений ломали верстку общего UI. И потом поди еще разберись, какой из виджетов в этом виноват. Тем не менее, такой подход несомненно имеет право на жизнь и, если вы выбираете его, то можно посмотреть на веб-компоненты как технологическую основу реализации виджетов приложений.

Что касается описания параметров встраивания виджетов (например, куда встраивать и прочие требуемые системой параметры) — для этого обычно используется JSON-структура (манифест). Мы здесь пошли немного другим путем и применяем XML — технические параметры интеграции приложений с МоимСкладом разработчики описывают в виде XML-дескриптора (являющегося аналогом JSON-манифеста). Почему мы предпочли XML в эру повсеместного распространения JSON’a — об этом расскажем ниже.

XML-дескриптор приложения

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

<ServerApplication xmlns="https://online.moysklad.ru/xml/ns/appstore/app/v2"             
                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"             
                    xsi:schemaLocation="https://online.moysklad.ru/xml/ns/appstore/app/v2      
                    https://online.moysklad.ru/xml/ns/appstore/app/v2/application-v2.xsd">
    <iframe>
        <sourceUrl>https://example.com/iframe.html</sourceUrl>
        <expand>true</expand>
    </iframe>
    <vendorApi>
        <endpointBase>https://example.com/dummy-app</endpointBase>
    </vendorApi>
    <access>
        <resource>https://online.moysklad.ru/api/remap/1.2</resource>
        <scope>admin</scope>
    </access>
    <widgets>        
        <entity.counterparty.edit>            
            <sourceUrl>https://example.com/widget.php</sourceUrl>            
            <height>                
                <fixed>150px</fixed>            
            </height>
            <supports>
                <open-feedback/>
                <save-handler/>
            </supports>
            <uses>
                <good-folder-selector/>
            </uses>                  
        </entity.counterparty.edit>    
    </widgets>
    <popups>
        <popup>
            <name>somePopup</name>
            <sourceUrl>https://example.com/popup.php</sourceUrl>
        </popup>
        <popup>
            <name>somePopup2</name>
            <sourceUrl>https://example.com/popup-2.php</sourceUrl>
        </popup>
    </popups>
</ServerApplication>

Итак, почему же мы выбрали именно XML, а не JSON? Основной наш поинт был в том, что для XML есть стандартизованный широко распространенный формальный способ описания схемы — XML Schema. Для JSON тоже есть аналоги — например, JSON Schema. Но для JSON-схем (в отличие от XML-схем) нам были не совсем понятны их текущий статус развития, уровень поддержки в библиотеках и прочих инструментах, таких как IDE. Также мы не знали, насколько гибкие JSON-схемы функционально. Все это требовало дополнительного анализа, в то время как опыт работы с XML-схемами у нас уже был. В итоге мы решили не тратить ресурс на изучение возможностей JSON-схем, расценив, что сама по себе форма текста XML или JSON особой разницы для наших целей не имеет, а гибкости XML-схем нам должно хватить до определенного уровня.

Какие же преимущества дает нам наличие формальной схемы описания дескриптора? Основных два:

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

2. Имея поддержку code completion для схемы в IDE мы по сути получаем “на халяву” UI для редактирования дескрипторов вендорами. Это позволяет нам использовать контекстно-зависимые структуры в дескрипторе (об этом ниже), максимизируя преимущество первого пункта без ущерба для удобства написания дескриптора вендором.

Вот, например, Intellij IDEA нам подсказывает, какие вообще точки расширения доступны для виджетов:

Так выглядит в IDE точка расширения только с поддержкой протокола open-feedback (что такое протоколы — расскажем ниже):

А так выглядит точка расширения с более полным набором доступных протоколов:

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

Модель описания виджетов в XML-дескрипторе

Приложения могут встраивать виджеты в разные места (точки расширения) системы. Например, у нас пару десятков (или даже больше) типов документов. Для каждого типа документа свой экран редактирования — и это отдельные точки встраивания. Хотелось бы добавлять новые точки расширения итеративно, так как каждая новая точка расширения требует разработки и тестирования. Оптимально было бы в первую очередь сделать и зарелизить точки расширения, наиболее востребованные вендорами. И уже потом доделывать остальные. Или может даже отложить доделку в пользу более приоритетных продуктовых задач. Хорошо бы иметь возможность на уровне схемы дескриптора задавать какие точки расширения есть в наличии на сейчас.   

В разных точках расширения виджетам может быть доступен разный функционал. Другими словами, каждая точка расширения теоретически может иметь свой набор параметров. Здесь примерно такая же ситуация, как с точками расширения — если мелкие фичи достаточно легко добавлять сразу во все точки расширения, то крупную фичу, затратную в разработке, стоит сначала сделать и запустить для одной точки, посмотреть для начала как она взлетит, получить обратную связь от вендоров, возможно что-то доработать и потом уже масштабировать на всю систему. Или, например, в каких-то точках расширения может быть специфичный только для этих точек функционал, который просто не применим в других местах. Хорошо бы иметь возможность на уровне схемы дескриптора для конкретной точки расширения описывать доступный в ней функционал.

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

<widgets>
    <some.extension.point1>...</some.extension.point1>
    <some.extension.point2>...</some.extension.point2>
</widgets>

Вместо, например, такой возможной:

<widgets>
    <widget location="some.extension.point1">...</widget>
    <widget location="some.extension.point2">...</widget>
</widgets>

Выбранный вариант позволяет нам явно и просто определять в XML-схеме свои собственные структуры (“подсхемы”) для каждой точки расширения по отдельности. Если для каких-то точек расширения “подсхемы” одинаковые — то эти точки расширения в схеме могут ссылаться на один и тот же тип. С учетом этого, а также возможности наследования для сложных типов в XML-схеме, мы эффективно избавляемся от дублирования кода в самой XML-схеме.

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

Рассмотрим на примере:

<document.customerorder.edit>
    <sourceUrl>https://example.com/widget.php</sourceUrl>
    <height>
        <fixed>150px</fixed>
    </height>
    <supports>...</supports>
    <uses>...</uses>
</document.customerorder.edit>

Здесь sourceUrl и height являются общими параметрами для всех виджетов. Параметр sourceUrl задает откуда будет загружен код виджета в iframe, а height описывает высоту блока виджета (как вы помните, у нас есть требование про отсутствие дергания — поэтому начали мы с поддержки только фиксированный высоты для виджета, которую пока нельзя изменять, а ширина у нас одинаковая для всех виджетов по дизайну UI).

Если мы захотим сделать поддержку динамической высоты (определяемой виджетом при открытии страницы с ним) в какой-то специфичной точке расширения (где, например, дёргание страницы несущественно), то мы сможем на уровне схемы дескриптора сделать так, что указывать <height><dynamic/></height> можно будет только для этой точки расширения. И вендор уже на этапе написания дескриптора будет знать — это работает только здесь. Это снижает риск того, что вендор не уследит, сделает виджет в расчете на <dynamic/> и обнаружит, что оно не работает в требуемой точке расширения на более позднем этапе разработки при тестировании или отладке. 

С supports и uses ситуация интересней. Об этом далее.

Протоколы и сообщения

Для описания интерфейсов взаимодействия МоегоСклада с виджетами мы используем понятия протоколов и сообщений (на самом деле модель описания API чуть сложнее, но в рамках данной статьи опустим второстепенные детали):

Рассмотрим на примере следующего описания виджета в дескрипторе:

<document.customerorder.edit>
    <sourceUrl>https://example.com/widget.php</sourceUrl>
    <height>
        <fixed>150px</fixed>
    </height>
    <supports>
        <open-feedback/>
        <save-handler/>
        <change-handler>
            <expand>agent</expand>
            <expand>positions.assortment</expand>
        </change-handler>
    </supports>
    <uses>
        <good-folder-selector/>
    </uses>
</document.customerorder.edit>

Итак.

Протокол — это конкретный набор спецификаций взаимодействия приложения, расширяющего UI МоегоСклада и МоегоСклада, как платформы. Протокол может включать в себя в общем случае разные типы взаимодействия, например такие как HTTP и обмен сообщениями по postMesssage. В протокол может входить несколько сообщений.

Протоколы мы делим на несколько типов.

Основной протокол — это протокол, который обязательно должен поддерживать виджет/плагин определенного типа (зависит от типа плагина). Не требует явного объявления виджетом. Например, для виджетов основной протокол включает в себя указание параметров sourceUrl и height, загрузку кода виджета в iframe по HTTP с передачей контекста текущего пользователя и отправку хост-окном postMessage-сообщения Open с указанием идентификатора открываемой пользователем сущности или документа.

Пример встраивания виджета в DOM-дерево страницы МоегоСклада:

Пример сообщения Open:

{
  "name": "Open",
  "messageId": 12345,
  "extensionPoint": "entity.counterparty.edit",
  "objectId": "8e9512f3-111b-11ea-0a80-02a2000a3c9c",
  "displayMode": "expanded"
}

Дополнительный протокол — это дополнительный (к основному) протокол, который может поддерживать плагин. Требует явного объявления в теге supports в дескрипторе (в блоке плагина). Перечень доступных дополнительных протоколов зависит от точки расширения.

В нашем примере выше в теге supports для виджета указаны три дополнительных протокола. Посмотрим на них подробнее.

оpen-feedback (протокол без параметров) — поддержка виджетом этого протокола означает, что при открытии экрана редактирования система закрывает виджет заглушкой и убирает заглушку, отображая содержимое виджета, только при явном получении сообщения OpenFeedback от виджета. Это нужно для того, чтобы виджет успел перерисовать свое содержимое для вновь открываемого объекта. Иначе вследствии кэширования виджета пользователь может какое-то время видеть состояние для объекта, который пользователь открывал до этого.

Заглушка выглядит как простая рамка с таким же серым фоном как и сама страница:

Пример сообщения OpenFeedback:

{
  "name": "OpenFeedback",
  "correlationId": 12345
}  

save-handler (протокол без параметров) — если виджет указывает поддержку этого протокола, то хост-окно при нажатии пользователем кнопки “Сохранить” отправляет виджету сообщение Save.

Пример сообщения Save:

{
  "name": "Save",
  "messageId": 32109,
  "extensionPoint": "entity.counterparty.edit",
  "objectId": "8e9512f3-111b-11ea-0a80-02a2000a3c9c"
}

сhange-handler (протокол с параметрами) — на примере этого протокола, который на момент написания статьи еще находится в разработке, можно видеть, что есть возможность определять параметры для дополнительных протоколов (аналогично параметрам для основных протоколов). Виджет, объявляющий поддержку протокола change-handler, начинает получать от хост-окна данные о редактируемом пользователем объекте в режиме “онлайн” — при изменении какого-либо атрибута объекта (например, при добавлении нового товара в заказ покупателя) хост-окно отправляет виджету сообщение Change с JSONом с данными объкета. С помощью параметров протокола expand вендор может дополнительно запросить замену ссылок на объекты аналогично тому, как это делается у нас в JSON API (в первом релизе change-handler будет без поддержки допольнительных параметров expand).

Сервисный протокол — это протокол, который реализует хост-окно с целью предоставления плагину некоторого сервисного функционала. Перечень доступных сервисных протоколов зависит от точки расширения. Для использования сервисного протокола плагином требуется явное объявление указание сервисного протокола в теге uses в дескрипторе (в блоке плагина). Сервисы похожи на дополнительные протоколы, но отличаются своей узкой направленностью взаимодействия виджет -> хост-окно в режиме запрос-ответ.

Пример сервисного протокола — good-folder-selector. Этот сервис виджетам приложений переиспользовать существующий в МоемСкладе селектор группы товаров с получением виджетом результата выбора пользователя. Работает это так:

1. Виджет отправляет хост-окну сообщение SelectGoodFolderRequest (например, при нажатии пользователем какой-либо кнопки в виджете):

{
  "name": "SelectGoodFolderRequest",
  "messageId": 12345
}

2. Хост-окно открывает встроенный в МойСклад селектор:

3. Пользователь совершает выбор и хост-окно возвращает виджету результат в сообщении SelectGoodFolderResponse:

{
  "name": "SelectGoodFolderResponse",
  "correlationId": 12345,
  "selected": true,
  "goodFolderId": "8e9512f3-111b-11ea-0a80-02a2000a3c9c"
}

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

1. Возможность указания вендором параметров протокола, если таковые у протокола имеются.

2. С помощью XML-схемы дескриптора вендор может узнать в каких точках расширения какие протоколы поддерживаются, а мы можем статически провалидировать дескриптор на корректность при (при загрузке вендором дескриптора в систему). 

3. Также статическим анализом по дескрипторам мы всегда можем легко можем посмотреть/замерять метрики, какие виджеты какой функционал используют и с какими параметрами. Привет контрактным тестам: например, если вдруг окажется, что какую-то фичу виджеты перестали использовать, то мы будем это знать точно и сможем ее безопасно выпилить или зарефакторить, если решим, что это актуально.

4. Зная, какой именно дополнительный и сервисный функционал используют виджеты мы можем оптимизировать работы хост-окна. Например, если виджеты на экране не используют change-handler, то хост-окно может вообще не инициализировать соответствующий функционал, экономя ресурсы компьютера пользователя (чтобы может быть важно для больших масштабных SPA-приложений типа нашего).

Альтернативой статического указания протоколов для виджета в дескрипторе могло бы быть динамическая регистрация при загрузке виджета (например, через какое-нибудь сообщение Init через postMessage, которое бы виджет отправлял при загрузке своего кода в iframe. Конечно, все вышеперечисленные пункты возможностей и преимуществ статического способа можно повторить и в динамическом, но это может потребовать больше ресурсов для разработки (нужно собирать метрики из браузера), больше ресурсов в рантайме (процессор, память на клиенте и сетевой трафик). При этом, ориентируясь только на динамические метрики, мы уже не так достоверно сможем определять что именно используют виджеты — например, если где-то в уголке лежит редко используемое пользователями приложение, запускаемое раз в месяц (и которое запускалось последний раз месяц назад). Тем не менее, динамические метрики тоже полезны и хорошо дополняют статические в плане реальной картины происходящего на проде.

Как работают виджеты

Как это работает всё вместе и какие именно функциональные возможности есть у наших виджетов на текущий момент можно прочитать в документации. Дублировать это здесь наверное будет излишним.

Что дальше?

Что у нас есть еще на текущий момент и какие дальнейшие планы?

Из интересного хотелось бы отметить кастомные попапы. Это возможность виджету открыть большое попап-окно с содержимым, определяемым приложением. Попап-окно по завершению своей работы может вернуть результат виджету. Кастомные попапы являются основным протоколом аналогично виджетам. В открываемом попапе находится iframe, в который загружается код попапа аналогично коду виджета. Виджет взаимодействует с попапом используя postMessage-сообщения через посредничество хост-окна. Подробнее о кастомных попапах с примерами можно посмотреть в документации.

На момент написания статьи активно работаем над упомянутом выше протоколом change-handler. В планах дальнейшее развитие этого направления — протокол update, который позволит виджетам обновлять данные редактируемого объекта в хост-окне.

Идеи на перспективу:

• Завернуть “голое” взаимодействие через postMessage в удобное JavaScript/TypeScript Widget SDK для вендоров

• Постепенное распространение поддержки виджетов и соответствующих протоколов на всех экранах МоегоСклада

• Новые типы UI-плагинов (новые типы точек расширения) — например, такие как:

  • Кнопки действий, пункты в выпадающих или контекстных меню

  • Столбцы в гридах

  • Кастомные вкладки

• Стандартные модальные диалоги

• Дальнейшее развитие возможности использования виджетами существующих интерфейсных объектов МоегоСклада

• Взаимодействие между виджетами одного приложения

• Навигация внутри UI МоегоСклада

• Доступ к эндпоинтам RESP API через Widget SDK

Объем работы по расширению возможностей интеграции в UI нашего сервиса огромный — мы планомерно двигаем наш SaaS-продукт в сторону гибкой, максимально расширяемой и удобной платформы для разработчиков приложений.

При этом МойСклад активно помогает вендорам с продвижением и продажей приложений — рассказывает пользователям МоегоСклада о новых приложениях в email-рассылках и соцсетях, проводит совместные с вендорами вебинары для пользователей МоегоСклада, продвигает приложения баннерами внутри сервиса.

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