Интеграция 1С и B2B-проектов

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

Задача – интегрировать B2B-портал с 1С

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

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

При этом договоримся, что хотя интеграция – это всего лишь часть разработки B2B-портала, мы непосредственно о разработке портала сегодня говорить не будем, мы будем говорить только о том, что касается именно интеграции с 1С.

Общие моменты разработки и интеграции

Сначала немного об общих моментах.

• Первое, самое важное – вы обязательно должны участвовать в написании технического задания, особенно спецификации интеграции. Обычно в этом никому участвовать не хочется, и согласование спецификации скидывается на какого-нибудь менеджера. И этот менеджер без вашего ведома может произнести следующую волшебную фразу: «Ребята, давайте начнем работу, мне уже нужно показывать, что все это запущено, а наши 1С-ники без проблем выгрузят вам все, как вы захотите – в любом формате, в любой структуре». Если менеджером такая волшебная фраза произносится, то, когда доходит непосредственно до выгрузки, начинаются слезы, боль и большая переделка. Поэтому берите на себя этот момент, участвуйте в написании технического задания. Особенно, что касается интеграции.
• Также нужно понимать ваше место в этапах разработки. Дело в том, что чтобы проект не растягивался в сроках и держался календарного плана, вы в какие-то моменты должны будете что-то реализовать, чтобы весь проект двигался дальше. Например, это какой-то веб-сервис на стороне 1С, чтобы при запросе что-то отдавал. И вроде как написать его не сложно – нужно максимум два-три дня, но после того, как вы его реализуете, нужно будет написать какую-то инструкцию для веб-программистов, чтобы они им грамотно пользовались. А еще потом сделать пусконаладку, все это протестировать, запустить, и все это растягивается на две-три недели. Поэтому находите это время, оно у вас очень дорогое и очень важное. Иначе проект может затянуться на годы. Хотя он очень часто и затягивается на годы вне зависимости от наличия инструкций.
• Дальше – участвуйте в выборе транспорта. Дело в том, что ребята из веб-студий не очень хорошо знают, какие могут быть варианты, поэтому берите это на себя. Говорите, что мы будем делать вот так и вот так. Конечно, лучше использовать что-то более понятное и стандартное типа CommerceML, который себя хорошо зарекомендовал.
• Также очень важно учитывать, что могут возникнуть сложности в случае, если у вас уже есть какая-нибудь внедренная CRM не на 1С (сейчас это частая ситуация), в которой уже работают менеджеры по продажам и которая тоже интегрирована с 1С. В этом случае, если появляется B2B-площадка, получается некий треугольник, в котором все себя не очень хорошо чувствуют. Учитывайте это обязательно. Иначе может получиться следующая ситуация: например, сделка в CRM уже интегрирована с 1С, а когда появляется B2B-портал, заказ оттуда тоже падает сразу в 1С – происходит задвоение. Нельзя этого допускать, нужно это учитывать. И самое главное, что вам нужно будет коммуницировать с командами, которые делают web-портал, поэтому самое главное напутствие – это терпение и лояльность. В некоторых моментах можно будет хотеть наругаться на них очень сильно, но до добра это не доведет.

Выгрузка номенклатуры

Теперь по конкретике.

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

• Сначала нужно зафиксировать транспорт – как будет происходить выгрузка.
• Что-то можно выгрузить стандартно через CommerceML, а для остатков, которые нужно выгружать очень часто, возможно, придется реализовать какой-то веб-сервис (следовательно, имейте в виду, что это нужно будет сделать).
• Вообще структура данных в 1С такая, что ее редко когда можно выгрузить на B2B-площадку – там требуется совершенно другая структура. Вспоминаем менеджера, который сказал, что наши программисты вам все выгрузят. Именно по этой причине нельзя доверять менеджеру, чтобы он говорил такие слова. Поэтому нужно договориться – или вы пересобираете структуру на стороне 1С, или вы отдаете как есть, а на стороне сайта она уже пересобирается.
• Есть еще более тонкий момент. Очень хочется, чтобы на B2B-площадке была красивая карточка товара с выбором торгового предложения, но, допустим, разрез характеристик в 1С не ведется, потому что в свое время, когда переходили с 7.7, с этим разбираться не стали – оставили все, как отдельные товары. Что тогда можно сделать? Можно выгружать товары, пересобрать их на стороне веба, а когда они будут падать обратно в 1С, чтобы заказ приходил в виде товаров. Об этом тоже нужно договориться и сказать, что мы будем выгружать вот так, а вы уже там смотрите, ничего не потеряйте – нужно, чтобы отображалось вот так. Это прямо крайне важный момент.
• В конечном итоге это опять сводится к тому, что вам нужно в каком-то техническом задании описать, как каталог на основе ваших данных должен отобразиться на B2B-площадке.

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

Что касается наличия товаров по складам и регионам – какие здесь особенности:

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

Все эти особенности нужно учесть.

Что нужно иметь в виду при реализации выгрузки остатков по складам?

• Никогда не надо бояться ограничивать пользователя, потому что, когда мы убираем менеджера, у нас заказ происходит уже не в форме диалога, а в форме кликания. В этом случае нужно вводить какие-то ограничения – не бойтесь это делать.
• Особенно это важно, если не налажена система перемещения внутри компании между складами. Сделайте четко: один заказ – один склад. Если это самовывоз, сделайте, чтобы клиент видел, где можно забрать одни товары и где другие. Эта схема хорошо себя зарекомендовала. Имейте это в виду, никогда не бойтесь ограничивать, иногда это очень хорошо спасает.

Ценообразование по сложным алгоритмам

Дальше самое вкусное – это ценообразование. Какие здесь особенности в отличие от стандартного интернет-магазина? Это:

•  индивидуальные цены по договорам;
•  индивидуальные скидки в зависимости от условий;
•  накопительные скидки;
•  скидки в зависимости от объема.

Что здесь важно иметь в виду?

• Сначала нужно описать все группы пользователей, особенно на пограничных случаях. Например: нужно ли пользователя верифицировать, что делать, если он ввел новое юрлицо и т.д. Эти моменты очень важно оговорить. Ни в коем случае нельзя позволять им делать заказ, пока в 1С это юрлицо не появится.
• И еще очень важный момент – это непосредственно цена. Не надо гнаться за отображением пользователю конечной цены. Важнее, чтобы заказ сформировался по той цене, по которой пользователь ждет. Поэтому сосредоточиться нужно именно на этом.
• Соответственно, так как на цену влияет огромное количество скидок и прочего – иногда даже выгрузить не получается, потому что документ имеет огромное количество строк.
• Какое здесь есть хорошее красивое решение, которое себя прекрасно зарекомендовало? Это веб-сервис на стороне 1С, который работает следующим образом. Когда товар попадает в корзину (меняется состав или количество), все это прилетает в 1С, и 1С отдает обратно ту цену, которая у этого пользователя именно для того юрлица, которое он хочет. Веб-сервис в этой задаче себя зарекомендовал очень хорошо, имейте это в виду.

Пакет документов и обмен документами

Следующий момент – это пакет документов и обмен документами.

Какие моменты здесь важно решить, на какие особенности обратить внимание:

• к каждому заказу должен быть полный комплект документов;
• и хорошо бы предусмотреть в личном кабинете также сервисы для взаимодействия – чтобы если нам что-то нужно от системы, мы могли бы получить это в личном кабинете.

При интеграции с 1С важно договориться – что мы передаем в личный кабинет B2B-площадки.

• В подавляющем числе случаев это могут быть данные, на основе которых генерируются печатные формы. Если вам по какой-то причине удобнее передавать файлы – ничего страшного в этом нет, это тоже будет вполне работоспособная система.
• А вот по поводу того, чтобы интегрировать с 1С какие-то сервисы – это не всегда нужно. Это дорого и не оправдывает средств. Например, сколько наши клиенты ни пытались обязательно собирать в 1С все рекламации, в конечном итоге от этого отказывались и экономили на этом много денег. Потому что пока еще на этой стадии все решается на уровне коммуникаций и в дальнейшем может пойти по разным путям, т.е. все это интегрировать не имеет смысла.

Управление контрагентами и платежные балансы

Следующий момент  - управление контрагентами и платежные балансы.

На что здесь нужно обратить внимание?

Пользователь выбирает разных контрагентов, и тут нужно решить – одна учетная запись равна одному контрагенту или нет? Понятно, что выбор контрагента – это удобно, но это требует часов доработок. Иногда лучше зафиксировать, что у нас одна учетная запись – это один контрагент. Система тоже живая, иногда, когда нужно запуститься быстрее, вполне рабочая. Эти моменты важны.

Обработка заказов

Дальше – «кит интеграции». Это непосредственно обработка заказов.

Какие могут быть особенности у обработки заказов?

Особенностей много. Несмотря на то, что каждая компания заказы обрабатывает одинаково, нюансы здесь значат очень много.

Поэтому как мы вообще реализуем интеграцию, на что обращаем внимание.

• Первое – это статусы. Как заказ будет выгружаться, как он будет меняться. Вообще не стоит делать большое количество статусов. Даже если вам хочется фиксировать каждый шаг по заказу с помощью изменения статуса – не нужно стремиться к этому. Но в то же время мало иметь всего три статуса – заказ принят, в обработке и завершен. Наша рекомендация в этом плане всегда – разделяйте статус логистики и статус заказа в целом. Обычно в B2B-порталах доставка и оплата могут обрабатываться абсолютно по-разному – для каких-то контрагентов обязательна предоплата, кто-то платит по постоплате и пр. Логистический статус нужно передавать как отдельное свойство, чтобы на основе этого свойства менялся нужный статус.
• Еще важен вопрос обратной интеграции, потому что все равно убрать телефон окончательно мы не можем. И что делать, если один и тот же заказчик часть сделал сам, а часть по телефону? Нужно ли заказ, оформленный по телефону, также отдавать на B2B-площадку? Это важно зафиксировать. И если это надо, реализовывать это придется довольно долго.

Интеграция с CRM

Дальше – интеграция с CRM. О ней я уже немного вначале сказал.

Какие у интеграции с CRM особенности:

• часто CRM не является частью 1С;
• это вызывает определенную нагрузку на менеджеров – они работают в нескольких системах и по этому поводу сильно нервничают;
• и интеграция необходима не только с порталом – мы меняемся данными и с B2B-порталом и с CRM-системой.

В этом плане вам нужно внедрить в ваши системы специальные защиты.

• Обычно, как только менеджеры начинают работать в какой-нибудь популярной CRM-системе, у них появляется желание перевести туда все обеспечение сделки, хотя CRM-система не должна за это отвечать. Они хотят видеть там все «от и до», чтобы, не дай Бог, не заходить в 1С. Безусловно, это круто, но это очень дорого.
• Поэтому стремитесь скорее к единому информационному пространству (чтобы не вводить одну и ту же информацию несколько раз). Что я имею в виду под единым информационным пространством? Необходимо обеспечить такую интеграцию между системами, чтобы заказ падал в CRM-систему, и после того как менеджер вводил по нему всю необходимую информацию, в 1С все данные по заказу уже должны быть сформированы – заведены все нужные контрагенты и пр. Потому что если этого нет, менеджер начинает нервничать. А если это есть, то это хорошая, отличная схема, по которой можно работать.
• Более того, рассмотрите такой вариант, чтобы интегрировать 1С с чем-то одним. Хорошо себя зарекомендовала следующая схема – есть портал, есть 1С и есть CRM. Что бы ни происходило в 1С, это сначала выгружается в портал, а из портала выходит в CRM. И наоборот. Такая система тоже вполне себя хорошо зарекомендовала.

Также важно

Если все это подытоживать, то, что хочется сказать:

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

Вопросы

• Если мы цены рассчитываем через веб-сервис, что будет в случае обновлений, падений 1С и т.д. – клиент не сделает заказ?
• Да, клиент не сделает заказ. Все эти темы нужно отдельно оговаривать. Например, сервер с порталом тоже могут упасть – в этом случае клиент тоже не сможет сделать заказ. Отказоустойчивость – это, безусловно, отдельная тема, но если интеграция нарушена, то лучше, чтобы клиент не делал заказ, чем потом это синхронизировать дополнительно вручную. Хотя иногда говорят – пусть наоборот, делает с теми ценами, которые на сайте, а мы потом сами все это перепроведем.
• А если B2B-портал организовывать внутри 1С-ной CRM-системы – это хорошая идея или плохая?
• Вообще пока классическая схема, что учетная система на 1С – отдельно, CRM – отдельно и портал – отдельно. Иногда бывает, что портал тоже реализуется на связке с CRM – например, Битрикс сделал на своем CRM-движке интернет-магазин и уже поставляет это в коробке. Но там с интеграцией пока очень все сложно – она плохо работает.
• А как быть, если мы на портале для дилеров, предположим, предоставляем функциональность бронирования объектов – и такую же функциональность мы предоставляем в CRM-системе – как такие механизмы решать?
• Поучаствовать в написании технического задания, чтобы не навертеть чего-нибудь лишнего. Если мы говорим про бронирование объектов, то это менее популярный случай, чем обычный каталог товаров, поэтому мне сходу сложно ответить. Нужно осознать, какой здесь оптимальный механизм будет.
• А насколько нормально не показывать цену в каталоге товаров?
• Нормальная практика. Раз это B2B, то, как правило, все, кто приходят на портал, уже являются вашими постоянными клиентами. Они прекрасно знают, по каким ценам они работают, и если им просто в личном кабинете дать информацию, что заказ будет по этим ценам, но в целом в каталоге отображать цены по типам, без конкретных значений, то какого-то большого негатива быть не должно. Но формироваться заказ, безусловно, должен по тем ценам, по которым клиент с вами работает.
• Если у вас уникальный продукт – это возможно. Но в основном закупщики, даже если они наши клиенты, они мониторят рынок и что-то могут купить у нас, а что-то не у нас. И ладно, если это одна позиция – сформировал счет, получил цену. А если закупщику интересно три-четыре-пять позиций?
• Если говорить именно о нашем опыте, то за последние два года мы выполнили около 8 проектов, где было принято решение не отображать финальную цену. От них не было требования переделывать эту особенность.
• А в чем главный бонус неотображения цены?
• Тут дело в том, как организован вывод цены в веб-части в том же Битриксе. Там, чтобы вывести нужную цену – это нужно постараться. Тем более если они индивидуальные, назначены по группам пользователей. Хорошо, если есть пять цен и есть пять групп. А когда начинаются тонкости, когда клиент часть товара может по одной цене покупать, другую часть – по другой, а остальное – по третьей, то нужно думать. Так устроено назначение цен в популярном Битриксе. И из-за сложности отображения цены покупателя для данного товара этот вопрос приходится тщательно прорабатывать. Из-за этой сложности и происходит отказ от показа цены для ее вывода только при оформлении. Потому что иначе это приводит к удорожанию проекта.
• Я правильно понимаю, что вы не показываете цену в списке, но ничего не стоит сделать кнопку «Показать цену» для конкретной позиции?
• Тот пример, о котором я говорю, это в принципе – клиент видит товар по тем ценам, которые назначены группе пользователей, к которой он относится. Но когда он будет оформлять, конечная цена может отличаться, потому что действуют какие-то тонкости, связанные с маркетинговой активностью и пр. Для бизнеса нет никакого бонуса в том, что мы не показываем цены, но мы экономим очень много часов веб-разработки, а это экономия денег.
• Если мы говорим про интеграцию 1С и Битрикс, вы используете типовой обмен, который предлагает Битрикс, или у вас практика писать свой уникальный под конкретную задачу.
• Если говорить про подход к решению задачи, то, безусловно, если что-то можно решить с помощью стандартного модуля, мы предлагаем этим воспользоваться, тем более, что последние версии у него действительно неплохие. Например, если можно хотя бы пересобрать каталог через модуль, то без проблем. Но в целом для B2B того, что предлагает именно этот модуль Битрикса для 1С, очень мало. Этот модуль не для B2B. Он очень хорошо покрывает запросы обычного интернет-магазина, но для B2B-площадок он не очень подходит. Мы в последнее время очень многое делаем на стороне 1С через веб-сервисы и на стороне портала. А в модуле Битрикса для 1С этого нет.
• Интересно узнать ваш опыт в интеграции команд веб-разработчиков и 1С-разработчиков. Есть ли какой-то утвержденный формат взаимодействия в плане ТЗ на написанный веб-сервис? К примеру, веб-разработчик ожидает какой-то экспортный файл для Postman, а 1С-ник дает ему только какое-нибудь описание в Word.
• Для этого и нужно участвовать на этапе технического задания. Вообще коммуницировать обязательно, договариваться обязательно. Но лучше в этом плане все брать на себя в плане того, что если нужно что-то выгрузить, и вы можете сделать такой веб-сервис, вы просто пишете к нему какую-то инструкцию. Если говорить в целом про объединение команд – это всегда боль. Если мы берем частый случай (веб-команда, которая делает одну часть, и 1С-команда) – они не любят коммуницировать друг с другом. И, к сожалению, у веб-студии нет понимания этого языка – они не знают различия между свойствами и характеристиками, поэтому очень часто могут не понять, о чем вы говорите. Универсальной таблетки тут нет. А наш опыт такой, что это понятие – системный интегратор и родилось из того, что мы понимаем, что происходит на стороне обоих систем, и это позволяет нам находить взаимопонимание между отделами. А в целом я не вижу какой-то таблетки, как сделать четко. Если мы говорим про документацию – да, очень важно давать хорошоописываемые методы. Например, если мы что-то реализовали, то у нас обязательно для API еще приложено описание для разработчиков, где все видно, чтобы у них никаких проблем не возникало.
• А какой у вас самый популярный инструментарий для создания документации? Чем вы пользуетесь? Как-то автоматизируете это или нет?
• Если честно, то у нас невысокий уровень написания технической документации. Есть команды, которые это делают очень круто – мы завидуем. Но автоматизацию по созданию документации мы сами пока не внедряли, поэтому у нас инструментарий стандартный, и вся автоматизация заканчивается гуглдоксами.
• Два вопроса – используете ли вы в интеграции протокол oData и читали ли вы про новые механизмы, которые появились в 8.3.16, когда есть возможность встраивать веб-клиент в iframe сайтов. И как вы думаете, повлияет ли эта возможность на B2B-сектор и CRM-сектор.
• Безусловно, рано или поздно, повлияет. Но мое субъективное видение в том, что пока лучше оставаться на этой консервативной связке и делать порталы на вебовских движках, и интеграцию проводить именно передачей данных, а не встраиванием чего-то. Пока так. А что касается oData – да, используем.
• Какое вы считаете среднестатистическое удовлетворительное время обмена между порталом, CRM-системой и 1С? Пять, десять минут, полчаса, час?
• Если мы говорим про удовлетворение, то удовлетворяет любое время, которое демонстрирует система. Как пример – если у нас номенклатура в 90000-100000 SKU, то стандартный модуль делает первую полную выгрузку за 16 часов. И никак это мы не ускорим. Именно поэтому мы клиенту говорим – давайте мы сейчас будем писать много кода, чтобы обмен происходил не средствами стандартного модуля обмена, или вы устанавливаете бесплатно этот модуль и 16 часов выгружаете. Он всегда выберет второе. Поэтому нельзя сказать, какое время для клиента будет удовлетворительным – клиент будет удовлетворен любым временем, которое занимает обмен. Разумеется, если мы говорим про остатки, которые должны обновляться раз в полчаса – тут совершенно другая история, понятно, что такие обмены должны происходить быстро.

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.