Как связать сайт с 1С: товары, цены и остатки

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

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

Начните с конкретной базы и двух направлений данных

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

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

Дальше используем учебный магазин настольных ламп. Ассортимент, обозначения и сценарии вымышлены; они не описывают клиентский проект или готовую настройку 1С. В этом примере учётная система передаёт на сайт товары, цены и доступное количество. Сайт передаёт обратно заказы. Описания для покупателей остаются в редакторе сайта.

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

Назначьте владельца каждому полю

Владелец поля — система, значение которой принимается за основное. При этом за его правильность отвечает конкретный сотрудник бизнеса. Фраза «всё синхронизируется в обе стороны» оставляет неясным, чья правка победит.

Для учебного магазина можно принять такой договор:

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

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

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

Передавайте конкретное предложение, а не только название товара

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

В нашем учебном примере общая модель обозначена как demo-lamp, а синее предложение — как demo-lamp-blue. Это условные метки для объяснения, не формат идентификаторов конкретной конфигурации 1С. На сайте предложение имеет свой внутренний ID; связь с учётной системой хранится отдельно.

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

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

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

Что именно означает цена и остаток

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

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

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

Проверьте оба направления на одном учебном заказе

Из 1С на сайт. Ответственный меняет цену синего предложения demo-lamp-blue и его доступное количество. Получатель узнаёт предложение по сохранённому ID, проверяет допустимость значений и обновляет только поля, принадлежащие 1С. Редакторский заголовок, описание и галерея остаются на месте. Повторная передача той же записи не создаёт ещё одну карточку.

С сайта в 1С. Покупатель оформляет заказ на синее исполнение. Сайт сохраняет постоянный ID заказа, ID предложения, количество и зафиксированную цену покупки. В учебном примере заказ обозначен demo-order-A; персональные данные здесь не приводятся. Принимающая сторона сопоставляет предложение с записью своей базы и подтверждает, что заказ принят. В журнале сохраняется связь между заказом сайта и документом учётной системы.

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

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

Особенно важен случай, когда 1С уже записала заказ, но сайт не получил подтверждение из-за обрыва связи. Повторная передача с тем же ID должна найти принятый заказ, а не создать новый документ. Такое поведение нужно проверить отдельно; надпись «обмен успешен» после первого прогона его не доказывает.

Выберите способ обмена после согласования правил

Варианты различаются не только форматом файлов, но и объёмом настройки, доступами и дальнейшим сопровождением.

• Готовый механизм обмена с сайтом на основе CommerceML. Официальный протокол описывает передачу торговых предложений и обмен заказами. Его разумно рассмотреть, когда обе стороны поддерживают нужный состав данных. Совместимое название формата ещё не подтверждает обработку ваших дополнительных полей, вариантов и состояний.
• Обмен файлами. В официальном описании ряда торговых решений 1С предусмотрен файловый ресурс. Он может пригодиться для проверки и отладки. Если файлы используются в рабочем процессе, отдельно нужны правила доставки, завершённости пакета, подтверждения обработки и повторной отправки.
• Собственный HTTP-сервис или доступ через OData. Платформа 1С:Предприятие предоставляет такие средства интеграции. Их рассматривают для процессов, которые не покрывает готовый обмен. Это техническая возможность платформы; готовые бизнес-правила вашего магазина из неё не следуют.

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

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

Установите правила задержек, конфликтов и удаления

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

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

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

Для устойчивой работы зафиксируйте ещё несколько правил:

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

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

Диагностика должна показывать, где остановились данные

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

В открытом протоколе обмена с сайтом успешная запись файла и завершение его обработки — разные шаги. Поэтому факт доставки файла не равен проверенному результату в карточке товара. Смотрите конкретную запись после обработки.

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

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

Принимайте обмен по поведению, а не по факту подключения

До запуска проверьте на согласованном тестовом наборе:

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

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

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