Головна Інстаграм

1с віртуальна таблиця залишки та обороти. Вкладка Пакет запитів

Вирішив зробити свій внесок і описати ті особливості мови, які не були розглянуті в наведених вище статтях. Стаття орієнтована на розробників-початківців.

1. Конструкція "ІЗ".

Для того, щоб отримати дані з бази, зовсім необов'язково використовувати конструкцію "З".
Приклад: Нам необхідно вибрати всю інформацію про банки з довідника.
Запит:

ВИБРАТИ Довідник.Банки.*

Вибирає всі поля із довідника Банки. І є аналогічним запиту:

ВИБРАТИ Банки. * З Довідник. Банки ЯК Банки

2. Упорядкування даних по посилальному полю

Коли нам необхідно впорядкувати дані запиту за примітивними типами: "Рядок", "Кількість", "Дата" і т.д., то все вирішується використанням конструкції "Упорядкувати за", якщо вам необхідно впорядкувати дані по посилальному полю? Посилальне поле є посилання, унікальний ідентифікатор, тобто. Власне кажучи якийсь довільний набір символів і нормальне впорядкування може видати неочікуваний результат. Для упорядкування посилальних полів використовується конструкція "АВТОПОРЯДОЧУВАННЯ". Для цього необхідно спочатку впорядкувати дані безпосередньо за посиланням типу конструкцією "Упорядкувати за", а потім конструкція "автоупорядкування".

У цьому випадку для документів упорядкування відбуватиметься в порядку "Дата->Номер" для довідників за "Основним поданням". Якщо упорядкування відбувається не за посиланнями, то використовувати конструкцію "АВТОПОРЯДОЧУВАННЯ" не рекомендується.

У деяких випадках конструкція "АВТОПОРЯДОЧУВАННЯ" може уповільнювати процес вибірки. Аналогічно можна переписати без автоупорядкування для документів:

3. Отримання текстового подання типу посилання. Конструкція "ПРЕДСТАВЛЕННЯ".

Коли вам необхідно вивести для показу поле посилання типу, наприклад поле "Банк", яке є посиланням на елемент довідника "Банки", то необхідно розуміти, що при виведенні цього поля автоматично виконається підзапит до довідника "Банки", щоб отримати подання довідника. Це уповільнюватиме виведення даних. Для того, щоб цього уникнути, необхідно використовувати конструкцію "ПРЕДСТАВЛЕННЯ" в запиті, щоб відразу отримати подання об'єкта і вже його виводити для перегляду.

У система компонування даних цей механізм використовується за замовчуванням, а ось при формуванні макетів в комірках слід вказувати подання поля посилання, а наприклад, у розшифровку поміщати саме посилання.

4. Умова на вибірку даних за шаблоном.

Наприклад, вам необхідно отримати мобільні телефони працівників виду (8-123-456-78-912). Для цього необхідно поставити таку умову у запиті:

ВИБРАТИ Співробітник.Найменування, Співробітник.Телефон ЯК Телефон З Довідник.Співробітники ЯК Співробітники ДЕ Телефон ПОДІБНО "_-___-___-__-__"

Символ "_" є службовим та замінює будь-який символ.

5. Одночасне використання підсумків та угруповань.

Підсумки часто використовуються разом із угрупованнями, у разі агрегатні функції в підсумках можна не вказувати.

ВИБРАТИ Надання Послуг. Організація ЯК Організація, Надання Послуг. ганізація, Номенклатура

У цьому випадку запит поверне практично те саме, що і такий запит:

ВИБРАТИ Надання Послуг. Організація ЯК Організація, Надання Послуг. Номенклатура ЯК Номенклатура, Надання Послуг.

Тільки перший запит згорне записи з однаковою номенклатурою.

6. Розіменування полів.

Звернення до полів через точку називається операцією розіменування поля посилання. Наприклад Оплата. Організація. Адміністративна Одиниця. В цьому випадку в полі "Організація" документа "Оплата" посилається на іншу таблицю "Організації", в якій буде отримано значення реквізиту "Адміністративна Одиниця". Важливо розуміти, що при зверненні до полів через точку платформа неявно створює підзапит і з'єднує ці таблиці.

Запит:

Можна уявити у вигляді:

ВИБРАТИ Оплата.Посилання, Оплата.Організація, Оплата.Організація, Організації. Адміністративна Одиниця З Документ. Оплата ЯК Оплата ЛІВОЕ З'ЄДНАННЯ Довідник. Організації ЯК Організації ПЗ Оплата.

При розіменуванні полів посилань складового типу платформа намагається створити неявні з'єднання з усіма таблицями, які входять в тип цього поля. У цьому випадку запит буде неоптимальним. Якщо чітко відомо, якого типу поле, необхідно обмежувати такі поля за типом конструкцією ВИРАЗИТИ().

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

ВИБРАТИ НерозподіленіОплати.Реєстратор.Дата, ..... З РеєстрНакопичення.НерозподіленіОплати ЯК НерозподіленіОплати

слід обмежити тип складеного поля реєстратор:

ВИБРАТИ ВИРАЗИТИ(НерозподіленіОплати.Реєстратор ЯК Документ.Оплата).Дата, ..... З РеєстрНакопичення.НерозподіленіОплати ЯК НерозподіленіОплати

7. Конструкція "ДЕ"

При лівому з'єднанні двох таблиць, коли ви накладаєте умову "ДЕ" на праву таблицю, то ми отримаємо результат аналогічний результату при внутрішньому з'єднанні таблиць.

приклад. Необхідно вибрати всіх Клієнтів із Довідника клієнти і для тих клієнтів, у яких є документ оплата зі значенням реквізиту "Організація" = &Організація вивести документ "Оплата", для тих, хто не має, не виводити.

Результат запиту поверне записи лише для тих клієнтів, які мали оплату по організації в параметрі, а інших клієнтів відсіє. Тому необхідно спочатку отримати всі оплати за "такоюсь" організацією у тимчасовій таблиці, а потім уже з'єднувати з довідником "Клієнти" лівим з'єднанням.

ВИБРАТИ Оплата.Посилання ЯК Оплата, Оплата.Пайщик ЯК Клієнт ПОМІСТИТИ оплати З Документ.Оплата ЯК Оплата ДЕ Оплата.Відділення = &Відділення; //////////////////////////////////////////////////// ////////////////////////////// ВИБРАТИ Клієнти.Посилання ЯК Клієнт, ЄNULL(тОплати.Оплата, "") ЯК Оплата З Довідник .Клієнти ЯК Клієнти ЛІВОЕ З'ЄДНАННЯ тОплати ЯК тОплати ПО Клієнти.Посилання = тОплати.Клієнт

Можна обійти цю умову іншим способом. необхідно накласти умову "ДЕ" у зв'язку двох таблиць. Приклад:

ВЫБРАТЬ Клиенты.Ссылка, Оплата.Ссылка ИЗ Справочник.УС_Абоненты КАК УС_Абоненты ЛЕВОЕ СОЕДИНЕНИЕ Документ.Оплата КАК Оплата ПО (Клиенты.Ссылка = Оплата.Клиент И Оплата.Клиент.Наименование ПОДОБНО "Сахарный Пакет") СГРУППИРОВАТЬ ПО Клиенты.Ссылка, Оплата. Посилання

8. З'єднання з Вкладеними та Віртуальними таблицями

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

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

ВИБРАТИ НерозподіленіОплатиЗалишки.Клієнт, НерозподіленіОплатиЗалишки.СумаЗалишок З (ВИБРАТИ Клієнти.Посилання ЯК Посилання З Довідник.Клієнти ЯК Клієнти ДЕ Клієнти.Посилання В(&Клієнти)) ЯК ВкладенийЗапрошенняЛЕПІДІСЛЕННЯ АК Нерозподілені Оплати ПЗ Вкладений Запит. Посилання = Нерозподілені Оплати Залишки.

При виконанні такого запиту можливі помилки оптимізатора СУБД при виборі плану, що призведе до неоптимального виконання запиту. При з'єднанні двох таблиць оптимізатор СУБД вибирає алгоритм з'єднання таблиць виходячи з кількості записів в обох таблицях. У разі наявності вкладеного запиту визначити кількість записів, яка поверне вкладений запит вкрай складно. Тому замість вкладених запитів завжди варто використовувати часові таблиці. Тому перепишемо запит.

ВИБРАТИ Клієнти.Посилання ЯК Посилання ПОМІСТИТИ тКлієнти З Довідник.Клієнти ЯК Клієнти ДЕ
Посилання В (&Клієнти) ; //////////////////////////////////////////////////// ////////////////////////////// ВИБРАТИ тКлієнти. Посилання, Нерозподілені Оплати Залишки. (, Клієнт В (ВИБРАТИ тКлієнти.Посилання З тКлієнти)) ЯК НерозподіленіОплатиЗалишки ПО тКлієнти.Посилання = НерозподіленіОплатиЗалишки.Клієнти

В даному випадку оптимізатор зможе визначити, скільки записів використовує тимчасова таблиця тКлієнти і зможе підібрати оптимальний алгоритм з'єднання таблиць.

Віртуальні таблиці , дозволяють отримати практично готові дані для більшості прикладних завдань. Ці таблиці є фізичними, а компонуються системою нальоту, тобто. при отриманні даних із віртуальних таблиць система збирає дані з підсумкових таблиць регістрів, компонує, групує та видає користувачеві.

Тобто. при з'єднанні з віртуальною таблицею відбувається з'єднання з підзапит. У цьому випадку оптимізатор СУБД також може вибрати неоптимальний план з'єднання. Якщо запит формується недостатньо швидко і в запиті використовуються з'єднання у віртуальними таблицями, то рекомендується винести звернення до віртуальних таблиць у тимчасову таблицю, а потім зробити з'єднання між двома тимчасовими таблицями. Перепишемо попередній запит.

ВИБРАТИ Клієнти.Посилання ЯК Посилання ПОМІСТИТИ тКлієнти З Довідник.Клієнти ЯК Клієнти ІНДЕКСОВАТИ ПО Посилання ДЕ
Посилання В (&Клієнти) ; //////////////////////////////////////////////////// ////////////////////////////// ВИБРАТИ Нерозподілені Оплати. Сума Залишок, Нерозподілені Оплати. Клієнт В (ВИБРАТИ тКлієнти.Посилання З тКлієнти)) ЯК Нерозподілені Оплати Залишки; //////////////////////////////////////////////////// ////////////////////////////// ВИБРАТИ тКлієнти.Посилання, залишки.СумаЗалишок ЯК СумаЗалишок З тКлієнти ЯК тКлієнти тКлієнти.Посилання = тЗалишки.Клієнт

9.Перевірка результату виконання запиту.

Результат виконання запиту може бути порожнім, для перевірки порожні значення слід використовувати конструкцію:

РезЗапроса = Запрос.Выполнить(); Якщо резЗапроса.Пустой() Тоді Повернення; КінецьЯкщо;

Метод Порожній()слід використовувати до методів Вибрати()або Вивантажити(), тому що на отримання колекції витрачається час.

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

Це позбавить систему синтаксичної перевірки запиту в циклі.

11. Конструкція "МАЮЧІ".

Конструкція, що досить рідко зустрічається в запитах. Дозволяє накладати умови на значення агрегатних функцій (СУМА, МІНІМУМ, СЕРЕДНЕ і т.д.). Наприклад, вам необхідно вибрати тільки тих клієнтів, у яких сума оплат у вересні була більшою за 13 000 рублів. Якщо використовувати умову "ДЕ", то доведеться спочатку створювати тимчасову таблицю або вкладений запит, там групувати записи по сумі оплати та потім накладати умову. Конструкція "МАЮЧІ" допоможе цього уникнути.

ВИБРАТИ Оплата.Клієнт, СУМА(Оплата.Сума) ЯК Сума З Документ.Оплата ЯК Оплата ДЕ МІСЯЦЬ(Оплата.Дата) = 9 ЗГРУПУВАТИ ПО Оплата.

У конструкторі для цього достатньо перейти на вкладку "Умови", додати нову умову та поставити галочку на "Довільне". Далі просто написати Сума(Оплата.Сума) > 13000

12. Значення NULL

Я не описуватиму тут принципи тризначної логіки в БД, є безліч статей на цю тему. Просто коротко про те як NULLможе вплинути результат запиту. Значення NULL насправді не значення, а факт, що значення не визначено, невідомо. Тому будь-які операції з NULL повертають NULL, чи то додавання, віднімання, розподіл чи порівняння. Значення NULL не можна порівняти зі значенням NULL, оскільки ми знаємо, що саме порівнювати. Тобто. обидва ці порівняння: NULL = NULL, NULL<>NULL - це не Істина чи не Брехня, це невідомо.

Давайте розглянемо приклад.

Нам необхідно для тих клієнтів, які не мають оплат, вивести поле "Ознака" зі значенням "Ні оплат". Причому ми достеменно знаємо, що такі клієнти у нас є. І для того, щоб відобразити суть того, що писав вище, зробимо це так.

ВИБРАТИ "Ні оплат" ЯК Ознака, NULL ЯК Документ ПОМІСТИТИ оплати; //////////////////////////////////////////////////// ////////////////////////////// ВИБРАТИ Клієнти.Посилання ЯК Клієнт, Оплата.Посилання ЯК Оплата ПОМІСТИТИ тКлієнтОплата З Довідник.Клієнти ЯК Клієнти ЛІВОЕ З'ЄДНАННЯ Документ.Оплата ЯК Оплата ПО Клієнти.Посилання = Оплата.Пайщик; //////////////////////////////////////////////////// ////////////////////////////// ВИБРАТИ тКлієнтОплата.Клієнт З тКлієнтОплата ЯК тКлієнтОплата ВНУТРІШнє З'ЄДНАННЯ тОплати ЯК тОплати ПО тКлієнтОплата. Документ

Зверніть увагу на другу тимчасову таблицю тКлієнтОплата. Лівим з'єднанням я вибираю всіх клієнтів та всі оплати за цими клієнтами. Для тих же клієнтів, які не мають оплат у полі "Оплата", буде NULL . Наслідуючи логіку, в першій тимчасовій таблиці "тОплати" я позначив 2 поля, одне з них NULL, друге рядок "Не має оплат". У третій таблиці я з'єдную внутрішнім з'єднанням таблиці "тКлієнтОплата" та "тОплати" по полях "Оплата" та "Документ". Ми знаємо, що в першій таблиці поле "Документ" це NULL, і в другій таблиці у тих, хто не має оплат у полі "Оплата" теж NULL. Що ж поверне нам таке з'єднання? А нічого не поверне. Тому що порівняння NULL = NULL не набуває значення Істина.

Щоб запит повернув нам очікуваний результат, перепишемо його:

ВИБРАТИ "Ні оплат" ЯК Ознака, ЗНАЧЕННЯ(Документ.Оплата.ПустаПосилання) ЯК Документ ПОМІСТИТИ оплати; //////////////////////////////////////////////////// ////////////////////////////// ВИБРАТИ Клієнти.Посилання ЯК Клієнт, ЄNULL(Оплата.Посилання, ЗНАЧЕННЯ(Документ.Оплата.ПустаПосилання) )) ЯК Оплата ПОМІСТИТИ тКлієнтОплата З Довідник.Клієнти ЯК Клієнти ЛІВОЕ З'ЄДНАННЯ Документ.Оплата ЯК Оплата ПО Клієнти.Посилання = Оплата.Пайщик; //////////////////////////////////////////////////// ////////////////////////////// ВИБРАТИ тКлієнтОплата.Клієнт З тКлієнтОплата ЯК тКлієнтОплата ВНУТРІШнє З'ЄДНАННЯ тОплати ЯК тОплати ПО тКлієнтОплата. Документ

Тепер у другій тимчасовій таблиці ми вказали, що у випадку, якщо поле "Оплата" є NULL, тоді це поле = порожнє посилання на документ оплата. У першій таблиці ми також замінили NULL на порожнє посилання. Тепер у поєднанні беруть участь не NULL поля і запит поверне нам очікуваний результат.

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

13. Недокументована особливість конструкції "ВИБІР КОЛИ...ТОДІ....КІНЕЦЬ".

У разі, коли необхідно описувати у запиті контрукцію "Умови", ми використовуємо стандартний синтаксис:

ВИБРАТИ ВИБІР КОЛИ Користувачі.Найменування = "Вася Пупкін" ТОДИ "Наш улюблений співробітник" Інакше "Не знаємо такого" КІНЕЦЬ ЯК Поле1 З Довідник.Користувачі ЯК

А що робити, якщо, наприклад, нам треба отримати назву місяця у запиті? Писати величезну конструкцію у запиті негарно і довго, тому нас може виручити така форма запису вище:

ВИБІР МІСЯЦЬ (УС_РозрахунокСпоживання_ГрафікОбороти.ПеріодРозрахунку) КОЛИ 1 ТОДІ "Січень" КОЛИ 2 ТОДІ "Лютий" КОЛИ 3 ТОДІ "МІТКА КОЛИ 7 ТОДІ "Липень" КОЛИ 8 ТОДИ "Август" КОЛИ 9 ТОДИ "Вересень" КОЛИ 10 ТОДИ "Жовтень" КОЛИ 11 ТОДИ "Листопад" КОЛИ 12 ТОДИ "Грудень"

Тепер конструкція виглядає не такою громіздкою та легко сприймається.

14. Пакетне виконання запиту.

Щоб не плодити запити, можна створити один великий запит, розбити його на пакети і працювати вже з ним.
Наприклад, мені потрібно отримати з довідника "Користувачі" поля: "ДатаНародження" та доступні ролі для кожного користувача. вивантажити це в різні табличні частини на формі. Звичайно, можна зробити це в одному запиті, тоді доведеться перебирати записи або згортати, а можна так:

ВИБРАТИ Користувачі.Посилання ЯК ПІБ, Користувачі.ДатаНародження, Користувачі.Роль ПОМІСТИТИ в Користувачі З Довідник.Користувачі ЯК Користувачі; //////////////////////////////////////////////////// ////////////////////////////// ВИБРАТИ в Користувачі. ПІБ, ВТ Користувачі. Дата народження; //////////////////////////////////////////////////// ////////////////////////////// ВИБРАТИ втКористувачі.ПІБ, втКористувачі.Роль З втКористувачі ЯК втКористувачі ЗГРУПУВАТИ ПО вкористувачі.ПІБ, вт. Дата народження

тПакет = Запрос.ВыполнитьПакет();

ТП_ДатиНародження = тПакет.Выгрузить();
ТП_Ролі = тПакет.Вивантажити();

Як ми бачимо, запит можна виконати в пакеті та працювати з результатом як з масивом. У деяких випадках дуже зручно.

15. Умови пакетного запиту

Наприклад, у нас є пакетний запит, де спочатку ми отримуємо поля: "Найменування, ДатаНародження, Код" з довідника "Користувачі" і хочемо з довідника "ФізОсоба" отримати записи з умовою по цих полях.

ВИБРАТИ Користувачі.ФізОсоба.Найменування ЯК Найменування, Користувачі.ФізОсоба.ДатаНародження ЯК ДатаНародження, Користувачі.ФізОсоба.Код ЯК Код ПОМІСТИТИ в Користувачі З Довідник.Користувачі ЯК //////////////////////////////////////////////////// ////////////////////////////// ВИБРАТИ ФізичніОбличчя.Посилання ЯК ФізОбличчя З Довідник.

Можна накласти умови таким чином:

ДЕ ФізичніОбличчя.Код В (ВИБРАТИ втПользователи.Код З втКористувачі) І ФізичніОбличчя.Найменування В (ВИБРАТИ втКористувачі.Код З втКористувачі) І ФізичніОбличчя.

А можна й так:

ДЕ (Фізичні Особи. Код, Фізичні Особи. Найменування, Фізичні Особи.

Причому обов'язково дотримуватися порядку.

16. Виклик конструктора запитів для "умови" у пакетному запиті

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

Необхідно після конструкції "В" поставити дужки і між дужками залишити порожнє місце (пробіл), виділити це місце і викликати контруктор запитів. Контруктору буде доступно всі таблиці пакетного запиту. Прийом працює як на віртуальних таблицях регістрів, так вкладки "Умови". В останньому випадку необхідно поставити галочку "П(вільна умова)" і увійти в режим редагування "F4".

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

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

upd1. Пункти 11,12
upd2. Пункти 13,14,15,16

Використовувана література:
Мова запитів "1С:Підприємства 8" - Е.Ю. Кришталева
Професійна розробка у системі 1С:Підприємство 8".

При організації вибірок у реальних завданнях у переважній більшості випадків організується відбір даних відповідно до деяких умов.

У разі коли вибірка робиться з реальної таблиці, ніяких складнощів не виникає. Дані обробляються абсолютно очевидно:

У тому випадку, коли джерелом у запиті виступає віртуальна таблиця, ситуація стає дещо складнішою.

Мова запитів дозволяє накласти умову вибірку з віртуальних таблиць двома способами: у пропозиції ДЕ та з допомогою параметрів віртуальних таблиць. Обидва способи призведуть до одного результату (за винятком деяких специфічних випадків), проте вони далеко не еквіваленти.

Ми вже знаємо, що віртуальні таблиці тому і називаються віртуальними, що в основі їх насправді немає. Формуються вони лише тоді, коли до них звертається запит. Незважаючи на це нам (тобто тим, хто складає запит) зручно розглядати віртуальні таблиці саме як реально існуючі. Що ж станеться у системі 1С Підприємство 8, коли складений нами запит таки звернеться до віртуальної таблиці?

На першому етапі система побудує віртуальну таблицю. На другому кроці з отриманої таблиці будуть вибрані записи, які відповідають умові, заданій у пропозиції ДЕ:
Добре видно, що у підсумкову вибірку потраплять в повному обсязі записи з віртуальної таблиці (отже, і з бази даних), лише ті, які задовольняють заданому умові. А решту записів просто буде виключено з результату.

Таким чином, система зробить не просто марну, а подвійну марну роботу! Спочатку будуть витрачені ресурси на побудову віртуальної таблиці на основі зайвих даних (на малюнку вони позначені як «області даних А та Б»), а потім ще буде виконано роботу з фільтрації цих даних з остаточного результату.

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

У чому полягає відмінність значень параметра віртуальної таблиці "МетодДоповнення"?
Коли МетодДоповнення встановлено в "руху", то будуть видані тільки ті періоди, в яких були рухи. Коли встановлено "Руху Границі Періоду", тоді до вищевказаних рухів додадуться 2 записи: руху на початок і кінець заданого в параметрах ВТ періоду. Поле "Реєстратор" при цьому для цих 2 записів буде порожнім.

Інформація взята із сайту

У тому випадку, коли джерелом у запиті виступає віртуальна таблиця, ситуація стає дещо складнішою.

На першому етапі система побудує віртуальну таблицю. На другому кроці з отриманої таблиці будуть вибрані записи, які відповідають умові, заданій у пропозиції ДЕ:

Добре видно, що у підсумкову вибірку потраплять в повному обсязі записи з віртуальної таблиці (отже, і з бази даних), лише ті, які задовольняють заданому умові. А решту записів просто буде виключено з результату.

Чи не можна відразу, на етапі побудови віртуальної таблиці, відмовитися від використання непотрібних даних? Виявляється, можна. Саме для цього і призначено параметри віртуальних таблиць:

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

Викликаємо діалог введення параметрів віртуальної таблиці Ціни Зріз Останніх та вкажемо, що період буде переданий у параметрі Дата Звіту. Для цього виділимо цю таблицю у списку Таблиці та натиснемо кнопку Параметри віртуальної таблиці. Потім виберемо з таблиць такі поля:

СпрНоменклатура. Батько,

ЦіниЗріз Останніх.Ціна.

Ліве з'єднання таблиць

- На закладці Зв'язки: у полі Умова зв'язку, що значення виміру Номенклатура регістра відомостей має дорівнювати посиланням на елемент довідника Номенклатура. А також знімимо прапорець Все у таблиці регістру та встановимо його у таблиці довідника, тим самим встановивши вид зв'язку як ліве з'єднання для таблиці довідника:

Мал. 13.15. Зв'язок таблиць у запиті

- На закладці Умовизадамо умову вибору елементів довідника Номенклатура - елементи, що вибираються, повинні відповідати виду номенклатури, переданому в параметрі запиту Вид Номенклатури:

Мал. 13.16. Умови вибору елементів

- На закладці Об'єднання/Псевдоніми:вказати псевдонім поля Батько = Група Послуг, а поля Посилання = Послуга. - Натиснемо-

Після цього необхідно відредагувати схему компонування даних, для цього на закладці Ресурси, натиснемо на кнопку додатиі виберемо ресурс - Ціна

- На закладці Параметризадамо значення параметра ВидНоменклатури - Перерахування.ВидиНоменклатури.Послуга. Крім цього, знімемо обмеження доступності для параметра ДатаЗвіту. У полі Тип цього параметра задамо склад дати - Дата. Для параметра Період, навпаки, встановимо обмеження доступності:

Мал. 13.17. Параметри схеми компонування

Налаштування

- Перейдемо на закладку Налаштування:створимо угруповання по полю Група Послуг, вказавши тип угруповання Ієрархія.

Існують такі типи ієрархії для угруповань звіту:Без ієрархії – у групуванні виводяться лише неієрархічні записи. Ієрархія - угрупованні виводяться як неієрархічні, і ієрархічні записи. Тільки ієрархія - угрупованні виводяться лише ієрархічні (батьківські) записи. Усередині цього угруповання створимо ще одне, без вказівки групового поля. На підзакладці Вибрані поля:вкажемо поля для виведення Послуга та Ціна:

Мал. 13.18. Структура та поля звіту

На підзакладці Іншіналаштування здійснимо наступні дії:

Мал. 13.19. Налаштування виведення загальних підсумків для групування "Група послуг"

Мал. 13.20. Налаштування та виведення підсумків для глобального звіту

На закінчення включимо параметр Дата звіту до складу налаштувань користувача і встановимо для нього Режим редагування -Швидкий доступ. Закриємо конструктор схеми компонування даних та у вікні редагування об'єкта ПерелікПослуг перейдемо на закладку Підсистеми. Зазначимо у списку підсистем конфігурації підсистеми Надання послуг та Бухгалтерія.

У режимі 1С: Підприємство

Запустимо 1С: Підприємство в режимі налагодження і перш за все відкриємо періодичний регістр Ціни. Після цього протестуємо звіт.

Приклад цього звіту було вивчено, як система компонування даних отримує останні значення з періодичного регістру відомостей і як виводяться угруповання з ієрархії довідника.

Якщо моя публікація вам корисна, не забудьте поставити плюсик:-)

Тут рубрикатор з усіх завдань збірника(сторінка, де зібрані посилання на гілки форуму з кожного завдання)
http://chistov.spb.ru/forum/16-969-1

Ну а тепер мої напрацювання та нотатки, які я створив у процесі підготовки.
Постараюся щонайменше повторюватися зі згаданими вище двома останнімипублікаціями.

Отже, приступимо:

У разі віддаленого складання у вас має бути в кінці іспиту на робочому столі два об'єкти:

1. Підсумкове вивантаження інформаційної бази (файл dt)
2. Пояснювальна записка

Нічого іншого не повинно бути, жодних проміжних копій тощо.

Пояснювальну записку пишете обов'язково!
У разі нечітко сформульованого завдання обов'язково напишіть там, що вибрали саме такий варіант рішення.
Також у коді в ключових місцях краще залишати короткі коментарі, без фанатизму, але там, де можуть виникнути питання у екзаменатора, краще напишіть.

Але про це Вам і так буде сказано в інструкції, яку прочитають перед початком іспиту.
Просто краще знати заздалегідь)

Використання амперсанда знак в запитах.

Іноді швидше набрати з додаткової клавіатури, ніж перемикати туди-сюди розкладку, економиться час
& = Alt+38

*************************************************************************************************
Використання МоментВремени() у запитах

У запитах до регістрів накопичення бухгалтерії як параметр віртуальної таблиці (періоду) необхідно використовувати не дату документа, а параметр Момент який визначається в коді наступним чином:

Момент = ?(РежимПроведення = РежимПроведенняДокумента.Оперативний, Невизначено, Момент Часу());

*************************************************************************************************
При формуванні рухів документа з регістру на початку процедури обробки проведення необхідно очищати руху поточного документа з регістру.

Код такий:

Рухи. НазваРегістра.Записувати = Істина; Рухи. НазваРегістра.Очистити();

Можливо, що в процесі проведення потрібно буде аналізувати записи цього регістру.
Так ось, щоб при аналізі поточні записи (старі, до зміни документа) точно не потрапили у вибірку, до наведених двох рядків можна додати ще одну:

Рухи. НазваРегістра.Записати();

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

Але скрізь просто вказував відразу конструкцію з цих трьох рядків:

Рухи. НазваРегістра.Записувати = Істина; Рухи. НазваРегістра.Очистити(); Рухи. НазваРегістра.Записати();

*************************************************************************************************
Є два способи блокування даних, вибір між ними залежить від методики проведення – старої чи нової:

1) Звичайне кероване блокування, стара методика проведення документа (об'єкт Блокування Даних)

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

Приклад:

У документі - кількість, у регістрі - кількість та сума (собівартість)
Так ось, кількість товару ми знаємо з документа – скільки списуємо, а собівартість – ні.
Ми можемо її дізнатися тільки з регістру, але щоб ніхто не змінив регістр між моментом отримання залишків і моментом запису рухів, нам необхідно ще до читання залишків заблокувати регістр.
Так ось, у цьому випадку і використовується об'єкт Блокування Даних. І при його створенні правильніше вказати за якими вимірами ми блокуємо регістр (наприклад у нашому випадку – тільки за вказаною в документі номенклатурою) – щоб не було зайвих блокувань та інший користувач зміг продавати іншу номенклатуру.

1. Встановлюємо блокування за допомогою об'єкта БлокуванняДаних
2. Читаємо залишки
3. Перевіряємо можливість списання
4. Формуємо рухи, наприклад списуємо товар
5. Після проведення документа блокування автоматично знімається (блокування діє в рамках транзакції проведення та автоматично знімається системою). Тобто якось спеціально розблокувати об'єкт не треба.

2) Нова методика проведення документів (використання властивості БлокуватиДля Зміни = Істина)

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

Приклад:
Розглянемо операцію реалізації товару.
У документі – кількість, у регістрі – лише кількість
Так ось, кількість товару ми знаємо із документа.
Ми формуємо рухи із зазначеною в документі кількістю та записуємо їх. Далі читаємо регістр, дивимося залишки, аналізуємо – чи є негативні. Якщо є виводимо помилку та ставимо Відмова = Істина.

Тобто послідовність така:
1. Для руху по регістру встановлюємо властивість БлокуватиДля Зміни = Істина
2. Формуємо рухи - списуємо товар
3. Записуємо рухи
4. Читаємо регістр, дивимося, щоби не було негативних залишків. Якщо є – то списали зайве, якщо ні – то все нормально.

Так от, у цьому випадку немає необхідності вказувати за якими вимірами нам треба блокувати регістр.
Ми просто встановлюємо властивість БлокуватиДля Зміни = Істина до запису наших рухів, формуємо рухи та записуємо.
Система сама заблокує регістр у момент запису за тими вимірами, які треба проаналізувавши те, що ми записали.
Після проведення блокування зніметься.

Цей варіант (другий) простіше називається "нова методика проведення документів" і 1С рекомендує використовувати саме його у разі можливості і знімає бали, якщо використовується перший варіант, але в деяких випадках його просто неможливо застосувати і використовується перший варіант з об'єктом БлокуванняДаних (див. наведений вище приклад).

Також зауважу, що незалежно від обраного способу руху перед роботою з ними необхідно очистити (див. попередню пораду)

*************************************************************************************************
Блокування даних (спосіб блокування №1 наведеного вище опису)

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

Виглядає приблизно так:

Блокування = Новий БлокуванняДаних; ЕлементБлокування = Блокування.Додати("РегістрНакопичення.ТовариНаСкладах"); ЕлементБлокування.Режим = РежимБлокуванняДаних.Винятковий; Елемент Блокування. Джерело Даних = ТЧ; ЕлементБлокування.ВикористовуватиДжерелаДаних("Номенклатура", "Номенклатура"); Блокування. Заблокувати ();

*************************************************************************************************
Табличну частину документів краще називати просто ТЧ

Таблична частина 99% документів - одна. Така уніфікована назва табличних частин дуже допоможе заощадити час, оскільки:
1) Дуже коротке – швидко писати
2) Однакове для всіх документів, не доведеться згадувати при написанні коду як вона називається

*************************************************************************************************
Результат запиту перевіряти на порожнечу перед вибіркою чи вивантаженням у ТЗ.

Загалом у всіх завданнях використовував вибірку.

Вибірка оптимальна для системи з погляду продуктивності, оскільки " заточена " лише читання даних (на відміну ТЗ).

Але в будь-якому випадку до методу Вибрати() краще перевірити на порожнечу результат запиту, це ще зменшить навантаження на систему.

Результат = Запит.Виконати(); Якщо Не Результат.Пустой() Тоді Вибірка = Результат.Вибрати(ОбхідРезультатуЗапроса.Угрупуванням); ... КінецьЯкщо;

А якщо нам потрібно отримати лише одне значення із запиту
(наприклад, лише метод списання відповідно до облікової політики, встановленої на цей рік):

Результат = Запит.Виконати(); Якщо Не Результат.Пустой() Тоді Вибір = Результат.Вибрати(); Вибірка.Наступний(); Метод Списання Собівартості = Вибірка.Метод Списання Собівартості; КінецьЯкщо;

*************************************************************************************************
Документ "Операція" для завдання щодо БУ

Обов'язково потрібно створювати документ Операція для завдань щодо БУ.

Відключаємо у нього проведення взагалі (у властивостях "Проведення = Заборонити"), вказуємо, що робить рухи по регістру бухгалтерії, рухи витягуємо на форму.

*************************************************************************************************
Оперативне проведення документів:

Повинно бути увімкнено:
В оперативному та бух. облік у документів має бути включений (крім документа "Операція", див. нижче).

Повинно бути вимкнено:
у розрахункових завданнях немає сенсу документа нарахування зарплати.

Для документа "Операція" проведення взагалі має бути відключено (у властивостях документа "Проведення = Заборонити"),
оскільки він пише просто пише дані безпосередньо в регістр під час запису.

*************************************************************************************************
Умова у запиті виду "Або вказана номенклатура або будь-яка, якщо не вказана"

У запитах зустрічається таке завдання: наприклад, потрібно вибрати документи із зазначеною номенклатурою або всі документи, якщо номенклатура не вказана.
Вирішується такою умовою в самому запиті:

Номенклатура = &Номенклатура АБО &Номенклатура = Значення(Довідник.Номенклатура.ПустаПосилання)

Але більш оптимально і правильніше ця умова буде перетворити (спасибі yukon):

Запит.Текст = Запит.Текст + "ДЕ Номенклатура = &Номенклатура";

КінецьЯкщо;

З появою об'єктної моделі запиту в 8.3.5 умову можна буде додавати безпечніше:

Якщо значенняЗаповнено(Номенклатура) Тоді
Запрос1.Отбор.Добавить("Номенклатура = &Номенклатура");
Запит.ВстановитиПараметр("Номенклатура", Номенклатура);
КінецьЯкщо;

*************************************************************************************************
Приєднання таблиць у запитах:

Кількість підсумкових записів не залежить від того, чи буде виведено поле таблиці, що приєднується, залежить тільки від налаштованих зв'язків.
Тобто, поле приєднаної таблиці можна і не виводити.

Якщо потрібно приєднати таблицю без жодних умов, то на закладці з умовами просто писати умову "ІСТИНА".
І тут таблиця приєднається точно.

*************************************************************************************************
Використання плану видів характеристик (ПВХ):

1. Використання як механізм опису характеристик об'єктів.

1.1. Створюємо ПВХ. Це будуть види характеристик (наприклад, колір, розмір, макс. швидкість і т.д.). У налаштуваннях вибираємо всі можливі типи значень характеристик і, якщо потрібно, створюємо об'єкт з пункту 1.2 і вказуємо його також у налаштуваннях.

1.2. Для додаткових значень ПВХ створюємо підпорядкований йому довідник Додаткових ознак (або просто значення характеристик).
У ньому зберігаються характеристики, якщо їх немає в існуючих довідниках. Ми можемо його не створювати, якщо всі необхідні нам характеристики є в існуючих довідниках, або ці значення можна уявити елементарними типами даних. У налаштуваннях ПВХ вказуємо, що цей довідник буде використовуватися для додаткової інформації. значень характерестик.

1.3. Створюємо регістр відомостей, що власне і пов'язує три об'єкти:
- Об'єкт, до якого ми підключаємо механізм характеристик
- Вид Характеристики (тип ПВХ)
- значенняхарактеристики (тип - характеристика, це новий тип, який з'явився в системі після створення ПВХ
і описує всі можливі типи даних, які можуть набувати значення характеристики).
У регістрі відомостей вказуємо, що ВидХарактеристики є власником для ЗначенняХарактеристики (зв'язок параметра вибору), і навіть зв'язок за типом для ЗначенияХарактеристики знову ж таки від ВидаХарактеристики.

Ще така особливість, що для кожного виду характеристики, що створюється, можна вказувати тип значення характеристики, якщо не потрібні всі можливі типи для опису значення цієї характеристики.

2. Використання ПВХ для створення механізму субконто регістра бухгалтерії .

2.1. Створюємо ПВХ ВидиСубконто.

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

2.3. Зв'язок провадиться за допомогою плану рахунків.

*************************************************************************************************
Ресурси регістру бухгалтерії:

Сума - балансова,
Кількість - небалансова і пов'язана з ознакою обліку Кількісний

*************************************************************************************************
Віртуальні таблиці регістра бухгалтерії:

Обороти: обороти якогось одного рахунку
ОборотиДтКт: обороти між якимись двома рахунками, тобто всі однакові проводки у період.

*************************************************************************************************
Валютний облік на регістрах бухгалтерії - як реалізувати:

Створюємо ознаку обліку "валютний" у плані рахунків.
У регістрі бухгалтерії створюємо додатково:
- вимір Валюта (заборона незаповнених значень, небалансова, ознака обліку - валютна)
- ресурс Валютна Сума (небалансова, ознака обліку - валютна, в ній буде зберігатися сума у валюті, тобто 100 $ наприклад)
Всі.

Таким чином структура регістру:

Вимірювання:
- Валюта
Ресурси
- Кількість
- сума (сума в рублях)
- Валютна Сума (сума у валюті)

Отже валютний облік - це лише доопрацювання нормального обліку на РБ, не змінює суті наприклад ресурсу Сума
(Там як і зазвичай сума в рублях, незалежно від того, чи валютний рахунок чи ні).
І якщо ознака обліку Валютний для рахунку виключено, це звичайна структура РБ (ресурси - лише кількість і сума).

*************************************************************************************************
Умови для встановлення параметрів віртуальної таблиці для отримання зрізу останніх накладаємо на вимірювання, а не на ресурси.

Інакше отримаємо не зріз останніх, а останній запис із зазначеним значенням ресурсу - він може бути не останнім за набором вимірів

*************************************************************************************************
Сенс ресурсу та реквізиту в регістрі розрахунку

У регістрах розрахунку створення ресурсу дає можливість отримувати його при розрахунку бази цього регістру.
І навіть пропорційно заданому періоду перераховуватиметься значення ресурсу (якщо базовий період не збігається з періодичністю регістру).

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

*************************************************************************************************
Галочка "Базове" у властивостях вимірювання регістру розрахунку
Означає, що з цього виміру надалі виходитиме база і служить для додаткової індексації значень цього поля.

*************************************************************************************************
Розбивка періоду дії відпустки за місяцями під час запису наборів записів регістру,
якщо відпустка задається в документі одним рядком відразу на кілька місяців одним рядком:

ДатаПочаткуТек Місяця = ПочатокМісяця(ТекРядокОсновніНарахування.ПеріодДіїПочаток); ДатаЗакінченняТекМісяця = КінецьМісяця(ТекРядокОсновніНарахування.ПеріодДіїПочаток); ТекМісяць = Дата; Поки ДатаПочаткуТекМісяць<= НачалоМесяца(ТекСтрокаОсновныеНачисления.ПериодДействияКонец) Цикл Движение = Движения.ОсновныеНачисления.Добавить(); Движение.Сторно = Ложь; Движение.ВидРасчета = ТекСтрокаОсновныеНачисления.ВидРасчета; Движение.ПериодДействияНачало = Макс(ДатаНачалаТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияНачало); Движение.ПериодДействияКонец = КонецДня(Мин(ДатаОкончанияТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияКонец)); Движение.ПериодРегистрации = Дата; Движение.Сотрудник = ТекСтрокаОсновныеНачисления.Сотрудник; Движение.Подразделение = ТекСтрокаОсновныеНачисления.Подразделение; Движение.Сумма = 0; Движение.КоличествоДней = 0; Движение.График = ТекСтрокаОсновныеНачисления.График; Движение.Параметр = ТекСтрокаОсновныеНачисления.Параметр; Движение.БазовыйПериодНачало = НачалоМесяца(ДобавитьМесяц(Дата, -3)); Движение.БазовыйПериодКонец = КонецДня(КонецМесяца(ДобавитьМесяц(Дата, -1))); ДатаНачалаТекМесяца = НачалоМесяца(ДобавитьМесяц(ДатаНачалаТекМесяца, 1)); ДатаОкончанияТекМесяца = КонецМесяца(ДатаНачалаТекМесяца); КонецЦикла; КонецЕсли;

*************************************************************************************************
Побудова Діаграми Ганта:

Розміщуємо на формі елемент типу "Діаграма Ганту", називаємо ДГ, далі створюємо команду "Сформувати" і в модулі форми пишемо наступне:

&НаКлієнті Процедура Сформувати(Команда) СформуватиНаСервері(); КінецьПроцедури &НаСервері Процедура СформуватиНаСервері() ДГ.Очистити(); ДГ.Оновлення = Брехня; Запит = Новий Запит("ВИБРАТИ |ОсновніНарахуванняФактичнийПеріодДії.Співробітник, |ОсновніНарахуванняФактичнийПеріодДії.ВідРозрахунку, |ОсновніНарахуванняФактичнийПеріодДії.ПеріодДіїПочаток ЯКПеріодДій | ДіїКінець ЯК ПеріодДіїКінець |З |РегістрРозрахунки.ОсновніНарахування.ФактичнийПеріодДії ЯК ОсновніНарахуванняФактичнийПеріодДії |ДЕ |ОсновніНарахуванняФактичнийПеріодДії. "); Запит.ВстановитиПараметр("ДатаПочатку", Період.ДатаПочатку); Запит.ВстановитиПараметр("ДатаЗакінчення", Період.ДатаЗакінчення); Вибірка = Запит.Виконати().Вибрати(); Поки Вибірка.Наступний() Цикл Точка = ДГ.ВстановитиТочку(Вибірка.Співробітник); Серія = ДГ. Значення = ДГ. ОтриматиЗначення (Крапка, Серія); Інтервал = Значення.Додати(); Інтервал.Початок = Вибірка.ПеріодДії Початок; Інтервал.Кінець = Вибірка.ПеріодДіїКінець; КінецьЦикл; ДГ.Оновлення = Істина; КінецьПроцедури

Власне тут нам важливий тільки код у циклі, інші допоміжні речі, просто цілком навів всю реалізацію цієї підзавдання.
У запиті нам важливо, щоб був співробітник, вид розрахунку, дата початку та дата закінчення періоду.
Код насправді дуже простий, запам'ятати його легко, не лякайтеся, якщо здається громіздким

*************************************************************************************************
Обробка записів "сторно" у розрахункових задачах:

У процедурі обробки проведення (модуль об'єкта) формуємо всі рухи, а далі якщо є записи в інших періодах отримаємо їх так
(Система формує їх автоматично – допомагає нам):

ЗаписиДоповнення = Рухи.ОсновніНарахування.ОтриматиДоповнення(); // Записувати рухи для отримання доповнення не потрібно

Для кожного ТекРядку З ЗаписуДоповнення Цикл
Запис = Рухи.ОсновніНарахування.Додати();
ЗаповнитиЗначенняВластивостей(Запис, ТекРядку);
Запис.ПеріодРеєстрації = ТекРядка.ПеріодРеєстраціїСторно;
Запис.ПеріодДіїПочаток = ТекРядка.ПеріодДіїПочатокСторно;
Запис.ПеріодДіїКінець = ТекРядок.ПеріодДіїКінецьСторно;
КінецьЦикл

А під час розрахунку записів вставляти перевірки:

Якщо ТекРух.
ТекРух.Сума = - ТекРух.Сума;
КінецьЯкщо;

*************************************************************************************************
Як визначити що відносити до основних нарахувань, а що - до додаткових у розрахункових задачах.

Але не завжди це на 100% ясно, бувають і випадки складніші, хоча їх досить мало
(Наприклад премія, яка залежить від кількості робітників у місяці днів - це ВІН).

Основні нарахування:
Якщо за видом розрахунку є залежність від графіка (мається на увазі регістр відомостей з датами календаря), він належить до основних нарахувань.

Приклад ВІН:
- Оклад
- Щось, що вважається від кількості робочих днів (а для цього потрібно використовувати графік): або в період дії (як оклад), або в базовому періоді

Додаткові нарахування:
Те, що вважається або від нарахованої суми, або відпрацьованого (а не норми!) часу, або взагалі не залежить - це доп. нарахування.

Тобто: нарахування для розрахунку яких використовується норма часу (може ще й факт) – це ВІН, а для яких фактичні дані чи взагалі нічого не потрібно – це РН.

Або іншими словами:

Якщо ВР використовує норму часу, то ПВР має бути включений період дії.

*************************************************************************************************
Додати можливість у формі списку довідника "Номенклатура" можливість відкриття розділу вбудованої довідки "Робота з довідниками".

Зробити на формі команду:

&На Клієнті
Процедура Довідка(Команда)
Відкрити Довідку ("v8help://1cv8/EnterprWorkingWithCatalogs");
КінецьПроцедури

Рядок розділу визначаємо так:
Зайти в довідкову інформацію об'єкта конфігурації (у конфігураторі), написати слово, виділити його, зайти в меню Елементи/Посилання та вибрати потрібний розділ хелпу 1С, після чого посилання підставляється автоматично. Виглядає складно, на практиці – все легко.

*************************************************************************************************
Здійснення взаємодії між формами, наприклад, підбір:

1. З поточної форми відкриваємо потрібну методом "Відкрити Форму()", другим параметром передаємо структуру з параметрами (якщо треба). Третім параметром можемо передати посилання на цю форму - ЕтаФорма.

2. У формі, що відкривається в обробнику "ПриСтворенніНа Сервері()" ми можемо зловити передані в п.1 параметри через "Параметри.[Ім'яПараметра]". Форма, яка ініціалізувала відкриття цієї форми, буде доступна через ідентифікатор "Власник" (якщо вона, звичайно, була вказана в п.1).

І що найголовніше – будуть доступні експортні функції форми-власника. Тобто ми можемо викликати експортну функцію вихідної форми та передати туди щось параметр для обробки підбору. А ця функція вже заповнить що потрібно у вихідній формі. Лише одне застереження - передавати таблицю значень між клієнтськими процедурами не можна, але ми можемо помістити її у тимчасове сховище і передати просто адресу ВХ, а там витягти з ВХ.

*************************************************************************************************
Життєвий цикл параметрів форми

Всі параметри, передані у форму в момент її відкриття, видно тільки в процедурі «Притворення на сервері».
Після створення всі параметри знищуються і не доступні у формі.
Виняток становлять параметри, які у редакторі форми оголошені з ознакою «Ключовий параметр».
Вони визначають унікальність форми.
Такий параметр існуватиме доти, доки існує сама форма.

*************************************************************************************************
Використання інтерфейсу "Таксі"

При розробці можна встановити у властивостях конфігурації простий керований інтерфейс 8.2 - так все помітно компактніше і звичніше.
Особливо це актуально, якщо здаєте віддалено - роздільна здатність екрану дуже маленька, з інтерфейсом "таксі" неможливо нічого зробити.
Тільки не забудьте, коли все зробите поставити знову "Таксі"!Інакше екзаменатор зніме бали!

*************************************************************************************************

PS: Е сть окремі типові підзавдання, які використовують у всіх завданнях, саме їх і потрібно вміти вирішувати (наприклад, списання по партіях, використання ПВХ (ну це правда рідко) та інші). І у всіх завданнях вони просто повторюються (десь одні підзавдання є, десь інші, просто у різних комбінаціях). Тим більше, що збірку ж уже давно обіцяли новий випустити (якщо ще не випустили), в якому начебто завдань має бути набагато більше, тобто немає сенсу запам'ятовувати розв'язання окремих завдань, є сенс навчитися вирішувати окремі типові підзадачі, тоді вирішиш будь-яке завдання.

PSS: Колеги, якщо у когось є ще якась корисна інформація з підготовки до іспиту та складання, прохання писати в коментарях, доповнимо статтю.