← На главную

В современных конфигурациях 1С, таких как Управление торговлей 11, механизмы взаиморасчетов вынесены в специализированные подсистемы. Часто у пользователей и разработчиков возникает закономерный вопрос: можно ли «подсветить» в журнале документов Реализация товаров и услуг те записи, которые еще не были полностью оплачены клиентом? Рассмотрим, почему это нельзя сделать «в два клика» через стандартное условное оформление и какие методы позволяют реализовать эту задачу грамотно.

Почему стандартное условное оформление не подходит?

Многие привыкли к тому, что в старых версиях 1С или в простых отчетах можно легко вывести колонку «Оплачено» через простое соединение таблиц. Однако в УТ 11 архитектура данных устроена иначе:

• Данные о взаиморасчетах хранятся в регистрах накопления, например, в РасчетыСКлиентами.
• Динамический список, на котором базируется журнал документов, — это высоконагруженный объект. Если мы добавим в его запрос левое соединение с регистрами взаиморасчетов для каждой строки, система начнет пересчитывать остатки долга при каждом обновлении или прокрутке списка.
• Это неизбежно приведет к «тормозам» интерфейса, особенно если в базе данных накоплено большое количество документов за несколько лет работы.

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

Метод 1: Использование дополнительного реквизита и подписки на событие

Это наиболее надежный способ сохранить быстродействие интерфейса. Вместо того чтобы вычислять статус оплаты «на лету» при открытии журнала, мы предлагаем сохранять этот статус непосредственно в документе.

1. Создание реквизита: Добавьте в документ Реализация товаров и услуг дополнительный реквизит, например, СтатусОплаты (булево или перечисление).
2. Подписка на событие: Создайте Подписку на событие (например, ПриЗаписи или ОбработкаПроведения) для документов, которые влияют на взаиморасчеты (Реализация, Приходный кассовый ордер, Списание безналичных денежных средств).
3. Актуализация данных: Внутри обработчика подписки при изменении оплат вызывайте процедуру, которая пересчитывает сумму долга по конкретному документу-основанию и записывает результат в ваш новый реквизит.

Теперь, когда данные об оплате хранятся прямо в табличной части документа, условное оформление будет работать мгновенно:

Условие: СтатусОплаты = Ложь

Оформление: Цвет текста = Красный или Цвет фона = Розовый.

Метод 2: Создание регистра сведений

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

Рассмотрим по шагам логику работы этого метода:

• Создайте независимый Регистр сведений (назовем его, например, СостояниеОплатыДокументов), где измерением будет Реализация товаров и услуг, а ресурсом — СуммаОстатка или ПроцентОплаты.
• При каждом проведении документов оплаты или реализации, записывайте в этот регистр актуальное состояние.
• В Динамическом списке журнала документов используйте левое соединение с этим регистром. Поскольку регистр сведений — это плоская таблица, запрос к нему будет выполняться значительно быстрее, чем к сложным регистрам накопления, что позволит избежать критических задержек.

Рекомендации по анализу данных

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

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

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