В процессе разработки отчетов на СКД в 1с предприятие часто возникает задача вывода нулей в пустые поля отчета. Дело в том, что, при отсутствии необходимых данных в базе, запрос возвращает не число 0, а специальное значение NULL, которое затем необходимо преобразовать в число. Например, если мы напишем
и регистр сведений окажется пустой, то в результате запроса в поле "Цена" будут значения NULL. И если нам по условиям задачи нужно в отчете вывести нули, то необходимо составить запрос следующим образом:
У вас есть вопрос, нужна помощь консультанта?
Но представим, что мы используем соединение 2 наборов данных в СКД, и результат одного из них оказывается пустым. В этом случае нам не поможет конструкция ЕСТЬNULL в тексте запроса этого набора, т.к. он вернет пустую выборку. Там не будет значений NULL, которые можно было бы преобразовать в 0, там вообще ничего не будет. NULL появляется только после соединения наборов данных, а за это отвечает система компоновки. Оставшийся выход - воспользоваться вычисляемыми полями. В нашем примере нам придется создать вычисляемое поле "Цена" и прописать в его выражение ЕСТЬNULL(Цена,0). К моменту срабатывания выражений вычисляемых полей уже произойдет соединение запросов, так что у нас уже будет поле "Цена", и оно будет содержать NULL. Создавая вычисляемое поле с таким же именем, мы по сути переопределяем поле, которое вернули нам наборы данных.
Дабы избежать комментариев типа "тоже мне открытие!", оговорюсь сразу: статья рассчитана на неискушённых СКД-разработчиков, тем кто это и так знает не обязательно высказывать своё "фи!", поймите, то что очевидно для вас - не всегда бывает очевидно остальным.
Для наглядного представления реализации части трюков я сделал небольшие заготовки в виде внешних схем СКД. Описание трюков и скриншоты постарался делать так, чтобы суть и техника реализации трюка были понятны без необходимости скачивания схем. Для кого-то этого будет вполне достаточно, но если что-то непонятно, то всегда можно скачать соответствующую схему и посмотреть непосредственно реализацию.
Трюк №1. Многоликость правого значения.
Итак, для разогрева начнём с чего-нибудь попроще. В таких механизмах СКД, как "Отбор" или "Условное форматирование" вы наверняка сталкивались с колонками "Поле" (или "Левое значение") и "Значение" (или "Правое значение"). Профессионалы, наверняка знают этот трюк, но начинающим не всегда легко догадаться, что поле компоновки данных можно использовать как слева, так и справа (т.е. сравнивать не только заданные фиксированные значения, но и другие поля СКД в пределах одной строки). Для этого достаточно в поле правого значения зайти в режим редактирования, нажать кнопку очистки значения ("кретик"), затем нажать появившуюся кнопку выбора типа (буква "Т") и выбрать тип "Поле компоновки данных".Пример.
В качестве примера я не стал изобретать велосипед, а взял самую обычную оборотно-сальдовую ведомость по счету 60 из демо-версии 1С:Бухгалтерии (я использую ред. 2.0.). Кто не знает, начиная с редакции 2.0 этот отчёт сделан на базе СКД.
Итак, зададим прямо в ней отбор для строк с условием "БУ Дт (оборот)" Равно "БУ Кт (оборот)", а также применим к отчёту условное оформление, подсветив жёлтым цветом ячейки строк, где "БУ Кт (кон. сальдо)" Больше "БУ Кт (оборот)". Если кто не знает, как включить панель "Оформление" - найдите кнопку "Параметры панели настроек" справа от надписи "Панель настроек".
Конечный результат должен получиться примерно таким:
Трюк №2. Отбор на группировках.
Все знают, что такое Отбор в СКД, но не все знают, что его можно применять не только для отчета в целом, но и на отдельных группировках строк и колонок. Прикладных задач для задействования такого средства много. Например, условная детализация (ограничение для каких группировок верхнего уровня выводить детализацию, а для каких нет), или вариативная детализация (для разных значений группировок верхнего уровня выводить разные расшифровки). На одном из проектов УПП, к примеру, пришлось делать форму калькуляции себестоимости с фиксированной структурой (отдельный справочник) и для разных статей калькуляции выводить расшифровки или по статьям затрат, или по конкретным затратам или не выводить ничего. Благодаря этому трюку не пришлось отказываться от СКД при разработке отчёта.Пример.
Цель примера: отобразить ОСВ, в которой для взаиморасчетных счетов (60,62,76) показать расшифровку по контрагентам, а для затратных (20,23,25,26) - по статьям затрат.
Сама СКД реализована в виде набора данных, где используется запрос к виртуальной таблице остатков и оборотов регистра бухгалтерии "Хозрасчетный".
Размещаем вложенные группировки "Организация" и "Счет". В группировке "Счет" параллельно размещаем 2 группировки "Субконто1" и "Субконто2", для которых задаем соответствующие отборы.
Иллюстрацию настройки привожу в скриншоте:
Если в основных настройках отчёта на закладке "Другие настройки" вы не отключали вывод отборов, то это обязательно нужно будет сделать в "других настройках" наших группировок "Субконто1" и "Субконто2"
Трюк №3. Шапка-невидимка
Следующий трюк можно представить, как продолжение предыдущего. Если вы обратили внимание, в получившемся отчёте несмотря на то, что фактически у нас выводится только одно субконто, в шапку попадают оба (и "Субконто1" и "Субконто2"). К сожалению разработчики СКД не предусмотрели возможность регулирования видимостью шапки или использования какого-нибудь служебного символа, при установке которого в качестве заголовка, шапка поля бы не формировалась. Но, как вы уже, наверное, догадались есть трюк, который в какой-то степени поможет обойти данное ограничение.При разработке схемы в предопределённом макете оформления добавьте макет группировки, с определением по имени группировки "Невидимка" так, как показано на скриншоте. Обратите внимание, что поле "Область" должно остаться пустым!
А затем задайте для группировки "Субконто2" имя "Невидимка":
И вуаля... шапка группировки "Субконто2" исчезает, а отчёт становится вот таким:
Спросите, почему макет оформления задаётся через имя, а не через указание конкретного поля группировки? Просто так получается более универсальное решение и впоследствии это имя группировки можно задать в вариантах отчёта на любой группировке, а вот менять предопределённый макет в вариантах уже не получится.
Да, есть ещё один ньюанс этого трюка: учитывайте, что "шапка-невидимка" накрывает не только эту группировку, но и все нижестоящие! Т.е. если вы назначите имя "Невидимка" группировке "Субконто1", то в шапке не будет видно ни "Субконто1", ни "Субконто2"!
Трюк №4. Называй меня как хочешь
Большинство разработчиков СКД знают, как можно задать заголовок поля запроса. На закладке СКД "Наборы данных", достаточно поставить галочку отмены автозаголовка и внести в поле "Заголовок" необходимый текст. Минус состоит в том, что в пользовательском режиме, этот способ недоступен, а переименовать заголовок хочется не прибегая к помощи конфигуратора. Так вот в настройках вариантов отчёта есть не только способ переименовать заголовки полей, но и "накрыть" их группировочной "шапкой". Для этого на закладке "Выбранные поля" необходимо выделить нужные поля и нажать правую кнопку мыши. Как видно на скриншоте для полей доступны опции "Установить заголовок" и "Сгруппировать поля".
Обратите внимание, что для полей группировок установку заголовка необходимо делать также именно через закладку "Выбранные поля", а не через контекстное меню "Установить имя" в верхней (структурной) части настройки варианта!
После всех настроек вариант отчёта выглядит вот так:
P.S.
Небольшая подсказка для тех, кто будет качать схему. Схема - одна, но все трюки выполнены в виде отдельных вариантов настроек отчёта этой схемы:
Продолжение следует...
) Lyns_owner,
Правильный - значит быстродейственный. При его использовании нет необходимости вычисления периода для каждой строчки отчета.
зато есть необходимость менять текст запроса, создавать ТЗ, загружать его в СКД и прочее. А посчитать case для строчки дело не сложное, к тому же в моем примере идет сравнение чисел, что в общем-то вряд ли сильно затруднит обработку.
Но я так же могу поспорить и с фразой "правильный - значит быстродейственный." Мы пишем не на С++ и 1С сама по себе довольно медлительна и много где теряет производительность. Вообще код в 1С должен соблюдать баланс между скоростью работы и скоростью восприятия этого кода другим программистом. По моему сугубо личному мнению все эти обработки при компановке, передача ТЗ как внешний источник и прочие извращения это от криворукости, когда человек не может в СКД сделать нормальный запрос. И анализировать это разбирая процедуры, которые наваял автор бывает довольно проблемно. И если вы ради вычисления одного поля будете всё переносить в модуль, то...ну даже не знаю. Бывают ситуации, когда без этого не обойтись, но они бывают редко.
однако вариант с переносом расчета периода из запроса в вычисляемые поля он и правда с этой точки зрения лучше, тк всё воспринимается ещё легче.
Не считаете - обоснуйте, почему.
Зачем? Это Вы должны обосновывать на каких таких основаниях вы считаете свой метод лучше и быстрее:) я ничего не брался доказывать, просто рассказал более удобный способ.
Более того, я в начале сказал, что мы можем что-то сделать с СКД при компановке, но это совершенно не интересно.
Я только что специально протестировал этот механизм с использованием планировщика(только сам запрос), чтобы я ни делал выше 0% общая стоимость выполнения comptute scalar не превышала, там что-то в районе 0.000000014 общая стоимость. Поэтому истории про то, что тяжело рассчитать case для каждой строчки несколько надуманы.
Кстати что интересно в SQL запрос попадает не весь case а только верный вариант, не знаю с чем это связано пока.
Я стесняюсь спросить, ЧТО вы еще собираетесь в отчете с вертикальной группировкой по периоду? Регистр сведений? Может вообще дату документов? Опять же возвращаемся к разговору про быстродействие.
Стесняться не надо, в этом нет необходимости. Дело в том, что мой метод универсален и конкретно я его придумал когда делал разворот по датам, которые брались из документа(но не дата документа) довольно сложная аналитическая самописная конфа для финансового планирования и ради одного отчета делать регистр начальство не посчитало нужным. Но в целом да, это своего рода обороты. Но дело ведь не в этом, правда? :) моя маленькая заметка находится в разделе "практика программирования" и она довольно универсальна, плюс раскрывает некоторые довольно интересные методы работы с СКД.
Я вообще не понимаю откуда этот спор. Я просто предложил ещё один метод(о чем и написал) как это сделать. На мой личный взгляд это самый красивый способ, хотя способов конечно много. Плюс, я уверен, он работает с не худшей производительностью, чем предложенный Вами способ.
Lyns_owner 339 03.02.15 00:38 Сейчас в теме
Мы пишем не на С++ и 1С сама по себе довольно медлительна и много где теряет производительность
А вам сказать, благодаря кому она такая медленная? или Сами догадаетесь? А тестировали вы на каких данных? Сколько строк в результирующем запросе? 10?
Программист пишет не так, чтобы это было легко сделать (очень близко к определению понятия "говнокод"), а так, чтобы это работа правильно и максимально быстро.
Да извольте анализировать процедуры, написанные автором. Все правильное реализуется непросто, а что реализуется просто - то поделка школьника. Возьмите к примеру запросы вычисления страховых взносов в ЗУПе - их тупо листать устанешь, не то что разбирать. А на первый взгляд, там сложного ничего нет - есть база и есть процент))
Разворот по датам, которые брались из документа(но не дата документа) довольно сложная аналитическая самописная конфа для финансового планирования и ради одного отчета делать регистр начальство не посчитало нужным
В корне неправильный подход. Возвращаясь к вопросу о быстродействии 1с - чего вы хотели, если не используете возможности платформы (виртуальные таблицы в частности)?
Но дело ведь не в этом, правда? :)
Да, дело не в этом. Дело в том, что ваша статья в том или ином виде уже больше года присутствует на Инфостарте. А еще ваши ответы характеризуют вас как некомпетентного специалиста.
Slazzy 38 03.02.15 12:19 Сейчас в теме
А еще ваши ответы характеризуют вас как некомпетентного специалиста.
Пойду поплачу.
А теперь по делу. Сделал регистр сведений, добавил туда пару полей и одно из полей Дата, добавил в него 510к строк. Судя по плану запроса вычисление периода тратит 1% от общего времени(ориентировочно)
Такие дела.
Да и, к слову, в 1С есть стандарты разработки, которые ставят качество восприятия кода на одну ступень с его быстродействием, за редчайшим исключением вроде процедур проведения, где каждая секунда важна.
И если по Вашему стоит из-за любого чиха обработку переносить в модуль, вместо СКД и считаете это правильным, то мне надо Вас огорчить. Сказать почему? Ну например СКД динамически формирует запрос и отборы в СКД автоматически переносятся в запрос тоже... Может случиться такая ситуация, что пользователю будет нужна одна строка, а вы создадите свою таблицу из миллиона записей в модуле и СКД всё равно отберет одну строку....поспорим о производительности? Или будете все допустимые отборы выносить на форму и обрабатывать в своем запросе? СКД автоматически работает с характеристиками. Но главная причина спора и производительность это тема тоже сложная. Я например абсолютно убежден, что сделать запрос на миллион строк и выгрузить его в ТЗ, а потом передать как внешний источник данных в СКД - нереально медленная операция, тут потери производительности на создание ТЗ просто громадны и они даже близко не сопоставимы с мизерными потерями на расчет периода в строке.
Да и просто анализировать единый запрос в СКД куда правильнее чем раскидывать код по модулям без причин.
Ваша статья несколько отличается от моей, спорить с этим бессмысленно. К тому же вы проповедуете несколько иные подходы. Вы предъявили мне претензии мол Ваш метод работает очевидно быстрее, но не приводите никаких доказательств и сравнений. Вместо этого пытаетесь оскорблять и придираться к несущественным аспектам, которые к статьей не имеют никакого отношения.
(), я надеюсь на этом мы закончим нашу беседу, мне она не очень интересна, извините уж:)
