ОсновыРаботы_1С_Предприятие. Занятие Установка и начало работы с 1С Предприятие 8
Скачать 3.65 Mb.
|
§9.1. План видов характеристик В реальных учетных системах часто возникает ситуации, когда необходимо задать какие-то характеристики: товаров, сотрудников, материалов и т.д. В разрабатываемой системе необходимо указывать ряд свойств товаров (цвет, размер, производитель и т.д.) и их значения. При этом заранее неизвестно, какой товар, какими характеристиками будет описываться и сколько их будет. Для задания характеристик можно завести специальные реквизиты: для описания вида и значения характеристики. Реквизит, хранящий значение характеристики, следует сделать составного типа (т.к. характеристики могут быть различного типа). Соответственно, везде в конфигурации, где следует описывать характеристику, для реквизита-значения необходимо заполнять данный составной тип. Такой подход несет в себе ряд проблем, особенно при добавлении новой характеристики нового типа: в больших конфигурациях нереально будет перебрать все объектам и настроить соответствующие реквизиты-характеристики и реквизиты-значения с их составными типами. Еще одна проблема, которая возникает при описании характеристик – это характеристики «нестандартных», собственных типов. Допустим, с размером или датой производства все понятно – это будут число или дата соответственно. А как, к примеру, быть с цветом (красный, желтый, и т.д.)? Если цвет задать как строку, то тогда: необходимо будет каждый раз вводить одинаковые значения, что неэффективно; невозможно проводить аналитику: к примеру, сколько товаров из США, или сколько материалов красного цвета и т.д. Имеет смысл реализовать возможность создания пользователем значений таких «нестандартных» характеристик для их дальнейшего использования и как-либо образом хранить их в базе. Перечисление использовать нельзя т.к. в режиме исполнения мы не сможем добавлять новые значения. Для хранения значений «нестандартных» типов возможно использование отдельного справочника, но необходимо как-то связать значение характеристики с ее видом. Для этого «1С: Предприятие» имеется прикладной объект «План видов характеристик». План видов характеристик (ПВХ) – это тоже справочник. Данный справочник состоит из элементов – наименований (видов) характеристик с указанием типа значения для каждой характеристики (число, дата, ссылка на перечисление, и т.д.). Для «нестандартных» характеристик реализована возможность хранения их значений в отдельном подчиненном справочнике (в качестве «Владельца» будет указан элемент ПВХ – вид характеристики). При создании ПВХ в систему добавляются два новых типа данных: «ПВХСсылка» – ссылка на виды характеристик (элементы ПВХ) и «ХарактеристикаПВХ» – составной тип данных, содержащий перечень типов, которые могут быть заданы для значений характеристик. Соответственно, в системе при описании реквизитов-значений характеристик указывается тип данных «ХарактеристикаПВХ». Если впоследствии, в ПВХ добавится новая характеристика с новым типом данных, то все описанные ранее реквизиты-значения автоматически будут «видеть» этот тип данных. Значения характеристик можно хранить в реквизитах шапки, реквизитах табличных частей, в ресурсах регистра сведений. Использование реквизитов шапки весьма ограничивает возможности по хранению нескольких характеристик. Использование табличной части, являясь самым простым способом, решает данную задачу, но приводит к тому, что значения характеристик могут быть неуникальными. К примеру, в одной строке можно указать, что цвет красный, а в другой – что зеленый. Вторая особенность, связанная с использование табличной части, заключается в трудностях при проведении аналитики по характеристикам. Поэтому, наиболее корректным способом, позволяющим реализовать контроль уникальности характеристик, является использование регистра сведений: в измерениях указывается набор, определяющий уникальность характеристик (например, номенклатура плюс вид характеристики), а в ресурсе хранится значение характеристики. Создадим ПВХ «Характеристики номенклатуры», добавим в подсистему «Отдел закупок». На вкладке «Основные» настройки свойств в разделе «Тип значения характеристик» (рис. 49) отметим «Составной тип данных» и укажем все примитивные типы, а также ссылки на справочник «Номенклатура» и перечисление «Виды номенклатуры». На самом деле, здесь можно указать абсолютно произвольно число типов, входящих в составной: ни на производительность, ни на объем хранимой информации это не влияет. Рис. 49. Создание плана видов характеристик Далее создадим справочник «Дополнительные значение свойств», включим в подсистему «Отдел закупок» и сделаем его подчиненным созданному ПВХ «Характеристики номенклатуры». Данный справочник будет хранить значения «нестандартных» характеристик. Подчинение позволяет однозначно связать вид характеристики со значением. В ПВХ добавим в «Тип значения характеристик» созданный подчиненный справочник. В разделе «Дополнительные значения характеристик» (рис. 49) также укажем созданный подчиненный справочник: тем самым мы указываем системе, где будут храниться значения «нестандартных» характеристик. Также данная настройка приводит к тому, что при создании новой характеристики система по умолчанию будет создавать характеристику «нестандартного» типа (чаще всего так и бывает), однако это можно изменить. Реализуем хранение значений характеристик. Создадим регистр сведений «Значения свойств товаров», непериодический, независимый, включим в подсистему «Отдел закупок». Измерения: «Номенклатура» (тип СправочникСсылка.Номенклатура, Ведущее) и «Свойство» (тип ПВХСсылка.ХарактеристикиНоменклатуры); ресурс – «Значение свойства» (тип Характеристика.ХарактеристикиНоменклатуры). Для ресурса на вкладке «Представление» панели свойств настроим «Связи параметров выбора»: отбор по владельцу для измерения «Свойство». Это необходимо для того, чтобы при выборе «нестандартных» характеристик, в форму выбора был представлен список не всех значений, хранящихся в подчиненном справочнике, а только тех, которые связаны с выбранным ранее «нестандартным» видом характеристики (аналогично использованию связей параметров выбора при работе с подчиненным справочником). Дополнительно для ресурса следует настроить «Связь по типу», где указать измерение «Свойство». Дело в том, что тип значений «Характеристика» - это составной тип данных, соответственно, ресурс может принимать значение любого из перечисленных в нем типов. Мы, в свою очередь, знаем, что ресурс должен быть того типа, какой тип у выбранного вида характеристики, указанной в измерении «Свойство». Поэтому реализуется такая связь по типу. Запустите систему в режиме отладки и проверьте реализованный механизм: задайте несколько характеристик стандартных (например, дата производства) и «нестандартных» (например, цвет и страна происхождения) типов. Для «нестандартных» характеристик заполните ряд значений. Заполните регистр сведений характеристиками некоторых товаров. Проверьте контроль уникальности. Самостоятельная работа №4: Предположим, организация продает одинаковые товары, с различными значениями характеристик. Например, карандаши разного цвета (красные, зеленые и т.д.). Очевидно, что в данном случае мы не можем регистр сведений заполнить значениями характеристик т.к. будет нарушаться уникальность. Для решения возникшей проблемы необходимо создать некий справочник «Варианты номенклатуры», подчиненный справочнику «Номенклатура». Соответственно, каждый вариант (карандаши красные, карандаши зеленые и т.д.) будет описан своим набором характеристик и их значений. Структуру регистра сведений для описания значений характеристик также следует изменить, добавив еще одно измерение «Вариант номенклатуры». Реализуйте данную возможность самостоятельно. Также реализуйте возможность учета (поступление, продажа, цены) товаров (в т.ч. автоматические подстановку цен и контроль остатков) для различных вариантов одной и той же номенклатуры. Для этого измените структуру необходимых регистров, документов, формы документов и исправьте процедуры их проведения. §9.2. Отчеты Отчеты – это то, к чему в итоге сводится деятельность организации. Необходимо получать итоговые отчеты о том, сколько и какого товары было продано за определенный период и на какую сумму; какую выручку получила организация; кто из сотрудников, сколько договоров заключил и какую прибыль принес; какие контрагенты наиболее часто работают с организацией; сколько товара есть на складах на данный момент; и т.д. Такая сводная, итоговая информация хранится в регистрах (сведений, накоплений и др.), а, если точнее, в виртуальных таблицах, формируемых на основании того, какие именно сгруппированные данные необходимо получить в отчете. Основным инструментом формирования отчетов служат запросы. В нынешних версиях «1С: Предприятия» для создания отчетов используется специальный инструмент «Система компоновки данных» (СКД). Создадим новый отчет «Остатки товаров», включим в его подсистему «Отдел закупок». На вкладке «Основные» окна настройки свойств выберем команду «Открыть схему компоновки данных» и нажмем «Готово». В результате откроется пустая схема компоновки данных, включающая в себя наборы данных для отчета и его настройки (рис. 50). Изначально необходимо при помощи запроса сформировать данные, выводимые в отчет. Для этого добавляем очередной набор данных типа «запрос» (рис. 50). В результате формируется пустой набор данных, для которого с помощью специальной кнопки запускаем конструктор запроса. Рис. 50. Система компоновки данных. Добавление набора данных Для получения остатков товаров, как и ранее, используем виртуальную таблицу «ОстаткиТоваровОстатки». В данной таблице содержится информация только о тех товарах, которые имеются на складе. Если мы хотим вывести остатки по всей номенклатуре, то необходимо с данной виртуальной таблицей левым соединением связать таблицу – справочник «Номенклатура». С учетом того, что в базе реализован учет различных вариаций одного и того же товара, то для получения остатков по вариантам товаров, еще одним источником данных будет справочник «Варианты номенклатуры» (который в свою очередь нужно связать со справочником-владельцем – «Номенклатура»). В запросе необходимо вывести все элементы справочников «Номенклатура» и «Варианты номенклатуры», с учетом взаимосвязей между ними, а для тех комбинаций «Номенклатура+Вариант», для которых есть остатки – выведем количество имеющегося товара из виртуальной таблицы. В указанном запросе мы добавили таблицу «Номенклатура» (справочник), и в то же время в качестве измерения второго источника (виртуальной таблицы «Остатки») также фигурирует «Номенклатура». Данная ситуация с точки зрения конструктора может вызвать неоднозначную интерпретацию того, к чему идет обращение: к справочнику или к измерению регистра. Для исключения конфликта, справочник-источник данных необходимо переименовать, допустим, в «спрНоменклатура». Далее из «спрНоменклатура» выбираем поле «Наименование», из справочника «Варианты номенклатуры» – тоже «Наименование», а из виртуальной таблицы остатков – «КоличествоОстаток» и «СтоимостьОстаток». Переходим на закладку связи и организуем следующие левые соединения (рис. 51): Рис. 51. Связи между таблицами - источниками данных в отчете «Остатки товаров» Поясним описанные связи. Первая связь – левое соединение таблицы «Варианты номенклатуры» и «ОстаткиТоваровОстатки»: выбираются все возможные вариации номенклатурных позиций, а для тех из них, для которых есть соответствие в виртуальной таблице, присоединяются соответствующие записи. После введения ПВХ и возможности ведения учета товаров в разрезе вариантов, в регистре накопления хранится информация по каждому варианту, а не по номенклатуре в целом. Вторая связь – это полное внутреннее соединение таблиц «Варианты номенклатуры» и «Номенклатура»: производится поиск соответствия между всеми элементами справочников по соответствующим полям условия связи (рис. 51). Напомним, что справочник «Варианты номенклатуры» подчинен справочнику «Номенклатура». Поэтому, поле «Владелец» у справочника «Варианты номенклатуры» заполняется ссылкой на элемент справочника «Номенклатура». Описанная связь (рис. 51) каждому элементу подчиненного справочника находит его «Владельца» среди элементов справочника-владельца. Определим ряд условий в запросе на соответствующей вкладке. Справочник «Номенклатура» имеет иерархию групп и элементов. Остатки товаров задаются лишь в разрезе элементов, не групп. Соответственно, из результата запроса нужно исключить записи, содержащие группы; добавляем условие: спрНоменклатура.ЭтоГруппа = ЛОЖЬ В справочнике «Номенклатура» есть как товары, так и услуги. Остатки накапливаются лишь в разрезе товаров, поэтому из результата запроса нужно исключить записи, содержащие услуги: необходимо наложить условие на поле «Вид номенклатуры». В конструкторе запроса данное поле перенесем из левого окна в правое. Сформированное условие будет в виде: спрНоменклатура.ВидНоменклатуры = &ВидНоменклатуры В тексте запроса указать конкретное значение (хоть «Вид номенклатуры» задается в конфигураторе) не удастся т.к. оно хранится в перечислении (а в запрос можно передавать лишь значения предопределенных элементов справочника). Поэтому &ВидНоменклатуры – это параметр запроса, значение которого мы заполним позже в СКД. На вкладке «Объединения/Псевдонимы» переименуем поля «Наименование» в «Номенклатура» и «Вариант» для соответствующих таблиц. На этом формирование запроса завершим и вернемся к настройкам СКД (рис. 52). В результате сформированного запроса мы получим все необходимые данные, поэтому нет необходимости в дополнительных наборах данных. На вкладке «Вычисляемые поля» (рис. 52) можно добавить поля, которые будут рассчитываться на основе получаемых из запроса полей. Рис. 52. Настройка СКД после формирования запроса (набора данных) Так, необходимо, к примеру, получить среднюю себестоимость единицы каждой номенклатурной позиции. Средняя себестоимость единицы товара – СтоимостьОстаток/КоличествоОстаток. Рис. 53. Настройка вычисляемых полей В поле «Путь данным» (рис. 53) указываем имя вычисляемого поля «Себестоимость». В результате автоматически сформируется «Заголовок» (типа псевдонима), который при необходимости можно изменить. В поле «Выражение» необходимо задать выражение для расчета. Запишем следующее выражение: ВЫБОР КОГДА ЕстьNULL(КоличествоОстаток, 0)<>0 ТОГДА СтоимостьОстаток/КоличествоОстаток КОНЕЦ Л.23 Поясним данный код. Поле «КоличествоОстаток» может принимать значение NULL (для тех товаров, по которым остатков нет). При помощи функции ЕстьNULL производится приведение данного поля к заданному числовому представлению – нулю. Также очевидно, что когда остаток равен нулю, себестоимость не должна считаться; во всех остальных случаях она вычисляется по приведенной ранее формуле. Для реализации такого условного оператора, в языке СКД (как и в языке запросов) есть специальная конструкция ВЫБОР КОГДА…ТОГДА, которую мы используем для проверки на неравенство нулю знаменателя («КоличествоОстаток») и вычисления себестоимости когда это допустимо. В поле «Тип значения» (рис. 53) в раскрывающемся списке выбираем: Число, длина 15, точность 2. В конце настраиваем представление данного числа. В поле «Оформление» (рис. 53) открываем список, настраивающий формат поля (рис. 54a). (а) (b) Рис. 54. Настройка формата поля (a) при помощи конструктора форматной строки (b) Для этого выбираем параметр «Формат», и в поле «Значение» открываем конструктор форматной строки (рис. 54b). Данный конструктор в удобном режиме позволяет настроить формат выводимых данных. Производится настройка вывода числа, поэтому указываем длину 15, точность 2. После чего закрываем конструктор форматной строки и настройку формата поля. На вкладке «Ресурсы» (рис. 52) можно добавить те поля, по которым система будет формировать Итоговые (суммируемые записи) по полям группировок (рис. 55). Рис. 55. Настройка ресурсов в отчете Поля группировок будут настроены позже, но, забегая вперед отметим, что ими будет поле «Номенклатура»: мы получим остатки не только по каждому варианту некоторой номенклатуры, но и по номенклатуре в целом. Нажав (рис. 55), мы предоставим системе возможность автоматически определить, какие ресурсы можно считать, т.е. все числовые поля. В поле «Рассчитывать по» вкладки «Ресурсы» для каждого ресурса можно настроить поля запроса, по которым необходимо вычислять итоги (рис. 55). По умолчанию итоги вычисляются по всем полям. В нашем примере, нет смысла считать ресурс «Себестоимость» (для единицы товара) по всей номенклатуре, или даже по каждой группе: нас будет интересовать себестоимость лишь отдельных вариантов номенклатуры. Поэтому среди всех полей отметим лишь поле «Вариант». На вкладке «Параметры» СКД (рис. 52) настраиваются и задаются параметры, передаваемые в запрос. Рис. 56. Настройка параметров в СКД Мы видим два параметра (рис. 56): «Период» и «ВидНоменклатуры». В конструкторе запроса для отчета мы не настраивали параметры виртуальной таблицы остатков неслучайно: СКД уже «знает» что такое виртуальные таблицы и как с ними работать. Поэтому при их добавлении в запрос СКД автоматически определяет параметры, особенно связанные с периодом, которые можно задать. Поэтому ряд «стандартных» параметров виртуальных таблиц можно не задавать вручную – все равно в СКД при формировании отчета они будут присутствовать. Параметр «ВидНоменклатуры» - это параметр, в котором необходимо указать на то, что остатки необходимо определять лишь для «Товаров», «Услуги» следует исключить из результата запроса. Для этого заполняем поле «Значение» (рис. 56) соответствующим образом. Чтобы пользователь не смог этот параметр изменить, отмечаем галочку «Ограничение доступности». Если есть необходимость, чтобы при формировании отчета пользователь мог изменять значение параметра (как, например, для «Периода»), то «Ограничение доступности» следует отключить. В представленной настройке (рис. 56), также возможно добавить свои собственные параметры, настроить их тип, значение и т.д. На вкладке «Настройка» (рис. 52) формируется внешний вид отчета. Все, что было сделано до этого, относилось лишь к данным, которыми оперирует и которые выводятся в отчете. А то, как эти данные будут отображены в интерфейсе, устанавливается лишь при настройке отчета. Во-первых, сразу отметим, что в СКД есть возможность создать несколько типов отчета (списком, таблицей, диаграммой). Дополнительно можно сделать несколько различных вариантов (рис. 57), а в режиме исполнения выбирать нужный способ представления. Рис. 57. Настройка вариантов отчета в СКД Для формирования любого из вариантов, самый простой способ – использование конструктора настроек. Для этого в панели инструментов нажмем (рис. 57). Выберем формирование отчета в виде списка. Далее укажем вывод в отчет всех полей. Далее укажем группировку по полю «Номенклатура», тип группировки «Иерархия». При настройке варианта отчета возможно три типа группировки: без иерархии (будут выводиться все записи без учета иерархии), иерархия (будут выводиться все записи с учетом иерархии), только иерархия (будут выводиться лишь записи верхнего уровня, т.е. только элементы-родители). На заключительной вкладке конструктора настроек не будем задавать упорядочение. В результате сформируются настройки по умолчанию. Сформированные настройки в дальнейшем можно изменить: отредактировать выбранные поля, настроить условное оформление и т.д. (рис. 55). При этом все настройки можно выполнить как для отчета в целом («Отчет»), так и для отдельных группировок («Номенклатура», «Детальные записи»), что указано на рис. 55. Следует отметить, что группировка «Детальные записи» существует всегда, вне зависимости от того, были иные группировки или нет. Данная группировка содержит все записи, возвращаемые запросом в наборе данных. На вкладке «Параметры» окна «Настройка» (рис. 57) необходимо указать параметры, которые необходимо отображать в интерфейсе. Здесь представлен список параметров, указанных в соответствующем разделе ранее (рис. 56) для которых не установлен флаг «Ограничение доступности». В данном случае – среди параметров присутствует только «Период», для указания даты, на которую необходимо получить остатки номенклатуры. Для отображения данных параметров в интерфейсе, указанные настройки необходимо включить в «Пользовательские настройки» (рис. 58) при помощи (рис. 57). «Быстрый доступ» (рис. 58) необходим для того, чтобы при запуске отчета указанные параметры отображались на главной странице отчета. Если режим редактирования изменить на «Обычный», то для задания параметров отчета необходимо перейти в раздел «Еще - Настройка». Рис. 58. Свойства элементов пользовательских настроек После того, как все указанные действия (формирование набора данных запросом, создание вычисляемых полей, задание ресурсов, параметров отчета, настройка представления отчета) выполнены, можно запустить систему в режиме исполнения и сформировать отчет на текущую дату, а также на ряд предыдущих (чтобы посмотреть, как изменялись остатки). Обратите внимание на формирование итоговых записей (те поля, которые были добавлены в ресурсы отчета). Самостоятельная работа №5: Сформируйте следующие отчеты: 1. сколько товара поступило, сколько было израсходовано за определенный период, а также, сколько товара было на начало и конец выбранного периода (представить в виде таблицы); 2. какова выручка от продаж контрагентам в выбранном периоде (представить в виде диаграммы); 3. какие услуги принесли больше всего прибыли в порядке убывания (представить в виде двух вариантов: в виде списка и в виде диаграммы); 4. *создайте отчет, в котором можно задать отбор с учетом характеристик товаров. К примеру, чтобы пользователь мог получить данные о том, сколько у него есть товара, допустим, красного цвета или сколько товаров из США и т.д. Темы для самостоятельного изучения: 1. Использование характеристик в отчетах 2. Использование нескольких наборов данных в отчетах 3. Задание пользовательских параметров отчета 4. Создание нескольких вариантов отчета 5. Настройка условного оформления, группировок, отбора в отчетах 6. *Создание отчетов без использования системы компоновки данных (с применением макетов) Занятие 10. Доработка интерфейса конфигурации В целом, можно сказать, что на этом разработанное прикладное решение уже представляет собой некоторый пусть черновой, упрощенный, но законченный вариант по автоматизации деятельности нашей организации (за исключением бухгалтерского и зарплатного учета). Сейчас уделим еще немного времени настройке интерфейса. |