Заказы между сайтом и 1С: как согласовать статусы, оплату и ответственных

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

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

Обмен заказами 1С и Битрикс связывает магазин на «1С-Битрикс: Управление сайтом» с учётной системой. Его задача зависит от проекта: передать новый заказ, вернуть сведения об оплате, обновить состояние отгрузки или сообщить об отмене. Это не то же самое, что обмен каталогом товаров или работа со сделками Битрикс24.

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

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

Назначьте источник каждого изменения

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

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

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

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

Составьте таблицу соответствия статусов

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

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

Проверьте обратные переходы. Можно ли вернуть заказ из сборки на уточнение? Что произойдёт, если отмену сняли? Какие письма повторятся? Редкие случаи лучше проговорить заранее, чем обнаружить после автоматической рассылки покупателям. Для каждого перехода нужен понятный инициатор и запись о причине.

Отделите оплату от создания документов

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

Опишите частичную оплату отдельно. Условный заказ на 30 000 рублей может иметь предоплату 10 000 рублей и остаток 20 000 рублей. Это учебные суммы. Сайт должен показывать согласованное состояние, а сотрудник — понимать, какая часть оплачена и какое следующее действие разрешено. Общая надпись «оплачен» в таком сценарии может вводить клиента в заблуждение.

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

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

Проверьте частичную отгрузку и изменение состава

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

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

Разберите ситуацию, когда количество уменьшилось после оплаты. Кто подтверждает новый состав, рассчитывает разницу, инициирует возврат и сообщает покупателю? Эти действия могут находиться в разных системах. Таблица ответственности должна связывать их в один процесс, иначе сайт обновит товары, но клиент не узнает, что происходит с переплатой.

Уточните правила доставки при разделении заказа. Изменение числа отправок не должно автоматически означать согласие покупателя на дополнительные расходы. Команда должна определить, где подтверждается новый вариант и как это отражается в данных заказа. Здесь речь о проектировании процесса; условия продажи и расчётов компания проверяет отдельно с ответственными специалистами.

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

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

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

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

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

Какие заказы включить в приёмку

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

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

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

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

Что делать, если обмен остановился

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

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

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

Для постановки задачи ШТАБ ИТ подготовьте таблицу статусов, перечень источников данных и несколько обезличенных сценариев. По ним можно обсудить интеграцию сайта и учётной системы, оценить поддерживаемые возможности и определить критерии приёмки. Результат — понятный и проверяемый путь заказа от создания до завершения.