Кредитные лимиты и отсрочка платежа для B2B-портала на 1С-Битрикс

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

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

Зачем оптовикам отсрочка и кредитный лимит

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

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

Кредитный лимит — это способ разрешить отсрочку, но ограничить риск. Он отвечает на вопрос «какую максимальную сумму долга мы готовы держать на этом контрагенте одновременно». Лимит назначается индивидуально и опирается на историю платежей, обороты, надёжность клиента и договорённости с финансовым отделом. Новому клиенту дают маленький лимит или не дают вовсе, проверенному — большой. Отсрочка отвечает на второй вопрос — «за какой срок клиент обязан закрыть конкретную поставку». Вместе эти два параметра описывают всю политику товарного кредитования.

Модель данных: лимит, сальдо, отсрочка

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

Минимальный набор полей, который нужно завести на контрагента:

Технически на стороне Битрикса эти атрибуты удобно держать в свойствах профиля контрагента или в отдельной служебной таблице (highload-блок либо своя таблица через ORM D7). Плоские значения — лимит, сальдо, срок — можно вынести в свойства; детализацию по документам (какой заказ, на какую сумму, до какого числа отсрочка) лучше хранить в отдельной таблице строк, потому что их много и они регулярно обновляются обменом.

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

Как считается доступный остаток лимита

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

Базовая формула такая:

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

Разберём на примере. Лимит контрагента — 1 000 000 ₽. Сальдо из 1С (отгружено и не оплачено) — 600 000 ₽. На портале висит оформленный, но не отгруженный заказ на 60 000 ₽. Тогда доступный остаток = 1 000 000 − 600 000 − 60 000 = 340 000 ₽. Новый заказ на 400 000 ₽ не пройдёт: он превышает остаток на 60 000 ₽. Заказ на 300 000 ₽ пройдёт и уменьшит остаток до 40 000 ₽.

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

Проверка лимита при оформлении заказа

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

Ключевые точки для обработчика:

• OnSaleOrderBeforeSaved — срабатывает до сохранения заказа. Здесь можно отменить сохранение, если лимит превышен, вернув ошибку в результат события. Это основной рубеж.
• OnSaleOrderSaved — после сохранения. Удобно, чтобы поставить заказу нужный статус («на согласовании») или записать в него факт превышения и одобрения.
• Событие смены статуса оплаты/отгрузки — чтобы пересчитывать сумму «заказов в работе» и корректно освобождать остаток лимита, когда заказ оплачен или отменён.

Логика обработчика на OnSaleOrderBeforeSaved по шагам:

1. Определите контрагента заказа. По пользователю и выбранному профилю плательщика найдите юрлицо, к которому привязаны лимит и сальдо. Если отсрочка контрагенту не разрешена — пропускаем проверку (он платит по предоплате) или требуем предоплатный способ оплаты.
2. Проверьте способ оплаты. Проверка лимита нужна только для оплаты «в кредит» (по счёту с отсрочкой). Если клиент выбрал предоплату, лимит не трогаем — деньги придут вперёд товара.
3. Посчитайте доступный остаток. Возьмите лимит, вычтите сальдо из 1С и сумму других незакрытых заказов портала этого контрагента.
4. Проверьте просрочку. Пробегитесь по реестру открытых документов: есть ли отгрузки с истёкшим сроком отсрочки. Если есть — блокировка по просрочке.
5. Сравните с суммой заказа. Если сумма нового заказа больше доступного остатка — превышение лимита.
6. Примите решение. В зависимости от политики: заблокировать оформление с сообщением, либо разрешить сохранить, но перевести в статус «на согласовании» для менеджера.

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

Блокировка заказов при превышении и просрочке

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

Разделяйте две причины блокировки, потому что выходы из них разные:

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

• Мягкая (на согласование). Заказ сохраняется, но не уходит в работу — переходит в статус «на согласовании» и ждёт решения менеджера. Клиент видит, что заказ принят, но требует подтверждения. Подходит для проверенных клиентов и небольших превышений.
• Жёсткая (запрет оформления). Заказ не сохраняется вовсе, пока не устранена причина. Подходит для просрочки и для новых, непроверенных контрагентов.
• Предупреждающая (порог внимания). Заказ проходит, но клиент видит предупреждение «вы приблизились к лимиту, осталось N ₽». Это не блокировка, а забота — помогает клиенту планировать закупки и не упереться в стену неожиданно.

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

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

Контроль дебиторской задолженности

Дебиторская задолженность — это деньги, которые вам должны за уже отгруженный товар. Управлять ею — значит видеть её структуру: сколько всего должны, кто именно, какая часть в пределах срока, а какая просрочена и на сколько дней. B2B-портал даёт удобную витрину для этой картины, если правильно организовать реестр открытых документов.

Практический инструмент контроля — реестр дебиторки с разбивкой по срокам (aging report, «отчёт по срокам задолженности»). Он группирует долг по «возрасту»: текущий (в пределах отсрочки), просрочка 1–7 дней, 8–30 дней, свыше 30 дней. Такая разбивка сразу показывает проблемные зоны: небольшая свежая просрочка — рабочий момент, а долги старше месяца — сигнал к жёстким мерам.

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

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

Обмен взаиморасчётами и балансом с 1С

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

Что именно выгружается из 1С:

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

Технически обмен на 1С-Битрикс обычно строят одним из способов: через типовой протокол обмена CommerceML (расширяя выгрузку взаиморасчётами), через отдельный REST/HTTP-сервис, отдающий баланс по запросу, или через промежуточную интеграционную шину. Для большинства проектов достаточно расширить существующий обмен товарами и заказами дополнительным пакетом взаиморасчётов, который принимает свой обработчик на стороне сайта и раскладывает данные по свойствам контрагента и таблице открытых документов.

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

Настройка обмена взаиморасчётами — часть более широкой работы по связке сайта и учётной системы. Общие принципы такой интеграции, форматы и типовые грабли мы разбираем в услуге по интеграциям с 1С и внешними системами.

Отображение баланса и лимита в личном кабинете

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

Что стоит вывести в кабинете:

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

Важна и точка контакта прямо в корзине. Когда клиент собирает заказ, полезно показывать доступный остаток лимита тут же: «Доступно по лимиту: 340 000 ₽. Ваш заказ: 300 000 ₽». Тогда превышение не станет неприятным сюрпризом на последнем шаге оформления — клиент видит границу заранее и планирует закупку под неё. Это та же серверная величина, что проверяется при сохранении, просто показанная раньше.

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

Уведомления о лимите и просрочке

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

Набор полезных триггеров:

Технически уведомления удобно строить на агентах и событиях Битрикса. Регулярный агент раз в сутки пробегает по реестру дебиторки, находит контрагентов, приблизившихся к лимиту или к сроку оплаты, и рассылает напоминания по почтовым шаблонам (событиям почтовых событий модуля main). Событийные уведомления (заказ на согласовании, наступление просрочки) шлются в момент действия. Если у поставщика есть Битрикс24, менеджерские оповещения удобно заводить туда как задачи или уведомления — тогда работа с дебиторкой встроена в CRM.

Сценарии частичной отгрузки

В опте редко бывает, что заказ отгружается целиком и разом. Часть позиций есть на складе, часть под заказ, что-то отгружается сегодня, что-то через неделю. Частичная отгрузка ломает наивную модель «заказ = долг» и требует аккуратной работы с лимитом и дебиторкой. Разберём, что меняется.

Ключевая идея: долг возникает не в момент оформления заказа, а в момент отгрузки. Пока товар не уехал, юридически долга нет — есть обязательство поставщика отгрузить. Поэтому в дебиторку попадает не сумма заказа, а сумма фактической отгрузки. Если заказ на 100 000 ₽ отгрузили наполовину, в долг встают 50 000 ₽, а не 100 000 ₽. Срок отсрочки по этой части считается от даты именно этой отгрузки.

Отсюда следствия для механики лимита:

• «Заказ в работе» и «отгружено» — разные суммы. В расчёте доступного остатка неотгруженная часть заказа держится как «в работе» (резервирует лимит), а отгруженная часть переходит в дебиторку (сальдо из 1С).
• Несколько сроков по одному заказу. Разные отгрузки одного заказа могут иметь разные даты и, значит, разные сроки оплаты. Реестр дебиторки ведётся по отгрузкам-документам, а не по заказам, — тогда сроки считаются корректно.
• Частичная оплата. Клиент может оплатить одну отгрузку и не оплатить другую. Долг и просрочка считаются по каждому документу отдельно, а в кабинете суммируются.

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

Роли: менеджер одобряет превышение

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

Типовой набор ролей в кредитной механике:

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

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

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

Сведём архитектуру в конкретные модули и шаги на платформе. Кредитная механика на 1С-Битрикс собирается из штатных кирпичей — событий модуля sale, хранилища на свойствах и ORM, обмена и почтовых событий. Ничего экзотического не требуется, важна аккуратная сборка.

1. Хранилище атрибутов контрагента. Заведите поля «Кредитный лимит», «Сальдо», «Срок отсрочки», «Отсрочка разрешена», «Дата обмена» — на свойствах профиля плательщика или в highload-блоке. Реестр открытых документов вынесите в отдельную таблицу через ORM D7 (класс DataManager).
2. Обработчик проверки лимита. Зарегистрируйте обработчик на событие sale:OnSaleOrderBeforeSaved (и вспомогательный на OnSaleOrderSaved). В нём считайте доступный остаток и просрочку, принимайте решение о блокировке или согласовании.
3. Статусы заказа. Добавьте статус «На согласовании (превышение лимита)» и, при необходимости, «Заблокирован (просрочка)». Настройте, какие статусы уходят в работу, а какие ждут менеджера.
4. Обмен взаиморасчётами. Расширьте обмен с 1С пакетом взаиморасчётов: приём сальдо, открытых документов, оплат и лимитов. Обработчик приёма должен быть идемпотентным по идентификаторам из 1С. Повесьте обмен на агент/крон и, для оплат, на событийную передачу.
5. Личный кабинет. Выведите виджет баланса, реестр документов, историю оплат и доступный остаток в корзине. Данные берите из хранилища, обновляемого обменом.
6. Уведомления. Настройте почтовые/пуш-события: приближение к лимиту, скорый срок оплаты, просрочка, заказ на согласовании. Регулярные — на агенте, событийные — по факту действия.
7. Роли и права. Разграничьте, кто видит дебиторку, кто одобряет превышение и до какой суммы. Логируйте одобрения.

Схематично интерфейс менеджера с карточкой согласования превышения выглядит так:

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

Безопасность и права доступа

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

• Изоляция данных контрагента. Пользователь видит баланс, лимит и документы только своего контрагента. Проверяйте принадлежность на сервере при каждом запросе, а не полагайтесь на то, что «в интерфейсе чужого не показываем».
• Только серверная проверка лимита. Как уже сказано, решение о блокировке принимается в обработчике события, а не в браузере. Любые клиентские подсказки — вспомогательные.
• Лимит меняется только уполномоченными. Ни клиент, ни рядовой менеджер не должны иметь возможности поднять себе лимит. Изменение лимита — операция финконтролёра, желательно из 1С, с журналированием.
• Журналирование финансовых действий. Одобрения превышений, ручные изменения лимита, снятия блокировок — всё логируется с автором и временем.
• Защита обмена. Канал обмена с 1С аутентифицируется, данные передаются по защищённому соединению; сервис баланса не отдаёт данные без авторизации.
• Идемпотентность и валидация. Приём оплат и сальдо проверяет корректность и не задваивает записи, чтобы сбой связи не «простил» клиенту долг и не создал фантомную переплату.

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

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

• Считают баланс на портале самостоятельно из заказов Битрикса вместо приёма сальдо из 1С — цифры расходятся с бухгалтерией, клиент не верит кабинету.
• Проверяют лимит только на JavaScript в корзине — проверку легко обойти, и клиент набирает долгов сверх лимита.
• Не вычитают из доступного остатка заказы «в работе» — клиент за день оформляет несколько заказов, каждый в пределах лимита, а в сумме выносит его.
• Ведут дебиторку по заказам, а не по отгрузкам — частичные отгрузки и разные сроки оплаты считаются неверно.
• Блокируют молча: «Ошибка, заказ не сохранён» без причины и цифр — клиент не понимает, что делать, и уходит.
• Не блокируют при просрочке, пока не выбран лимит — долг растёт на клиенте, который уже нарушил сроки.
• Обмен балансом идёт раз в сутки без событийной передачи оплат — клиент оплатил, а блокировка снимется только ночью.
• Не логируют одобрения превышений — при невозврате невозможно понять, кто принял решение о риске.
• Дают менеджеру или клиенту право менять лимит — теряется весь смысл контроля.
• Не показывают дату актуальности баланса — клиент видит устаревшие цифры и спорит с менеджером.

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

Сведём всё в практический список, по которому удобно принимать готовность кредитной механики перед запуском:

1. Модель данных заведена. На контрагенте есть лимит, сальдо, срок отсрочки, признак разрешения отсрочки; реестр открытых документов — в отдельной таблице.
2. Формула остатка зафиксирована. Доступный остаток = лимит − дебиторка − заказы в работе; одинаково применяется на портале и в отчёте менеджера.
3. Проверка на сервере. Лимит и просрочка проверяются в обработчике события sale, а не только в браузере.
4. Сценарии блокировки описаны. Понятно, когда заказ блокируется, когда уходит на согласование, что видит клиент и как выйти из ситуации.
5. Обмен с 1С настроен. Приходят сальдо, документы, оплаты, лимиты; обмен идемпотентен; оплаты передаются событийно или часто.
6. Кабинет показывает баланс. Виджет лимита, реестр документов, история оплат, доступный остаток в корзине, дата актуальности.
7. Уведомления работают. Приближение к лимиту, скорый срок оплаты, просрочка, заказ на согласовании — по нужным каналам.
8. Частичная отгрузка учтена. Долг растёт по факту отгрузки, дебиторка ведётся по документам с индивидуальными сроками.
9. Роли и одобрения. Настроено, кто одобряет превышение и до какой суммы; одобрения логируются.
10. Безопасность проверена. Изоляция данных контрагента, серверные проверки, защищённый обмен, журнал финансовых действий.

Вывод

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