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

Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce, и преподаю на курсах разработки и архитектуры в ОТУС.

Заказ в 1С проводится, склад отгрузку собирает, эквайринг деньги списывает — каждый кусок работает. А клиент звонит в поддержку: «Деньги вы списали, а в личном кабинете заказ отменён».

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

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

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

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

Исходные условия

Проект собирательный, но цифры и стек — из практики.

• Компания: e‑commerce, около 15 тысяч заказов в сутки в пик, три своих склада и фулфилмент‑партнёр.

• Контур учёта: 1С:ERP 2.5.26 на платформе 8.5.1. Напомню, что с 8.5.1 нумерация сменилась и версии 8.3.28 уже не будет — 8.3.27 закрыла ту линейку.

• Смежные системы: витрина и личный кабинет на Kotlin, WMS с терминалами сбора данных, платёжный шлюз с холдированием, CRM.

• Транспорт: 1С:Шина поверх RabbitMQ, обмен по AMQP. В типовых обменах — EnterpriseData; это формат сообщения, а не транспорт, выбор транспорта остаётся отдельным решением.

• Команда: два архитектора, пять разработчиков 1С, шесть бэкендеров, один аналитик на всех.

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

Последний пункт важнее остальных. Две недели — это не «давайте всё опишем», а «давайте решим, что описывать не будем».

Шаг 1. Собрать сквозной сценарий на одном листе

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

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

• Клиент подтвердил заказ — витрина.

• Заказ клиента создан — 1С:ERP.

• Товар зарезервирован — 1С:ERP.

• Сумма захолдирована — платёжный шлюз.

• Задание на отбор создано — WMS.

• Факт отгрузки зафиксирован — WMS.

• Реализация проведена — 1С:ERP.

• Списание выполнено — платёжный шлюз.

Восемь строк, полчаса работы. Дальше они превращаются в схему — не BPMN и не описание всех веток, а ответ на один вопрос: через сколько границ систем проезжает заказ (рис. 2).

Главная мысль этой схемы: заказ пересекает границу между системами шесть раз, и ни один из шести переходов не принадлежит целиком ни одному отделу. Разрывы появляются не внутри прямоугольников, а на стрелках между ними — ровно там, где ни у кого нет ответственности.

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

Шаг 2. Назначить владельца каждому объекту данных

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

Что делаем. Берём объекты, которые ходят между системами, и назначаем каждому ровно одну систему‑владельца. Не две. Не «ну там как бы обе». Владелец — тот, кто принимает окончательное решение по объекту, а не тот, кто чаще с ним работает.

Здесь обычно возражают: остаток же реально живёт в двух системах. Живёт. Но право быть правым в спорной ситуации принадлежит одной. В таблице выше владелец остатка — WMS, потому что она отражает физическое состояние склада, а 1С получает синхронизированные данные. Расклад частый, но не единственный: решение о доступности принимает ERP — владельцем будет ERP. Важно правило, а не конкретная система в ячейке.

Как проверяем. Для каждой строки задаём вопрос: «Значения разошлись. Чьё побеждает?» Если ответа нет за пять секунд — владелец не назначен, что бы ни было записано в таблице.

Шаг 3. Перевести пожелания в требования

Какой риск закрываем. Пожелание нельзя ни реализовать, ни проверить, но его можно записать в ТЗ и подписать. Дальше спор о том, что имелось в виду, переезжает на приёмку.

Что делаем. Раскладываем каждое пожелание по колонкам: триггер, правило, критерий приёмки.

И здесь я хочу привести историю, которая лучше всего объясняет, почему архитектор обязан спорить с бизнесом, а не переводить его дословно.

В 2011 году сеть Lidl начала проект eLWIS — замену самописной системы товародвижения Wawi на SAP for Retail. Конфликт возник в одной точке: Lidl оценивал запасы по закупочным ценам, а стандартная логика SAP для ритейла работала от розничных. Менять свою логику бизнес отказался, решили адаптировать систему. Дальше обычная механика: каждая доработка тянула следующую, стоимость росла. В июле 2018 года проект остановили и вернулись на Wawi, списав около 500 миллионов евро.

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

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

Как проверяем. Читаем критерий приёмки вслух и спрашиваем: сможет тестировщик проверить это без разработчика? Формулировки вроде «должно работать быстро» отправляются на переписывание.

Шаг 4. Разложить требования по компонентам

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

Что делаем. Каждое требование получает адрес и цену этого адреса.

К середине 2026 года расширения окончательно стали стандартом корпоративных доработок, а не вспомогательным механизмом. И если проект живёт дольше одного внедрения, вокруг расширений неизбежно вырастает инфраструктура: 1C:EDT (версия 2026.1 вышла 16 июля), Git, отдельная ветка с типовыми релизами вендора, пайплайн на CI и реестр доработок. Реестр скучный, но именно он отвечает на вопрос «почему после обновления отвалилось» за минуту, а не за день.

Рисунок 3 показывает, как требования из шага 3 расходятся по компонентам.

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

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

Как проверяем. Считаем строки в колонке «правка типовой конфигурации». Ноль — хорошо. Больше нуля — под каждой строкой должно стоять письменное обоснование с оценкой стоимости обновлений, иначе строка возвращается на пересмотр.

Шаг 5. Описать интеграции как контракты, а не как «обмен»

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

Что делаем. Для каждой стрелки со схемы пишем контракт события. Не «настроим обмен по расписанию», а конкретный документ.

Пример события списания (JSON):

{
  "eventId": "8f14e45f-ea28-4f7d-9d3c-b6a1c0c7d901",
  "eventType": "order.payment.captured",
  "occurredAt": "2026-07-24T11:42:07+03:00",
  "source": "payments",
  "idempotencyKey": "capture/PAY-2026-8842119/TRX-44012",
  "schemaVersion": "1.2",
  "payload": {
    "orderNumber": "8842119",
    "shipmentId": "SH-2026-0071233",
    "amount": 14990.00,
    "currency": "RUB"
  }
}

Обратите внимание на ключевую деталь: idempotencyKey собран из бизнес‑сущностей, а не из технического идентификатора сообщения. Технический меняется при каждой повторной доставке, бизнес‑ключ — нет.

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

На стороне 1С проверка опирается на независимый регистр сведений с одним измерением — ключом идемпотентности. Фрагмент намеренно сокращён, чтобы показать идею, а не готовый модуль (1С:Предприятие, встроенный язык):

Функция ЭтоПовторнаяДоставка(КлючИдемпотентности)
	Запись = РегистрыСведений.ОбработанныеСообщения.СоздатьМенеджерЗаписи();
	Запись.Ключ = КлючИдемпотентности;
	Запись.Прочитать();
	Возврат Запись.Выбран();
КонецФункции

Процедура ПринятьПодтверждениеОплаты(Сообщение) Экспорт
	Если ЭтоПовторнаяДоставка(Сообщение.idempotencyKey) Тогда
		ЗаписьЖурналаРегистрации("Обмен.Оплата",
			УровеньЖурналаРегистрации.Информация, , ,
			"Повторная доставка: " + Сообщение.idempotencyKey);
		Возврат;
	КонецЕсли;

	НачатьТранзакцию();
	Попытка
		СоздатьПоступлениеОплаты(Сообщение.payload);
		ЗафиксироватьОбработку(Сообщение.idempotencyKey);
		ЗафиксироватьТранзакцию();
	Исключение
		ОтменитьТранзакцию();
		ВызватьИсключение;
	КонецПопытки;
КонецПроцедуры

Отметка об обработке пишется в той же транзакции, что и документ. Разнесёте по разным — получите окно, в котором документ уже создан, а отметки ещё нет, и повторная доставка спокойно создаст второй.

База инструментов сегодня нормальная: 1С:Шина подключается к внешним брокерам по AMQP (RabbitMQ, ActiveMQ Artemis), показывает статистику по каналам и разделяет доставленные и недоставленные сообщения, для которых доступна повторная доставка. Гарантированную доставку вендор заявляет для связки платформы и Шины — но сам брокер её не обещает. На стороне RabbitMQ её собирают руками: publisher confirms, durable‑очереди, persistent‑сообщения и подтверждения потребителя. Шифрование HTTPS и AMQPS в продукте есть; поддержку AMQPS в сервисах интеграции на стороне платформы анонсировали на 1С DevCon 2026, официальной документации по срокам я не видел. Спорить в итоге имеет смысл не о транспорте, а о содержании контракта.

Как проверяем. Берём сообщение из журнала и инициируем повторную доставку. Появился второй документ — идемпотентности нет, что бы ни было написано в проектном решении.

Шаг 6. Прогнать процесс по отказам

Какой риск закрываем. Happy path проектируют все, разваливается процесс на остальном. Если поведение при сбое не описано, его в момент аварии придумает дежурный — и каждый раз по‑новому.

Что делаем. Берём пять сценариев отказа и для каждого фиксируем не только результат, но и владельца решения.

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

Эти пять строк определяют архитектуру сильнее, чем happy path: они отвечают, где живёт состояние процесса, кто имеет право его менять и что считается истиной в момент расхождения.

Как проверяем. Каждый сценарий воспроизводим на тестовом контуре руками. Не обсуждаем на встрече — воспроизводим и смотрим, что стало с документами.

Где этот подход не сработает

Честно про границы.

• Малый проект. Три человека, 1С:УНФ, пятьдесят заказов в день, один подрядчик. Шесть шагов здесь съедят больше, чем сэкономят: хватит шагов 1 и 6.

• Fixed‑price с подписанным ТЗ. Шаг 3 упирается в юристов, а не в архитектуру: карту разрывов делают ради допсоглашения, а не ради перепроектирования.

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

• Один монолит без смежных систем. Весь процесс внутри одной базы — шаги 2 и 5 вырождаются, остаются 1, 3, 4 и 6.

Чек‑лист

• Сквозной сценарий помещается на один лист, у каждого шага указана система.

• У каждого объекта данных ровно один владелец, и на вопрос «чьё значение побеждает» есть ответ.

• Каждое требование имеет триггер, правило и проверяемый критерий приёмки.

• У каждого требования есть адрес: типовое, расширение, сервис или отказ. Правок типовой ноль либо каждая обоснована письменно.

• Каждая интеграция описана контрактом с ключом идемпотентности из бизнес‑сущностей.

• Пять сценариев отказа воспроизведены руками на тестовом контуре.

Вместо заключения

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

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

Проекты на 1С разваливаются не из‑за кода. Они разваливаются на стрелках между прямоугольниками.

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

Приходите на бесплатные уроки: разберёте практические примеры и сможете задать вопросы преподавателям:

• 30 июля в 20:00. «Функциональный архитектор 1С: как перестать быть "переводчиком требований" и начать управлять системой». Записаться

• 20 августа в 20:00. «Типовые решения vs кастомная разработка: стратегический выбор функционального архитектора 1С». Записаться

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