Увага! Перед вами ознайомча версія уроку, матеріали якого можуть бути неповними.
Увійдіть на сайт як учень
Увійдіть як учень, щоб отримати доступ до матеріалів школи
Мова запитів 1С 8.3 для програмістів-початківців: функція ЗНАЧЕННЯ
Функція ЗНАЧЕННЯ призначена для зверненняу тексті запиту до значень системних перерахуваньі зумовленим даними.
Що ще за перерахування та зумовлені дані, запитайте ви. Давайте все по порядку.
Перерахування
Перерахування- це прикладний об'єкт (ви пам'ятаєте, що ще існують Довідникиі Документи). Навіщо він знадобився?
Справа в тому, що перерахування – це особливий об'єкт. На відміну від довідників та документів всі можливі значення перерахувань задаються на етапі конфігуруванняі не можуть бути надалі змінені в режимі користувача.
Незмінність – це їхній головний козир. Це своєрідні константи бази даних.
І якщо програміст у режимі конфігурування створив перерахування з ім'ям Підлогата значеннями Чоловічийі Жіночий, то при написанні програми може бути впевнений, що надалі значення цього перерахування не зміняться. Тому він може сміливо звертатися до цих значень із коду.
Уявіть, що буде, якщо він спробує з цією метою використати довідник?
По-перше, якийсь користувач візьме та й додасть якийсь "Марсіанський підлогу".
По-друге, інший користувач візьме та й видалить одну з вже існуючих підлог або ім'я йому поміняє.
А програма від цього зламається, тому що для її роботи необхідно, щоб було рівно дві статі і саме з іменами "Чоловічий" та "Жіночий".
Ось для таких випадків якраз і існують перерахування: щоб один раз (ще на етапі конфігурування) жорстко задати всі можливі варіанти значень і надалі використовувати їх у коді програм.
Давайте розглянемо приклад такого перерахування у нашій базі Гастроном. Ви читаєте ознайомлювальну версію уроку, повноцінні уроки .
Ось воно наше перерахування з ім'ям Підлога. Які значення воно може набувати?
Усього два значення. З іменами "Чоловічий" та "Жіночий". Те, що нам треба.
Де ми надалі можемо використати цей перелік? Ну, звісно, у довіднику Клієнти. Зверніть увагу, що у списку з'явився новий реквізит з ім'ям Підлогата типом Перерахування.:
Таким чином, при заповненні картки клієнта вже в режимі користувача ми зможемо як стать клієнта вибирати всього з двох значень Чоловічий і Жіночий:
Тепер давайте складемо запит, який вибирає клієнтів та їх підлогу з бази:
А тепер давайте змінимо запит, щоб залишилися лише чоловіки. Якщо ми спробуємо написати щось на кшталт:
то нічого не отримаємо:
Тому що до значень перерахунку так не можна звертатися. До них потрібно звертатися за допомогою функції ЗНАЧЕННЯ:
Отже, одне із завдань функції ЗНАЧЕННЯ- Використання в запитах значень перерахувань.
Зумовлені дані
Я краще покажу на прикладі, що таке наперед визначені дані для довідників. Ви читаєте ознайомлювальну версію уроку, повноцінні уроки .
У нашій базі "Гастроном" (у режимі користувача) відкрийте довідник "Одиниці виміру":
Придивіться його елементам. Бачите жовті кружечки поруч із деякими з елементів? Ось ці елементи (у яких кружечки) і є зумовлені дані.
Взагалі ж, якщо якийсь елемент довідника є зумовленим (тобто ньому стоїть жовтий кружечок), це особливий елемент.
По-перше, це означає, що елемент був створений ще на етапі конфігурування програмістом (у нашому випадку це елементи з кодами 1, 2 та 3).
А по-друге, це означає, що цей елемент дуже важливий для функціонування програми. Що на нього (вірніше на його наперед визначене ім'я) зав'язаний якийсь код у базі даних.
Саме тому просто видалити такий елемент не вдасться. Спробуйте помітити його на видалення:
Давайте тепер перейдемо в режим конфігурування і подивимося де ці найвизначеніші елементи (в даному випадку для довідника Одиниці вимірювання) створюються:
Ось вони всі наші визначені елементи для довідника Одиниця виміру. Зверніть увагу, що всі наперед визначені елементи мають спеціальне ім'я, яке не відображається в режимі користувача.
Для елемента з кодом 1 це ім'я Тонна, з кодом 2 Грам і так далі. Це ім'я називається визначеним ім'ям елементаі саме з цього імені можна звертатися до нього з коду (або із запиту у нашому випадку).
Ви запитаєте чому ж було не зробити одиниці виміру просто перерахуванням з елементами Тонна, Грам та Пачка? А все тому, що в даному випадку нам важливо, щоб довідник одиниці вимірювання завжди містив певні елементи (тонна, грам і пачка), але в той же час ми не хочемо забороняти користувачеві додавати якісь свої елементи (кілограм, штука і так далі). Ви читаєте ознайомлювальну версію уроку, повноцінні уроки .
Тому тут, безумовно, більше підходять зумовлені елементи, ніж перерахування.
А звертатися до наших наперед визначених елементів із запиту ми зможемо використовуючи вже знайому нам функцію ЗНАЧЕННЯ:
Пройдіть тест
Почати тест
1. Значення перерахунків задаються
2. Для зберігання списку складів фірмі підійде тип
3. Для зберігання списку одиниць виміру на складі підійде тип
4. Для зберігання ставок податку, список яких не повинен змінюватись користувачем, підійде тип
5. Щоб звернутися у запиті до значення переліку, підійде функція
6. Для зберігання ставок податку, список яких змінюватиметься користувачем, підійде тип
7. Зумовлені дані бувають у
Під час роботи на платформі 1С:Підприємство 8.x часто виникає необхідність прив'язатися до програмного коду до звичайних (не зумовлених) елементів довідників. Наприклад, у організації може бути п'ять видів цін, які використовуються практично у всіх механізмах. У цьому програмне звернення до конкретної ціні у разі здійснюється або писком по коду в довіднику, у найгіршому за найменуванням елемента.
Був свідком того, як у звітах для отримання необхідної ціни використовувався відбір за видом ціни у запиті щодо її найменування (див. наступний скріншот).
До того ж, якщо прив'язуватися до найменування або коду елементів довідника, то при отриманні посилання елемент завжди буде здійснюватися пошуку в таблиці довідника. Незважаючи на те, що стандартні реквізити системи індексуються СУБД, пошук за ними в деяких випадках може зайняти значні ресурси. До того ж, раціональніше було б не виконувати пошуковий запитпо таблиці довідника, якщо, скажімо, посилання на елемент і так " заздалегідь відома " .
Як вихід, можна зберігати посилання на кожен часто використовуваний елемент довідника Типи цін номенклатури в окремих константах і отримувати з них значення в запиті. Однак у такому разі розробнику доведеться додавати окрему константу для кожного подібного елемента. Ситуація значно ускладниться, якщо такі елементи будуть не лише у довіднику "Типи цін номенклатури", а й у інших довідниках ("Категорії об'єктів", "Якість", "Номенклатура" та інші). Тоді кількість констант у системі може збільшитись у кілька разів!
Звичайно можна було б додати наперед визначені елементи в кожен з довідників і звертатися до них стало б набагато простіше. Проте зміна типових об'єктів призвела б до ускладнення процесу оновлення конфігурації з пакетів постачальника.
Існує найбільш оптимальний підхід як з точки зору розробки структури метаданих конфігурації, так і з боку продуктивності системи. Про нього сьогодні й йтиметься.
Універсальне рішення
Суть універсального рішення полягатиме в наступному: буде створено довідник, до якого розробником додаватимуться визначені елементи. До довідника додано реквізит "Значення", тип якого залежить від значень, для яких буде створюватися відповідність "Зумовлений елемент довідника -> Пов'язане значення". Структура метаданих довідника виглядає так (див. наступний скріншот).
Для отримання визначеного елемента найкращим варіантомє використання глобального методу "ЗумовленеЗначення(<Имя>)" . Як параметр у метод передається повний шляхдо визначеного елементу. Синтаксис схожий на функцію мови запитів "ЗНАЧЕННЯ()" .
Для зручності розробки рекомендую винести функцію для отримання пов'язаного з визначеним елементом значення загального модуль. В тестової конфігурації, доступною для скачування за посиланням наприкінці статті, створено загальний модуль "ЗначенняПредвизначенихЕлементів" з експортною функцією "ОтриматиЗначенняПредвизначеногоЕлементу(<ИмяПредопределенногоЭлемента>)" . Програмний кодфункції отримує посилання на наперед визначений елемент, потім запитом отримує значень реквізиту "Значення". На наступному скріншоті наведено повний лістинг функції.
Як бачимо, функції формується запит до реквізиту "Значення" переданого як параметра визначеного елемента. Як параметр функції є рядок з ім'ям певного елемента.
Для правильної роботи створеного механізму потрібно зв'язати в режимі користувача визначений елемент зі звичайним елементом довідника, вибравши відповідний елемент в реквізиті "Значення". Перейдемо питання впливу на продуктивність.
Вплив на продуктивність
Проводив тест на швидкість для обох варіантів пошуку: за найменуванням та за посиланням з наперед визначеного елемента. Пошук проходив за довідником "Товари" із 20000 записів. Під час проведення тестів на файловій базі було отримано такі результати:
Результати показали, що для файлового варіанту роботи використання наперед визначених елементів для отримання часто використовуваних елементів інших довідників працює повільніше практично в 4 рази!
В клієнт-серверному варіантіРезультати роботи тестів показують зовсім іншу картину. Швидкість отримання посилання на потрібний елемент не значно знизилася (один з тестів показав 0.002 сек. для пошуку за найменуванням і 0.0008 сек. при роботі через зумовлений елемент), однак надійність роботи програми збільшилася в рази!
Висновки
Якщо часто необхідно прив'язуватися до звичайних елементів довідника, рекомендую не використовувати прив'язку за кодом або найменуванням. Цей підхід знижує надійність та продуктивність системи.
За час роботи з платформою не раз зустрічався з ситуаціями, коли після зміни найменування, наприклад, у елемента довідника "ТипиЦенНоменклатури", злітала робота у більшості не типових звітів.
Чим більше алгоритмів пов'язані зі звичайними елементами довідників через код або найменування, тим менш стійка система.
Крім того, цей підхід дозволить не змінювати типові об'єкти конфігурації, якщо необхідно додати до них визначений елемент. Надалі це зробить процес оновлення конфігурації дещо простіше.
Файли для завантаження:
- Вивантаження тестової бази із прикладами із статті.
Всім відомо відмінність наперед визначених елементів від звичайних: "Предвизначені елементи створюються в режимі "Конфігуратор" і не можуть бути видалені в режимі 1С:Підприємства". У режимі користувача відрізнити визначений елемент від доданих користувачами можна за спеціальною піктограмою (див. наступний скріншот).
Здебільшого зумовлені елементи створюються розробниками, щоб зав'язати саме них алгоритми у різних об'єкта конфігурації. Наприклад, у конфігурації "Управління виробничим підприємством" у довіднику "Якість" розробниками додано визначений елемент "Новий".
Цей елемент використовується у багатьох модулях конфігурації. Так, у документі "Надходження товарів та послуг" при виконанні проведення у всіх регістрах, де є вимір "Якість", підставляється значення зумовленого елемента. Далі наведено лістинг заповнення таблиці проведення за регістром "ТовариОрганизаций":
// ТОВАРИ З РЕЄСТРУ Товари Організацій.НабірРухів = Рухи. ТовариОрганізацій; Якщо ВидНадходження = Перерахування. ВидиНадходженняТоварів. На склад // Отримаємо таблицю значень, що збігається зі структурою набору записів регістру.ТаблицяРухів = НабірРухів. Вивантажити(); // Заповнимо таблицю рухів.Загального призначення. ЗавантажитиВТаблицюЗначень(ТаблицяПоТоварам, ТаблицяРухів) ; // Відсутні поля.ТаблицяРухів. ЗаповнитиЗначення(Організація, "Організація"); ТаблицяРухів. ЗаповнитиЗначення(Невизначено, "Комісіонер"); ТаблицяРухів. ЗаповнитиЗначення(Довідники. Якість. Новий, "Якість"); // Заповнюємо якість з визначеного елементаОтже, характерні риси зумовлених елементів та його призначення досить прості. Розглянемо спосіб їх зберігання у таблицях бази даних та його відмінність від звичайних елементів.
Відмінності
У тестовій конфігурації створено довідник "Товари". У ньому створено групу "Тестові елементи". Вміст групи Ви могли бачити на скріншоті на початку статті. Для довідника "Товари" в SQL-базі даних є відповідна таблиця "_Reference37" з наступною структурою:
Але як визначити відповідність реквізитів дереву конфігурації та полів у SQL-таблиці?
Скористаємося стандартним методом глобального контексту "ОтриматиСтруктуруЗберіганняБазиДаних()", який поверне нам таблицю значень з описом струкутри таблиць.
У таблиці значень "Поля" бачимо відповідність полів SQL-таблиці і реквізитів об'єкта в дереві метаданих. У прикладі ми розглядаємо структуру довідника " Товари " . У всіх довідників є стандартний реквізит "Зумовлений" бульового типу, який для наперед визначених елементів встановлений в ІСТИНІ:
По таблиці зі структурою зберігання довідника в базі даних ми можемо однозначно сказати, що поле "Призначений" відповідає полю "IsMetadata". Якщо ми переглянемо вміст таблиці "_Reference37" у SQL-базі, побачимо наступне:
У записі для визначеного елемента значення поля IsMetadata встановлено в "0x01", що відповідає прапорцю ІСТИНА. Для звичайних елементів значення встановлено "0x00". У цьому полягає головна відмінність зумовлених елементів від звичайних. Інші поля зберігаються у базі даних аналогічно полям звичайних елементів, доданих користувачами.
Наперед визначеним елементам можна знайти дуже цікаве призначення. З їх допомогою можна заборонити видаляти/помічати видалення групи елементів у довіднику та інших об'єктах, де їх можна додати. Якщо спробуємо видалити або помітити на видалення групу "Тестові елементи". то отримаємо такі помилки:
Таким чином, наперед визначені елементи роблять групу, в яку вони поміщені, теж "наперед визначеною".
Завершення
Обумовлені елементи є невід'ємною частиною більшості конфігурацій. Їх використання спрощує розробку та робить побудову функціоналу логічно більш "струнким" та цілісним.
Діє для версії платформи 1С:Підприємство 8.3.3 та вище без режиму сумісності з версією 8.2
1.1. У довідниках, планах рахунків, планах видів показників і планах видів розрахунку є можливість створювати визначені елементи автоматично чи програмно.
1.2. У більшості випадків, встановлені елементи рекомендується створювати автоматично, оскільки вони постійно потрібні і потрібно спростити звернення до цих елементів з коду.
Наприклад, визначена країна Росіяу довіднику Країни світу, визначені профіль груп доступу Адміністраторі т.п.
Для цього
- у властивості довідника, плану рахунків, плану видів характеристик або плану видів розрахунку має бути встановлено значення Авто(за замовчуванням), а також не слід допускати програмних викликів методу ВстановитиОновленняЗавданихДанихцих об'єктів для перемикання режиму.
- заборонити видалення визначених елементів користувачами, виключивши у всіх ролях такі права (за замовчуванням вимкнено):
- ІнтерактивнеВидаленняПредвизначенихДаних
- ІнтерактивнаПоміткаВидаленняПредвизначенихДаних
- ІнтерактивнеЗняттяПоміткиВидаленняПредвизначенихДаних
- ІнтерактивнеВидаленняПоміченихЗумовленихДаних
1.3. Виняток становлять дочірні вузли РИБ, в якому визначені елементи автоматично не створюються (і не оновлюються при зміні метаданих), а повинні бути передані з головного вузла разом зі змінами конфігурації.
При цьому:
а) конфігурація повинна забезпечувати завантаження повідомлення обміну в підлеглий вузол РІБ до виконання іншого прикладного коду, який звертається до зумовлених елементів головного вузла;
б) у прикладній логіці завантаження даних із головного вузла (обробник події При отриманні даних від головного, правила реєстрації об'єктів) слід уникати звернень до визначених елементів, оскільки немає гарантії, що вони вже були завантажені з повідомлення обміну;
в) код обробників оновлення ІБ, який обробляє визначені елементи, не повинен виконуватись у підпорядкованих вузлах РІБ:
Якщо ПланиОбміну. ГоловнийВузол() = Невизначено Тоді // Заповнюємо зумовлені елементи// ... КінецьЯкщо;При використанні в конфігурації підсистеми "Обмін даними" Бібліотеки стандартних підсистем (БСП) версії 2.1.4 та вище вимоги (а) та (б) знімаються.
1.4. Для таблиць з визначеними елементами, які не входять до складу плану обміну РІБ (і на які не посилаються інші таблиці, що входять до складу плану обміну РІБ), рекомендується встановлювати властивість ОновленняПредвизначенихДанихна значення ОновлюватиАвтоматично, а також при першому запуску підпорядкованого вузла РІБ встановлювати автоматичне оновленняданих за допомогою виклику:
Довідники Ім'яДовідника>. ВстановитиОновленняПредвизначенихДанних(ОновленняПредвизначенихДанних. ОновлюватиАвтоматично) ;
2. У деяких випадках, визначені елементи не потрібно створювати автоматично, якщо їх наявність залежить від будь-якої умови: увімкненої функціональної опції, режиму роботи програми тощо.
Наприклад, ті чи інші зумовлені види розрахунків у плані видів розрахунку Нарахуваннязалежать від значень функціональних опцій ВикористатиОблік Часів СпівробітниківВ Годинник, ВикористатиВідряднийЗаробітокта ін.
Для цього
- у властивості ОновленняПредвизначенихДанихдовідника, плану рахунків, плану видів характеристик або плану видів розрахунку потрібно встановити значення "Не оновлювати автоматично"
- передбачити код створення (і позначки недійсним) визначеного елемента залежно від бізнес-логіки, наприклад:
- враховувати в прикладному коді відсутність зумовлених елементів ІБ. В іншому випадку, при зверненні до неіснуючого наперед визначеного елемента з коду або тексту запиту буде викликано виключення:
У разі використання у конфігурації Бібліотеки стандартних підсистем (БСП) версії 2.1.4 та вище рекомендується використовувати функцію ЗумовленийЕлементзагального модуля Загального призначенняКлієнтСервер, яка повертає Не визначенедля неіснуючих ІБ визначених елементів.
Друк (Ctrl+P)
Робота з визначеними значеннями за допомогою менеджера об'єкта
Отримати визначене значення за сервера «1С:Підприємства» можна за допомогою менеджера відповідного об'єкта. Рядок, що визначає отримуваний реквізит, має такий вигляд:
ТипПредвизначеногоЗначення.Ім'яОб'єктаМетаданих.Значення
● ТипПрізначеногоЗначення– для отримання визначених значень доступна вказівка наступних типів даних (написання у
множині):
● Довідники,
● ПланиВидовХарактеристик,
● ПланиРахунків,
● ПланиВидівРозрахунки,
● Перерахунки.
● Ім'яОб'єктаМетаданих
● Значення – може бути одним із наступних:
● для перерахувань вказується ім'я перерахунку;
● ТочкиМаршрута.Ім'яТочки – точка маршруту бізнес-процесу.
У випадку, якщо потрібно отримати точку маршруту бізнес-процесу, рядок, що описує отримуване значення, буде виглядати так:
БізнесПроцеси.Ім'яОб'єктаМетаданих.ТочкиМаршрута.Ім'яТочкиМаршрута
Приклад:
Вид = Перерахування.ВидиТоварів.Товар;
// Отримання визначених даних довідника.
Елемент = Довідники.Валюта.Рубль;
// Точка маршруту бізнес-процесу
Крапка = БізнесПроцесс.Узгодження.ТочкиМаршрута.Схвалення;
Робота з визначеними значеннями За допомогою функції ЗумовленеЗначення()
У зв'язку з тим, що стороні клієнта недоступні прикладні об'єкти, отримання зумовлених реквізитів з допомогою менеджерів об'єктів стає неможливим. Тому їх отримання існує метод глобального контексту ПредопределенноеЗначение(). Параметром цього є рядок, що описує те, яке визначене значення потрібно отримати. Синтаксис опису визначеного значення збігається із синтаксисом оператора ЗНАЧЕННЯ мови запитів.
Рядок, що визначає отримуваний реквізит, має такий вигляд:
Розглянемо складові цього рядка.
● ТипПрізначеногоЗначення– для отримання визначених значень доступна вказівка таких типів даних (написання в
однині):
● Довідник ,
● План видівХарактеристик,
● План Рахунків ,
● ПланВідівРозрахунку,
● Перелік,
● БізнесПроцес.
● І мяОб'єктаМетаданих- Вказується ім'я об'єкта метаданих так, як воно встановлено в конфігураторі.
● Значення – може бути одним із наступних
● для перерахувань вказується ім'я перерахунку;
● для отримання визначеного значення вказується його ім'я, як воно встановлено в конфігураторі;
● ТочкаМаршрута.Ім'яТочки – точка маршруту бізнес-процесу;
● ПорожнєПосилання — щоб отримати пусте посилання.
У разі потреби отримати значення системного перерахування параметр методу буде виглядати так:
Ім'яСистемногоПерерахування.ЗначенняСистемногоПерерахування.
Наприклад:
ТипДіаграми = ЗумовленийЗначення(“ТипДіаграми.ВігнутаПоверхня“);
Якщо потрібно отримати точку маршруту бізнес-процесу, рядок, що описує отримуване значення, буде виглядати так:
Приклад:
// Отримання значення перерахування.
Вид = ЗумовленийЗначення(“Перечисление.ВидыТоваров.Товар”);
// Отримання значення порожнього посилання.
ПорожнєПосилання =
ЗумовленеЗначення("Документ.ВитратнаНакл.ПустаПосилання");
// Отримання визначених даних довідника.
Елемент = Зумовлене Значення("Довідник.Валюта.Рубль");
// Точка маршруту бізнес-процесу
Крапка = ЗумовленеЗначення("БізнесПроцесс.Узгодження. ТочкаМаршрута.Схвалення");
Завантаження...