Интеграции с 1С, CRM и маркетплейсами

Подробно

Интеграция 1С с сайтом нужна, когда менеджеры устают переносить заказы руками, а покупатели видят на витрине товар, которого нет на складе. Мы связываем учетную систему с интернет-магазином, мобильным приложением, CRM и маркетплейсами так, чтобы каталог, остатки, цены и заказы обновлялись автоматически. Беремся за типовые конфигурации 1С и сильно доработанные базы, за настройку готовых модулей обмена и за проекты, где нужен собственный API. Перед началом работ разбираемся, какие данные и в какую сторону должны ходить, и только потом выбираем способ интеграции.

Интеграция сайта с 1С: обмен данными между сайтом и учетной системой

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

Главный вопрос на старте: какая система главная для каждого типа данных. Если описания товаров правят контент-менеджеры в системе управления сайтом, а 1С каждую ночь перезаписывает их своими, работа команды пропадает. Поэтому для каждого поля договариваемся, где оно живет и кто его меняет. Цены и остатки почти всегда ведутся в 1С, тексты и фотографии часто удобнее вести на сайте. При таком разделении данные сайта и учета не расходятся, а сотрудники не спорят, чья правка важнее.

Второй вопрос касается ключей. Товары на сайте и в 1С связываем по уникальному идентификатору элемента справочника (GUID), а не по артикулу или названию. Артикулы дублируются, названия переименовывают, и после этого обмен начинает плодить копии товаров.

Что передается между системами

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

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

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

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

Способы обмена: XML-файлы, веб-сервисы и API

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

Первый вариант - обмен через XML-файлы по стандарту CommerceML. Это типовой механизм: 1С формирует XML-файлы с каталогом и предложениями (import.xml и offers.xml), передает их на сайт по HTTP, сайт разбирает файлы и отдает в ответ заказы. Модуль обмена со стороны 1С уже есть в типовых конфигурациях, поэтому такой вариант быстрее запустить. Минусы: обмен идет пакетами по расписанию, большие каталоги выгружаются долго, а любая доработка формата требует правок с двух сторон.

Второй вариант - веб-сервисы и HTTP-сервисы 1С. Базу публикуем на веб-сервере (Apache или IIS), и 1С начинает принимать запросы напрямую. Сайт или приложение спрашивает остаток конкретного товара в момент оформления заказа и сразу получает ответ, а не ждет ночной выгрузки. Для этого пишем в 1С собственные HTTP-сервисы с нужной логикой или используем стандартный интерфейс OData, если хватает типового набора объектов.

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

Обмен с большим каталогом

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

Как избежать сбоев обмена

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

• журнал обмена с датой, объемом и ошибками по каждому сеансу;
• уведомление ответственному, если обмен не прошел или затянулся;
• обработку ошибок по одной записи, чтобы битый товар не останавливал всю выгрузку;
• выгрузку только изменений вместо полного каталога каждый раз;
• инструкцию для администратора 1С: где смотреть журнал и как перезапустить обмен.

Интеграция 1С с Вайлдберриз

Wildberries дает продавцам API с отдельными токенами под разные задачи: контент, цены и скидки, сборочные задания, статистика. Токен создают в личном кабинете продавца и выбирают, к каким разделам он дает доступ. Для интеграции с 1С обычно нужны четыре направления.

1. Карточки товаров. Создаем и обновляем карточки из номенклатуры 1С: название, бренд, характеристики по требованиям категории, размеры, баркоды. У каждой категории свой набор обязательных характеристик, поэтому заранее сопоставляем свойства номенклатуры со справочниками маркетплейса.
2. Цены и скидки. Выгружаем цены из нужного типа цен 1С и управляем скидками без ручного редактирования в кабинете.
3. Остатки. Для схемы FBS (товар хранится на вашем складе, маркетплейс забирает собранные заказы) отправляем остатки по складам продавца. Для FBO (товар лежит на складе маркетплейса) забираем остатки из статистики, чтобы видеть их в 1С.
4. Заказы. Получаем новые сборочные задания, создаем по ним документы в 1С, передаем статусы сборки и коды маркировки для маркированных товаров.

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

Интеграция ВБ и 1С: частые проблемы

Большинство проблем в связке ВБ и 1С возникает не в коде, а в данных. Типичные ситуации:

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

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

Интеграция Ozon и 1С

У Ozon свой Seller API. Для подключения в личном кабинете продавца создают ключ, и запросы подписываются парой Client-Id и Api-Key. Набор задач похож на Wildberries, но детали отличаются.

• Товары. Ozon требует атрибуты, привязанные к категории, и проверяет карточку после загрузки. Статус проверки получаем обратно и показываем в 1С, чтобы менеджер видел, какие товары не прошли модерацию и почему.
• Цены. Кроме основной цены передаем цену до скидки и минимальную цену, ниже которой товар не должен уходить в акциях.
• Остатки. Для FBS и realFBS обновляем остатки по каждому складу продавца, заведенному в кабинете.
• Отправления. Забираем новые заказы, создаем в 1С документы отгрузки, передаем статусы сборки, получаем этикетки.
• Финансы. Загружаем отчеты о реализации и транзакции, чтобы бухгалтерия видела комиссии, логистику и выплаты по каждому заказу.

Если вы торгуете и на Ozon, и на Wildberries, строим общий слой интеграции. Остаток в 1С один, а маркетплейсы получают его долями по правилам, которые вы задаете: например, резерв под розницу и распределение остального между площадками. Товар не продается дважды, даже если заказы приходят одновременно с разных площадок.

Другие площадки

Та же схема работает с Яндекс Маркетом, Мегамаркетом и отраслевыми площадками, у которых есть API для продавцов. Если площадка принимает только файлы, формируем из 1С XML- или YML-фид (файл с товарами, ценами и наличием) и обновляем его по расписанию.

Учет продаж с маркетплейсов в 1С

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

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

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

Первое решение, которое принимает бизнес: поставить готовый модуль интеграции 1С с маркетплейсами или заказать разработку. Готовый модуль быстрее запустить, он уже умеет базовые операции, и его автор обновляет модуль при изменениях API. Этот путь подходит, если конфигурация 1С типовая, товаров немного и процессы стандартные.

Собственную интеграцию выбирают, когда:

• конфигурация 1С сильно доработана и модуль конфликтует с изменениями;
• площадок несколько и нужен общий центр управления остатками и ценами;
• есть свои правила ценообразования, резервов, комплектов;
• каталог настолько большой, что выгрузка целиком занимает часы, и нужна передача только изменений;
• данные о продажах нужно отдавать сразу в 1С, CRM, BI-систему (систему отчетов и аналитики) и мобильное приложение для сотрудников.

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

Интеграция по API

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

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

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

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

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

Безопасность интеграции

Интеграция открывает учетную систему наружу, поэтому защиту продумываем с первого дня:

• обмен идет только по HTTPS;
• опубликованная база 1С принимает запросы только с адресов наших серверов;
• для обмена заводим отдельного пользователя 1С с минимальными правами, без доступа к зарплате и кадрам;
• ключи API маркетплейсов и платежных систем храним в защищенном хранилище, а не в коде;
• каждое действие записываем в журнал, чтобы понять, кто и когда изменил данные.

Персональные данные покупателей передаем только туда, где они нужны для работы: курьер получает адрес и телефон, а история покупок остается в 1С и CRM.

Сколько стоит разработка API?

Цену называем после брифа, фиксированной вилки для этой работы у нас нет. На оценку влияют:

• число методов и сложность логики за ними;
• с какими системами API связан: только 1С или еще CRM, склад, платежи;
• требования к скорости ответа и нагрузке;
• нужна ли документация и тестовый стенд для партнеров;
• кто будет поддерживать API после запуска.

Небольшой набор методов под одного партнера требует меньше работы, чем публичный API для десятков подключений. Точную смету даем после того, как опишем методы и сценарии использования.

Платежные системы и службы доставки

Кроме учета, сайт и приложение обычно связаны с платежным шлюзом и службами доставки. Платежи подключаем через API банка или агрегатора: оплата картой и через СБП, возвраты, передача чеков в онлайн-кассу по 54-ФЗ. Факт оплаты сразу уходит в 1С, и менеджеру не нужно сверять выписки.

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

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

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

Какие данные обычно синхронизируем:

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

Технически связку строим через API обеих систем: у облачных CRM обычно есть открытый API и вебхуки, а для 1С пишем HTTP-сервис, который принимает данные сделки и создает документы.

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

Сквозная аналитика: от рекламы до оплаты в 1С

Когда сайт, CRM и 1С связаны, путь клиента видно от рекламного объявления до оплаты. Источник заявки сохраняется в сделке, сделка превращается в счет и оплату в 1С, и в отчете видно, сколько денег принес каждый рекламный канал. Для этого передаем в CRM UTM-метки (параметры в ссылке, по которым видно источник перехода) и связываем сделку с документами 1С по номеру.

Личный кабинет дилера и B2B-портал на данных 1С

Для оптовых компаний сайт часто работает как B2B-портал: дилер заходит в личный кабинет, видит свои цены, остатки на складах и историю заказов, оформляет заказ без звонка менеджеру. Все это строится на данных 1С.

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

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

Мобильное приложение и 1С

Мобильное приложение подключаем к 1С двумя путями. Первый - через промежуточный сервер с API: приложение для покупателей показывает каталог и остатки, принимает заказы и оплату, а сервер передает заказы в 1С и возвращает статусы. Так устроены клиентские приложения магазинов, потому что пользователей может быть много, а 1С не рассчитана на прямые запросы от каждого из них.

Второй путь опирается на собственные средства 1С. Мобильная платформа 1С собирает из конфигурации приложение для Android и iOS, а мобильный клиент открывает базу 1С на телефоне. Эти варианты подходят для сотрудников: торговых представителей, кладовщиков, курьеров, которым нужен доступ к учету в дороге. Для клиентских приложений с фирменным дизайном и платежами мы используем Flutter или нативную разработку, а данные берем из 1С через API.

Для сотрудников важна работа без сети: приложение хранит данные на телефоне и отправляет их в 1С, когда связь появится. Это закладываем в архитектуру с первого прототипа, потому что добавить офлайн-режим в готовое приложение сложнее.

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

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

Если в компании уже есть программисты 1С, мобильная платформа дает быстрый старт: приложение пишется на встроенном языке 1С, а данные синхронизируются с основной базой через тот же механизм обмена. Ограничения тоже есть: интерфейс строится по правилам платформы, и сделать его похожим на современное потребительское приложение сложно. Поэтому для складских и выездных сотрудников выбираем средства 1С, а для покупателей и партнеров собираем отдельное приложение и подключаем его к 1С через API.

Как создать приложение в 1С:Фреш?

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

Если нужна связка облачной базы с сайтом или приложением, работаем через механизмы, которые сервис открывает для внешних подключений. Когда расширений не хватает, например нужен клиентский сервис со своей базой, логичнее вынести его в отдельное приложение и связать с 1С:Фреш по API. Для небольших собственных облачных приложений у фирмы 1С есть отдельная платформа 1С:Предприятие.Элемент.

Что подготовить перед началом

Чтобы оценка была точной, на брифе просим:

• название и версию конфигурации 1С, список доработок, если он есть;
• доступ к копии базы или к тестовому контуру;
• описание процессов: кто оформляет заказы, где ведутся цены, как работает склад;
• список площадок и систем, которые нужно связать;
• контакт программиста 1С или администратора, если он есть в штате.

Если своего специалиста по 1С нет, берем доработку конфигурации на себя.

Этапы разработки: интеграция с 1С ERP и другими конфигурациями

Работу с 1С:ERP, Управлением торговлей или Комплексной автоматизацией проводим по одной схеме.

1. Анализ. Изучаем конфигурацию, версию платформы, доработки, объем справочников. Составляем карту потоков: какие данные, откуда, куда и как часто.
2. Проектирование. Выбираем способ обмена, описываем форматы, правила сопоставления и обработку ошибок. Согласуем, какая система главная для каждого типа данных.
3. Подготовка данных. Чистим дубли в номенклатуре, заводим недостающие идентификаторы, сопоставляем категории и характеристики с требованиями сайта или маркетплейса.
4. Разработка. Пишем код со стороны 1С, сайта и промежуточного сервиса. Веб-разработка и доработки 1С идут параллельно, чтобы обе стороны были готовы к общему тесту.
5. Тестирование. Проверяем обмен на копии рабочей базы: полная выгрузка, выгрузка изменений, обрыв связи посередине передачи данных, повторная отправка.
6. Запуск. Переключаем обмен на рабочие базы, первое время следим за журналом и сверяем остатки вручную.
7. Поддержка. Отслеживаем изменения API маркетплейсов и обновления конфигурации 1С, чтобы интеграция не ломалась после их выхода.

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