Рамочный договор в CRM: лимит есть, конкретной поставки ещё нет

Лимит договора на 1000 единиц часто путают с заказом на 1000, и остаток в CRM начинает означать не то, что думает менеджер. Ниже — как развести потолок, заявку и фактическую поставку, чтобы черновик не съедал лимит, а возврат не восстанавливал его сам.

Рамочный договор задаёт потолок и порядок выбора объёма, а заявка описывает конкретное намерение внутри него. Остаток считается только по правилу компании: какие состояния заявок входят в выборку. Черновики и отменённые обычно не входят, возврат не всегда восстанавливает лимит. Лимит в деньгах и в единицах ведёт себя по-разному, а истёкший договор требует отдельного решения.

В условном отделе продаж менеджер открывает договор с лимитом 1000 единиц и заявку клиента на 150 единиц. В CRM рядом видны договор, заявка и остаток, но это три разные сущности. Если склеить их в одну строку, следующий сотрудник решит, что поставка согласована, хотя принята только заявка.

Рамочный договор задаёт потолок и порядок, по которому компания готова выбирать объём. Заявка описывает конкретное намерение внутри этого потолка. Остаток появляется только тогда, когда правило компании говорит, какие состояния заявок считаются выборкой. Без такого правила любая цифра на экране выглядит убедительно и ничего не доказывает.

Рамочный лимит и заявка — разные обязательства

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

Условный пример: договор с лимитом 1000 единиц, приняты заявки на 100 и 150. Выборка — 250, условный остаток — 750, если правило считает именно принятые заявки. Черновик на 300 в эту арифметику не входит; отменённая заявка выходит, если правило разрешает освобождать объём. Это не юридический вывод, а проверка учётной логики.

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

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

Карточка договора: потолок, база и состояние

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

В описании соглашений о продажах Microsoft Dynamics 365 Supply Chain встречается разделение соглашения и заказа. Это полезный словарь для обсуждения, но он не доказывает, что в вашем контуре уже есть такие объекты. Свою модель лучше описывать через проверяемые поля, а не через название чужого модуля.

| Поле карточки договора | Что храним | Что проверяем |

|---|---|---|

| Идентификатор и стороны | Номер договора, контрагент, подразделение, ответственный. | Совпадают ли стороны и подразделение с заявкой; нет ли дубля карточки. |

| Лимит и единица | Потолок в единицах, часах, деньгах или другой мере; валюта и оговорка про НДС, если она есть в документе. | Одна ли единица у лимита и заявки; не смешаны ли упаковки и штуки. |

| База расчёта | Что считается выборкой: принятые заявки, отгрузки, подписанные акты или иная база по документам. | Может ли сотрудник показать правило и основание, а не «так исторически сложилось». |

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

| Связанные заявки | Ссылки на заявки и их состояния, а не только сумма. | Видно ли, какие заявки уже учтены, а какие ещё черновики. |

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

Заявка — самостоятельный объект, а не строка договора

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

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

| Поле заявки | Что храним | Зачем проверять |

|---|---|---|

| Номер и версия | Идентификатор заявки, версия, автор, дата. | Можно ли отличить черновик от принятой версии и не потерять историю. |

| Ссылка на договор | Договор и правило лимита, по которому считаем. | Не подменена ли база: единицы, деньги, часы. |

| Предмет | Товар, работа или услуга, количество, единица. | Совпадает ли единица с лимитом; нет ли пересчёта упаковок. |

| Цена и условия | Цена, скидка, срок, место исполнения, источник условия. | На каком основании цена считается действующей. |

| Состояние | Черновик, на согласовании, принята, отменена, исполнена, закрыта. | Кто и по какому правилу меняет состояние. |

| Согласование | Кто утвердил исключение, превышение или изменение цены. | Есть ли именное решение, а не безликая отметка. |

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

Черновая заявка не должна уменьшать остаток

Условный эпизод. Договор с лимитом 1000 единиц. Менеджер А создаёт черновик на 100 единиц и уходит на встречу. Менеджер Б создаёт черновик на 150 единиц и видит в интерфейсе «остаток 750». Он обещает клиенту поставку, хотя ни одна заявка ещё не принята. Если черновики считаются выборкой, остаток выглядит меньше, чем реально доступно для решения; если не считаются, но интерфейс не различает состояния, менеджер всё равно ошибается.

Правило проекта: черновик показывает намерение, но не уменьшает доступный лимит. В строке заявки нужны как минимум три величины: лимит договора, принятая выборка и черновики отдельно. Тогда сотрудник видит «лимит 1000, принято 0, в черновиках 250, доступно для принятия 1000». После принятия первой заявки на 100 появляется «принято 100, доступно 900»; второй черновик по-прежнему не съедает лимит.

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

Отмена заявки и возврат товара не одно и то же

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

| Событие | Что меняется в заявке | Что проверяем в лимите |

|---|---|---|

| Черновик создан | Появилась версия намерения. | Не считается ли черновик выборкой; виден ли он отдельно. |

| Заявка принята | Появилось основание для исполнения. | По какому правилу объём входит в выборку. |

| Заявка отменена до исполнения | Состояние меняется на отменённое. | Освобождается ли объём и кто это подтверждает. |

| Заявка исполнена | Появилась фактическая поставка или акт. | Не подменяет ли факт исполнения договорный лимит. |

| Товар возвращён | Появилось обратное движение. | Восстанавливает ли правило лимит; не решаем это по названию операции. |

| Цена изменена | Меняется сумма, но не всегда количество. | В какой мере лимита считаем: единицы или деньги. |

| Договор истёк | Меняется состояние договора. | Блокируются ли новые заявки; что делать с уже принятыми. |

Самый неприятный случай — возврат, который все считают автоматическим восстановлением. Сотрудник видит вернувшийся товар и снова обещает объём, а правило лимита считает выборкой отгрузки. Тогда остаток в CRM и ожидание менеджера расходятся. Лечится это не цветом кнопки, а явным правилом и журналом событий.

Цена выросла: лимит в деньгах и лимит в единицах ведут себя по-разному

Условный эпизод. Договор с лимитом 1 000 000 условных рублей. Принята заявка на 100 единиц по 5 000 рублей, то есть на 500 000. Поставщик повышает цену до 6 000 рублей. Если лимит считается в деньгах, та же заявка теперь занимает 600 000, и остаток меняется без изменения количества. Если лимит считается в единицах, выборка остаётся 100 единиц, а деньги влияют только на сумму заявки.

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

Если лимит в деньгах

Нужны валюта, источник цены и момент фиксации. Цена может быть в документе, в согласованном приложении или в правиле компании; это проверяет уполномоченный сотрудник. CRM показывает основание и версию, а не «среднюю цену по опыту».

Если лимит в единицах

Деньги не должны незаметно менять количество. Но цена всё равно важна для согласования: заявка может превысить не лимит единиц, а полномочия менеджера по скидке. Это отдельное правило, и его не стоит прятать в тот же остаток.

Истёкший договор: проверить основания новых и старых заявок

Условный эпизод. Договор действует до 31 декабря. 20 декабря принята заявка на поставку в феврале. 1 января карточка договора становится истёкшей. Если система автоматически отменяет всё, что связано с договором, компания теряет принятое обязательство и начинает объясняться с клиентом. Если система не замечает состояние, менеджер продолжает создавать новые заявки по истёкшему основанию.

Проектное правило мягче и честнее: новые заявки по истёкшему договору блокируются до проверки; уже принятые не исчезают, а получают отметку «требует решения». Уполномоченный сотрудник смотрит применимые документы и решает, что делать с конкретной заявкой. CRM не должна изображать юриста и сама решать судьбу обязательства.

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

Заявка превышает остаток: четыре честных исхода

Условный эпизод. Условный остаток по договору — 750 единиц. Клиент просит 800. Красивое решение «поставить минус 50» выглядит как гибкость, но прячет исключение. После него остаток становится отрицательным, а следующий сотрудник не понимает, это ошибка ввода или согласованное превышение.

| Исход | Что фиксируем | Чего не делаем |

|---|---|---|

| Отказ | Причина отказа и дата решения. | Не оставляем заявку в подвешенном состоянии без владельца. |

| Дробление | Две заявки: 750 сейчас и 50 после изменения основания. | Не считаем вторую часть автоматически принятой. |

| Согласованное исключение | Кто утвердил, на каком основании, до какой даты действует. | Не прячем исключение в комментарии без полномочий. |

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

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

Интерфейс сотрудника: лимит, выборка, остаток и причина

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

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

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

Трудные исключения: единицы, несколько мест и дубли

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

| Исключение | Риск | Правило проверки |

|---|---|---|

| Упаковка и штука | Лимит в штуках, заявка в упаковках. | Показывать коэффициент пересчёта и источник; не округлять молча. |

| Несколько мест исполнения | Одна заявка закрывает разные точки. | Считать лимит по договору, а не по складу; место показывать отдельно. |

| Дубли заявок | Два менеджера создали почти одинаковую заявку. | Искать совпадение по договору, предмету, количеству и дате; не склеивать автоматически. |

| Одновременное согласование | Две заявки проходят почти в одну секунду. | Показывать актуальный остаток на момент решения; конфликт не прятать. |

| Замена предмета | Один товар заменили другим. | Проверять, та же ли единица лимита и не нужен ли новый документ. |

| Ручная правка лимита | Кто-то исправил число в карточке. | Хранить автора, дату и основание; не позволять безымянную правку. |

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

Проверки на демо: сценарии, которые ломают красивую таблицу

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

| Проверка | Вход | Ожидаемое поведение |

|---|---|---|

| Черновик | Создать черновик на 120 при лимите 480. | Принятая выборка не меняется; черновик виден отдельно. |

| Отмена | Отменить принятую заявку на 30. | Объём освобождается только по явному правилу; причина видна. |

| Возврат | Вернуть исполненную поставку. | Лимит не восстанавливается автоматически без правила и подтверждения. |

| Цена | Изменить цену принятой заявки. | Видно, пересчитывается ли денежный лимит и с какой даты. |

| Истечение | Открыть истёкший договор. | Новые заявки блокируются с причиной; старые не исчезают. |

| Превышение | Запросить больше остатка. | Появляется выбор исхода, а не отрицательный остаток. |

| Дубль | Создать почти одинаковую заявку. | Система предупреждает или показывает совпадение; решение остаётся за сотрудником. |

| Единицы | Смешать упаковки и штуки. | Пересчёт виден; молчаливого округления нет. |

После каждой проверки полезно задать один вопрос: «Кто может объяснить это число, не открывая переписку?» Если ответ «только автор настройки», процесс ещё не готов к работе.

Практикум на другом примере: 480 часов и четыре заявки

Возьмём условный договор на 480 часов работ. Это не расчёт стоимости и не обещание поставки, а проверка учётной логики. В договоре сказано, что выборкой считаются принятые заявки; черновики и отменённые не входят. Уполномоченный сотрудник подтвердил это правило по документам — в статье мы не выводим его из названия договора.

| Заявка | Состояние | Входит в выборку | Комментарий |

|---|---|---|---|

| 60 часов | Принята | Да | Первая часть выбранного объёма. |

| 90 часов | Принята | Да | Выборка становится 150. |

| 120 часов | Черновик | Нет | Намерение, а не обязательство. |

| 30 часов | Отменена | Нет | Освобождает объём, если правило это разрешает. |

При таком правиле выборка — 150 часов, условный остаток — 330. Если интерфейс показывает 210, он, скорее всего, посчитал черновик. Если показывает 360, он мог не учесть отмену или применить другое правило. Разница не в арифметике, а в том, какие состояния считаются выборкой.

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

Один шаг проверки

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

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

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