Проектирование структуры метаданных

СОДЕРЖАНИЕ

 

1. Цель работы.. 4

2. Теоретические сведения. 4

2.1 Методология разработки. 4

2.2 Язык запросов..........................................................................................12

2.3 Аналитическая отчетность. 13

3. Пример выполнения.......................................................................................14

4. Порядок выполнения работы.. 28

5. Варианты заданий. 28

6. Контрольные вопросы.. 28

Библиография. 29

Приложение А 30

 

 

ЦЕЛЬ РАБОТЫ

Ознакомиться с формированием аналитической отчетности. Разработать небольшую систему учета на основе описания предметной области.

 

ОСНОВНЫЕ ПОЛОЖЕНИЯ

 

2.1 Методология разработки

 

Можно сказать, что собственно создание будущего прикладного решения начинается с его проектирования.

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

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

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

Прежде всего, это решение вопроса о том, каким образом будет реализовываться та или иная функциональность будущей системы. В крупных решениях, как правило, всегда присутствует большое количество функциональности, которая не может быть реализована только каким-либо одним объектом конфигурации. Возникает необходимость задействовать несколько различных объектов, причем далеко не всегда можно однозначно, без внимательного рассмотрения, сказать, какие именно объекты конфигурации лучше использовать в данном случае. Одна и та же задача, в принципе, может быть решена с использованием различных объектов конфигурации, поэтому вопрос правильного выбора используемых объектов и построения эффективной структуры метаданных приобретает первостепенное значение.

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

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

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

Проектирование структуры метаданных

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

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

Язык запросов

 

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

 

Таблица 2 – Язык запросов

1 Указание источников в запросе
Выбрать НазваниеОрганизации, ЮридическийАдрес Из Константы	Источник запроса (под источником запроса обычно понимается таблица, реальная или виртуальная) указывается после ключевого слова «Из». В общем случае источников может быть несколько. Описание источников разделяется запятыми, после последнего источника запятая не ставится.
Выбрать * Из Константы	Запрос показывает содержимое всех полей в таблице констант. Исходя из назначения констант, таблица «Константы» всегда содержит одну строку.
2 Конструкции «Различные», Первые N. После ключевого слова «Выбрать» можно указывать дополнительную конструкцию «Первые N». В результат выполнения запроса войдут только первые N записей. Если указать «Различные», то результат запроса не будет содержать повторяющихся (одинаковых по значениям всех полей выборки) записей.
3 Фильтрация результатов запроса
Выбрать * Из Справочник. Номенклатура Где Не Справочник. Номенклатура. ЭтоГруппа   Выбрать Различные ОснЕдиницаИзмерения Из Справочник.Номенклатура   Выбрать Первые 4 ОснЕдиницаИзмерения Из Справочник.Номенклатура	Для фильтрации (указания условия отбора) используется структура, определяемая ключевым словом «Где».   В данных примерах знак равно (в условии) не обязателен, так как поле «ЭтоГруппа» содержит значения типа «Булево». В условиях (это не обязательно может быть конструкция «Где») помимо обычных операций сравнения могут использоваться «В», «Между И», «Подобно», «Есть».
4 Указание нескольких источников, соединения, псевдонимы
Выбрать Номен. Наименование, ЕдИзм. Наименование, ЕдИзм. Коэффициент Из Справочник. Номенклатура Как Номен, Справочник. ЕдиницыИзмерения Как ЕдИзм	Во всех предыдущих примерах источник был один. Но иногда могут возникать ситуации, когда данные находятся в разных таблицах, а должны попасть в результат выполнения одного запроса. Язык запросов предоставляет возможность указывать более чем один источник. Результат подобного запроса состоит из всех возможных комбинаций записей обеих таблиц. Такой результат мало кого устроит, но так будет всегда, если не указывать способ связи таблиц.
Выбрать Номен.Наименование, ЕдИзм.Наименование, ЕдИзм.Коэффициент Из Справочник.Номенклатура Как Номен, Справочник.ЕдиницыИзмерения Как ЕдИзм Где Номен.ОснЕдиницаИзмерения. Код=ЕдИзм.Код	Связывать таблицы можно с помощью конструкции языка запросов «Где». Хочется отметить, что, во-первых, данный пример является абстрактным. В реальной жизни (в общем случае) чем меньше источников вы указываете в запросе, тем лучше. Во-вторых, условие в данном примере построено не эффективно.
Номен.ОснЕдиницаИзмерения = ЕдИзм.Ссылка	Если указать условие следующим образом, то время выполнения данного запроса снизится почти в два раза.
Другим способом указания взаимосвязи таблиц является использование «Соединений». Соединения бывают нескольких видов: ● Внутреннее соединение ● Левое внешнее соединение ● Правое внешнее соединение ● Полное внешнее соединение В любом случае, когда речь заходит о соединении, существует несколько связанных с этим понятий: Таблица № 1, Таблица № 2, соединение (его вид и условие соединения).Рассмотрим эти варианты на следующем примере: Есть две таблицы:     Таблица 2.1 Номен Номер1 Ручка   Карандаш   Вилка     Таблица 2. ЕдИзм Номер2 Шт   Гр   Кг   Банка       Условием соединения будет: Таблица1. Номер1=Таблица2. Номер2 В качестве полей запроса определим две колонки: «Номен» из первой таблицы и «ЕдИзм» из второй таблицы. Теперь рассмотрим варианты соединения:
· Внутреннее соединение
Номен ЕдИзм Ручка Шт Ручка Банка Вилка Гр	В результат выполнения запроса войдут только данные записей из обеих таблиц, для которых выполняется условие соединения
· Левое/правое внешнее соединение
Номен Е Изм Ручка Шт Ручка Банка Вилка Гр Карандаш NULL	В результат выполнения запроса войдут данные из записей, для которых выполняется условие соединения и «не вошедшие» из Таблицы № 1. Можно сказать, что в результат запроса войдут все данные из Таблицы № 1, и для тех записей результата запроса, для которых выполнялось условие соединения в полях, куда помещаются данные из таблицы № 2, будут стоять значения, для которых условие не выполняется, будет стоять Null.
Номен ЕдИзм Ручка Шт Ручка Банка Вилка Г   NULL Кг	Правое внешнее соединение обратно левому.
· Полное внешнее соединение
Номен ЕдИзм Ручка Шт Ручка Банка Вилка Гр Карандаш NULL NULL Кг	В результат запроса войдут как записи, для которых выполнялось условие соединения, так и записи, полученные из «не вошедших» данных из обеих таблиц. В любом случае, даже в результате использования полного внешнего соединения не получается полная комбинация значений. (В случае полного соединения добавляются записи, не удовлетворяющие условию, а не все возможные их комбинации).
5 Объединение таблиц
ВЫБРАТЬ Таблица1.Номен, Таблица1.Номер ИЗ Таблица1 КАК Таблица1   ОБЪЕДИНИТЬ ВСЕ   ВЫБРАТЬ Таблица2.ЕдИзм, Таблица2. Номер ИЗ Таблица2 КАК Таблица2   Номен Номер Ручка   Карандаш   Вилка   Шт   Гр   Кг   Банка	В языке запросов имеется возможность объединять несколько запросов; при этом записи, полученные с помощью каждого из объединяемых запросов, будут собраны в один результат запроса. При объединении каждый запрос собирает данные независимо, а такие операции, как дополнение результатов, упорядочивание ре­зультатов и расчет итогов выполняются уже над результатом объ­единения запросов. Поля результата запроса будут называться так, как описано в списке полей выборки первого из объединяемых запросов. Поля выборки остальных запросов сопоставляются с полями результата в соответствии с порядком их следования в списке полей выборки. Объединяемые запросы должны иметь одинаковое количество полей в списке полей выборки. Если поля выборки объединяемых запросов имеют разный тип, то поля результата запроса будут иметь составной тип. Объединение запросов начинается с обязательного ключевого слова ОБЪЕДИНИТЬ, после которого следует описание присоеди­няемого запроса. Далее может присоединяться еще один запрос и т.д. По умолчанию при объединении запросов полностью одинаковые строки в результате запроса, сформированные разными запроса­ми, заменяются одной. Если требуется, чтобы были оставлены разные строки, необходимо указать ключевое слово ВСЕ.
6 Упорядочивание результатов запроса
Выбрать * Из Документ. Приходная Упорядочить По Контрагент Иерархия	Просматривая данные из вложенной таблицы видно, что они упорядочены по дате документа. Если требуется получить данные с другим вариантом сортировки, то для этих целей можно использовать конструкцию «Упорядочить По». Возможные варианты упорядочивания: «Возр», «Убыв», «Иерархия». В качестве имен полей, по которым производится упорядочивание, можно указывать их псевдонимы. В случае, если вариант упорядочивания не указан (и не используется «автоупорядочивание»), то упорядочивание будет производиться по значению внутренних идентификаторов. Важно помнить, что упорядочивание по иерархии возможно только по таблицам с иерархией.
7 Группировки результатов запроса
Выбрать Номенклатура Как Товар, Сумма (Количество), Сумма (Сумма) Из Документ. Приходная. Товары Сгруппировать По Номенклатура	При просмотре предыдущих результатов выполнения запросов данные получались в том виде, как они вводились в документы. Но если требуется получить ответ на вопрос: сколько какого-то товара закупалось (вообще), то либо придется складывать все вручную, либо использовать группировку. Данные в запросе могут быть сгруппированы с помощью агрегатных функций, указанных в качестве полей выборки. Очень важно помнить, что в большинстве случаев все поля выборки запроса должны делиться на агрегатные функции и поля, по которым ведется группировка (исключение в определенных случаях составляют поля «Представление», встроенные функции и т. п.). При указании группировки псевдоним поля указывать нельзя. В качестве агрегатных функций можно использовать: • Сумма (Выражение) • Среднее (Выражение) • Минимум (Выражение) • Максимум (Выражение) • Количество ([Различные] Выражение)
8 Итоги в запросе
Выбрать Номенклатура, Цена, Количество, Сумма Из Документ.Приходная.Товары Итоги Сумма (Количество), Сумма (Сумма) По Номенклатура	Для получения итогов в результате запроса в тексте запроса необходимо определить конструкцию «Итоги». Итоги добавляются в результат запроса как итоговые строки.
9 Передача параметров в запрос
Где Номенклатура=&Номен	Очень часто встает задача передачи каких-либо значений (параметров) в запрос. К примеру, это могут быть значения условий, накладываемых на запрос.

 

Аналитическая отчетность

Конструктор выходной формы

 

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

 

 

Рисунок 2.1 – Конструктор выходной формы

 

Конструктор включает в себя все возможности конструктора запросов и кроме этого позволяет создавать и настраивать форму, которая будет использована для вывода результатов запроса пользователю. Конструктор поддерживает вывод результатов в разнообразные элементы управления:

● табличный документ - представляет результаты в виде документа, похожего на электронную таблицу;

● сводную таблицу - многомерная таблица с возможностью интерактивного формирования состава строк и столбцов;

● диаграмму - поддерживает несколько различных видов диаграмм (линейная, круговая, гистограмма и пр.);

● сводную диаграмму - диаграмма с возможностью интерактивного формирования состава строк и столбцов.

 

 

Рисунок 2.2 – Формирование табличного документа

 

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

Результатом работы конструктора является набор связанных процедур, которые могут располагаться в различных модулях, и готовый макет отчета. Разработчику остается лишь запустить отчет на выполнение и проверить правильность его работы. Никакого дополнительного программирования или конфигурирования не требуется - конструктор создает полностью работоспособный элемент системы.

 

 

3. Пример ВЫПОЛНЕНИЯ

 

Приступим к изучению языка запросов на примере документа «РасходнаяНакладная». Нам необходимо переписать все возможные алгоритмы, описанные в модуле объекта и в модуле формы, при помощи языка запросов. Однако запросы нам понадобятся не во всех алгоритмах, а только в тех, где происходит выборка данных из БД.

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

Удаляем весь текст, который написан в обработчике, ставим курсор на свободное место внутри процедуры и нажимаем правую кнопку мыши. В появившемся списке выбираем «Конструктор запросов».

 

 

На вопрос, нужно ли создавать новый запрос, можно смело отвечать «Да».При этом появится окно конструктора запросов. Конечно запрос можно писать и вручную, исходя из тех правил, которые описаны в пункте 2.2, но это достаточно сложный процесс, поэтому мы воспользуемся конструктором, который заметно упрощает работу и позволяет создавать сложные запросы.

Перед вами 3 колонки: в 1-ой располагаются все возможные таблицы, из которых можно делать выборку; во 2-ой будут размещаться таблицы, которые необходимы нам непосредственно для запроса; в 3-ей колонке мы будем определять, а какие поля из выбранных таблиц нам нужны.

 

 

Из левого списка выберем РегистрыСведений->Цены->ЦеныСрезПоследних.

Выбранная нами таблица появится в средней колонке. Откроем список её полей и выберем «Цена». Выбранные поля перемещаются в 3-ю колонку. Теперь окно должно выглядеть так.

 

 

Что мы сейчас сделали - мы показали конструктору, что хотим выбрать данные из регистра «Цены», при этом для выборки нам нужна таблица ЦеныСрезПоследних. Данная таблица не является объектом конфигурации и просмотреть её из конфигуратора невозможно. Она является встроенной таблицей регистра и обновляется автоматически при внесении в регистр каких-либо данных. Срез последних на определённую дату означает, что в регистре будет искаться самая последняя запись в интервале от 01.01.01 00:00:00 по нашу дату. Срез первых выполняет похожую функцию - ищет ближайшую запись в регистре от заданной даты до текущей. Если регистру не указывать, на какую дату искать записи, то данные будут выбираться для текущей даты.
Что же вернёт такой запрос - он вернёт набор записей регистра «Цены» по каждому товару для каждого контрагента и для каждого типа цен (при этом этот набор записей будет ограничен 1 колонкой: Цена). Такая выборка нас не устроит, ведь нам нужна информация о конкретном товаре для конкретного контрагента и только по цене продажи. Для наложения ограничений можно зайти во вкладку «Условия» и сделать следующее:

 

 

Тем самым мы задаём 3 параметра, согласно которым будет происходить выборка. Сами параметры будут передаваться в запрос из модуля формы. Однако такой подход нас не устраивает и вот почему. Условие «Где» работает на верхнем уровне, т.е. сначала происходят соединения, объединения таблиц или другие возможные действия, а только потом на это накладываются ограничения. Намного проще сначала наложить ограничения на каждую из таблиц, а только потом соединять или объединять их - это приводит к заметному ускорению работы запроса на больших объёмах данных. Пока разница нам не видна, ведь мы работаем с одной таблицей, но стоит сразу приучать себя к правильному написанию. Поэтому все ограничения, сделанные во вкладке «Условия», мы удалим.

 

Во 2-ой колонке выделим нашу таблицу и нажмём на пиктограмму «Параметры виртуальной таблицы».

 

В поле «Период» напишем &Дата. Это означает, что в запрос будет передан некоторый параметр с именем Дата, который будет определять, на какую дату регистру брать записи. Откроем поле «Условие» и напишем следующее

 

 

По сути мы здесь написали то же самое, что до этого писали во вкладке «Условия», с той лишь разницей, что мы не передаём параметром тип цен, а указываем его сразу как предопределённый элемент перечисления. Здесь функция ЗНАЧЕНИЕ нужна для того, чтобы конструктор понял, что это вычисляемое значение, которое нужно взять из объекта конфигурации Перечисления, иначе конструктор бы считал, что Перечисление - это измерение или реквизит регистра и не найдя подобного, выдал бы ошибку. Ещё один нюанс - если во встроенном языке мы писали Перечислени Я, то в языке запросов нужно писать Перечислени Е. Теперь наш запрос вернёт всего лишь одну строчку, состоящую из 1 колонки Цена. Нужно предусмотреть момент, когда регистр не будет содержать ни одной записи, тогда запрос в качестве цены вернёт NULL, а должен вернуть число, поэтому мы явно укажем конструктору как быть в этой ситуации. В 3-ей колонке нажмём 2 раза мышкой на поле «ЦеныСрезПоследних.Цена». В открывшемся окне изменим первоначальный текст на такой:

Если цена примет значение NULL, то конструктор подставит вместо NULL ноль.

 

Вроде бы всё, но мы забыли ещё об одном - если мы не продавили товар указанному контрагенту, мы ищем цену, по которой продавали этот товар любому контрагенту. Для этого нам потребуется ещё один запрос, но чтобы было интереснее, сделаем 2-ую выборку в этом запросе. Из 1-ой колонки ещё раз выберем ЦеныСрезПоследних. Т.к. такая таблица во 2-ой колонке уже есть конструктор переименует новую таблицу, дописав 1 к имени. Все остальные действия точно такие же за исключением настроек виртуальной таблицы - необходимо убрать строку Контрагент = &Контрагент. Тем самым мы уточняем, что нам не важен контрагент, поэтому из регистра будет взята ближайшая к указанной дате запись о продаже этой номенклатуры.

 

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

 

Мы связали 2 таблицы по номенклатуре, т.е. результатом соединения будет одна строка, состоящая из 2 цен. Обратите внимание на галочки Все, которые мы поставили при настройке связи. Эти галочки отвечают за вид соединения.

 

		Внутреннее соединение
ü		Левое соединение
	ü	Правое соединение
ü	ü	Внешнее соединие

 

Наш запрос готов. Нажмём «ОК» и увидим текст запроса, который сформировал конструктор:

 

Когда мы воспользовались функцией ЕстьNULL, конструктор автоматически переименовал поля Цена и Цена1 в Поле1 и Пол2. Такая замена не является ошибкой, и мы сможем обращаться к этим полям, однако читабельность такого кода резко снижается, т.к. совсем не ясно, к чему именно мы обращаемся. Исправить эту ситуацию можно 2 способами:

1) Наведите курсор на текст запроса и снова зайдите в конструктор. Перейдите на вкладку «Объединения/Псевдонимы» и переименуйте поля.

2)Не заходя в конструктор, просто сотрите Поле1 и Поле2, а вместо них можно написать ЦенаПоКонтрагенту и Цена.

 

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

 

 

Теперь перепишем с помощью языка запросов обработку проведения. При этом удалим процедуру ПроверитьКорректность, а все проверки заполнения реквизитов формы будет производить непосредственно в обработчике проведния. Текст обработчика представлен ниже:

 

Если НЕ Отказ Тогда

Движение = Движения.Цены.Добавить();

Движение.Период = Дата;

Движение.Контрагент = Контрагент;

Движение.Номенклатура = Выборка.Номенклатура;

Движение.ТипЦен = Перечисления.ТипыЦен.ЦенаПродажи;

Движение.Цена = Выборка.Цена;

Движение = Движения.ОстаткиНоменклатуры.ДобавитьРасход();

Движение.Период = Дата;

Движение.Склад = Склад;

Движение.Номенклатура = Выборка.Номенклатура;

Движение.Количество = Выборка.Количество;

Если Выборка.Количество = Выборка.КоличествоОстаток Тогда

Движение.Сумма = Выборка.СуммаОстаток;

Иначе

Движение.Сумма = Выборка.СуммаОстаток/Выборка.КоличествоОстаток*Выборка.Количество;

КонецЕсли;

КонецЕсли;

КонецЦикла;

КонецПроцедуры

 

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

 

Если НЕ Отказ Тогда

Движение = Движения.Цены.Добавить();

Движение.Период = Дата;

Движение.Контрагент = Контрагент;

Движение.Номенклатура = Выборка.Номенклатура;

Движение.ТипЦен = Перечисления.ТипыЦен.ЦенаПокупки;

Движение.Цена = Выборка.Цена;

Движение = Движения.ОстаткиНоменклатуры.ДобавитьПриход();

Движение.Период = Дата;

Движение.Склад = Склад;

Движение.Номенклатура = Выборка.Номенклатура;

Движение.Количество = Выборка.Количество;

Движение.Сумма = Выборка.Сумма;

КонецЕсли;

КонецЦикла;

КонецПроцедуры

Приступим к созданию отчёта. Отчёт представляет из себя объект конфигурации, призванный отражать некоторый набор данных в удобном для пользователя виде. В 3-ей лабораторной работы мы создали печатную форму документа, и при этом использовали макет и табличный документ. Создание отчёта по своей структуре не отличается от создания печатной формы. Мы создаём тот же макет, а затем выводим данные согласно макету в табличный документ. Отличие заключается в том, что и макет, и табличный документ нам помогает создать конструктор выходной формы.

 

Итак, создадим новый отчёт и назовём его «ОстаткиНоменклатуры». Перейдём на вкладку Макеты->Конструкторы->Конструктор выходной формы. Нам предложат создать новую выходную форму. Соглашаемся. Перед нами открывается окно, очень напоминающее конструктор запросов. Это действительно так - основная работа по созданию отчёта в конструкторе заключается в выборке данных (как мы делали в конструкторе запросов), и только потом настраивается отображение этих данных на выходной форме. Для отчёта нам понадобится таблица ОстаткиНоменклатуры.Остатки. Из неё мы возьмём 2 поля: «Номенклатура» и «КоличествоОстаток». Заметьте, что для более компактной записи во 2-ой колонке мы переименовали таблицу ОстаткиНоменклатурыОстатки в Остатки

 

 

В настройках виртуальной таблицы в поле «Период» пишем &Дата, а в поле «Условие» Номенклатура В ИЕРАРХИИ (&Номенклатура). Что мы сейчас сделали. Мы могли не писать условие и тогда отчёт формировался бы по всей существующей номенклатуре. Мы могли написать Номенклатура = &Номенклатура, и тогда отчёт формировался бы по заданной номенклатуре. Но мы поступили иначе и написали В ИЕРАРХИИ. Это означает, что мы сможем выбрать не только конкретный товар, но и его родителя, т.е. можем посмотреть остатки по конкретному телевизору или по всем телевизорам сразу. Такой подход может применяться только для иерархических справочников. При этом, если в отчёте мы не зададим номенклатуру, то он автоматически выдаст данные для всей номенклатуры. Тоже самое происходит и с датой - если она не будет заполнена, то отчёт строится на текущую дату.

 

Теперь предположим, что мы хотим увидеть не только остатки по каждой номенклатуре, но и остатки в пределах группы, т.е. сколько у нас всего телевизоров и т.д. Для этого перейдём на вкладку «Итоги» и настроим окно так, как показано ниже.

 

 

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

 

Элементы:

Только иерархия:

Элементы и иерархия:

 

Третий вариант нам подходит больше всего, т.к. предоставляет более полные данные. В настройках итогов не забудьте поставить галочку «Общие итоги» - это позволит нам увидеть общее количестве всей номенклатуры. Эти данные мало информативны, но зато позволят нам лучше понять возможности конструктора. Перейдём на вкладку «Отчёт» и снимем галочку «Использовать построитель отчётов». Дело в том, что кроме классического конструктора, платформа 1С предоставляет ещё 2 возможности создания отчётов: с помощью построителя и компоновщика, но мы не будем ими пользоваться, т.к. объяснение их функционирования может занять несколько отдельных лабораторных работ. Осталось перейти на закладку «Выходная форма» и настроить параметры, которые будут передаваться в отчёт:

 

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

 

Также не забудьте назначить права на использование этого объекта.

Порядок выполнения работы

 

1. Изучить теоретические сведения.

2. Изучить постановку задачи, разработать структуру метаданных конфигурации.

3. Реализовать алгоритмы функционирования системы.

4. Реализовать необходимую отчетность.

5. Подготовить отчет о работе.

5. Содержание отчета

1. Цель работы.

2. Описание варианта задания (предметной области и набора ее элементов, отображаемых в БД).

3. Копии всех подготавливаемых аналитических отчетов.

4. Выводы по работе.

6. Контрольные вопросы

 

1. Как определить, какие именно объекты конфигурации использовать для описания предметной области?

2. Как осуществить выбор представления данных?

3. В какие элементы управления позволяет выводить отчет конструктор выходной формы?

4. Какие данные может содержать макет?

5. Для чего используется конструктор запросов.

6. Объясните разницу между видами группировок при подведении итогов.

7. Какие виды соединения таблиц вы знаете? Опишите их.

 

 

 

БИБЛИОГРАФИЧЕСКИЙ СПИСОК