При створенні звітів на СКД часто виникає необхідність вивести на форму звіту вибір періоду, причому, щоб не потрібно було забивати дати вручну, а вибрати зі списку стандартних періодів, таких як: «Рок», «Місяць», «Тиждень» тощо. . Для параметрів типу Дата можна вказати лише «Початок цього року, місяця тощо», але «Закінчення» не передбачено.

Справа в тому, що з типів даних доступний тільки тип «Стандартна дата початку», а хочеться ще «Стандартна дата закінчення».

Існує спосіб як це обійти.

  1. Створимо новий параметр, назвемо його «Період»
  2. Встановимо для цього параметра тип "Стандартний період"
  3. У полі "Вираз" параметрів "ПочатокПеріоду" і "КінецьПеріоду", які використовуються в запиті, встановимо вирази " &Період.ДатаПочатку» та « &Період.ДатаЗакінчення» відповідно.

Але є невелика тонкість. Якщо ми використовуємо у запиті віртуальні таблиці, то, швидше за все, звіт перестане працювати і видаватиметься повідомлення про помилку типу «Помилка обробки подання, невідповідність типів, параметр номер...».

Щоб уникнути цього, потрібно прибрати всі параметри віртуальних таблиць.

І додати їх до таблиць на закладці «Компонування даних».

Для того, щоб параметри відображалися в швидких налаштуваннях звіту, увімкнемо відповідний прапор для параметрів звіту.

Тепер вибір періоду на формі звіту має такий вигляд.

Тож почнемо.

Для простоти розуміючи приклад будуватимемо одному простому оборотному регістрі накопичення.

У моєму випадку це регістр накопичення "Незавершене виробництво бухгалтерського обліку".

Його параметри для прикладу вкажемо жорстко (не через м'яке накладання параметрів на СКД):

Звернімо увагу, періодичність віртуальної таблиці – "Запис".

Але, як було помічено вище, період нам потрібен у розрізі періодичності, тому поле "Період" я пропоную обчислити наступним шляхом (не дуже красиво, але краще варіантів я не бачив):

Як видно зі скріншоту, запит передається параметр, який користувач вказує на формі: Значення перерахування "Періодичність" - дане перерахування є практично у всіх типових рішеннях.

Його достічні типи вкажемо на вкладці "Параметри":

Цим налаштуванням ми форматуємо наш період, щоб все було красиво та раділо очей)

Ось, власне, самі формати:

Місяць: ДФ="ММММ рррр "р.""

День: ДФ = дд.ММ.гггг

Тиждень: ДФ = ""Тиждень з" дд.ММ.гггг"

Квартал: ДФ = "до "квартал" рррр "р."

Рік: ДФ = "гггг "р.""

Декада: ДФ = "Декада з" дд.ММ.гггг "

Півріччя: ДФ = ""Півріччя з" дд.ММ.гггг"

От і все. На виході маємо чудову картину:

У цій статті розглянуто деякі особливості налаштування періоду при використанні Системи Компонування Даних (СКД), проблеми які виникають через відмінність у понятті періоду між рядовим користувачем та системою 1С, а також запропоновані шляхи їх вирішення.
Більшість звітів, які розробляються за допомогою Системи компонування Даних (СКД), вимагають від користувача введення періоду, за який буде побудований звіт. Як правило, в СКД введення періоду організовано через параметри, за допомогою наступної конструкції див. Рис.1Цей спосіб введення періоду вважається "класичним", він описаний у статті на ІТС та іншій літературі, присвяченій розробці 1С, тому візьмемо його за основу. Розглянемо як приклад простий запит, який отримує всі документи Реалізація ТоварівПослуг за заданий період див. Рис.2При використанні цього звіту користувач задає період через параметри див. Рис.3Начебто все коректно ..., АЛЕ є маленька проблема:

Вся справа в тому, що переважна більшість користувачів «розуміють» період не так як його «розуміє» 1С.
1). Розглянемо Рис.3
З погляду користувача період не заданий, тобто НЕ ОБМЕЖЕНИЙ, тобто до звіту мають потрапити ВСІ документи без обмеження за датою.
«З точки зору» системи 1С параметр-період заданий і … обидві його межі дорівнюють 01.01.0001 та до звіту, потраплять лише документи з порожньою датою, що на практиці означає, що не потрапить жодного документа.
2). Розглянемо Рис.4
З погляду користувача до звіту мають потрапити всі документи починаючи з дати 28.01.2010.
«З точки зору» 1С період 28.01.2010 – 01.01.0001 викличе виняток.

Можна звичайно спробувати пояснити користувачеві, чому звіт не виводить ті документи, які він очікує побачити і як період представляється з точки зору 1С, але невдячна це справа, та й неправильне. Хороша програма має бути, перш за все, зручна користувачеві, тому як програма існує для користувача, а не навпаки, тому доведеться «навчити» 1С розуміти період, оскільки його розуміє користувач, а саме:
1). ПочатокПеріоду та ЗакінченняПеріоду не задано -> всі документи.
2). Задано тільки ПочатокПеріоду -> всі документи починаючи з ПочаткуПеріоду
3). Крім того перевірятимемо що б ЗакінченняПеріоду >= ПочатокПеріоду, і якщо це не виконується то будемо вважати що ЗакінченняПеріоду не задано, тобто. 2).
Виходячи з усього вищесказаного вираз для параметра ДатаЗакінчення матиме такий вигляд:

ВИБІР КОЛИ & Період.<&Период.ДатаНачала ТОГДА ДАТАВРЕМЯ(3999,12,31,23,59,59) ИНАЧЕ &Период.ДатаОкончания КОНЕЦ КОНЕЦ

Остаточний вид нашої конструкції вибору періоду представлений на Рис.5

Доброго часу доби, шановні читачі блогу сайт! Минулої статті ми дізналися, і навіщо ці ролі потрібні. А сьогодні у другій із цієї серії статей, ми розглянемо налаштування ролі з властивістю «Період», і навіть розглянемо приклади заповнення цих ролей. По полю за участю «Період» розраховується залишок. Так само, як і по полю за участю «Вимірювання», про яке ми поговоримо в інший раз. Тож почнемо!

Створимо новий звіт:

  1. У Конфігураторі виберемо пункт меню "Файл" - "Новий" - "Зовнішній звіт".
  2. Натисніть кнопку «Відкрити схему компонування даних». У діалозі, що відкрився, натиснемо кнопку «Готово».
  3. Тепер створимо , який звертається до віртуальної таблиці "Регістри Накопичення".
  4. Натисніть правою кнопкою миші на вузлі «НабориДаних» і виберемо рядок «Додати набір даних - Запит».
  5. Тепер натисніть кнопку «Конструктор запиту». Виберемо регістр накопичення «ТовариНаСкладахЗалишкиІОбороти» (конфігурація УТП).
  6. Відкриємо діалог «Параметри віртуальної таблиці» і вкажемо, що використовуватиметься періодичність «Авто», тобто можна буде вказувати кілька періодів.

Тепер налаштуємо вихідні поля. Нехай це будуть такі поля: «Реєстратор», «Період Місяць», «Номенклатура», «Якість» та інформація про залишки. Додавання поля здійснюється подвійним натисканням лівої кнопки на потрібному полі або за допомогою кнопки «>». Після додавання полів натисніть кнопку "ОК".

Зверніть увагу, що для деяких полів автоматично настроїлася роль із властивістю «Період».

Розглянемо які існують налаштування ролі для властивості «Період». По-перше, зазначається порядковий номер періоду. Нумерація має бути безперервною, починатися з одиниці, від молодших періодів до старших, тобто спочатку йтиме, наприклад, номер рядка, далі «Реєстратор», потім секунда, день, тиждень, місяць, квартал, рік.

Таким чином, повинні бути пронумеровані поля, які зустрічаються в нашому запиті. Зауважте, що ми маємо два поля періоду — «Реєстратор» та «ПеріодМісяць». Молодшим полем є «Реєстратор» йому присвоєно одиниця, а старшим полем є «Період Місяць» йому присвоєно двійку. Більш докладно ми розглянемо в наступній статті.

Налаштуємо наш звіт:

  1. Перейдемо на закладку «Ресурси» та визначимо ресурси нашого звіту.
  2. Натисніть кнопку «>>», щоб вибрати всі поля для ресурсів.
  3. Тепер перейдемо на закладку "Налаштування" і створимо налаштування у вигляді списку.
  4. Натисніть кнопку «Конструктор налаштувань компонування даних» (кнопка як чарівної палички).
  5. Тип звіту: "Список". Натисніть кнопку "Далі".
  6. Налаштуємо вихідні поля, натиснувши кнопку «>>». Упорядкуємо їх так: "Період Місяць", "Номенклатура", "Якість", "Реєстратор".
  7. Натисніть кнопку «Далі» та налаштуємо угруповання. Угруповання налаштуємо в наступному порядку: "Період Місяць", "Номенклатура", "Якість". Угруповання «Реєстратор» буде виводитись у вигляді детальних записів.
  8. Натисніть кнопку "ОК".

Відкриємо наш звіт. Якщо ми виконаємо цей звіт, побачимо деякі особливості при отриманні залишків. Якщо уважно придивитися до результату звіту, то відразу помітно кілька помилок. Зокрема, чомусь на початку періоду діяльності компанії існує початковий залишок.

І ця помилка пов'язана з особливістю отримувати залишки за реєстратором. Щоб ці залишки виводилися коректно, необхідно додати ще одне поле у ​​вихідні поля запиту до цього поля «ПеріодСекунда». Для додавання поля «ПеріодСекунда» відкриємо звіт у конфігураторі, натисніть кнопку «Відкрити схему компонування даних». Тепер натисніть кнопку «Конструктор запиту» і додамо «ПеріодСекунда». У цьому випадку поле "Реєстратор" у нас залишиться першим полем періоду, "ПеріодСекунда" буде другим, а "ПеріодМісяць" буде третім.

Навіщо потрібна секунда? Система компонування даних обчислює залишки розрахунковим шляхом, і щоб однозначно визначити положення реєстратора на тимчасової осі самого посилання на реєстратор недостатньо, потрібна ще й секунда, тобто дата цього реєстратора, і тоді система компонування зможе розрахунковим шляхом отримати правильний залишок. Якщо вкажемо правильний порядок полів та сформуємо звіт заново, то отримаємо:

Наразі залишку на початок діяльності за номенклатурою «Плінтус» уже немає. Далі наступного періоду він збігається з кінцевим залишком, тобто бачимо справді правильний результат. Приклад звіту можна завантажити за посиланням нижче. Чи сподобалася вам стаття? Що можна змінити, що додати? Не соромтеся ділитися про це у коментарях!

Наприкінці статті хочу порадити вам безкоштовний від Сотнікова Анатолія. Це курс досвідченого програміста. Він на окремій базі покаже вам, як робити звіти в СКД. Вам тільки потрібно уважно слухати та запам'ятовувати! Ви отримаєте відповіді на такі запитання:
  • Як створити простий звіт у вигляді списку?
  • Навіщо потрібні колонки Поле, Шлях і Заголовок на закладці «Поля»?
  • Які існують обмеження для полів компонування?
  • Як правильно налаштовувати ролі?
  • Які існують ролі для полів компонування?
  • Де знайти закладку компонування даних у запиті?
  • Як настроювати параметри в СКД?
  • Далі ще цікавіше...
Напевно, чи не варто самому намагатися борознити інтернет у пошуках потрібної інформації? Тим більше, все готове для застосування. Тільки почніть! Всі подробиці про те, що є у безкоштовних відеоуроках

Ось один із уроків про закладання компонування даних у запиті:



Деякі особливості налаштування періоду в СКД.

Більшість звітів, які розробляються за допомогою Системи компонування Даних (СКД), вимагають від користувача введення періоду, за який буде побудований звіт.

Як правило, в СКД введення періоду організовано через параметри, за допомогою наступної конструкції див. Цей спосіб введення періоду вважається "класичним", він описаний у статті на ІТС та іншій літературі, присвяченій розробці 1С, тому візьмемо його за основу. Розглянемо як приклад простий запит, який отримує всі документи Реалізація ТоварівПослуг за заданий період див.

При використанні цього звіту користувач задає період через параметри див. Начебто все коректно ... АЛЕ є маленька проблема:

Вся справа в тому, що переважна більшість користувачів «розуміють» період не так як його «розуміє» 1С.

З погляду користувача період не заданий, тобто НЕ ОБМЕЖЕНИЙ, тобто до звіту мають потрапити ВСІ документи без обмеження за датою.

«З точки зору» системи 1С параметр-період заданий і … обидві його межі дорівнюють 01.01.0001 та до звіту, потраплять лише документи з порожньою датою, що на практиці означає, що не потрапить жодного документа.

З погляду користувача до звіту мають потрапити всі документи починаючи з дати 28.01.2010.

«З точки зору» 1С період 28.01.2010 – 01.01.0001 викликає виняток.

Можна звичайно спробувати пояснити користувачеві, чому звіт не виводить ті документи, які він очікує побачити і як період представляється з "точки зору" 1С, але невдячна ця справа та й неправильна. Хороша програма має бути, перш за все, зручна користувачеві, тому як програма існує для користувача, а не навпаки, тому доведеться «навчити» 1С розуміти період, оскільки його розуміє користувач, а саме:

1). ПочатокПеріоду та ЗакінченняПеріоду не задано -> всі документи.

2). Задано тільки ПочатокПеріоду -> всі документи починаючи з ПочаткуПеріоду

3). Крім того перевірятимемо що б ЗакінченняПеріоду >= ПочатокПеріоду, і якщо це не виконується то будемо вважати що ЗакінченняПеріоду не задано, тобто. 2).

Виходячи з усього вищесказаного вираз для параметра ДатаЗакінчення:

КОЛИ &Період.ДатаЗакінчення=ДАТАЧАС(1,1,1)

ТОДІ ДАТАВРЕМЯ(3999,12,31)

КОЛИ &Період.ДатаЗакінчення<&Период.ДатаНачала

ТОДІ ДАТАВРЕМЯ(3999,12,31)ДАТАВРЕМЯ(3999,12,31,23,59,59)

&Період.ДатаЗакінчення

Остаточний вид нашої конструкції вибору періоду представлений на

Примітка: цей механізм установки параметрів призначений для старих платформ 1С 8.1 і 8.2 (і конфігурацій, що працюють під їх керуванням), у старших версіях платформи 1С є вбудовані механізми для контролю незаповнених параметрів і вдаватися до механізму описаного в цій статті немає жодної необхідності, крім того на деяких версіях платформи 1С можливі помилки та некоректна робота.