Этапы интеграции
1. Что такое интеграция?
2. Какими данными вы хотите обмениваться (что выгружается на сайт, что выгружается с сайта).
3. Кто главный?
4. Что можно сделать на стандартном функционале, а что придется дописывать самим.
5. Сложности на стороне сайта и сложности на стороне 1С (где проще решать проблему и почему).
6. Как настраивать интеграцию на уже существующий проект, в чем особенности работы в данном случае.
Что такое интеграция?
Для начала давайте определимся с тем, что мы будем подразумевать, говоря об интеграции 2-х и более систем между собой.
Интеграция двух и более систем между собой – это односторонний или взаимный (многосторонний) обмен данными данных систем, то есть процесс при котором данные из одной системы (например, товары из 1С) попадают во вторую систему (на сайт), а из второй возвращаются в первую (например, заказы с сайта выгружаются в 1С). Взаимодействие систем не обязательно ограничивается двумя, например, есть 1С, есть сайт, есть CRM, есть мессенджеры, есть некая система учета рабочего времени и выполненных задач – связь всех этих систем может быть сколь угодно сложная, но, если они в автоматическом или полуавтоматическом режиме обмениваются между собой данными, то эти системы можно считать интегрированными друг с другом.
Какими данными вы хотите обмениваться (что выгружается на сайт, что выгружается с сайта)
Очень важно изначально правильно создать модель взаимодействия интегрируемых систем, желательно хотя бы примерно представлять как эта интеграция может в дальнейшем укоренится, то есть сейчас мы, к примеру, выгружаем из 1С товары и цены, а с сайта в 1С мы отправляем только заказы и на этом все, а в дальнейшем мы планируем выгружать скидочную политику (то есть будет какая-то логика понижения или повышения цены для пользователя или группы пользователей на сайте, и эти данные так же должны выгружаться из 1С), остатки, а после того как заказ отгружен, из 1С к нему должны приложиться закрывающие документы (акты, счета фактур и т.д.). В зависимости от того насколько верно и точно вы проведете этот этап ваша дальнейшая работа может быть, как сильно осложнена, так и сильно упрощена, так как вы сможете правильно спланировать нагрузки на сервер (как сервер 1С, так и сервер сайта), понять какой алгоритм обмена необходимо делать за счет стандартных средств, а какой лучше писать самим, как спроектировать базу данных будущих систем (если вы с нуля делаете сайт и заводите 1С) для наиболее быстрой и простой интеграции.
Давайте коротко опишу чем обычно обмениваются системы
1. Торговый каталог
1.1. Список товаров (с характеристиками – цвета, размеры, и т.д.), сюда же отнесем торговые предложения (это такая небольшая пакость, которая нередко усложняет жизнь специалистам 1С при подготовке выгрузки, чтобы понять что такое торговое предложение обратимся к примеру – есть два iPhone 14 pro но один 128 ГБ, а другой 256 ГБ, при этом их цена так же отличается, так вот товары которые отличаются одним или более ЗНАЧЕНИЯМИ свойств, но по сути своей являются одним и тем же товаров, называют торговыми предложениями на языке Битрикса и Характеристиками на языке 1С, если этот функционал сделан не верно на стороне 1С, то специалистам приходится изрядно попотеть чтобы сделать корректную выгрузку).
1.2. Цены (особенно если цена не одна, а, например, разная для разных регионов, стран или в зависимости от фасовки, например, за 1 кг 1000 рублей, а за упаковку – 3000 или в случае с проводами за метр и за бухту).
1.3. Склады и остатки (детально останавливаться на этом пункте не буду, так как чаще всего на сайт прилетает один склад, даже если он является суммой всех складов, но бывают и очень сложные решения вплоть до участия логистики в ценообразовании при перемещении с одного склада на другой и т.д., поэтому тут все зависит от фантазии заказчика).
1.4. Разделы и свойства для умного фильтра для каждого раздела (представьте, что вы торгуете товарами, которые сильно отличаются по характеристикам, предположим, телевизор и утюг, у телевизоров есть диагональ, разъемы и т.д. и, разумеется, вы хотите, чтобы когда человек выбирает на вашем сайте телевизор, он мог указать диапазон интересующих его диагоналей, а если переходит в раздел с утюгами, то там не было диагоналей, но были свойства актуальные для утюгов, вот для этого и необходимо выгружать разделы товаров со свойствами для умного фильтра).
1.5. Скидочная политика.
2. Пользователи
Их, как правило, выгружают для того чтобы в последствии привязать к ним скидочную политику и давать какие-то особенные цены для существующего пользователя, также крепить к нему все его заказы; но бывают и более экзотические цели, например, в качестве пользователей выгружаются не только клиенты, но и сотрудники компании, которые привязываются к пользователям-клиентам, чтобы при возникновении вопросов по заказу пользователь-клиент мог быстро получить консультацию у своего персонального пользователя-менеджера; помимо этого пользователь может объединять в себе много персональных данных которые так же нужны для построения взаимодействия с ним, например, список договоров заключенных с ним и юридических лиц от имени которых он выступает.
3. Заказы
Когда создан новый заказ, не важно сделан он на сайте или по телефону через менеджера, он должен появиться в обеих учетных системах, то есть, если он создан на сайте, он должен попасть в 1С, а если в 1С, то на сайт, помимо этого может обновляться статус или даже состав заказа, заказ может быть полностью или частично отгружен, к нему на разных этапах его обработки могут крепиться разные документы, все это достаточно часто выгружается в процессе интеграции этих систем).
4. Внутренний (персональный, бонусный) счет
Счет на котором накапливаются бонусы и с него можно производить оплату на сайте (в полном объеме, частичную, всех товаров или только группы).
5. Плательщики
Те, кто платят по заказу (например, у одного пользователя может быть несколько плательщиков на которых он оформляет заказ, например, несколько юридических лиц и несколько физических, выгрузка этих данных чаще всего нужна для удобства пользователя и для корректного внутреннего учета)
Это самые часто встречающиеся данные, которыми обмениваются системы, но далеко не единственные.
Кто главный?
Когда мы планируем наладить интеграцию каких-либо систем, перед нами неизменно встает вопрос - какая система будет основной? К ответу на него надо подходить, изучая не степень значимости этой системы в вашем бизнесе, а степень ее надежности и понимание о том может ли она выполнять функции этой ОСНОВНОЙ системы.
Давайте попытаемся понять на конкретном примере.
Пример.
Есть 1С, разрабатывается интернет-магазин. Планируется, что из 1С будут выгружаться товары, остатки, склады, цены, пользователи, статусы заказов и закрывающие документы. С сайта будет выгружаться заказы.
Теперь важно!!! Планируется, что на сайте будут скидки и будет внутренний счет (бонусный счет). Вроде кажется ну будет и будет, но если задуматься глобальнее, то:
1. Бонусный счет подразумевает, что вам надо за эти виртуальные бонусы, продавать вполне реальные товары, а это надо проводить по бухгалтерии: «Ну, ок», - скажете вы, бонус для бухгалтерии - это просто скидка, согласен, но кто будет следить за начислением этих бонусов, за тем сколько их осталось, сколько и когда списано. И вот в этот момент большая часть клиентов, говорит – это все должно быть на стороне сайта! Супер, но что, если в процессе работы сайта у вас произошло не корректное списание или начисление, или что еще хуже, кто-то сумел найти способ увеличить эти бонусы не совсем так как вы это подразумевали (дырка в алгоритме начисления)? Как восстановить справедливость и не потерять деньги? Надо помнить важную вещь, про которую я сказал в начале этого пункта – «может ли она (система) выполнять функции этой ОСНОВНОЙ», сайт не предназначен для того чтобы быть учетной системой, сайт предназначен для того чтобы просто транслировать информацию пользователю. Это связано с техническими особенностями работы:
· нагруженность – на сайте одновременно сотни пользователей выполняют различные действия, что не самым лучшим образом влияет на скорость его работы, разумеется для оптимизации этого параметра стараются снять с него всю лишнюю нагрузку;
· постоянное развитие – сайт постоянно допиливается, обновляется, а это всегда, как бы классно ни работали специалисты, ведет к тому, что появляются баги, и, если эти баги просто в том, что у вас кнопка немного отъехала ниже положенного, то это одно, и совсем другое, если вы бесплатно отпустили товаров на сотни тысяч рублей;
· надежность – сайт это изначально продукт, в который не закладывается высокий показатель стабильной работы, исключением могут быть разве что сайты такого размера как соцсети, и то вспомните, сколько раз было такое что вы грузите какие-то фото, а они не загрузились или загрузились, но не все, это из-за того что скрипт – файл с кодом, отвечающий за это – не завершил свою работу; а представьте, если это скрипт который начисляет или списывает ваши бонусы и вместо того чтобы списать их при заказе, оставил их неизменными, и человек сделал один или несколько бесплатных заказов).
Кто-то может сказать, что надо просто делать более отказоустойчивый продукт, но реальность такова, что сайт, написанный на PHP, не может и не должен быть системой учета ваших денег, если вы это примете, то вы избавите себя от ненужных трат времени, денег и нервов. Что делать в этом случае? Надо чтобы бонусный баланс хранился в 1С, списания происходили в момент оплаты заказа и все это из 1С выгружалось на сайт. Так вы никогда не сможете ошибиться, ведь списания будут в системе, которая предназначена для проведения таких операций, и, если что-то пойдет не так, то вы, скорее всего, не сможете провести оплату по заказу, и баг очень быстро всплывет. Так же к 1С имеет доступ только сотрудник компании, и манипулировать бонусным балансом становится практически невозможно. Проще говоря, определяя, что в данном случае 1С является главной системой, вы решаете очень много проблем.
2. Скидки. Безусловно, можно завести скидки на сайте, но в этом случае сайт будет той конечной системой, в которой вы сможете увидеть цену для конкретного пользователя по конкретному продукту, а что, если таких скидок много и, если они достаточно сложные и в какой-то момент база данных вашего сайта оказалась повреждена, а актуального бекапа содержащего всю последнюю информацию не было и, чтобы внести скидки, необходимо понять какие скидки сейчас отсутствуют. Это, поверьте, не самый приятный процесс. Вы можете сказать «делайте бекапы почаще» и в целом будете правы, но в них все равно не будет всей последней актуальной информации, как бы часто вы их ни делали. И даже если там не будет всего одной скидки для одного пользователя, вам надо будет либо просто смириться с этим, либо проверять все. Так же если вы не имеете скидок в 1С, то не понятно, как сотрудники будут видеть конечную цену (напоминаю, мы говорим про сложную скидочную политику, а не про ту, где на все для всех скидка в 5%). Так вот, если вы выберите 1С главной в данной ситуации, то вы одним нажатием на кнопку быстро восстановите все скидки на сайте после завершения выгрузки.
Концепция того, что одна система должна быть ОСНОВНОЙ (главной) строится на том, что в ней можно посмотреть основные данные, не собирая их из разных систем и из нее, что еще важнее, можно быстро передать эти данные в интегрированные системы если в них они были утеряны. В этом случае вам надо организовывать серьезную защиту и бекапы одной системы, а не всех (это не значит, что другие системы должны быть проходным двором и не бекапится, я говорю именно о повышенной осторожности).
Надеюсь, что пример был достаточно наглядным, теперь коротко подытожим.
Система должна и может быть главной если:
1. нагрузка на нее позволяет организовать сбор и хранение агрегированной информации необходимой для работы других интегрированных систем (1С имеет существенно меньшую нагрузку в числе пользователей в сравнении с сайтом, 1С предназначена для хранения большого объема информации и ее автоматической обработки);
2. система достаточно хорошо защищена, чтобы не было опасности потерять все данные (при обмене 1С и сайта, сайт не обращается к 1С, это она запрашивает у него данные или передает их, то есть является инициатором, такой подход существенно усложняет несанкционированный доступ к 1С; при необходимости можно делать более сложную систему обмена данными, когда 1С вообще будет находится исключительно в локальной сети компании и доступ из вне к ней будет абсолютно недоступен, но это задача редкая и скорее больше похожа на паранойю, нежели на реально необходимую степень защиты);
3. система имеет возможность передавать данные в другую систему в нужном формате (из 1С можно передавать данные в любом формате);
4. архитектура системы подразумевает хранение и обработку такого вида данных (1С предназначена для работы с текстовыми и числовыми данными, она приемлемо работает с картинками, во всяком случае инструментарий там не хуже, чем на сайте; я бы не стал нагружать 1С видео файлами, она совершенно точно не предназначена для их обработки; если мы говорим про обзоры к товарам или группе товаров, то это приемлемо, хотя чаще всего видео стараются грузить в свой канал на Ютубе, а в 1С уже просто ссылку на это видео для его отображения, и сам файл не надо хранить в 1С; задача привязки видео к товару решена – 1С может хранить техническую документацию по товарам, может держать их в архиве или в исходном состоянии).
Если вы правильно выбрали, кто будет главный, вы избегаете многих проблем с интеграцией систем.
Подписывайтесь на канал ЮниВеб, чтобы не пропустить продолжение статьи, которое выйдет 8 мая!
