Разберем две важные задачи, с которыми часто сталкиваются разработчики и руководители проектов 1С: раскраска строк динамического списка в зависимости от внешних данных и аргументированное обоснование решений по складскому учету. Мы рассмотрим несколько подходов к решению первой проблемы, включая обход ограничений расширений, а также проанализируем, как убедить руководство в целесообразности или нецелесообразности отказа от ордерной схемы и ячеистого склада.
Автор столкнулся с задачей раскрасить строки динамического списка в зависимости от количества строк табличной части связанного документа. Для этого было выбрано событие динамического списка СписокПриПолученииДанныхНаСервере. Однако при попытке перенести этот обработчик в расширение возникают сложности: либо EDT выдает ошибку "не поддерживается создание расширения для события формы, связанного с несколькими элементами", либо после добавления через конфигуратор метод не отрабатывает, и точка останова не достигается.
Прежде всего, давайте выясним, что может быть причиной невозможности работы с событием ПриПолученииДанныхНаСервере в расширении. Поддержка расширений для обработчиков событий формы, таких как ПриПолученииДанныхНаСервере, была существенно улучшена в более поздних версиях платформы 1С:Предприятие. В частности, полноценная поддержка данного события в расширениях доступна начиная с версии платформы 8.3.10.
Мы рекомендуем проверить:
Если версия платформы соответствует требованиям, а проблема сохраняется, возможно, дело в особенностях создания обработчика в расширении. Попробуйте добавить пустой обработчик в расширение через конфигуратор (не через EDT), а затем уже в EDT наполнить его логикой. Иногда такой подход позволяет обойти ограничения EDT.
Самый типовой и производительный способ раскраски строк динамического списка – это использование условного оформления. Для этого вам потребуется поле, содержащее необходимую информацию (в данном случае – количество строк табличной части), которое будет доступно в динамическом списке. Мы рассмотрим несколько вариантов подготовки таких данных.
Чтобы использовать условное оформление, нам нужно "служебное" поле, которое будет содержать данные для условия раскраски. Это поле может быть булевым (истина/ложь), числовым (собственно, количество строк) или текстовым (например, "много", "мало").
Вариант A: Добавление поля в запрос динамического списка
Мы можем включить расчет количества строк непосредственно в текст запроса основного динамического списка. Это позволяет получить все данные за один запрос, однако при работе с большими таблицами или сложными связями может негативно сказаться на производительности.
Предположим, у нас есть список документов, и мы хотим раскрасить его строки в зависимости от количества строк в табличной части "Товары".
ВЫБРАТЬ
ДокументСсылка.Ссылка КАК Ссылка,
ДокументСсылка.Номер КАК Номер,
ДокументСсылка.Дата КАК Дата,
КОЛИЧЕСТВО(ДокументТабличнаяЧасть.НомерСтроки) КАК КоличествоСтрокТЧ
ИЗ
Документ.ИмяВашегоДокумента КАК ДокументСсылка
ЛЕВОЕ СОЕДИНЕНИЕ Документ.ИмяВашегоДокумента.Товары КАК ДокументТабличнаяЧасть
ПО ДокументСсылка.Ссылка = ДокументТабличнаяЧасть.Ссылка
СГРУППИРОВАТЬ ПО
ДокументСсылка.Ссылка,
ДокументСсылка.Номер,
ДокументСсылка.Дата
В этом примере мы добавили поле КоличествоСтрокТЧ. Затем это поле можно использовать в условном оформлении. Важно: если табличные части очень большие, а список часто прокручивается, такое соединение может быть неэффективным, как было отмечено в обсуждении.
Вариант B: Хранение данных в регистре сведений
Если расчет количества строк является ресурсоемкой операцией или данные требуются не только для одного списка, а для многих, то оптимальным решением будет предварительный расчет и хранение этих данных в отдельном регистре сведений. Этот регистр можно периодически обновлять или обновлять при записи (проведении) основного документа.
Создадим регистр сведений, например, КоличествоСтрокДокументов, с измерениями Документ (тип – ссылка на ваш документ) и ресурсом КоличествоСтрок (число). Затем в обработчике события ПриЗаписи (или ПриПроведении) основного документа мы будем обновлять запись в этом регистре:
// В модуле объекта документа
Процедура ПриЗаписи(Отказ)
// ... ваш код перед записью
// Получаем количество строк табличной части
КоличествоСтрок = Товары.Количество(); // Предполагаем, что ТЧ называется "Товары"
// Записываем данные в регистр сведений
Движения.КоличествоСтрокДокументов.Записывать = Истина;
Движения.КоличествоСтрокДокументов.Очистить();
НовоеДвижение = Движения.КоличествоСтрокДокументов.Добавить();
НовоеДвижение.Период = Дата; // Если регистр периодический
НовоеДвижение.Документ = Ссылка;
НовоеДвижение.КоличествоСтрок = КоличествоСтрок;
// ... ваш код после записи
КонецПроцедуры
После этого вы можете добавить регистр сведений к динамическому списку через ЛЕВОЕ СОЕДИНЕНИЕ в запросе списка или использовать его как дополнительный источник данных для условного оформления. Этот подход считается более эффективным, поскольку расчет происходит один раз при изменении документа, а не при каждом открытии или прокрутке списка.
Вариант C: Использование дополнительных сведений объекта
Вместо создания отдельного регистра сведений можно использовать типовой механизм дополнительных сведений и реквизитов объектов. Если данные для раскраски не изменяются слишком часто или относятся к метаданным, их можно хранить как дополнительные сведения к основному документу. Это позволяет избежать создания новых таблиц в базе данных для каждого условия оформления.
Для этого необходимо создать дополнительный реквизит для вашего документа (например, КоличествоСтрокТЧ) и заполнять его аналогично регистру сведений в обработчике ПриЗаписи документа. Затем этот дополнительный реквизит можно вывести в динамический список и использовать для условного оформления.
После того как у нас есть поле в динамическом списке (полученное любым из вышеуказанных способов), мы можем настроить условное оформление:
КоличествоСтрокТЧ > 10.Вся строка или конкретное поле).Этот способ является наиболее гибким, стандартным и, как правило, производительным для визуального выделения строк.
Несмотря на наличие более эффективных способов, бывают ситуации, когда обработчик ПриПолученииДанныхНаСервере может быть оправдан. Согласно документации 1С (ИТС), этот обработчик рекомендуется использовать, когда в динамическом списке требуются вспомогательные колонки, по которым не требуется отбирать, сортировать или группировать, и ЗАТРУДНИТЕЛЬНО, НЕЭФФЕКТИВНО или НЕВОЗМОЖНО выполнить получение данных с помощью основного запроса.
Когда это оправдано:
Потенциальные проблемы и производительность:
Имейте в виду, что при каждом получении порции данных (например, при прокрутке списка) этот обработчик будет выполняться для каждой отображаемой строки. Если внутри обработчика вы будете выполнять отдельные запросы к базе данных для каждой строки, это приведет к "N+1" проблеме и значительному снижению производительности.
Если вы все же решите использовать этот метод, постарайтесь оптимизировать его:
// Пример использования ПриПолученииДанныхНаСервере (псевдокод)
Процедура СписокПриПолученииДанныхНаСервере(ИмяТаблицы, Данные, Отказ)
// Если данные получены одним запросом для всех строк,
// мы можем обработать их эффективно.
// Иначе, придется делать отдельные запросы для каждой строки, что нежелательно.
// Пример получения данных из "Данные" и добавления к ним служебного поля:
Для Каждого СтрокаДанных Из Данные Цикл
// Здесь мы могли бы выполнить запрос для получения
// КоличествоСтрокТЧ для СтрокаДанных.СсылкаДокумента
// Но лучше, чтобы эти данные уже были в "Данные"
// или загружены одним запросом для всего набора.
// Допустим, мы каким-то образом получили КоличествоСтрокТЧ для текущей строки
// ИмяСлужебногоПоля - это имя дополнительного поля, которое мы добавили в список
// через ЭлементыФормы.Список.Колонки.Добавить("ИмяСлужебногоПоля")
СтрокаДанных.ИмяСлужебногоПоля = ПолучитьКоличествоСтрокТабличнойЧасти(СтрокаДанных.Ссылка);
КонецЦикла;
// После этого ИмяСлужебногоПоля можно использовать в условном оформлении
КонецПроцедуры
В любом случае, мы настоятельно рекомендуем в первую очередь рассмотреть варианты с условным оформлением, используя предварительно рассчитанные данные, так как они обеспечивают лучшую производительность и масштабируемость.
Креативное начальство решило отказаться от использования ячеистого склада и ордерной схемы, убрать лишние документы. Ваша задача – аргументированно убедить руководство в целесообразности или бредовости этой идеи.
Для того чтобы аргументация была убедительной, мы должны глубоко понимать суть как ордерной схемы, так и ячеистого склада, а также их влияние на бизнес-процессы. Отказ от них может быть как рациональным упрощением, так и шагом, который приведет к хаосу на складе.
Что это такое: Ордерная схема в 1С (например, в УТ, ERP) подразумевает разделение физического движения товаров на складе от их финансового или управленческого отражения в учете. Документы-ордера (например, Приходный ордер на товары, Расходный ордер на товары) фиксируют факт физического перемещения, а основные документы (Поступление товаров и услуг, Реализация товаров и услуг) регистрируют событие в учете.
Преимущества ордерной схемы:
Когда отказ от ордерной схемы может быть оправдан:
Последствия отказа от ордерной схемы:
Что это такое: Ячеистый (адресный) склад предполагает точное знание места хранения каждой единицы или партии товара вплоть до конкретной ячейки. Каждая ячейка склада имеет свой уникальный адрес, и система фиксирует, какой товар и в каком количестве хранится в каждой ячейке.
Преимущества ячеистого склада:
Когда отказ от ячеистого склада может быть оправдан:
Последствия отказа от ячеистого склада:
Чтобы эффективно убедить руководство, мы должны опираться на конкретные факты, цифры и потенциальные последствия для бизнеса. Давайте посмотрим, как это можно сделать.
Мы предлагаем провести детальный анализ текущих складских операций. Какими бы простыми ни казались эти операции, они являются частью общей цепочки поставок. Необходимо ответить на вопросы:
Если компания планирует рост или уже сейчас сталкивается с проблемами в скорости и точности, то отказ от ордерной схемы и адресного хранения может сильно ухудшить ситуацию и стать "бутылочным горлышком" для развития.
На первый взгляд отказ от "лишних документов" кажется экономией. Однако мы должны посчитать реальные затраты и выгоды:
Подчеркните, что краткосрочная экономия на количестве документов может обернуться долгосрочными потерями из-за снижения эффективности и роста ошибок.
Мы должны акцентировать внимание на рисках, связанных с упрощением:
Мы объясним, что упрощенная схема может быть не масштабируемой. Если компания планирует рост объемов, расширение ассортимента или открытие новых складов, то в будущем ей все равно придется возвращаться к более сложным и эффективным схемам. И в этот момент внедрение будет гораздо дороже и болезненнее, чем поддержание уже существующей или незначительно доработанной типовой функциональности.
Наконец, мы отметим, что типовые решения 1С (УТ, ERP) имеют развитый функционал для ордерной схемы и адресного хранения. Отказ от них означает, что мы либо:
Поясните, что типовая функциональность – это не просто "лишние документы", а продуманный инструмент, созданный для оптимизации работы склада, который уже многократно протестирован и поддерживается фирмой "1С". Отключение его без веских причин может привести к необходимости серьезных доработок в будущем, что в долгосрочной перспективе может быть дороже и менее надежно.
Итоговая рекомендация – провести глубокий анализ текущих процессов и потребностей бизнеса. Возможно, для "трех стеллажей" и розницы действительно можно отказаться от некоторых элементов (например, не использовать весь функционал ордерной схемы или внедрить только частичное адресное хранение). Но полностью отказываться от проверенных механизмов без четкого понимания последствий – крайне рискованное решение.