Можно ли по одной фразе выполнить трудоемкую задачу? Это нереально и мы рассмотрим это на основе интеграции с 1С, заодно и увидим почему нельзя просто так и прийти и сказать "Сделай".
В 10:00 покупатель оформил и оплатил заказ. На сайте было пять единиц товара.
В 10:03 менеджер открыл 1С — заказа нет.
В 10:07 заказ появился, но сумма отличается: сайт применил скидку, а учётная система пересчитала стоимость по своим правилам.
В 10:12 выяснилось, что четыре единицы товара уже зарезервированы. Покупатель заказал две.
Это условная ситуация. Но она хорошо показывает, почему наличие обмена ещё не означает, что магазин и 1С работают согласованно.
Данные могут передаваться. Подключение может быть настроено. А сотрудникам всё равно приходится сверять суммы, исправлять документы и звонить покупателям.
Именно поэтому по фразе "нужна интеграция с 1С" нельзя обоснованно назвать фиксированную стоимость. Пока непонятно, какой результат мы оцениваем: передачу данных или работу всего процесса — от изменения цены до отгрузки заказа.
Пять единиц на складе — не обязательно пять в продаже
Начнём с товара из нашего примера.
Сайт получил остаток: пять штук. Технически всё верно. Только бизнес рассчитывал увидеть количество, которое можно продать, а в обмен попало физическое наличие без учёта резервов.
Пример товарного учета
Чтобы избежать такого расхождения, ещё до настройки нужно разобраться:
- Какие склады передают остатки на сайт?
- Нужно ли складывать их количество или показывать наличие отдельно?
- Где рассчитывается доступный остаток?
- В какой момент заказ резервирует товар и какая система отвечает за резерв?
- Что делать при нулевом количестве: запрещать покупку, разрешать предзаказ или оставлять заявку?
Следующий вопрос — задержка.
Если товар одновременно продаётся на сайте и в розничном магазине, сколько времени сайт может показывать устаревшее наличие? Минута, пятнадцать минут, час?
Это не пожелание "обновлять почаще", а требование, которое влияет на организацию обмена и его проверку.
Причём частота запуска и фактическая скорость обновления — разные вещи. Задание может запускаться каждые пять минут, но это ещё не значит, что все изменения успевают за это время обработаться.
Почему оплаченный заказ вдруг подорожал
Теперь вернёмся к сумме.
Покупатель увидел цену, применил промокод и оплатил заказ. В 1С приехали товары и количество, после чего стоимость рассчиталась заново.
Возникает вопрос: какая система в этом процессе должна определять итоговую сумму?
Для каталога источником цен может быть 1С. Но из этого не следует, что она должна заново рассчитывать уже оформленный заказ.
Поэтому отдельно обсуждаем два процесса.
Первый — обновление цен на витрине:
- Передаём розничную цену или несколько типов цен?
- Нужны ли отдельные условия для оптовиков и дилеров?
- Где рассчитываются скидки?
- Что делать с товаром, у которого нет цены?
Второй — передача стоимости покупки:
- Должна ли сохраняться цена, зафиксированная при оформлении?
- Как передаются промокоды и скидки?
- Как учитывается доставка?
- Допускается ли изменение суммы после оплаты и кто может его выполнить?
Слово "цены" в списке передаваемых данных одно. А решения за ним стоят разные.
Заказ не появился. Отправить ещё раз?
Менеджер не видит заказ в 1С и просит повторить передачу.
Допустим, первая попытка на самом деле прошла успешно, но сайт не получил подтверждение. Если повторная отправка создаст новый документ, вместо пропавшего заказа бизнес получит два одинаковых.
Поэтому обработка ошибок — часть интеграции, а не дополнительное удобство на потом.
Нужно определить:
- По какому идентификатору системы узнают один и тот же заказ.
- Как отличить новый заказ от обновления существующего.
- Что повторяется автоматически при временной недоступности.
- Что происходит с заказом, если один из товаров не удалось сопоставить.
- Где сотрудник увидит ошибку и кто получит уведомление.
- Как восстановить передачу, не создавая дублей.
В своей статье о работе тимлида мы уже объясняли этот подход: синхронизации, таймауты, ошибки и повторные попытки нужно фиксировать, чтобы разбираться в проблемах по логам, а не только по жалобам клиента.
Но одного журнала мало. В постановке задачи стоит закрепить и ответственность: кто следит за обменом, кто исправляет данные, кто восстанавливает работу.
Иначе сообщение об ошибке есть, а человека, который должен на него отреагировать, нет.
Двусторонний обмен — не право менять всё с двух сторон
У заказа есть состав, сумма, оплата, доставка, отгрузка, отмена. У каждого события может быть свой источник.
Например:
- Сайт создаёт заказ и сообщает об онлайн-оплате.
- 1С передаёт сведения об отгрузке.
- Цены и остатки ведутся в 1С.
- Описания и SEO-поля редактируются на сайте.
Это возможная схема, а не универсальный стандарт.
Самое интересное начинается там, где обе системы могут менять одни и те же сведения.
Менеджер исправил заказ на сайте. Другой сотрудник в это время изменил его в 1С. Какое изменение должно сохраниться? Нужно ли блокировать редактирование после определённого этапа? Как покупатель узнает, что состав заказа поменялся?
Поэтому мы предлагаем обсуждать не просто «двусторонний обмен», а ответственность за конкретные данные и события.
Для каждой сущности должно быть понятно: где её создают, где разрешено изменять и куда передают результат.
Что тогда можно передать на оценку
Необязательно заранее писать большой документ. Для начала достаточно описать рабочий сценарий и его границы.
Вот условный пример:
Интернет-магазин работает на «1С-Битрикс», учёт ведётся в «1С:Управление торговлей». Перед оценкой фиксируем версии систем, модуль обмена и существующие доработки.
В каталоге около 15 000 торговых предложений. Нужно сохранить существующие карточки, предварительно проверить идентификаторы и согласовать сопоставление товаров.
Из 1С на сайт передаём розничные цены и доступные остатки по двум складам. Остатки рассчитываются на стороне 1С с учётом резервов. При нулевом количестве покупка запрещается.
Изменения цен и остатков должны появляться на сайте не позднее чем через 15 минут при согласованном объёме данных и штатной доступности систем.
Заказы передаются с сайта в 1С после оформления, независимо от оплаты. Сохраняются цены, скидки и стоимость доставки, зафиксированные в заказе. Повторный пересчёт суммы в 1С не выполняется.
Сведения об онлайн-оплате идут с сайта в 1С, сведения об отгрузке — из 1С на сайт. Соответствие статусов согласуем отдельно.
На первом этапе изменение состава переданного заказа и отмены обрабатываются менеджером вручную. Автоматизация этих сценариев в текущую оценку не входит.
При временном сбое передача повторяется без создания дублей. Ошибки сопоставления фиксируются с номером заказа или идентификатором товара. Ответственный сотрудник получает уведомление.
При приёмке проверяем не только успешный обмен, но и недоступность 1С, повторную отправку заказа, отсутствие товара при сопоставлении и восстановление после сбоя.
И предложения подрядчиков становится проще сравнивать: не по одинаковой строке «интеграция с 1С», а по конкретным обязательствам.
Где заканчивается настройка и начинается отдельная разработка
Покупать собственный механизм обмена там, где задачу закрывает готовый модуль, не нужно. Но и считать любой процесс стандартным только потому, что для него существует модуль, тоже не стоит.
Перед расчётом важно отделить:
- настройку существующих возможностей;
- исправление и сопоставление исходных данных;
- доработки сайта;
- доработки 1С;
- тестирование совместной работы;
- запуск и контроль после него.
Иногда основная сложность оказывается не в передаче данных, а в том, что компания ещё не договорилась, где резервировать товар или кто имеет право менять оплаченный заказ.
Разработчик может реализовать выбранный порядок. Но сам порядок должен быть согласован с теми, кто продаёт, принимает оплату и отгружает.
Поэтому хороший результат интеграции проверяется не фразой «файл загрузился».
Покупатель оформил заказ на согласованных условиях. Менеджер увидел его в учётной системе. Сумма не изменилась без причины. Остатки обработались по установленным правилам. А если передача прервалась, команда знает об этом и может восстановить её без ручного поиска потерянных заказов.
Вот такой процесс уже можно оценивать, разрабатывать и принимать.