Доброго вам дня.
Сьогодні поговоримо про нововведення в платформі 8.3 стосується визначених елементів.
вступ
Нагадаю, що раніше на практиці, дуже часто хотілося дивлячись в елемент довідника дізнатися його визначене ім'я. Наприклад Ви створили два предопределнних контрагента і назвали його ІПСідоров і ОООМетеор. І зашили на них якусь логіку.
Коли все налагодили і відпрацювали, з'ясувалося, що задача була поставлена навпаки і логіка для ІП потрібна для ТОВ, а логіка ТОВ для ВП. "Немає проблем", говоримо ми і в режимі підприємства перейменовуємо елементи. Адже лізти в код набагато складніше. Минає рік і Вам поставлена нове завдання: Для ІП Сидорова налаштувати ще якусь логіку. Ви лізете в конфігуратор, пишіть логіку, починаєте перевіряти і нічого не працює, тому що в конфігураторі ІПСідоров, а в підприємстві - ОООМетеор. Мозок зламаний і ці граблі хочеться знищити. Найпростіше і наочне - це вивести ім'я визначеного елемента в форму списку. Ось тут засідка, отримати ім'я визначеного в 8.2 можна тільки методом. А метод це свої незручності, його не можна отримати в запиті. Тобто перша незручність - отримати ім'я визначеного за посиланням на довідник.
Друга незручність, коли ми вже маємо елемент довідника і нам треба його зробити визначеним. Ми створюємо зумовлений елемент і отримуємо два елементи в довіднику. Один зумовлений, інший робітник, на який посилаються всі наші документи. Заміна посилань звичайно виручає, але якщо база велика, то це тяжко.
Тепер у справі
Перше, це те, що у довідника з'явилася властивість "Оновлення зумовлених даних".
Що нам дає це поле? Якщо воно встановлено в "Не оновлювати автоматично", то додавши зумовлений елемент, ми його не побачимо в довіднику відразу. Тобто метадані ніяк не пов'язані з даними. І якщо його не створити в довіднику, то і звернення до нього по його імені через менеджер довідника викличе синтаксичну помилку.
Дуже цікаво, а навіщо? Як же нам створити елемент в довіднику? А як хочете, можете створити, а можете і зв'язати його з вже існуючим. Тепер у довідника є реквізит "ІмяПредопределеннихДанних". Ми створюємо елемент довідника програмно як зазвичай через "Справочнікі.Контрагенти.СоздатьЕлемент ()" і заповнюємо його реквізит "ІмяПредопределеннихДанних" рівним імені визначеного елемента. Або ж якщо елемент вже є, отримуємо його об'єкт і в ньому знову таки заповнюємо "ІмяПредопределеннихДанних". Всі.
І на останок трохи сиропу
Цей новий реквізит, мало того, що він доступний для читання і запису, так він ще і доступний в запитах. Таким чином Ви можете накладати на нього умови в запитах, визначати зумовлений він чи ні.
Спасибі за увагу.
При роботі на платформі 1С: Підприємство 8.x часто виникає необхідність прив'язатися в програмному коді до звичайних (не визначеного) елементам довідників. Наприклад у організації може бути п'ять видів цін, які використовуються практично у всіх механізмах. При цьому програмне звернення до конкретної ціні в кращому випадку здійснюється або писком по коду в довіднику, в гіршому по найменуванню елемента.
Був свідком того, як в звітах для отримання необхідної ціни використовувався відбір по виду ціни в запиті по її найменуванню (див. Наступний скріншот).
До того ж, якщо прив'язуватися до найменування або коду елементів довідника, то при отриманні посилання на елемент завжди буде здійснюватися пошуку в таблиці довідника. Не дивлячись на те, що стандартні реквізити системи індексуються СУБД, пошук по ним в деяких випадках може займати значні ресурси. До того ж, раціональніше було б не виконувати пошукової запитпо таблиці довідника, якщо, скажімо так, посилання на елемент і так "заздалегідь відома".
Як вихід, можна зберігати посилання на кожен часто використовуваний елемент довідника "Типи цін номенклатури" в окремих константи і отримувати з них значення в запиті. Однак, в такому випадку розробнику доведеться додавати окрему константу для кожного подібного об'єкта. Ситуація значно ускладниться, якщо такі елементи будуть не тільки в довіднику "Типи цін номенклатури", а й в інших довідниках ( "Категорії об'єктів", "Якість", "Номенклатура" і інші). Тоді кількість констант в системі може збільшитися в кілька разів!
Звичайно можна було б додати зумовлені елементи в кожен з довідників і звертатися до них стало б набагато простіше. Однак зміна типових об'єктів призвело б до ускладнення процесу оновлення конфігурації з пакетів постачальника.
є більш оптимальних підхідяк з точки зору розробки структури метаданих конфігурації, так і з боку продуктивності системи. Про нього сьогодні і піде мова.
універсальне рішення
Суть універсального рішення буде полягати в наступному: буде створено довідник, в який розробником будуть додаватися зумовлені елементи. У довідник доданий реквізит "Значення", тип якого залежить від значень, для яких буде створюватися відповідність "Зумовлений елемент довідника -> Пов'язаної значення". Структура метаданих довідника виглядає наступним чином (див. Наступний скріншот).
Для отримання визначеного елемента найкращим варіантомє використання глобального методу "ПредопределенноеЗначеніе (<Имя>)" . Як параметр в метод передається повний шлях до визначених елементу. Синтаксис схожий на функцію мови запитів "ЗНАЧЕННЯ ()".
Для зручності розробки рекомендую винести функцію для отримання пов'язаного з визначеним елементом значення в загальний модуль. В тестової конфігурації, Доступною для скачування за посиланням в кінці статті, створено спільний модуль "ЗначеніяПредопределеннихЕлементов" з експортної функцією "ПолучітьЗначеніеПредопределенногоЕлемента (<ИмяПредопределенногоЭлемента>)" . Програмний код функції отримує посилання на визначений елемент, потім запитом отримує значень реквізиту "Значення". На наступному скріншоті наведено повний лістинг функції.
Як ми бачимо, в функції формується запит до реквізиту "Значення" переданого в якості параметра зумовленого елемента. Як параметр функції є рядок з ім'ям зумовленого елемента.
Для правильної роботи створеного механізму потрібно зв'язати в призначеному для користувача режимі зумовлений елемент зі звичайним елементом довідника, вибравши відповідний елемент в реквізиті "Значення". Перейдемо до питання впливу на продуктивність.
Вплив на продуктивність
Проводив тест на швидкість для обох варіантів пошуку: по найменуванню і по посиланню з визначеного елемента. Пошук проходив за довідником "Товари" з 20000 записів. При проведенні тестів на файлової базібули отримані наступні результати:
Результати показали, що для файлового варіанту роботи використання визначених елементів для отримання часто використовуваних елементів інших довідників працює повільніше практично в 4 рази!
У клієнт-серверному варіанті роботи результати тестів показують зовсім іншу картину. Швидкість отримання посилання на потрібний елемент не знизилася значно (один з тестів показав 0.002 сек. Для пошуку по найменуванню і 0.0008 сек. При роботі через визначений елемент), проте надійність роботи програми збільшилася в рази!
висновки
У випадках, якщо часто необхідно прив'язуватися до звичайних елементів довідника, рекомендую не використовувати прив'язку за кодом або найменуванням. Даний підхід знижує надійність і продуктивність системи.
За час роботи з платформою не раз зустрічався з ситуацій, коли після зміни найменування, наприклад у елемента довідника "ТіпиЦенНоменклатури", злітала робота у більшості не типових звітів.
Чим більше алгоритмів пов'язані зі звичайними елементами довідників через код або найменування, тим менш стійка система.
Крім того, даний підхід дозволять не змінювати типові об'єкти конфігурації, якщо необхідно додати в них зумовлений елемент. Надалі це зробить процес оновлення конфігурації дещо простіше.
Файли для завантаження:
- Вивантаження тестової бази з прикладами зі статті.
Всім відомо відміну визначених елементів від звичайних: "Визначені елементи створюються в режимі" Конфігуратор "і не можуть бути видалені в режимі 1С: Підприємства". У призначеному для користувача режимі відрізнити зумовлений елемент від доданих користувачами можна за спеціальною піктограмі (див. Наступний скріншот).
В основному зумовлені елементи створюються розробниками, щоб зав'язати саме на них алгоритми в різних об'єкта конфігурації. Наприклад, в конфігурації "Управління виробничим підприємством" в довіднику "Якість" розробниками доданий зумовлений елемент "Новий".
Цей елемент використовується в багатьох модулях конфігурації. Так в документі "Надходження товарів і послуг" при виконанні проведення у всіх регістрах, де є вимір "Якість", підставляється значення визначеного елемента. Нижче наведено лістинг заповнення таблиці проведення по регістру "ТовариОрганізацій":
// ТОВАРИ по регістрах ТовариОрганізацій.НаборДвіженій = Руху. ТовариОрганізацій; Якщо ВідПоступленія = Перерахування. ВідиПоступленіяТоваров. НаСклад Тоді // Отримаємо таблицю значень, збігається зі структурою набору записів регістра.ТабліцаДвіженій = НаборДвіженій. Вивантажити (); // Заповнимо таблицю рухів.Загального призначення. ЗагрузітьВТабліцуЗначеній (ТабліцаПоТоварам, ТабліцаДвіженій); // Відсутні поля.ТабліцаДвіженій. ЗаполнітьЗначенія (Організація, "Організація"); ТабліцаДвіженій. ЗаполнітьЗначенія (Не визначено, "Комісіонер"); ТабліцаДвіженій. ЗаполнітьЗначенія (Довідники. Якість. Новий, "Якість"); // Заповнюємо якість з визначеного елементаТаким чином, характерні риси визначених елементів і їх призначення досить прості. Розглянемо спосіб їх зберігання в таблицях бази даних і його відмінність від звичайних елементів.
відмінності
У тестовій конфігурації створений довідник "Товари". У ньому створено групу "Тестові елементи". Вміст групи Ви могли бачити на скріншоті на початку статті. Для довідника "Товари" в SQL-базі даних є відповідна таблиця "_Reference37" з наступною структурою:
Але як визначити відповідність реквізитів дереві конфігурації і полів в SQL-таблиці?
скористаємося стандартним методомглобального контексту "ПолучітьСтруктуруХраненіяБазиДанних ()", який поверне нам таблицю значень з описом струкутри таблиць.
У таблиці значень "Поля" ми бачимо відповідність полів SQL-таблиці і реквізитів об'єкта в дереві метаданих. У нашому прикладі ми розглядаємо структуру довідника "Товари". У всіх довідників є стандартний реквізит "Зумовлений" булевого типу, який для визначених елементів встановлено в ІСТИНА:
По таблиці зі структурою зберігання довідника в базі даних ми однозначно можемо сказати, що поле "Зумовлений" відповідає полю "IsMetadata". Якщо ми переглянемо вміст таблиці "_Reference37" в SQL-базі, то побачимо наступне:
У записі для визначеного елемента значення поля "IsMetadata" встановлено в "0x01", що відповідає прапору ІСТИНА. Для звичайних елементів значення встановлено в "0x00". В цьому і полягає головна відмінність визначених елементів від звичайних. Всі інші поля зберігаються в базі даних аналогічно полях звичайних елементів, доданих користувачами.
Визначеним елементам можна знайти дуже цікаве призначення. З їх допомогою можна заборонити видаляти / позначати на видалення групи елементів в довіднику і інших об'єктах, де їх можна додати. Якщо ми спробуємо видалити або позначити на видалення групу "Тестові елементи". то отримаємо такі помилки:
Таким чином, зумовлені елементи роблять групу, в яку вони поміщені, теж "зумовленою".
завершення
Зумовлені елементи є невід'ємною частиною більшості конфігурації. Їх використання спрощує розробку і робить побудову функціоналу логічно більш "струнким" і цілісним.
На четвертому уроці нашогоми продовжимо знайомитися з програмою. Сьогодні ми на практичних прикладахпознайомимося з іерархіческімі довідниками, а також навчимося створювати зумовлені елементи.
Хронометраж 4 уроки курсу:
00:19
Зміни в довіднику Співробітники після виконання домашнього завдання по 3 уроку курсу
00:35
Редагування порядку проходження реквізитів в довідниках
02:54
Створення довідника Номенклатура
03:40
Створення та налагодження ієрархічного довідника
05:10
Створення груп Послуги і Товари в довіднику Номенклатура
06:05
Заповнення довідника Номенклатура
07:14
3 способи перенесення елемента довідника в іншу групу
08:21
Створення довідника Склади
09:19
Створення визначених елементів довідника
11:25
Заповнення довідника Склади
12:20
Пройти тест за матеріалом 4 уроки
ієрархічний довідник- довідник з можливістю ієрархічного розташування його елементів. Наприклад, в довіднику Номенклатура можуть бути створені групи: Товари, Послуги тощо, в яких розташовуються елементи, що відносяться до цих груп. Крім того групи довідника можуть включати в себе і інші групи, створюючи тим самим багаторівневу ієрархічну структуру.
Крім цього, довідники підтримують і інший вид ієрархії, при якому елементи довідника будуть відноситися не до груп, а до інших елементів цього ж довідника. Такий вид ієрархії ( ієрархія елементів) Може використовуватися, наприклад, при створенні довідника Підрозділи, де один підрозділ (підрозділ в даному випадку елемент довідника, а не група) може включати в себе кілька інших підрозділів. Такий вид ієрархії застосовується досить рідко.
форми довідника- візуальне уявлення довідника. Залежно від того, які саме дії ми хочемо виконати з нашим довідником, нам потрібно відображати довідник у «різних видах». Так, на 4 уроці курсу ми з вами редагували порядок проходження реквізитів у формі списку і в формі елемента довідника.
Система створює (генерує) форми автоматично, але, при необхідності, розробник можемо «малювати» форми самостійно.
Всього для довідників існує 5 форм (типів форм):
- форма елемента- для створення або редагування елемента довідника;
- форма групи- для створення або редагування групи довідника;
- форма списку- для відображення списку елементів довідника;
- форма вибору- використовується, щоб в поле якоїсь форми вибрати один з елементів даного довідника. Наприклад, щоб в документі Надходження товару в поле склад вибрати конкретний склад з довідника Склади;
- форма вибору груп- використовується, щоб в поле якоїсь форми вибрати одну з груп даного довідника.
Зумовлені елементи довідника- елементи довідника, створювані розробником в режимі Конфігуратора, і до яких можна звертатися з вбудованої мови 1С по Імені.
Між звичайними і зумовленими елементами довідника існує принципова різниця. Звичайні елементи непостійні в конфігурації. В процес роботи користувача вони можуть створюватися, редагуватися і віддалятися і, саме тому, на них не слід покладатися при виконанні будь-яких алгоритмів (код і найменування елемента може змінюватися користувачем).Зумовлені елементи, навпаки, постійні. В процесі роботи, навіть якщо користувач перейменує такий елемент, до нього можна буде звертатися з вбудованої мови 1С. Це досягається за рахунок того, що у зумовленого елемента є реквізит ім'я, Який недоступний користувачеві. У звичайних елементів довідника такого реквізиту немає.
Важливо! Технічно користувач имет можливість видалити зумовлений елемент довідника, але, як правило, користувачам відключають права на видалення визначених елементів довідника.
Домашнє завдання по 4 уроку курсу
Домашнє завдання по четвертому уроку курсу буде вам доступно відразу після успішного вирішення теоретичного тесту.
Сама ідея програмної роботи з зумовленими елемементамі, на мій погляд, дуже правильна. Просто є нюанси, які потрібно враховувати при роботі.
Для початку необхідно чітко усвідомити для себе, що є зумовлені елементи в конфігурації і є зумовлені елементи в інформаційній базі (ІБ). Технічно зумовлені елементи ІБ це звичайнісінькі елементи довідників, у яких у реквізиті "ІмяПредопределеннихДанних" зазначено, який саме зумовленої елементу конфігурації вони відповідають. Нічим більше вони від звичайних елементів не відрізняються. Відповідно, будь-який звичайний елемент ІБ можна зробити визначеним, будь зумовлений звичайним. Для цього достатньо вписати потрібне значення в реквізит "ІмяПредопределеннихДанних".
Періодично в цій властивості виявляється не те значення, яке передбачив розробник. В результаті виникають помилки в роботі 1С. Від критичних, при яких робота в принципі неможлива, до некритичних, при яких порушується логіка роботи алгоритмів.
Умовно можна виділити три типи помилок:
1. "Зумовлений елемент відсутній в даних";
3. Невірне значення визначеного елемента;
1. "Зумовлений елемент відсутній в даних" - протсутствіе описаного в конфігурації зумовленого елемента в даних ІБ.
Це найбільш простий в налагодженні і виправленні тип помилки. Його простота в тому, що платформа досить коректно повідомляє про цю ситуацію "Зумовлений елемент відсутній в даних" і цілком зрозуміло, як її виправити.
При зверненні до відсутнього елемента в коді "Справочнікі.ВідиКонтактнойІнформаціі.EmailКонтактногоЛіца" видається повідомлення
При зверненні до елементу в запиті "ЗНАЧЕННЯ (Справочнік.ВідиКонтактнойІнформаціі.EmailКонтактногоЛіца)" видається повідомлення:
Така помилка виникає в разі, якщо елемент в конфігурації описаний, але в базі йому елемент не підтверджено.
Для початку уточнимо, що така ситуація не завжди є помилковою. Цілком можливим є використання зумовлених даних в якийсь програмної логіці, яка для більшості користувачів може не використовуватися. У цьому випадку, щоб не захломлять довідник у всіх користувачів конфігурації, логічно визначити зумовлені елементи в конфігурації, але не створювати їх у всіх ІБ, а лише для тих ІБ, в яких потрібна логіка конфігурації використовується. В цьому випадку програміст може вказати для довідника властивість "Не оновлювати зумовлені дані" і створити елементи програмно при зверненні до функціоналу модуля. Або дати можливість користувачеві самостійно прив'язати зумовлені елементи модуля до наявних у нього звичайних елементів.
Також не використовується автоматичне створеннявизначених елементів при роботі в режимі РИБ. Так як нові елементи повинні передаватися з центральної бази, а не створюватися в вузлах з відмінними УІДамі.
Тобто іноді помилкою є звернення до несопоставленние елементу, а не сама наявність такого елемента.
Необхідно проаналізувати, чому елемент не створений. Можливо, він повинен створитися при виконанні будь-якого режиму програми. Наприклад, після виконання обміну в РИБ. А можливо, його просто випадково видалили.
Якщо логікою передбачено заповнення визначених елементів не автоматично, а окремим режимом, то перед використання звернення на ім'я " Справочнікі.ВідиКонтактнойІнформаціі.EmailКонтактногоЛіца"Для запобігання виняткової ситуації бажано перевірити, що елемент вже є в базі. Якщо елемент відсутній, то повідомити користувачеві про це і пояснити, який режим йому потрібно виконати для заповнення елемента. Для такої перевірки маєте змогу надсилати запити до даних.
Запит = Новий запит; Запрос.Текст = "ВИБРАТИ | ВідиКонтактнойІнформаціі.Ссилка | З | Справочнік.ВідиКонтактнойІнформаціі ЯК ВідиКонтактнойІнформаціі | ДЕ | ВідиКонтактнойІнформаціі.ІмяПредопределеннихДанних =" " EmailКонтактногоЛіца"" "; ЕлементОтсутсвуетВДанних = Запрос.Виполніть (). Порожній ();
Якщо це все-таки помилка в даних бази, то необхідно виконати прив'язку до визначених елементу елемента ІБ. Тобто необхідно пояснити системі, до якого елементу ІБ повинен звернутися програмний код з даного імені. Технічно прив'язка це просто вказівка імені визначеного елемента в властивості "ІмяПредопределеннихДанних"Елемента ІБ. Для її установки досить виконати код:
2. "Зумовлений елемент не унікальний" - задвоенние зумовлені елементи:
Ця ситуація полягає в тому, що до одного зумовленої елементу прив'язане кілька елементів ІБ. В цьому випадку при зверненні до визначених імені елемент буде вибиратися випадковим чином. Така ситуація завжди є хибною. Її складність в тому, що платформа ніяк про неї не повідомляє. Просто алгоритми починають працювати невірно.
Платформа повідомить про помилку "Зумовлений елемент не унікальний" лише при спробі редагування задублірованного елемента.
До тих пір, поки нікому не знадобиться редагувати елемент, про помилку ніхто не дізнається.
Такі дублі можуть створитися, наприклад, якщо для довідника використовуючи РИБ і у властивостях для визначених даних вказано режим "Оновлювати автоматично". В цьому випадку при виконанні обміну один екземпляр зумовлених даних створиться при оновленні конфігурації. Другий примірник визначених елементів з тим же ім'ям передасться з центральної бази при обміні.
Також ці дублі виникнуть при використанні обробок обміну між конфігураціями в разі, якщо в різних базахвизначеним елементам соответствеют різні елементи ІБ. У цьому випадку один примірник зумовлених даних в базі вже є, другий прийде при виконанні завантаження даних з іншим Уідом. Якщо ви виконуєте перенесення даних, необхідно вирішити, елементи якої бази вважаються основними і використовувати їх же в підпорядкованій базі. В підпорядкованої базі необхідно замінити використання старих елементів на елементи основної бази.
Такі помилки в базі даних можна виявити запитом виду:
ВИБРАТИ ВідиКонтактнойІнформаціі.ІмяПредопределеннихДанних, КІЛЬКІСТЬ (РІЗНІ ВідиКонтактнойІнформаціі.Ссилка) ЯК КолічествоПредопределенних З Справочнік.ВідиКонтактнойІнформаціі ЯК ВідиКонтактнойІнформаціі згруповані за ВідиКонтактнойІнформаціі.ІмяПредопределеннихДанних МАЮТЬ КІЛЬКІСТЬ (РІЗНІ ВідиКонтактнойІнформаціі.Ссилка)> 1
Цей запит поверне перелік визначених елементів, з яким пов'язано більше одного елемента ІБ.
При наявності таких елементів необхідно прибрати для одного з них зв'язок з визначеним. Тобто необхідно однозначно визначити для системи, до якого елементу ІБ повинен звернутися програмний код при використанні даного імені.Для цього досить виконати код.
3. Невірне значення визначеного елемента.
Помилка полягає в тому, що зумовленої елементу відповідає не той елемент, який передбачений логікою програми. Такі помилки найбільш складні в діагностиці. На відміну від перших двох типів, на наявність цих помилок автоматично перевірити конфігурацію можна. Їх можна виявити тільки аналізуючи логіку роботи. При виникненні сумнівів можна перевірити, чи потрібен елемент використовується.
Для цього досить виконати одну з команд.
// Визначення елемента ІБ, який прив'язаний до потрібного зумовленої Повідомити (Справочнікі.ВідиКонтактнойІнформаціі.EmailКонтактногоЛіца) // Визначаємо зумовлений елемент, до якого прив'язаний обраний Повідомити (СсилкаНаЕлемент.ІмяПредопределеннихДанних)
При виявленні таких помилок необхідно прибрати некоректну зв'язок зі старим елементом і додати зв'язок з новим елементом. Код операцій аналогічний коду виправлення перших двох типів помилок.
Ну і коротко про помилки при програмній роботіабо в режимі конфігуратора:
"Зумовлений елемент не належить<Имя справочника>" - помилка виникає при спробі записати зумовлений елемент з ім'ям, що не збігається з ім'ям в коонфігураторе.
"Чи не зумовлені об'єкти не можуть мати зумовлені записи видів субконто" - помилка виникає при спробі зробити елемент зумовлений плану рахунків непредопределенним. Для усунення помилок необхідно у кожного рядка субконто елемента зняти ознака "приречення".
"Чи не зумовлені об'єкти не можуть мати зумовлені записи провідних видів розрахунків"- помилка виникає при спробі зробити зумовлений елемент плану видів розрахунку непредопределенним. Для усунення помилок необхідно у кожного рядка провідного виду розрахунку елемента зняти ознака "приречення".
"Визначені елементи не унікальні"- помилка видається в конфігураторі при оновленні інформаційної базина реліз конфігурації без режиму сумісності з 8.3.4. Необхідно до поновлення перевірити дублі і усунути їх.
"Ім'я зумовленого елемента не унікально" - помилка виникає при наявності в конфігурації декількох однойменних визначених елементів при оновленні на платформу8.3.6.2332 і вище. Необхідно усунути дублі в конфігурації.
Для роботи з зумовленими даними рекомендую обробку. Вона вміє виконувати будь-які дії з зумовленими даними, а також може перевірити конфігурацію в цілому на наявність у всіх об'єктах ІБ (довідниках, планах рахунків, ПВХ, ПВР) помилок перших двох типів (задвоєння і відсутніх елементів).
