Есть несколько вариантов вывода информации перед основным отчетом,какой лучше?! - зависит от задачи:
Допустим нам нужно вывести дату и время формирования отчета и свою шапку отчета, например так:
Варианты решения:
1. Использование группировки и макета заголовка:
1. Создаем в схеме новую группировку (без поля) и установим имя группировке Шапка отчета.
2. Удалим у данной группировки из выбранных полей автополе
В других настройках выберем макет оформления "Без оформления" (иначе на наш макет будет накладываться стандартный макет и вокруг всех ячеек будет рамка)
На вкладке макеты добавляем макет заголовка группировки (при добавлении указываем наше имя группировки (Шапка отчета) и указываем область с нашими данными), справа в табличном документе пишем необходимый текст и параметр
Сохраняем, формируем и видим результат как выше
2. Программное изменение текста заголовка
Код нужно установить в процедуре модуля отчета ПриКомпоновкеРезультата()
еще пример:
3. Вывод табличного макета с параметром перед формированием отчета
Создаем макет ВыводСформирован, в нем создаем параметр Сформирован и назначаем имя области Заголовок
Данная функция возвращает значение Истина, если хотя бы в одной из таблиц перерасчета есть хотя бы одна запись по данному документу. Если таких записей нет, то функция вернет значение Ложь, и перерассчитывать записи этого документа не нужно.
Собственно перерасчет записей, как и их расчет, рекомендуется выполнять в процедуре общего модуля по тем же причинам, что и расчет. Процедура перерасчета отличается от процедуры расчета только тем, что в расчете участвуют не все записи документа, а только удовлетворяющие усло- виям проводимого перерасчета. Например, только записи по конкретным сотрудникам и конкретным видам расчета.
Наконец, после того как нужные записи перерассчитаны, необхо- димо средствами встроенного языка удалить соответствующие записи из таблицы перерасчета, так как перерасчет больше не требуется.
Процедуру перерасчета записей документа рекомендуется помещать в модуле этого документа как экспортную процедуру. В этом случае она может быть вызвана из других модулей, в том числе из обработки перерасчета, описанной в предыдущем разделе. В качестве параметров в процедуру должна передаваться информация о том, какие именно записи документа необходимо перерассчитать. Ниже приведен пример такой процедуры, где в качестве параметра используется список сотрудников, по которым необходимо выполнить перерасчет.
Процедура перерасчета записей документа
Процедуры общего модуля, выполняющие непосредственный перерасчет записей, по алгоритму схожи с процедурами расчета. Основное отличие состоит в том, что в процедурах перерасчета происходит расчет только тех записей, которые удовлетворяют заданным условиям. В данном случае это записи по заданному списку сотрудников. Также при перерасчете не нужно производить предварительную запись набора с формированием фактического периода действия, так как набор уже записан в регистр (перерассчитываемый документ всегда проведен). Ниже приведен пример процедур ПерерассчитатьЗаписиРегистраРасчета() и ПерерассчитатьНаборЗаписей(). Эти процедуры используют вызов тех же самых процедур и функций, которые используются при расчете.
Механизм бизнес-процессов автоматически формирует задачи по точкам маршрута в соответствии с настройками свойств адресации.
Однако в некоторых случаях встает необходимость программно переопределить стандартное создание задач. Для этого предназначены обработчики ПередСозданиемЗадач() и ПриСозданииЗадач().
Под согласованием понимается предварительная оценка проекта документа и/или получение согласия на его утверждение.
Бизнес-процесс согласования состоит из трех точек маршрута:
* определение списка рецензентов;
* cогласование рецензентами;
* обработка результата согласования.
В бизнес-процессе участвуют инициатор согласования и рецензенты.
После старта бизнес-процесс попадает на 1-ю точку маршрута, на которой инициатора согласования выбирает документ для согласования и определяет список рецензентов. После того, как инициатор выполняет свою задачу, бизнес-процесс переходит к следующей точке маршрута, на которой формируется по одной задаче для каждого из указанных рецензентов. При интерактивной активации задач рецензентов открывается форма для ввода текста согласования, после закрытия которой задача выполняется. После согласования у всех рецензентов, бизнес-процесс возвращается обратно инициатору для обработки результатов согласования.
После выполнения этой задачи бизнес-процесс завершается.
Так как исполнителей заранее определить нельзя , то в пояснении точек маршрута вписаны строки "Инициатор" и "Рецензенты" для того, чтобы сделать карту нагляднее. С этой же целью точке маршрута "На согласование" установлено свойство "Групповая", хотя реально оно не используется механикой бизнес-процесса, т.к. все задачи формируются программно.
Исполнителем первой и последней точки является инициатор бизнес-процесса. Исполнители точки "На согласование" определяются списком рецензентов, который составляет инициатор.
Формирование задач на точках "Определить список рецензентов" и "Обработать результаты" происходит в обработчике ПередФормированиемЗадач() и отличается тем, что в первом случае свойство "Сотрудник" берется из параметра сеанса, а во втором - из свойства "Инициатор" бизнес-процесса:
На точке "На согласование" задачи формируются в обработчике "ПриСозданииЗадач" путем перебора элементов табличной части "Рецензии":
Пожалуй, начнем сразу с практического примера.
В справочник Контрагенты нам необходимо заносить информацию о поставщиках, покупателях, банках, налоговых органах, различных фондах и пр. Для каждого вида контрагента нас интересует разная информация.
Создадим функцию, возвращающую список «важных» реквизитов в зависимости от вида контрагента:
Где же ее правильнее разместить?
Напрашивается вариант - в процедуре Модуля объекта «ПередЗаписью()». Тем самым мы на этапе записи будем контролировать правильность заполнения нужных нам реквизитов. С точки зрения создания, изменения элемента справочника, нас все устраивает. Но если нам необходимо, чтобы некоторые менеджеры заносились контрагентов в ИБ без контроля, а спустя какое-то время мы будем выполнять проверку на корректность заполнения данных в справочнике. Тогда нужно будет написать обработку. И в этой обработке, перебирая элементы, проверять заполнение реквизитов. Т.о. эту функцию придется разместить в коде обработки. А это получается дублирование кода, со всеми вытекающими проблемами. Можно получать объект каждого элемента, обращаться к функции, расположенной в его Модуле объекта. Но это будет дополнительные обращения к БД, тогда как в обработке нам достаточно только ссылок.
Можно выйти из этой ситуации создав Общий модуль «РаботаСКонтрагентами» и разместить в нем функцию возвращающую список реквизитов для проверки. В этом случае будем обращаться так «РаботаСКонтрагентами.ПолучитьСписокВажныхРеквизитов(ВидКонтрагента)».
Но! На платформе 8.2 как раз для решения подобной задачи и был создан Модуль менежера. Там и разместим нашу функцию. А обращаться мы будем: «Справочники.Контрагенты.ПолучитьСписокВажныхРеквизитов(ВидКонтрагента)».
Т.о. на ряду с предопределенными методами, мы можем самостоятельно разработать свои процедуры и обращаться к ним как методам Менеджера объекта, через точку. У нас отпадает необходимость создавать «тематические» внешние модули такие как «Работа с Контрагентами», «Процедуры Номенклатуры»...
Обратимся теперь к теории, чтобы «разложить все по полочкам».
Руководство разработчика дает нам следующее описание: «Модуль менеджера существует у всех прикладных объектов и предназначен для управления этим объектом как объектом конфигурации. Модуль менеджера позволяет расширить функциональность менеджеров за счет введения процедур и функций на встроенном языке. Фактически это позволяет описать методы для объекта конфигурации, которые относятся не к конкретному экземпляру объекта базы данных, а к самому объекту конфигурации». Именно это мы и разобрали в нашем практическом примере.
Отобразим иерархию классов прикладных объектов на примере Справочников:
Т.е. мы видим, что появление «Модуля менеджера объекта» логично расширяет свойства класса СправочникМенеджер, так же как экспортные процедуры «Модуля объекта» расширяют методы класса СправочникОбъект. Нужно ли было создавать «Модуль прикладного объекта Справочники (Документы, Перечисления)». Наверное нет. Достаточно трудно придумать какие-либо задачи для единой обработки всех видов справочников.
Кроме возможности расширения методов класса, в модуле менеджера существует предопределенная процедура События . Она возникает на сервере перед стандартным формированием списка при вводе по строке, автоподборе текста и быстром выборе, а также при выполнении метода «ПолучитьДанныеВыбора()».
Так же хочу обратить внимание. При использовании конструктора печати прикладного объекта, платформа расположит процедуру формирования табличного документа непосредственно в Модуле менеджера. И это логично. Теперь, чтобы получить табличный документ элемента справочника нет необходимости получать объект. Достаточно кода: .
Для пользователя:
Последовательность документов есть в УПП, УТ (8), ТиС, ПУБ (7). Операции – Проведение документов, на закладке «Восстановление последовательностей» приведены все имеющиеся в программе последовательности и указана дата актуальности каждой из них. То есть если в июне 2010 года мы видим такое:
то это плохо. Партионный учет давно неактуален, значит – все значения себестоимости, которые появляются в отчетах, врут. (Учет кадров и налоговый учет УСН в данной базе не ведется).
Что значит последовательность? Строго говоря, одним из правил учета является его оперативность, т.е. отражение хозяйственных операций по мере их возникновения. 1 июня на склад поступило 10 штук товара А, потом 10 июня продано 8 штук. Если проводить эти документы (Поступление товаров и услуг, Реализация товаров и услуг) строго в хронологическом порядке, то последовательность установится сначала на 1 июня, потом на 10 июня. Т.е. ее граница будет сдвигаться вперед каждым документом, и итоги (количество, сумма, себестоимость) будут актуальными на каждый момент времени. Если же потом, задним числом, провести еще один документ (Реализация товаров и услуг) от 8 июня, которым будет оформлена реализация 7 штук товара А, программа дает это сделать беспрепятственно. Граница последовательности при этом установится на 8 июня, на этот документ. То есть информация ДО ввода этого документа верна, а ПОСЛЕ – уже нет. При восстановлении последовательности (перепроведении документов, входящих в последовательность), документ от 10 июня проведен не будет, потому что нет необходимого количества товара А. Далее пользователь должен искать причину этой ошибки, устранять и восстанавливать последовательность заново.
Как часто восстанавливать последовательность? Как минимум – перед выполнением регламентных операций, формированием значимых отчетов и т.п. Поскольку любое перепроведение документа (относящегося к последовательности) сдвигает ее границу, имеет смысл закрывать для редактирования прошлые периоды (Сервис – Установка даты запрета изменения данных).
В Бухгалтерии последовательности нет (за исключением кадровых приказов – в 8.1), но есть возможность автоматического перепроведения документов за период. Перед закрытием месяца это делать необходимо (Операции – Проведение документов). Для программиста: Последовательность – объект метаданных 1С – предназначена для упорядоченного хранения множества документов согласно дате и времени.
Граница последовательности (ГП) – позиция, последнего введённого документа в последовательность. Если после ГП есть другие документы в последовательности, то последовательность считается нарушенной и её необходимо восстановить.
Логически - последовательность можно условно представить как «Общий» журнал документов входящих в эту последовательность. Условно, потому, что на последовательностях строится логика учета.
У некоторых последовательностей, для дополнительного контроля автоматически при движении регистров, отслеживается связь: регистр – последовательность. Если изменился регистр, должна измениться и последовательность.
Физически – последовательность состоит из двух таблиц:
1. Таблица регистрации;
2. Таблица границ.
Таблица регистрации (ТР) – коллекция зарегистрированных в последовательности документов в разрезе измерений. В случае повторной записи документа сначала удаляется старая запись, затем записывается новая.
Таблица границ (ТГ) – хранит границу последовательности в разрезе измерений, одно измерение – одна запись если измерений нет, то у ТГ одна запись. Запись ТГ показывает, какой документ в ТР является последним правильно проведённым, т.е. не нарушившим правильное ведение учёта.
Обе таблицы идентичны по составу колонок: «Период», «Регистратор», «Измерение».
Восстановить последовательность возможно путём простого программного переноса ГП (если вы уверены, что итоги не нарушены) на последний документ в последовательности или повторным, последовательным проведением всех документов от ГП до последнего по времени документа в последовательности. Для исправления последовательности существует штатная обработка «Проведение документов».
Механизм «последовательность» имеет подчинённые объекты, свойство – измерения.
Измерения – это разрезы последовательности. Измерения, условно разбивают последовательность на несколько логически целых частей.
Измерение позволяет, в случае необходимости, перепроводить не все документы, входящие в последовательность, а только те которые содержат данное измерение, что ускоряет скорость работы при восстановлении последовательности.
Измерения повышают производительность системы в целом, так как при записи и проведении захватывается не вся таблица целиком, а только те её строки, которые соответствуют данному измерению.
Регистрация документа в последовательности, т.е. в ТР, производится в момент его записи.
Регистрация документа в последовательности может осуществляться автоматически, под руководством системы, если свойство «Заполнение последовательностей» документа будет установлено в «Заполнять автоматически» если иначе, то сам разработчик описывает правила регистрации.
Запись в ТГ происходит при проведении документа.
При проведении документа, его движения учитываются в:
· «Оперативном учёте» - записывает движения документа в регистрах;
· «Бухгалтерском учёте» - запись проводок.
ПоследовательностьМенеджер.< ИмяПоследовательности > - Данный менеджер предназначен для управления последовательностью:
Последовательность.«ИмяПоследовательности».Восстановить
Последовательность.«ИмяПоследовательности».ПолучитьГраницу
Последовательность.«ИмяПоследовательности».ПолучитьГраницы
Последовательность.«ИмяПоследовательности».Принадлежит
Последовательность.«ИмяПоследовательности».Проверить
Последовательность.«ИмяПоследовательности».СоздатьНаборЗаписей
Последовательность.«ИмяПоследовательности».УстановитьГраницу
Вся работа «ПоследовательностьМенеджер» складывается из анализа и работы с ТР и ТГ. Например, метод «Проверить» - если документ в ТГ, есть последний в ТР, значит, последовательность не нарушена и наоборот и т.д. Что такое Последовательности Документов
Как в СКД вывести дату и время формирования отчета? 
