Договоры и спецификации в B2B-кабинете на 1С-Битрикс: согласование и документы

Оптовый клиент работает не по публичной оферте, а по договору: у него свои цены, отсрочка, согласованный перечень номенклатуры и лимиты. Пока таких клиентов пять, менеджер держит договоры в почте и папках на диске, а спецификации пересылает в Excel. Когда клиентов становится пятьдесят, эта схема рассыпается: цены расходятся с 1С, кто-то отгрузил по устаревшей спецификации, счёт-фактуру потеряли, а на сверке всплывает, что подписанной редакции договора вообще нет. Всё это лечится одним — переносом договоров и спецификаций внутрь B2B-кабинета на 1С-Битрикс, где они связаны с контрагентом, ценами, заказами и печатными формами.

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

Договор и спецификация: что это в B2B-кабинете

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

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

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

Заказ (заявка на отгрузку) — оперативный документ: «в рамках такой-то спецификации отгрузите вот эти позиции к такой-то дате». По одной спецификации проходит серия заказов, пока она действует и пока не выбраны согласованные объёмы.

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

Какую роль играют договор и спецификация у оптовика

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

• Правильные цены без ручной работы. Клиент видит в каталоге не розницу и не «среднюю» оптовую цену, а именно свои цены по действующей спецификации. Менеджеру не нужно пересчитывать корзину вручную.
• Прозрачность условий. Отсрочка, лимит, минимальная партия, доступная номенклатура — всё это следствие договора и видно и клиенту, и менеджеру в одном месте.
• Контроль отгрузок по согласованному. Заказ проверяется на соответствие спецификации: нельзя заказать позицию не из перечня или по цене, отличной от согласованной.
• Готовые документы. Счёт, накладная, счёт-фактура и УПД формируются из заказа автоматически — клиент скачивает их сам, не дёргая менеджера.
• История и доказуемость. Кто согласовал спецификацию, когда, какая редакция действовала на дату отгрузки — всё фиксируется и доступно на сверке и в спорных ситуациях.

Иными словами, договор и спецификация превращают кабинет из «витрины с ценами» в рабочий инструмент сделки. Клиент самостоятельно оформляет заказы в рамках согласованных условий, а поставщик получает предсказуемый, контролируемый и документированный поток отгрузок. Это ровно та разница, которая отличает настоящий B2B-портал от розничного интернет-магазина с прикрученной «оптовой» скидкой.

Привязка договора к контрагенту, ценам и условиям

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

Контрагент и его представители. В опте покупатель — это юридическое лицо (контрагент), а входят в кабинет конкретные люди: закупщик, бухгалтер, руководитель. Поэтому в модели данных нужно разделять контрагента (компанию с ИНН и реквизитами) и пользователей, которые к нему привязаны. Один контрагент — несколько пользователей с разными ролями и правами; один пользователь в редких случаях может представлять несколько компаний.

Договор как носитель условий. К контрагенту привязывается один или несколько договоров. Каждый договор несёт набор условий: тип цены, базовую скидку, отсрочку платежа, кредитный лимит, валюту, срок действия, признак активности. Именно договор — а не абстрактный «профиль клиента» — определяет, по каким ценам работает контрагент.

Цены и скидки. Здесь есть два уровня. Первый — тип цены договора: например, «Оптовая-2» вместо «Розница». Второй, более точный — индивидуальные цены на конкретные позиции, зафиксированные в спецификации. Спецификация всегда «главнее» типа цены: если позиция есть в действующей спецификации, берётся цена оттуда, если нет — применяется тип цены договора. О самих индивидуальных прайсах и о том, как их технически собирать в Битриксе, у нас есть отдельный разбор: индивидуальные прайс-листы в B2B на 1С-Битрикс.

Ограничение номенклатуры. Часто договор ограничивает не только цены, но и ассортимент: контрагент видит и заказывает только согласованную номенклатуру. Это реализуется через привязку списка товаров (или разделов) к договору либо через фильтрацию каталога по спецификации.

Спецификация как согласованный перечень позиций

Спецификация — центральный документ опта, поэтому уделим ей отдельное внимание. По сути это таблица: номенклатура, единица измерения, количество (или диапазон), цена за единицу, сумма, НДС. Плюс шапка со ссылкой на договор, номером, датой и сроком действия. Но в кабинете спецификация — не просто PDF, а структурированные данные, с которыми работает система.

Что даёт хранение спецификации как данных, а не как файла:

• Цены применяются автоматически. Каталог и корзина берут цену позиции прямо из строки спецификации — не нужно, чтобы менеджер вручную выставлял её в заказе.
• Контроль объёмов. Если спецификация задаёт объём (например, «до 500 шт за квартал»), система отслеживает выборку по заказам и предупреждает о приближении к лимиту.
• Проверка заказа на соответствие. При оформлении заказа система сверяет позиции и цены с действующей спецификацией и не даёт «вылезти» за согласованное.
• Аналитика. Видно, какие спецификации активны, что по ним выбрано, какие скоро истекают и требуют пересмотра.

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

Архитектура: где всё хранится в 1С-Битрикс

Теперь переведём модель на язык платформы. В 1С-Битрикс сущности «договор», «спецификация» и «документ» удобно раскладывать по инфоблокам и highload-блокам, а заказы и покупателей — по модулю интернет-магазина. Разберём типовое распределение.

• Контрагенты. Профили покупателей модуля Sale (учётные записи с типом «юрлицо») плюс собственные свойства: ИНН, КПП, юридический адрес, банковские реквизиты. Часто удобно дополнить отдельным инфоблоком «Контрагенты» со связью «компания → пользователи».
• Договоры. Отдельный инфоблок «Договоры» с элементами-договорами: свойства «контрагент», «тип цены», «отсрочка», «лимит», «срок действия», «статус». Либо highload-блок, если договоров очень много и не нужен полноценный контент-редактор.
• Спецификации. Инфоблок «Спецификации» с привязкой к договору. Перечень позиций хранится как связанные строки: либо как товары с ценами через свойства, либо в отдельной таблице highload-блока «строки спецификации».
• Цены по договору. Механизм цен модуля Каталог: отдельные типы цен под договоры и индивидуальные цены через API. Для индивидуальных прайс-листов часто применяют highload-блок «цены контрагента».
• Документы и печатные формы. Инфоблок «Документы» с файлами и метаданными (тип, номер, дата, версия, статус, ссылка на заказ/договор) — единое хранилище счетов, накладных, актов, подписанных сканов.
• Заказы. Заказы модуля Sale с привязкой к договору и спецификации через свойства заказа и статусную модель.

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

Процесс согласования: статусы, роли, уведомления

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

Маршрут описывается через статусы. Каждый статус — это состояние документа, у которого есть ответственная роль, разрешённые действия и уведомления. Типовая цепочка для спецификации выглядит так:

1. Черновик. Менеджер формирует спецификацию: подбирает позиции, проставляет цены и объёмы. Документ виден только внутри компании.
2. На внутреннем согласовании. Руководитель отдела продаж проверяет цены и скидки. При превышении порогов скидки подключается финансовый контроль. На этом шаге можно вернуть на доработку.
3. Отправлена клиенту. Согласованная внутри спецификация публикуется в кабинете контрагента, клиент получает уведомление.
4. Акцепт клиента. Уполномоченный представитель клиента подтверждает спецификацию в кабинете (или запрашивает изменения). Факт и время акцепта фиксируются.
5. Действует. Спецификация активна, её цены применяются к заказам, объёмы отслеживаются.
6. Архив. По истечении срока или при выпуске новой версии документ переводится в архив, оставаясь доступным для сверки.

Для заказа маршрут короче, но логика та же: «новый → на согласовании (проверка лимита, соответствия спецификации, наличия) → подтверждён → в отгрузке → отгружен». Подробно про сценарии согласования заказов и роли участников мы разбираем в отдельном материале: согласование заказов на B2B-портале.

Отдельного внимания заслуживают роли. Минимальный набор для опта: менеджер (создаёт документы), руководитель продаж (утверждает цены), финансовый контролёр (проверяет лимиты и дебиторку), представитель клиента (акцептует). У каждой роли — свой набор прав: кто может менять цену, кто только просматривает, кто акцептует. В 1С-Битрикс это ложится на группы пользователей и права доступа, а для клиентской стороны — на роли внутри контрагента (главный, закупщик, наблюдатель).

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

Печатные формы из данных заказа

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

Базовый набор форм для опта:

Технически формы можно готовить двумя путями. Первый — генерация на стороне сайта: шаблон формы (HTML/DOCX/PDF) заполняется данными заказа средствами Битрикса, клиент скачивает готовый файл из кабинета. Это быстро и удобно для счетов и коммерческих документов. Второй — получение готовых форм из 1С: бухгалтерская система формирует юридически выверенные счёт-фактуру, ТОРГ-12 и УПД, а обмен передаёт их на сайт, где кабинет просто отображает и отдаёт на скачивание. Для налоговых документов второй путь надёжнее, потому что 1С уже содержит корректные правила заполнения и учётные данные.

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

ЭДО и обмен юридически значимыми документами

Скачанный из кабинета PDF удобен, но юридической силы сам по себе не имеет. Чтобы документ был значимым, его подписывают квалифицированной электронной подписью и передают через оператора электронного документооборота (ЭДО). Здесь важно не путать «электронный документ в кабинете» и «юридически значимый электронный документ».

Как это связывается с B2B-кабинетом:

• Кабинет — интерфейс, ЭДО — юридический канал. Клиент видит и инициирует документы в кабинете, а фактический обмен подписанными версиями идёт через оператора ЭДО (Диадок, СБИС, Такском и другие).
• Статусы синхронизируются. Кабинет показывает состояние документа: «отправлен в ЭДО», «подписан контрагентом», «отклонён». Клиенту не нужно заходить в кабинет оператора, чтобы понять, что происходит.
• Подписание вне сайта. Как правило, квалифицированная подпись и обмен идут в системе оператора ЭДО, а сайт лишь отражает результат. Реже подписание встраивают прямо в кабинет через интеграцию с оператором.
• Роуминг между операторами. Если поставщик и клиент используют разных операторов ЭДО, документы ходят через роуминг — это стоит проверить на старте, иначе часть контрагентов «не увидит» документы.

Для большинства проектов практичный сценарий такой: юридически значимый документооборот ведётся в 1С через модуль ЭДО (1С-ЭДО), а B2B-кабинет на сайте отображает статусы и хранит копии для удобства клиента. Полноценно тему электронного документооборота и его связки с Битриксом мы разбираем отдельно: документооборот и ЭДО в B2B на 1С-Битрикс.

Хранение и версии документов

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

Принципы версионирования документов в B2B-кабинете:

• Новая редакция — новый элемент. Пересмотр спецификации не затирает старую, а создаёт новую версию со ссылкой на предыдущую. Прежняя переходит в статус «Архив».
• Метаданные на каждой версии. Номер, дата, автор изменения, срок действия, статус, ссылка на договор/заказ. По ним потом строятся сверки и отчёты.
• Действует ровно одна версия. В любой момент времени по каждой товарной группе действует одна редакция спецификации — именно её цены применяются. Остальные — черновики или архив.
• Неизменяемость архива. Архивная версия не редактируется — она свидетельство о том, на каких условиях работали в прошлом. Это критично для доказуемости при спорах и проверках.
• Привязка к отгрузкам. Заказ хранит ссылку на ту версию спецификации, по которой он оформлен. Тогда даже после смены цен видно, что конкретная отгрузка прошла по согласованным на тот момент условиям.

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

Обмен с 1С: номенклатура, цены, документы

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

• Номенклатура и её привязка к договору. Из 1С приходит каталог, включая признаки того, какие позиции доступны конкретному контрагенту по его договору. Ограничение ассортимента формируется в 1С и отражается на сайте.
• Цены по типам и индивидуальные цены. Типы цен договоров и индивидуальные цены по спецификациям ведутся в 1С и выгружаются на сайт. Именно поэтому кабинет показывает клиенту его цены — они пришли из учётной системы.
• Контрагенты и договоры. Реквизиты контрагентов, список договоров, их условия (отсрочка, лимит, статус) синхронизируются, чтобы кабинет и 1С видели одну картину.
• Документы. Счета, счета-фактуры, накладные, УПД, сформированные в 1С, передаются на сайт для отображения в кабинете. В обратную сторону идут заказы, оформленные клиентом.
• Статусы и оплаты. Оплаты, отгрузки, состояние взаиморасчётов приходят из 1С, чтобы клиент в кабинете видел актуальный баланс и статус своих заказов.

Технически обмен строится на штатном протоколе обмена Битрикс — 1С (CommerceML) и его расширениях либо на кастомной интеграции через REST, если стандартного формата не хватает для договоров и спецификаций. Практически всегда стандартный обмен покрывает товары, цены и заказы, а договоры, спецификации и документы требуют доработки формата — потому что «из коробки» этих сущностей в обмене нет. Планировать эту доработку нужно заранее, а не после запуска витрины.

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

Реализация в 1С-Битрикс пошагово

Соберём всё вышесказанное в практический порядок внедрения. Это укрупнённый план, по которому мы обычно ведём проекты B2B-кабинета с договорами и спецификациями.

1. Спроектируйте модель данных. Определите сущности: контрагенты, договоры, спецификации, документы, заказы. Решите, что живёт в инфоблоках, что в highload-блоках, что в модуле Sale. Зафиксируйте связи и правило приоритета цен.
2. Настройте типы цен и права. Заведите типы цен под договоры, группы пользователей под роли (менеджер, руководитель, финконтроль), роли внутри контрагента для клиентской стороны.
3. Создайте инфоблоки договоров и спецификаций. Со свойствами «контрагент», «тип цены», «срок действия», «статус», «версия» и структурированным перечнем позиций у спецификации.
4. Реализуйте применение цен. Логика, которая при показе каталога и расчёте корзины берёт цену из действующей спецификации, а при её отсутствии — из типа цены договора.
5. Постройте маршрут согласования. Статусная модель для спецификаций и заказов, права на переходы по ролям, обработчики уведомлений (почта, кабинет, мессенджер). При сложной логике — на бизнес-процессах.
6. Подключите генерацию печатных форм. Шаблоны счёта и коммерческих документов на стороне сайта; приём готовых счёта-фактуры, ТОРГ-12 и УПД из 1С.
7. Настройте обмен с 1С. Товары, цены, контрагенты, договоры, документы, заказы. Доработайте формат обмена под договоры и спецификации, предусмотрите обработку ошибок.
8. Свяжите ЭДО. Отображение статусов документов из оператора ЭДО в кабинете, хранение копий, при необходимости — инициация обмена.
9. Настройте хранилище документов и версии. Инфоблок «Документы» с версионированием, привязкой к заказам и договорам, статусами «действует/архив».
10. Протестируйте на реальном контрагенте. Пройдите весь путь: договор → спецификация → согласование → заказ → печатные формы → ЭДО → сверка. Проверьте цены, лимиты, уведомления и документы на боевых данных.

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

Юридические нюансы

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

• Юридическая сила документа. PDF, скачанный из кабинета, — копия для удобства, а не оригинал. Юридически значимы либо бумажные документы с «живой» подписью и печатью, либо электронные, подписанные квалифицированной электронной подписью через ЭДО.
• Акцепт условий. Подтверждение спецификации кликом в кабинете само по себе не всегда равнозначно подписи. Чтобы электронный акцепт имел вес, порядок его совершения стоит закрепить в рамочном договоре (условие о признании действий в кабинете) либо вести акцепт через ЭДО.
• Реквизиты и НДС. В печатных формах должны быть корректные реквизиты сторон, правильные ставки НДС и суммы. Ошибка в счёте-фактуре — это уже налоговый риск, поэтому их и формируют в 1С.
• Сроки хранения. Первичные документы и счета-фактуры хранятся установленный законом срок. Архив кабинета и 1С должен это обеспечивать, а не «затирать» старые документы.
• Персональные данные. Кабинет обрабатывает данные представителей контрагентов — это персональные данные, требующие согласия и защиты по 152-ФЗ.
• Доказуемость версий. При споре важно показать, какая редакция спецификации действовала на дату отгрузки. Отсюда требование неизменяемости архива и привязки заказа к версии.

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

Кабинет, ЭДО и почта — что для чего

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

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

Частые ошибки

• «Зашивают» индивидуальные цены прямо в профиль клиента без понятия спецификации — при первом же пересмотре цен и появлении разных условий по группам товаров модель ломается.
• Хранят спецификацию только как PDF-файл, а не как структурированные данные — цены нельзя применить автоматически, а заказ невозможно проверить на соответствие.
• Не версионируют документы — теряют историю и не могут доказать, какая редакция действовала на дату отгрузки.
• Считают, что скачанный из кабинета PDF юридически значим — на сверке и при споре выясняется, что подписанной версии нет.
• Генерируют счёт-фактуру и УПД самописно на сайте вместо получения из 1С — формы расходятся с бухгалтерией и создают налоговые риски.
• Не прописывают приоритет источников цен — менеджеры и клиенты спорят, почему в корзине «не та» цена.
• Забывают про роуминг ЭДО — часть контрагентов на другом операторе не получает документы.
• Не планируют доработку обмена под договоры и спецификации — стандартный обмен эти сущности «не знает», и после запуска витрины всё приходится переделывать.

Чек-лист внедрения

Сведём готовность B2B-кабинета в области договоров и спецификаций в практический список для приёмки перед запуском:

1. Модель разведена. Договор, спецификация и заказ — отдельные сущности с разным жизненным циклом; связи и правило приоритета цен зафиксированы.
2. Цены привязаны к договору. Тип цены на уровне договора, индивидуальные цены — на уровне спецификации; каталог показывает клиенту его цены.
3. Спецификация структурирована. Перечень позиций хранится как строки с ценами, а не как PDF; заказ проверяется на соответствие.
4. Маршрут согласования работает. Статусы, роли, права на переходы и адресные уведомления настроены и протестированы.
5. Печатные формы формируются. Счёт — на сайте; счёт-фактура, ТОРГ-12, УПД — из 1С; клиент скачивает всё из кабинета.
6. ЭДО подключён. Статусы подписания видны в кабинете, роуминг между операторами проверен.
7. Версии хранятся. Инфоблок документов с версионированием, неизменяемым архивом и привязкой заказа к версии спецификации.
8. Обмен с 1С настроен. Товары, цены, контрагенты, договоры, документы и заказы синхронизируются; ошибки обмена обрабатываются.
9. Юридическая часть согласована. Порядок акцепта, набор документов и правила подписания проверены юристом и бухгалтерией.
10. Проверено на боевом контрагенте. Пройден весь путь от договора до сверки на реальных данных.

Вывод

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