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

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

- Доработанная под логику бизнеса 1С. 
- Нужные данные не выгружаются на сайт. 
- Нужные данные выгружаются на сайт, но не туда. 
- При выгрузке есть ошибки. 
Будьте готовы, что доработки потребуется либо со стороны 1С, либо со стороны сайта, а то и в двух системах.
Кейсы по обмену данными с 1С на примере интернет-магазина канцтоваров
Интернет-магазин канцтоваров — это крупный поставщик канцелярских товаров на российском рынке, ведущий оптовый оператор и трижды обладатель престижной канцелярской премии «Золотая Скрепка» в номинации «Лучшая национальная торговая компания».
С этой компанией работают более 3500 компаний в 80 регионах России: оптовые покупатели, корпоративные клиенты, специализированные магазины и крупные торговые сети. Масштаб впечатляет.
Для оптимизации работы с организациями (юридические лица и индивидуальные предприниматели) было принято решение о создании корпоративного интернет-магазина .
Оптовый интернет магазин имеет свои особенности, что отличает его от розничного:
- Персональные цены. 
- Упрощенная навигация и быстрый поиск. 
- Товары без картинок и подробных описаний. 
- Табличная форма заказа. 
- Оптовые единицы измерения. 
- Заказ по списку. 
- Личный кабинет с платежным балансом счета. 
- “Поговорить с вашим менеджером”. 
- Счета-фактуры, товарно-транспортные накладные, договоры, акты. 
- Интеграция с учетной системой и логистикой. 
Эти нюансы обязательно надо учитывать при проектировании.
Кейс 1: Обмен партнерами и контрагентами

Задача:
Что есть на стороне 1С:
Партнеры -> У каждого партнера есть несколько контрагентов -> У каждого контрагента есть несколько договоров, расчетных счетов и адресов доставок, а также информация по остатку и персональному менеджеру.
Что требуется на стороне сайта:
Партнеры из 1С должны формировать пользователей на стороне сайта. При этом регистрация на самом сайте должна отсутствовать. У каждого пользователя должна быть возможность переключения между своими контрагентами. При этом у каждого контрагента должна быть своя корзина, свой личный кабинет и свои персональные цены (о ценах в кейсе 2). Договора, р/с и адреса должны использоваться при оформлении заказа, остаток и персональный менеджер должен отображаться в личном кабинете.
Решение:
На стороне 1С:
Потребовалось сформировать соответствующие справочники, которые можно выгрузить штатным механизмом.
На стороне сайта:
- Программирование формирование пользователей. 
- Программирование переключения между контрагентами и отображения соответствующих им данных. 
- Доработка оформления заказа на основании данных контрагента. 
- Доработка отображения данных контрагента в личном кабинете. 
С какой проблемой столкнулись и как решили:
На стороне 1С были изменены данные контрагентов и выгружены на сайт. На стороне сайта часть контрагентов подверглись изменениям, а часть контрагентов эта участь миновала. Стали разбираться и выяснили, что для контрагента приходит уникальный код версии. Если он изменился, то данные изменяются на сайте, если нет, то остаются неизменными. Отказ от сравнения версий на стороне сайта помог решить проблему с обновлением информации.
Вывод:
Нетиповой обмен требуется дорабатывать на стороне двух систем. Могут встретиться различные сложности. Главное, чтобы хватило компетенции определить источник проблемы и исправить. Имея большой опыт в разработке и интеграции различных систем, мы делаем это успешно.
Кейс 2: Индивидуальные цены

Задача:
Что есть на стороне 1С:
У контрагентов есть типовые и индивидуальные соглашения, в которых определены индивидуальные типы цен и скидки.
Что требуется на стороне сайта:
Цены должны соответствовать ценам из соглашений в 1С.
Решение:
На стороне 1С:
Потребовалось сформировать соответствующие справочники, которые можно выгрузить штатным механизмом.
На стороне сайта:
Было придумано решение, которое позволило использовать штатные возможности отображения скидок Битрикса, но их расчет осуществлять с использованием справочников из 1С.
Когда вы заходите на страницу с товаром, то его цена с учетом скидки неизвестна. Расчет происходит “на лету” из справочника скидок контрагентов и подставляется в нужном месте по технологии Ajax. Это сделано для ускорения отображения страницы за счет возможности создания ее кэша (готовых страниц).
С какой проблемой столкнулись и как решили:
- Сортировка товаров по цене. Так как цены со скидкой “прилетают” после загрузки страницы, то корректная сортировка возможна только после их получения. В данному случае применимо решение с небольшой погрешностью. Товары можно отсортировать по цене без применения скидок, а в рамках страницы уже с учетом скидок после их получения. Погрешность будет наблюдаться именно на стыке страниц при постраничной навигации. 
- “Умный” фильтр. Использование “умного” фильтра в Битрикс основано и возможно по присвоенному контрагенту типу цены без скидок. Для учета скидок потребуется данный инструмент прилично доработать, что может быть неоправданно затратно. 
Какие варианты для выгрузки индивидуальных цен были рассмотрены:
- Рассчитывать цены на стороне 1С с учетом скидок. Выгружать их в виде типов цен для контрагента на сайте. На сайте предполагается 2000 - 3000 контрагентов, что равносильно 2000 - 3000 типам цен. Редактирование товара с таким количеством типов цен на стороне сайта становится невозможным, так как страница редактирования просто зависает или выдают ошибку о нехватке памяти. При этом открытие страницы с “лица” сайта со списком товаров осуществляется за 20 - 30 секунд, что также неприемлемо. 
- Рассчитывать цены на стороне сайта с учетом скидок в специальную таблицу. Потом выводить цены уже исходя из нее. Расчет цен для одного контрагента для всех товаров на стороне сайта с использованием сервера заказчика составляет 20 секунд. Для 2000 - 3000 - это уже 11 ~ 17 часов. С учетом изменения и выгрузок скидок каждые 20 - 30 мин, получаем нерабочий вариант. 
Вывод:
Индивидуальные цены на сайте - достаточно сложная задача. Учитывая ограниченность возможностей технических ресурсов и используемых трудозатрат, ее решение не будет идеальным. Мы решили данную задачу вышеописанным способом. Если у вас есть интересное решение, то можете поделиться им в комментарии.
Заключение
В этом проекте были достигнуты следующие бизнес-результаты:
- Компания начала работать с клиентами быстрее, лучше, эффективнее и напрямую. 
- Автоматизированы рутинные операции (все заказы попадают напрямую в 1С). 
Это стало возможным за счет наших интеграционных компетенций:
- Проектирование крупных информационных систем. 
- Разработка на Битрикс. 
- Разработка высоконагруженных проектов. 
- Интеграция 1С-Битрикс с 1C и другими системами. 
- Создание интернет-магазинов с адаптивным дизайном. 
Комментарии (16)
 - SergeiMinaev07.09.2021 20:51+3- Извиняюсь, но пока читал, почувствовал, что попал на чужую планёрку, где кто-то кому-то докладывает об успехах :) 
 - mSnus08.09.2021 01:35+1- Нужные данные выгружаются на сайт, но не туда - Это удивительно и прекрасно одновременно! - Когда вы заходите на страницу с товаром, то его цена с учетом скидки неизвестна. Расчет происходит “на лету” из справочника скидок контрагентов и подставляется в нужном месте по технологии Ajax. Это сделано для ускорения отображения страницы за счет возможности создания ее кэша - Все очень запущено... Все эти "20-30 секунд на расчёт" и последующие костыли -- остаётся только развести руками. А всё только потому, что зачем-то решили использовать Битрикс, который для решения этих задач в принципе не приспособлен. - Вот и получаются Признаки нетрадиционной интеграции с 1С.  - stepan_ovchinnikov Автор08.09.2021 08:37- тут дело не в Битриксе - дело в расчете цен на стороне 1С, я ниже написал про это - как бы вы решали эту задачу?  - mSnus08.09.2021 08:55- Уточните, пожалуйста: - Насколько часто меняются цены? 
- Цены меняются у всех клиентов единовременно? 
- На каком сервере это всё работает? 
  - stepan_ovchinnikov Автор08.09.2021 08:59- 1 - это вне зоны нашего контроля, к сожалению. у клиента торговая сеть, они могут менять это ежечасно. на практике корректировка любой цены происходит с 95% в течение недели, с 20% вероятностью в течение дня 
 2 - нет, охват по группам, которые тоже частично пересекаются, например "регион Х" или "те кто покупают мало" или "школьный ассортимент"
 3 - вы про сайт или про 1С? под сайтом обычный виртуальный (или физический, точно не знаю) выделенный сервер. CentOS, SSD. 1С на серверах заказчика, отдельных конечно
 
  - Anton_Zh17.09.2021 05:30- А не пробовали при изменении цены на конкретный товар в 1С делать событие в сервер очередей со всеми необходимыми данными и слушать его на сайте, изменяя соответствующую информацию в БД?  - stepan_ovchinnikov Автор17.09.2021 08:23- конечно. так и делаем в большинстве проектов сейчас. событийная модель через веб-сервисы или серверы очередей для надежности 
 
 
 
 - vmorsk08.09.2021 08:32- Выгружать индивидуальные цены, серьезно? - 3500 клиентов * 10000 един ц sku = большие таблицы, с которыми, мало того что Битрикс работает с трудом, так ещё и 1с грузить такими масштабными выгрузками... Ну нецелесообразно точно =) - Берём матрицу исчисления цен (тупо математика, та же что и в 1с), и считаем на лету при формировании страницы. Не нужно конструировать статического монстра, одновременно нагружая 1с.  - stepan_ovchinnikov Автор08.09.2021 08:37- тут все дело как раз в математике на стороне 1С 
 очень часто логика определения цены это далеко не просто коэффициент к базовой. она может зависеть и от других параметров, например от логистики поставщика или объема продаж в прошлом месяце. или "акций", конструктор которых есть в УТ, например- поэтому на практике тащить всю логику определения цены из 1С на сайт – неверно, это дублирование кода и необходимость поддерживать 2 копии логики - тащить всю ценовую матрицу – решение безусловно не самое изящное, но проблем с этим нет. на стороне сайта используются не инфоблоки Битрикса, а физические таблицы, они миллион записей с индексами переваривают как СУДБ позволит, не медленнее - альтернатива – веб-сервис "расчета цен на лету" на стороне 1С, и кеширование этого дела на стороне сайта. сейчас так делаем все чаще  - vmorsk08.09.2021 11:11- Не знаю, насколько у вас большая и нагруженная база 1С, у нас более 1Тб постоянно в оперативке приходится крутить, так что всегда приходится отталкиваться от постулата "лучше отдать сырые данные и обработать их вовне". - Копию логики создать и поддерживать в актуальном состоянии не так сложно (с учетом собственной команды разработки), и именно из-за необходимости учета не-линейных показателей - это наиболее актуально, т.к. веб-сервер математику исполняет не хуже самой 1С, а вот с выгрузками масштабных данных у 1С проблемы, и, как следствие, возможны проблемы: - 
в процессе выгрузки гигантского массива происходит сбой: 1.1. со стороны 1С - отрубился интернет 1.2. со стороны веб-сервиса - недоступность 1.3. со стороны веб-сервиса - в процессе приема и разбора данных появились ошибки и некоторые блоки не были записаны / обновлены 1.4. и так далее, вариантов масса 
- пока на стороне 1С формируются данные на отдачу - могут возникать конфликты блокировок. 
- пока на стороне 1С формируются данные на отдачу - могут быть произведены изменения в записях самой 1С. И это не будет исправлено до следующего обмена. 
- любые попытки снизить риски предыдущих трех пунктов без изменения глобального подхода - это временные костыли, которые сломаются в самый неподходящий момент (дело пошло в гору, много пользователей, много заказов - и привет) 
 - По акциям, спецценам, индивидуальным скидкам и т.д. - обычная работа с матрицами, ничего особенного. Работает математика на веб-сервере не хуже чем в 1С, с той разницей, что горизонтально масштабировать его кудааааааа как проще, чем 1С (на случай наплыва пользователей). - Складывается впечатление, что, либо у вас не такая нагруженная система как вы описываете в статье, которая чувствует себя вальяжно, либо вам еще предстоит узнать все "прелести" проблем, о которых я пишу :)  - stepan_ovchinnikov Автор08.09.2021 11:45- спасибо за мысли - в моей реальности гораздо проще сделать предрасчет и выгрузку на стороне 1С (при не-супер-частых изменениях цен) или веб-сервис, чем дублировать математику  - vmorsk08.09.2021 12:53- Всегда пожалуйста. С ростом нагрузок, SKU, вариативности продаж, внедрения маркировки, открытия филиалов и точек продаж, РЦ и т.д., вы также узнаете, что битрикс не тянет от слова "совсем", и нужно будет отдельное решение, скорее всего двухкомпонентное. В общем, впереди много нового, если что пишите, подскажу что знаю из практики. - Надеюсь, что вы вскоре с этим столкнетесь, т.к. это будет означать бурный рост ;) 
 
 
- 
 
 
 - L4NiK17.09.2021 08:22- По моему 5ти летнему опыту с редакциями "Магазин" и "Корпортал" коробочными, говорю одно: - 1.) Взяли программистов 1С и программистов Битры. - 2.) Разработали спецификации обмена в JSON - 3.) Написали приемники/передатчики - В битре допилили необходимое также... 
 - 4.) Профит всем. - Все остальное извращение слабо конфигурируемое и поддерживаемое. 
 
           
 
Naf2000
А не думали вместо выгрузок таблиц использовать rest -запросы изменений данных?
stepan_ovchinnikov Автор
конечно, часто так и делаем. это более изящный способ
но файлы – более традиционный для 1С
выбираем "по месту"