Интеграция сайта с 1С: что согласовать до настройки обмена

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

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

Какие данные нужно передавать

Начните со списка объектов. Обычно в обсуждение попадают товары, варианты, цены, остатки, покупатели, заказы и статусы. Но не нужно включать всё автоматически. Для каждого объекта ответьте: кому он нужен, какое действие запускает и что произойдёт без него.

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

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

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

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

Где находится источник каждого значения

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

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

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

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

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

Какие исключения обсудить заранее

Возьмите обычную покупку и измените по одному условию. Покупатель отменил заказ. Менеджер заменил позицию. На одном складе товар закончился, а на другом остался. У клиента изменился тип цены. В момент передачи недоступна одна из систем.

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

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

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

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

Более широкий путь покупки между участниками компании разобран в статье об автоматизации обработки заказов.

Как замечать и разбирать сбои

У интеграции должен быть понятный контроль. Спросите, где видно последнее успешное обновление, какие объекты не прошли и кто получает уведомление. Сообщение «обмен выполнен» без результата по данным недостаточно: успешное соединение ещё не подтверждает, что каждый заказ принят в работу.

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

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

Разделите ответственность за сайт, 1С и обмен. В компании должен быть владелец рабочего процесса, который видит незавершённый результат, а у исполнителей — согласованный порядок диагностики. Тогда вопрос не зависнет между ответами «сайт отправил» и «учёт ничего не получил».

Как принимать обмен на тестовых сценариях

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

Каталог, заказы и поведение при ошибке принимают по отдельным контрольным сценариям.

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

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

В Goncharoff.PRO можно обсудить интеграцию сайта, CRM и учёта по вашей схеме данных. Для начала подготовьте названия систем, их версии и один обезличенный заказ. По нему гораздо проще договориться, какой результат должен дать обмен.