Встановлення певних елементів. Установка зумовлених елементів 1з8

Проста обробкадо роботи з визначеними значеннями.

Дозволяє зіставити елементи ІБ з визначеними у конфігурації елементами.

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

Можна просто переглянути поточні значення, можна зробити будь-які зміни.

Порядок роботи:

1. Запускаємо обробку.

2. Вибираємо тип (довідник, план рахунків, ПВХ, ПВР).

3. Вибираємо сам довідник вибраного типу.

4. У табличній частині обробки з'являються всі наперед визначені елементи, що є в ІБ, і описані в конфігурації.

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

5. Встановлюємо нові значення для необхідних визначених елементів.

У цьому червоним позначаються рядки, котрим із зміни зникає зумовлений елемент. Синій рядки для яких змінюється певний елемент, зеленим рядки, по яких утворюється наперед визначений елемент.
При велику кількістьдублів зручно виділити мишкою всі зайві рядки та вказати для всіх обраних скасування зв'язку кнопкою "Скасувати відповідність" (з версії 1.3.1)

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

Перевірка дублів(помилка "Визначений елемент не унікальний"):

При натисканні конопки "Перевірити дублі" обробка перевірить усі довідники, плани рахунків, ПВХ та ПВР та виведе список таблиць із задвоєними елементами із зазначенням кількості задвоєних елементів.

Після цього необхідно перевірити окремо об'єкти, для яких виявлено помилки.

Перевірка пропущених(помилка "Визначений елемент відсутній у даних"):

При натисканні кнопки "Перевірити пропущені" обробка перевірить всі довідники, плани рахунків, ПВХ та ПВР і виведе список визначених елементів, яким не зіставлені дані ІБ.

Для використання потрібна платформа 8.3.3 або вище.

Універсальна, може використовуватись з будь-якими конфігураціями.

Detect language Afrikaans Albanian Арабська Armenian Azerbaijani Basque Bengali Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Czech Slovenian Spanish Swahili Swedish Tamil Telugu Thai Turkish

Afrikaans Albanian Арабський Armenian Azerbaijani Basque Bengali Український Bulgarian Catalan Chinese (Simp) Chinese (Trad) Croatian Czech Danish Dutch English Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Czech Slovenian Spanish Swahili

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

Спочатку необхідно чітко усвідомити собі, що є зумовлені елементи у конфігурації і є зумовлені елементи в інформаційній базі (ІБ). Технічно визначені елементи ІБ це звичайні елементи довідників, які у реквізиті "ИмяПредопределенныхДанных" зазначено, якому визначеному елементу конфігурації вони відповідають. Нічим більше вони від звичайних елементів не відрізняються. Відповідно, будь-який звичайний елемент ІБ можна зробити зумовленим, будь-який зумовлений звичайним. Для цього достатньо вписати потрібне значення у реквізит "Ім'яПредвизначенихДаних".

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

Умовно можна виділити три типи помилок:
1. "Призначений елемент відсутній у даних";

3. Неправильна вказівказумовленого елемента;

1. "Призначений елемент відсутній у даних" - провідсутність описаного в конфігурації визначеного елемента даних ІБ.

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

При зверненні до відсутнього елемента в коді "Довідники.ВидиКонтактноїІнформації.EmailКонтактноїОсоби" видається повідомлення

При зверненні до елемента у запиті "ЗНАЧЕННЯ(Довідник.ВидиКонтактноїІнформації.EmailКонтактноїОсоби)" видається повідомлення:

Така помилка виникає у разі, якщо елемент у конфігурації описаний, але у основі йому елемент не зіставлений.

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

Також не використовується автоматичне створеннявизначених елементів під час роботи у режимі РИБ. Оскільки нові елементи повинні передаватися з центральної бази, а не створюватися у вузлах з УІДами, що відрізняються.

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

Необхідно проаналізувати, чому елемент не створено. Можливо, він має створюватися під час виконання будь-якого режиму програми. Наприклад, після виконання обміну в РИБ. А можливо, його випадково видалили.

Якщо логікою передбачено заповнення визначених елементів не автоматично, а окремим режимом, то перед використанням звернення по імені " Довідники.ВидиКонтактноїІнформації.EmailКонтактноїОсобиДля запобігання винятковій ситуації бажано перевірити, що елемент вже є в базі. Якщо елемент відсутній, то повідомити користувача про це і пояснити, який режим йому потрібно виконати для заповнення елемента. Для такої перевірки можна виконати запит до даних.

Запит = Новий Запит; Запит.Текст = "ВИБРАТИ | Види КонтактноїІнформації.Посилання |З | Довідник.ВидиКонтактноїІнформації ЯК ВидиКонтактноїІнформації |ДЕ | ВидиКонтактноїІнформації. EmailКонтактноїОсоби""";

Якщо це все-таки помилка в даних бази, необхідно виконати прив'язку до визначеного елемента елемента ІБ. Тобто. необхідно пояснити системі, якого елементу ІБ повинен звернутися програмний код по даному імені. Технічно прив'язка це просто вказівка ​​імені зумовленого елемента як "Ім'яПредвизначенихДанихелемента ІБ. Для її встановлення достатньо виконати код:

2. "Призначений елемент не унікальний" - задвоєні зумовлені елементи:

Ця ситуація у тому, що до одного зумовленого елементу прив'язано кілька елементів ІБ. У цьому випадку при зверненні до наперед визначеного імені елемент буде вибиратися випадковим чином. Така ситуація завжди є хибною. Її складність у тому, що платформа про неї ніяк не повідомляє. Просто алгоритми починають працювати неправильно.

Платформа повідомить про помилку "Призначений елемент не є унікальним" лише при спробі редагування задубльованого елемента.

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

Такі дублі можуть створюватися, наприклад, якщо для довідника використовується РІБ і у властивостях для визначених даних вказаний режим "Оновлювати автоматично". У цьому випадку при виконанні обміну один екземпляр наперед визначених даних створиться при оновленні конфігурації. Другий екземпляр зумовлених елементів з тим самим ім'ям передається з центральної бази при обміні.

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

Такі помилки у базі даних можна виявити запитом:

ВИБЕРІТЬ Типи контактної інформації. Назва попередньо визначених даних, КІЛЬКІСТЬ (РІЗНІ типи контактної інформації. Посилання) ЯК Номер попередньо визначеної інформації З каталогу Типи контактної інформації ЯК Типи контактної інформації ГРУПУВАТИ ЗА Типами контактної інформації Назва попередньо визначених даних З КІЛЬКОСТІ (РІЗНІ типи контактної інформації. Посилання) > 1

Цей запит поверне перелік визначених елементів, з яким пов'язано більше одного ІБ.

За наявності таких елементів необхідно прибрати для одного з них зв'язок із зумовленим. Тобто. необхідно однозначно визначити для системи, якого елементу ІБ повинен звернутися програмний код під час використання даного імені.Для цього достатньо зробити код.

3. Неправильна вказівка ​​наперед визначеного елемента.

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

Для цього достатньо виконати одну із команд.

//Визначення елемента ІБ, який прив'язаний до потрібного зумовленого Повідомити(Довідники.ВидиКонтактноїІнформації.EmailКонтактноїОсоби) //Визначаємо зумовлений елемент, до якого прив'язаний вибраний Повідомити(ПосиланняНаЕлемент.Ім'яЗумовленихДаних)

При виявленні таких помилок необхідно прибрати некоректний зв'язок із старим елементом та додати зв'язок із новим елементом. Код операцій аналогічний коду виправлення перших двох типів помилок.

Ну і коротко про помилки при програмній роботіабо в режимі конфігуратора:

"Наперед визначений елемент не належить<Имя справочника>" - помилка виникає при спробі записати наперед визначений елемент з ім'ям, що не збігається з ім'ям у коонфігураторі.

"Не зумовлені об'єкти не можуть мати зумовлені записи видів субконто" - помилка виникає при спробі зробити елемент зумовлений планом рахунків невизначеним. Для усунення помилок необхідно у кожному рядку субконту елемента зняти ознаку "Зумовлене".

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

"Наперед визначені елементи не унікальні"- помилка видається у конфігураторі під час оновлення інформаційної базина випуск конфігурації без режиму сумісності з 8.3.4. Необхідно до оновлення перевірити дублі та усунути їх.

"Ім'я визначеного елемента не є унікальним" - помилка виникає за наявності у конфігурації кількох однойменних наперед визначених елементів при оновленні на платформу8.3.6.2332 та вище. Необхідно усунути дублі у конфігурації.

Для роботи з визначеними даними рекомендую обробку. Вона вміє виконувати будь-які дії з наперед визначеними даними, а також може перевірити конфігурацію в цілому на наявність у всіх об'єктах ІБ (довідниках, планах рахунків, ПВХ, ПВР) помилок перших двох типів (задвоєних та відсутніх елементів).

Доброго вам дня.

Сьогодні поговоримо про нововведення у платформі 8.3, що стосується зумовлених елементів.

Вступ

Нагадаю, що раніше на практиці дуже часто хотілося дивлячись в елемент довідника дізнатися його зумовлене ім'я. Наприклад, Ви створили два передумови і назвали його ІПСидорів і ТОВМетеор. І зашили на них якусь логіку.

Коли всі налагодили та відпрацювали, з'ясувалося, що завдання було поставлене навпаки і логіка для ІП потрібна для ТОВ, а логіка ТОВ для ІП. "Немає проблем", говоримо ми і в режимі підприємства перейменовуємо елементи. Адже лізти в код набагато складніше. Минає рік і Вам поставлено нове завдання: для ІП Сидорова налаштувати ще якусь логіку. Ви лізете до конфігуратора, пишіть логіку, починаєте перевіряти і нічого не працює, т.к. у конфігураторі ІПСидорів, а у підприємстві - ТОВМетеор. Мозок зламаний і ці граблі хочеться знищити. Найпростіше та наочне - це вивести ім'я зумовленого елемента у форму списку. Ось тут засідка, отримати ім'я зумовленого в 8.2 можна лише способом. А метод – це свої незручності, його не можна отримати у запиті. Тобто. перше незручність - отримати ім'я зумовленого посилання на довідник.

Друга незручність, коли ми вже маємо елемент довідника і нам треба зробити його зумовленим. Ми створюємо наперед визначений елемент і отримуємо два елементи в довіднику. Один зумовлений, інший робітник, на який посилаються усі наші документи. Заміна посилань звичайно рятує, але якщо база велика, це тяжко.

Тепер у справі

Перше, це те, що у довідника виникла властивість "Оновлення зумовлених даних".

Що нам дає це поле? Якщо воно встановлено в "Не оновлювати автоматично", то додавши наперед визначений елемент, ми його не побачимо в довіднику відразу. Тобто. метадані не пов'язані з даними. І якщо його не створити у довіднику, то й звернення до нього на його ім'я через менеджер довідника викличе синтаксичну помилку.

Дуже цікаво, а навіщо? Як нам створити елемент у довіднику? А як хочете, можете створити, а можете пов'язати його з уже існуючим. Тепер у довідника є реквізит "Ім'яПредвизначенихДаних". Ми створюємо елемент довідника програмно як зазвичай через "Довідники. Контрагенти. Або якщо елемент вже є, отримуємо його об'єкт і в ньому знову таки заповнюємо "Ім'яПредвизначенихДаних". Усе.

І наостанок трохи сиропу

Цей новий реквізит, мало того, що він доступний для читання та запису, так він ще й доступний у запитах. Таким чином, Ви можете накладати на нього умови в запитах, визначати зумовлений він чи ні.

Дякуємо за увагу.