Интеграция сайта с 1С УНФ: обмен интернет-магазина товарами и заказами

Обмен 1С УНФ с интернет-магазином — это регулярная передача товаров, цен, остатков и заказов между учётной системой и сайтом. После установки модуля обмена в меню 1С:УНФ появляется раздел «1С-Битрикс: Управление сайтом»: оттуда запускают обмен, настраивают подключение к сайту и смотрят журналы. Ниже разобрано, какие данные ходят в обе стороны, как выглядит схема заказа в УНФ, что подготовить до настройки, как принять работу и где границы решения.

Что решает обмен 1С УНФ с интернет-магазином и где границы задачи

Обмен 1С УНФ с интернет-магазином закрывает одну конкретную задачу: сделать так, чтобы сайт и учётная система говорили об одном и том же наборе товаров, цен, остатков и заказов. Без обмена менеджер вынужден вручную переносить заказ с сайта в 1С, вручную править цены и остатки, вручную сверять, что продалось, а что лежит на складе. Каждый такой перенос — источник расхождений: где-то цена осталась старой, где-то товар продали дважды, где-то заказ потерялся между почтой и таблицей.

Интеграция убирает ручной перенос, но не отменяет учёт. УНФ остаётся системой, где формируются документы, считается себестоимость, ведутся взаиморасчёты и склад. Сайт остаётся витриной и точкой приёма заказов. Обмен — это транспорт между ними, а не замена ни тому, ни другому.

Границы задачи стоит проговорить сразу, до начала работ:

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

Если задача сформулирована как «хотим, чтобы всё синхронизировалось», её нужно сузить до перечня сущностей и правил. Иначе приёмка превратится в спор о том, что считать правильным результатом.

Какие данные ходят между сайтом и УНФ

Направлений два, и их полезно держать раздельно, потому что настройки и ответственные у них разные.

Из УНФ на сайт обычно уходит:

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

С сайта в УНФ приходит:

• заказы покупателей;
• контрагенты, если заказы должны попадать в учёт с привязкой к покупателю;

Отдельно стоит отметить режим загрузки документов в реальном времени. В модуле обмена он описан как «Загрузка документов в режиме реального времени»: соединение с сайтом можно запустить, чтобы отслеживать новые заказы, и отключить, когда мониторинг больше не нужен. Поведение при запуске зависит от типа базы: если база 1С файловая, текущий сеанс становится подключением и «зависает» — пока видно зависание сеанса, сайт подключён; если база клиент-серверная, запускается фоновое задание, которое и становится подключением. Это важно для планирования рабочего места: на файловой базе нельзя одновременно работать в УНФ и держать мониторинг в том же сеансе.

Помимо этого, в модуле есть раздел «Чеки» с командами открытия и закрытия смены ККМ. Это относится к торговой логике, а не к обмену с сайтом, но встречается в том же меню и иногда путает при настройке.

Схема заказа в УНФ: от корзины до отгрузки

Схема заказа — главный практический артефакт, который нужно согласовать до настройки. Она показывает, в какой момент заказ с сайта становится документом в УНФ, когда встаёт резерв, как фиксируется оплата и что уходит обратно на сайт.

Путь заказа

Типовой путь выглядит так:

1. Покупатель оформляет заказ на сайте. Заказ существует только на сайте, в УНФ его ещё нет. 2. Обмен переносит заказ в УНФ. Там он превращается в заказ покупателя. 3. Менеджер или автоматика подтверждает заказ, при необходимости уточняет состав и количество. 4. Под заказ встаёт резерв на складе — по правилам, которые заданы в УНФ. 5. Фиксируется оплата: по факту поступления денег или по другому согласованному признаку. 6. Заказ отгружается, оформляется реализация. 7. Статус заказа возвращается на сайт, чтобы покупатель видел актуальное состояние.

Каждый шаг — это развилка. Например, заказ может быть отменён покупателем до подтверждения, тогда его не нужно резервировать. Товар может закончиться между оформлением и подтверждением, тогда нужен сценарий частичной отгрузки или замены. Эти сценарии описываются заранее, иначе они всплывут в первый же день работы.

Резерв и склад

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

Оплата и статусы

Статусы заказа на сайте и состояния документа в УНФ — это две разные системы координат. Их нужно сопоставить: какой статус сайта соответствует какому этапу в УНФ, кто переводит заказ из состояния в состояние и в какой момент статус уходит обратно на сайт. Если это сопоставление не сделать, покупатель будет видеть «в обработке» даже после отгрузки.

Роли и ответственность: кто за что отвечает

Интеграция ломается не только по техническим причинам. Чаще она ломается потому, что никто не отвечает за конкретный участок.

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

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

Что подготовить до настройки обмена

До технических действий нужно собрать входные данные. Это экономит время и снижает риск переделок.

• Перечень сущностей, которые участвуют в обмене: товары, цены, остатки, заказы, контрагенты, справочники.
• Правила сопоставления: как товар на сайте связан с номенклатурой в УНФ, как сопоставляются склады, цены и статусы.
• Описание схемы заказа: этапы, развилки, ответственные, что уходит на сайт.
• Требования к расписанию: как часто запускается обмен и что происходит, если он не прошёл.
• Тестовый контур: копия базы и тестовый сайт, где можно проверить сценарии без риска для рабочего контура.

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

Настройка со стороны УНФ: команды модуля обмена

После установки модуля обмена в меню 1С:УНФ появляется пункт «1С-Битрикс: Управление сайтом». Он открывает настройки обмена данными с сайтами. В правой части выводится список команд:

• «Общие настройки» — глобальные настройки, которые применяются ко всем настройкам обмена;
• «Настройки обмена с сайтами» — список настроек обмена; здесь создаются новые подключения к сайтам;
• «Выполнить обмен с сайтом» — запуск обмена; если настроек несколько, выбирается нужная;
• «Зарегистрированные изменения» — список данных, которые будут выгружены в ближайшем обмене.

Раздел «Загрузка документов в режиме real time» позволяет запустить соединение к сайту для мониторинга новых заказов и отключить его. Раздел «Сервис» даёт доступ к журналу обменов, журналу ошибок, идентификаторам объектов, импорту товаров из интернет-магазина и ссылкам на прикладные объекты. Журнал ошибок доступен только при установке соответствующего флажка в общих настройках — это стоит проверить сразу, иначе при разборе сбоя не будет данных.

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

По документации, работа с модулем обмена в 1С:УНФ аналогична работе с модулем обмена в 1С:УТ, поэтому часть описаний берётся из главы про УТ. Это удобно, но требует внимания: не все формулировки из документации по УТ автоматически применимы к конкретной конфигурации УНФ.

Настройка со стороны сайта: что сверить

Со стороны сайта нужно убедиться, что приём и отдача данных настроены согласованно с УНФ. Проверяются:

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

Если сайт работает на Битрикс, общая логика обмена товарами и заказами описана в материале Интеграция Битрикс с 1С: как настроить обмен товарами и заказами. Там разобраны общие принципы, которые применимы и к связке с УНФ, — этот материал стоит прочитать до настройки, чтобы не дублировать базовые шаги.

Оплата, резерв и отгрузка: как связаны статусы

Связка «оплата — резерв — отгрузка» определяет, что видит покупатель и что происходит на складе. Здесь важно не смешивать три разных события.

Оплата — это факт поступления денег. Резерв — это закрепление товара за заказом. Отгрузка — это передача товара покупателю с оформлением документа. В разных компаниях эти события идут в разном порядке: где-то резерв ставится сразу при оформлении, где-то только после подтверждения менеджером, где-то после оплаты.

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

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

Учебный пример: обмен заказами на тестовых данных

Учебный пример. Данные условные и не описывают реальную компанию.

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

Что делаем по шагам:

1. Фиксируем перечень сущностей: номенклатура, цены, остатки, заказы, контрагенты. 2. Сопоставляем склады и типы цен между сайтом и УНФ. 3. Описываем схему заказа: заказ на сайте → заказ покупателя в УНФ → подтверждение → резерв → оплата → отгрузка → статус на сайте. 4. На тестовом контуре создаём настройку обмена и запускаем выгрузку товаров. 5. Проверяем, что на тестовом сайте появились позиции с корректными ценами и остатками. 6. Оформляем тестовый заказ на сайте и запускаем обмен в обратную сторону. 7. Проверяем, что в УНФ появился заказ покупателя с правильным составом и привязкой к контрагенту. 8. Проводим заказ по этапам: подтверждение, резерв, оплата, отгрузка. 9. Проверяем, что статус вернулся на сайт и совпал с ожидаемым. 10. Повторяем обмен и убеждаемся, что дубли не создаются.

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

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

Как проверить результат и принять работу

Приёмка — это не «обмен запустился». Это набор проверок, которые можно повторить.

• Перечень сущностей обмена совпадает с согласованным списком.
• Номенклатура с характеристиками переносится без потерь и дублей.
• Цены и остатки на сайте соответствуют данным УНФ на момент проверки.
• Тестовый заказ с сайта появляется в УНФ как заказ покупателя с корректным составом.
• Повторный обмен не создаёт дублей заказов и позиций.
• Резерв встаёт и снимается по согласованным правилам.
• Статусы заказа на сайте соответствуют этапам в УНФ.
• Журнал ошибок доступен и заполняется при сбое.
• Поведение при недоступности сайта или УНФ описано и проверено.
• Есть план возврата: как откатиться к предыдущему состоянию, если обмен пойдёт не так.
• Ответственные за каждый участок названы и знают свой маршрут действий.

Если какой-то пункт не проверен, работа не принята — это нормальное правило, а не придирка. Непроверенный сценарий почти всегда всплывает в первый рабочий день.

Типичные ошибки и ограничения

Большинство проблем связано не с самим модулем, а с несогласованными правилами и неподготовленными данными.

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

Если обмен уже работал и перестал, полезно сначала посмотреть материал Обмен с 1С сломался: типичные проблемы интеграции и как их решить — там разобраны общие причины сбоев, которые встречаются и в связке с УНФ.

Какие исходные данные подготовить для оценки

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

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

Чем точнее эти данные, тем меньше допущений в оценке. Если какой-то пункт неизвестен, это тоже полезно зафиксировать: значит, его нужно выяснить до начала работ, а не в процессе.

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