1С-Битрикс и обмен контрагентами: как не сдохнуть по пути

• Выгрузка контрагентов: «дорогие» вопросы и набитые шишки
  • Необходимый и достаточный состав данных
  • Частота и направление обмена
  • Где источник правды
  • IT-ресурсы на стороне учетной системы
  • Структура данных на сайте и в 1С
  • Связь контрагентов с заказами
  • Как тестировать обмен контрагентами
• Импорт контрагентов: рецепты
  • Выгрузка контрагентов в 1С-Битрикс «из коробки» 1С
  • «Мыши, станьте ёжиками»... и используйте справочники
  • Веб-сервисы и режим реального времени
  • Экзотика: транзитная база данных
• В сухом остатке

Однажды мы (ИНТЕРВОЛГА) консультировались с руководителем проектов компании 1С-Битрикс Вадимом Думбравану по архитектуре большого проекта со множеством двусторонних интеграций.
Вадим долго и внимательно слушал, а потом сказал:
— По предварительным данным, вы сдохнете на этом проекте.

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

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

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

Поговорим о том, как связать эту «оффлайн-информацию» с интернет-магазином или личным кабинетом клиентов.

Обычно выход в онлайн начинается с задачи-минимум:

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

Задача относительно простая. Она требует 20% усилий и дает 80% результата. Ее может решить почти любой разработчик. Не будем на ней останавливаться.

Серьезным заказчикам этого мало. Они «взрослые». Они работают уже много лет и успели обрасти учетными системами, тысячами контрагентов и сложными бизнес-процессами. Для них выход в онлайн возможен только с отражением всех процессов в вебе: на сайте, в интернет-магазине, в CRM.

Обычно эти процессы сводятся к:

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

Фундаментом для всех этих процессов является выгрузка справочника контрагентов на сайт.

Узнали себя? — Тогда в статье Вы найдете минную карту и решения, которые сэкономят Вам много месяцев и денег.

Выгрузка контрагентов: «дорогие» вопросы и набитые шишки

Любая интеграция похожа на возведение моста одновременно с двух берегов: сложно, дорого, рискованно. А еще команды «строителей» разговаривают на разных языках: разработчики сайтов и учетных систем часто друг-друга плохо понимают. В вопросах интеграции максимализм будет стоить Вам очень дорого. И в денежном и во временном выражении. Чтобы минимизировать потери нужно включить чувство меры на максимум. Рассматриваемые ниже вопросы появились из опыта многих проектов, в том числе неудачных.

Необходимый и достаточный состав данных

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

Частота и направление обмена

Бывают:

• разовые выгрузки,
• периодические (например, каждый час),
• режим реального времени.

Разовые правильно делать «на коленке» с применением Excel и стандартных инструментов импорта/экспорта (обычно они существуют). Например, так можно достаточно быстро выгрузить контрагентов(почта + ФИО контактного лица) из 1С и зарегистрировать их как пользователей сайта.

Периодические выгрузки уже сложнее. Они подразумевают необходимость при каждом обмене объединять старые и новые данные. Для этого придется писать код. Много кода. И в учетной системе, и на сайте. Настоящим подарком судьбы будет уже готовый формат / протокол обмена. Пример будет ниже.

Идеальным для бизнеса является режим реального времени. Он же будет самым трудоемким, ненадежным и неудобным для разработчиков сайта. Такой режим подразумевает отправку кучи запросов в учетную систему в момент при каждом открытии каждой страницы. А это десятки тысяч запросов в сутки для сайта со «средней» посещаемостью. Обычно учетные системы не рассчитаны на такие нагрузки. Использовать такой подход целесообразно только для обмена маленькими объемами самых критичных данных.

Важный вопрос: какие данные должны только выгружаться на сайт, а какие нужно передавать «в обе стороны». Двусторонний обмен сложнее и требует определить «кто главнее»?

Где источник правды

Для антихрупкости обмена контрагентами важно, чтобы полный и непротиворечивый набор данных хранился в 1С Рассмотрим 2 примера, когда эти требования нарушается.

Пример 1. Доп. информация, которой нет в 1С

Обычно в 1С для контрагентов не указаны email-адреса. А для регистрации на сайте они нужны (например, для отправки пароля). Конечно, можно вносить руками на сайте, но… Однажды произойдет сбой в выгрузке. Все контрагенты будут удалены с сайта.
Подобные ситуации мы наблюдаем на каждом проекте без исключения.

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

Пример 2. Платежные реквизиты контрагентов

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

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

Правильного решения здесь нет. Все зависит от Ваших внутренних правил. Чаще выбирают вариант с корректировкой по телефону.

IT-ресурсы на стороне учетной системы

Для синхронизации контрагентов с сайтом у Вас должны иметься в наличии 1−2 программиста, которые смогут разработать нужный механизм в учетной системе. Это не типовая настройка форм и правил учета. Это программирование. Нужно задать себе вопрос: «а наши спецы по учетной системе XX точно смогут»? Опыт показывает что каждый второй разработчик 1С — не сможет. На середине пути придется искать других разработчиков для доработки. А это остановка проекта на 1−2-4−12 месяцев (цифры взяты из реальных проектов).

Структура данных на сайте и в 1С

Структура данных в учетной системе (на примере 1С: УТ) сильно отличается от структуры данных сайта. Даже на логическом уровне.

На сайте есть всего 2−3 сущности относящиеся к контрагентам:

• Пользователь = логин + пароль + email
• Платежный профиль = название компании + реквизиты + контакты

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

Особняком стоит синхронизация адресов (юридических, почтовых, доставки заказа). И в 1С и на сайте для формирования адреса используются древовидные классификаторы: КЛАДР, ФИАС и их модификации. Проблема в их несовпадении в учетной системе и на сайте. В одном есть уровень «ЮФО», в другом — пропущен. В одном города называются «г. Волгоград», в другом — «Волгоград».

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

Связь контрагентов с заказами

Когда мы решим как сопоставить контрагентов на сайте и в 1С (см. предыдущий раздел) нужно позаботиться, чтобы контрагенты остались корректно связаны с другими сущностями. Например, с заказами на сайте. Сама по себе эта связь не заработает корректно.

Как тестировать обмен контрагентами

Один из самых неочевидных вопросов: кто, как и сколько времени будет тестировать обмен контрагентами между Битриксом и 1С. А тестировать ее нужно на нескольких уровнях:

• Формат и корректность данных при обмене файлами / сообщениями и т.д.
  На 1 проверку файла обмена уходит до нескольких часов работы программиста. Обычно мы закладываем в цену интеграции до 5 проверок. Но если разработчик со стороны учетной системы не проводит тестирование сам, то и 20 проверок не хватит.
• Протокол обмена: последовательность шагов, сценарий действий в случае сбоев.
  Автоматизированное тестирование на стыке двух сильно разных систем делается очень редко. Почти никогда. А значит потребуется пара десятков часов на ручное тестирование.
• Сценарии использования
  Здесь также доступно только ручное тестирование. Выполнять его придется часто и по многу раз. А значит потребуется еще XX часов исполнителей.

Мораль: кто, как, что и сколько раз тестирует нужно договариваться на берегу. А еще неплохо бы заранее продумать тестируемые сценарии использования :) Если этого не сделать — тестирование и запуск затягиваются на несколько месяцев, копятся взаимные обиды.

Импорт контрагентов: рецепты

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

Выгрузка контрагентов в 1С-Битрикс «из коробки» 1С

… к сожалению работает на твердую двойку. И лучше работать в ближайшие годы не будет. На прямой вопрос Product Manager-у БУС Юрию Волошину был получен такой же прямой ответ: в 1С-Битрикс считают что выгружать контрагентов на сайт большинству владельцев сайтов не нужно и данный механизм развиваться не будет. Можно конечно взять формат обмена из коробки и хорошенько его допилить. Мы пробовали так делать на двух проектах. Трудоемкость разработки и тестирования высокая, качество низкое. Не рекомендуем.

«Мыши, станьте ёжиками»... и используйте справочники

Готового (хорошего) механизма для выгрузки контрагентов в 1С-Битрикс нет. Но есть протокол и формат выгрузки произвольных справочников из 1С. Их может использовать любая учетная система, не только 1С.

Идея состоит в том, чтобы сформировать на стороне учетной системы 1−2-10 справочников с нужными данными (юр. лица, платежный баланс, доступы к различным типам цен) и выгрузить их на сайт с помощью готового «транспорта». В результате на сайте появятся Highload-блоки. Работать с ними одно удовольствие (в отличие от инфоблоков). Так например, реализована выгрузка контрагентов на Mybox, Светосила, GRASS и еще паре секретных проектов.

Решение экономит 100+ часов разработки и зарекомендовало себя как надежное. Именно этот способ мы рекомендуем «по умолчанию». Внимательный читатель спросит: «но ведь это только выгрузка контрагентов на сайт, а как же загрузка с сайта в 1С?». Все верно, это только половина работы. Но она уже позволяет реализовать 90% бизнес-сценариев. А обратную загрузку можно сделать, например, вместе с информацией о заказах.

Веб-сервисы и режим реального времени

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

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

Данный способ можно использовать для синхронизации контрагентов не только 1С, но и с другими системами. Например, в проекте «Клуб клиентов АльфаБанка» при авторизации пользователя через веб-сервисы из внешней системы загружается информация о нем.

Экзотика: транзитная база данных

Базы данных и сайта и учетной системы устроены нетривиально. Нельзя вот так взять и написать старый добрый SQL-запрос. Плюс по соображениям безопасности никто не хочет пускать «чужаков» в свою базу.

В этом случае можно встретиться на нейтральной территории. — Завести отдельную базу данных, с которой без опасений смогут работать обе системы. Для программистов такой способ удобнее чем передача данных через файлы. Разумеется, помимо транзитной БД нужно еще организовать канал оповещения. Через него системы будут сообщать друг другу об изменениях данных. Это могут быть, например, веб-сервисы описанные в предыдущем пункте. По такому сценарию работает «Личный кабинет клиентов ЕВРАЗ».

В сухом остатке

Обмен контрагентами между сайтом и учетной системой — фундамент для развития сайта. Чтобы сделать его правильно и с первого раза нужно иметь соответствующий опыт. Мы — имеем и готовы помочь Вам в интеграционных задачах. Обращайтесь!