Самата идея за програмна работа с предварително дефинирани елементи според мен е много правилна. Има просто нюанси, които трябва да се вземат предвид при работа.
Първо, трябва ясно да разберете за себе си, че има предварително дефинирани елементи в конфигурацията и има предварително дефинирани елементи в информационната база (IS). Технически, предварително дефинираните елементи за информационна сигурност са най-често срещаните елементи на директории, в които атрибутът „Име на предварително дефинирани данни“ показва на кой предварително дефиниран конфигурационен елемент съответстват. Те не се различават от обикновените елементи. Съответно, всеки обикновен елемент за защита на информацията може да бъде направен предварително дефиниран, всеки предварително дефиниран елемент може да бъде направен обикновен. За да направите това, просто въведете желаната стойност в атрибута „Предварително определено име на данни“.
От време на време това свойство съдържа стойност, която не е предвидената от разработчика. В резултат на това възникват грешки в работата на 1C. От критични, при които работата е принципно невъзможна, до некритични, при които е нарушена логиката на алгоритмите.
Условно можем да подчертаем три вида грешки:
1. „Преддефинираният елемент не е в данните“;
3. Неправилна спецификация на предефиниран елемент;
1. „Предварително зададеният елемент не е в данните“ – олипса на предварително дефиниран елемент, описан в конфигурацията в данните за информационна сигурност.
Това е най-лесният тип грешка за отстраняване и коригиране. Неговата простота е, че платформата доста коректно отчита тази ситуация „Предварително дефинираният елемент липсва в данните“ и е съвсем ясно как да се поправи.
При достъп до липсващ елемент в кода "Директории. Видове информация за контакт. Имейл на лицето за контакт" се показва съобщение
При достъп до елемент в заявката "VALUE(Директория.Видове информация за контакт.Имейл на лицето за контакт)" се показва следното съобщение:
Тази грешка възниква, ако даден елемент е описан в конфигурацията, но елементът не е свързан с него в базата данни.
Като начало нека изясним, че тази ситуация не винаги е грешна. Напълно възможно е да се използват предварително дефинирани данни в някакъв вид програмна логика, която за повечето потребители може да не се използва. В този случай, за да не се претрупва директорията за всички потребители на конфигурацията, е логично да се дефинират предварително дефинирани елементи в конфигурацията, но не да се създават във всички системи за информационна сигурност, а само за тези системи за информационна сигурност, в които използва се необходимата конфигурационна логика. В този случай програмистът може да укаже свойството „Не актуализирай предварително дефинирани данни“ за директорията и да създаде елементи програмно при достъп до функционалността на модула. Или позволете на потребителя самостоятелно да обвърже предварително дефинирани модулни елементи към съществуващи редовни елементи.
Освен това автоматичното създаване на предварително дефинирани елементи не се използва при работа в режим RIB. Тъй като новите елементи трябва да се прехвърлят от централната база данни, а не да се създават във възли с различни UID.
Тези. Понякога грешката е препратката към несъвпадащ елемент, а не самото присъствие на такъв елемент.
Необходимо е да се анализира защо елементът не е създаден. Може би трябва да се създаде, когато се изпълнява някакъв програмен режим. Например след завършване на обмен в RIB. Или може би случайно е изтрит.
Ако логиката предвижда попълване на предварително зададени елементи не автоматично, а в отделен режим, тогава преди да използвате достъп по име " Директории. Видове информация за контакт. Имейл на лицето за контакт"За да предотвратите извънредна ситуация, препоръчително е да проверите дали елементът вече е в базата данни. Ако елементът липсва, информирайте потребителя за това и обяснете какъв режим трябва да изпълни, за да попълни елемента. За такава проверка , можете да изпълните заявка за данни.
Заявка = Нова заявка; Request.Text = "ИЗБЕРЕТЕ | Типове информация за контакт. Връзка | ОТ | Директория. Типове информация за контакт КАК Типове информация за контакт | КЪДЕ | Типове информация за контакт. Име на предварително дефинирани данни = "" EmailContactPerson""; Item Is MissingInData = Query.Execute().Empty();
Ако това все още е грешка в данните на базата данни, тогава е необходимо да се свържете с предварително дефиниран елемент от елемента за защита на информацията. Тези. необходимо е да се обясни на системата към кой елемент за защита на информацията трябва да има достъп програмният код с това име. Технически, обвързването е просто указване на името на предварително дефиниран елемент в свойството "Предварително зададено име на данни" на елемента IS. За да го инсталирате, просто стартирайте кода:
2. "Предварително дефинираният елемент не е уникален" - hдвойни предварително дефинирани елементи:
Тази ситуация е, че няколко елемента за информационна сигурност са прикрепени към един предварително дефиниран елемент. В този случай, при достъп до предварително зададено име, елементът ще бъде избран на случаен принцип. Тази ситуация винаги е грешна. Трудността му е, че платформата не го отчита по никакъв начин. Алгоритмите просто започват да работят неправилно.
Платформата ще отчете грешката „Предварително зададеният елемент не е уникален“ само когато се опитате да редактирате дублиран елемент.
Докато никой не трябва да редактира елемента, никой няма да разбере за грешката.
Такива дубликати могат да бъдат създадени, например, ако RIB се използва за директорията и режимът „Актуализиране автоматично“ е посочен в свойствата за предварително дефинирани данни. В този случай, когато се извършва обмен, един екземпляр на предварително дефинираните данни ще бъде създаден, когато конфигурацията се актуализира. Второ копие на предварително дефинирани елементи със същото име ще бъде прехвърлено от централната база данни по време на обмена.
Също така, тези дубликати ще възникнат при използване на обработка на обмен между конфигурации, ако различни елементи за информационна сигурност съответстват на предварително дефинирани елементи в различни бази данни. В този случай едно копие на предварително дефинираните данни вече съществува в базата данни, второто ще дойде при зареждане на данни с различен UID. Ако извършвате прехвърляне на данни, трябва да решите кои елементи от базата данни се считат за основни и да ги използвате в подчинената база данни. В подчинената база данни е необходимо да се замени използването на стари елементи с елементи от основната база данни.
Такива грешки в базата данни могат да бъдат идентифицирани със заявка като:
ИЗБЕРЕТЕ типове информация за контакт. Име на предварително дефинирани данни, КОЛИЧЕСТВО (РАЗЛИЧНИ типове информация за контакт. Референция) КАТО Брой предварително дефинирани ОТ директория. Типове информация за контакт КАТО типове информация за контакт ГРУПИРАНЕ ПО Типове информация за контакт. Име на предварително дефинирани данни С КОЛИЧЕСТВО (РАЗЛИЧНИ типове тактична информация. Връзка) > 1
Тази заявка ще върне списък с предварително дефинирани елементи, с които е свързан повече от един елемент за защита на информацията.
При наличие на такива елементи е необходимо да се премахне връзката с предефинирания за един от тях. Тези. Необходимо е недвусмислено да се определи за системата към кой елемент за информационна сигурност трябва да се отнася програмният код, когато се използва това име.За да направите това, просто стартирайте кода.
3. Неправилна спецификация на предварително дефиниран елемент.
Грешката е, че предварително дефинираният елемент съответства на елемент, който не е предоставен от логиката на програмата. Такива грешки са най-трудни за диагностициране. За разлика от първите два типа, конфигурацията не може да бъде автоматично проверена за тези грешки. Те могат да бъдат идентифицирани само чрез анализ на логиката на работа. Ако се съмнявате, можете да проверите дали се използва правилният елемент.
За да направите това, просто изпълнете една от командите.
//Дефиниране на елемент за сигурност на информацията, който е свързан с желаното предварително дефинирано уведомяване (Директории.Типове информация за контакт.Имейл на лицето за контакт) //Дефиниране на предварително дефиниран елемент, към който е прикачено избраното уведомяване (Връзка към елемент.Име на предварително дефинирани данни )
Ако се установят такива грешки, е необходимо да се премахне неправилната връзка със стария елемент и да се добави връзка с новия елемент. Кодът на операцията е подобен на кода за коригиране на първите два вида грешки.
Е, накратко за грешки по време на работа на програмата или в режим на конфигуратор:
„Предварително зададеният елемент не принадлежи<Имя справочника>" - възниква грешка при опит за запис на предварително дефиниран елемент с име, което не съвпада с името в конфигуратора.
„Непредефинираните обекти не могат да имат предварително дефинирани записи за преглед на подконто“ - възниква грешка, когато се опитвате да направите елемент от предварително дефиниран сметкоплан непредефиниран. За да елиминирате грешки, е необходимо да премахнете флага „Предварително дефиниран“ от всеки подконтактен ред на елемента.
„Недефинираните обекти не могат да имат предварително дефинирани записи на водещи типове изчисления“- възниква грешка, когато се опитвате да направите предварително дефиниран елемент от плана на видовете изчисления. За да елиминирате грешки, е необходимо да премахнете отметката „Предварително зададени“ за всеки ред от водещия тип изчисление на елемента.
„Предварително зададените елементи не са уникални“- генерира се грешка в конфигуратора при актуализиране на информационната база за версия на конфигурация без режим на съвместимост с 8.3.4. Необходимо е да проверите за дубликати и да ги премахнете преди актуализиране.
„Името на предварително дефинирания елемент не е уникално“ - грешката възниква, когато има няколко предварително дефинирани елемента с едно и също име в конфигурацията при актуализиране на платформата8.3.6.2332 и по-нови. Необходимо е да се елиминират дубликати в конфигурацията.
За работа с предварително дефинирани данни препоръчвам обработка. Може да извършва всякакви действия с предварително дефинирани данни, а също така може да проверява конфигурацията като цяло за наличие на грешки от първите два вида (дублирани и липсващи елементи) във всички обекти за информационна сигурност (директории, сметкопланове, PVC, PVR) .
Когато работите на платформата 1C:Enterprise 8.x, често има нужда от обвързване в програмния код към обикновени (не предварително дефинирани) елементи на директория. Например една организация може да има пет вида цени, които се използват в почти всички механизми. В този случай програмният достъп до конкретна цена в най-добрия случай се осъществява или чрез скърцане чрез код в директорията, или чрез името на елемента, в най-лошия случай.
Бях свидетел как в отчетите, за да се получи необходимата цена, се използва селекция по тип цена в заявка по нейното име (вижте следната екранна снимка).
Освен това, ако се свържете с името или кода на елементи на директория, тогава, когато получите връзка към елемент, винаги ще се извършва търсене в таблицата на директорията. Въпреки факта, че стандартните системни данни се индексират от СУБД, търсенето им в някои случаи може да отнеме значителни ресурси. Освен това би било по-рационално да не се извършва заявка за търсене, като се използва референтната таблица, ако, да кажем, връзката към елемента вече е „известна предварително“.
Като изход можете да съхранявате връзка към всеки често използван елемент от директорията „Типове цени на артикули“ в отделни константи и да получавате стойности от тях в заявката. В този случай обаче разработчикът ще трябва да добави отделна константа за всеки такъв елемент. Ситуацията ще стане значително по-сложна, ако такива елементи не са само в директорията „Видове цени на артикулите“, но и в други директории („Категории обекти“, „Качество“, „Номенклатура“ и други). Тогава броят на константите в системата може да се увеличи няколко пъти!
Разбира се, би било възможно да се добавят предварително дефинирани елементи към всяка от директориите и достъпът до тях ще стане много по-лесен. Промяната на обектите по подразбиране обаче би затруднила актуализирането на конфигурацията от пакетите на доставчика.
Съществува по-оптимален подход както по отношение на разработването на структурата на метаданните за конфигурация, така и по отношение на производителността на системата. За това ще говорим днес.
Универсално решение
Същността на универсалното решение ще бъде следната: ще бъде създадена директория, в която разработчикът ще добави предварително дефинирани елементи. Атрибутът „Стойност“ е добавен към търсенето, чийто тип зависи от стойностите, за които ще бъде създадено съответствието „Предварително зададен елемент за търсене -> Свързана стойност“. Структурата на метаданните на директорията изглежда така (вижте следната екранна снимка).
За да получите предварително дефиниран елемент, най-добрият вариант е да използвате глобалния метод "PredefinedValue(<Имя>)" . Пълният път до предварително дефинирания елемент се предава като параметър на метода. Синтаксисът е подобен на функцията на езика за заявки VALUE().
За по-лесно разработване препоръчвам да поставите функцията за получаване на стойността, свързана с предварително дефиниран елемент, в общ модул. В тестовата конфигурация, достъпна за изтегляне чрез връзката в края на статията, беше създаден общ модул „Стойности на предварително дефинирани елементи“ с функция за експортиране "GetValue of PredefinedElement(<ИмяПредопределенногоЭлемента>)" . Програмният код на функцията получава препратка към предварително дефиниран елемент, след което получава стойностите на атрибута „Стойност“, използвайки заявка. Следната екранна снимка показва пълния списък с функции.
Както виждаме, функцията генерира заявка за атрибута “Value” на предефинирания елемент, предаден като параметър. Параметърът на функцията е низ с името на предварително дефиниран елемент.
За да работи правилно създаденият механизъм, трябва да свържете предварително дефиниран елемент в потребителски режим с обикновен елемент от директорията, като изберете съответния елемент в атрибута „Стойност“. Да преминем към въпроса за въздействието върху производителността.
Въздействие върху производителността
Проведох тест за скорост и за двете опции за търсене: по име и по връзка от предварително зададен елемент. Търсенето се проведе в директория "Продукти" с 20 000 записа. При провеждане на тестове върху файлова база данни бяха получени следните резултати:
Резултатите показаха, че за файловата версия на работа използването на предварително дефинирани елементи за получаване на често използвани елементи от други директории е почти 4 пъти по-бавно!
Във версията клиент-сървър на работа резултатите от теста показват съвсем различна картина. Скоростта на получаване на връзка към желания елемент не е намаляла значително (един от тестовете показа 0,002 секунди за търсене по име и 0,0008 секунди при работа с предварително зададен елемент), но надеждността на програмата се е увеличила значително!
заключения
В случаите, когато често е необходимо да се свързвате към обикновени елементи на директория, препоръчвам да не използвате обвързване по код или име. Този подход намалява надеждността и производителността на системата.
По време на работата си с платформата неведнъж съм се сблъсквал със ситуации, при които след промяна на името, например елемент на директорията „Типове на номенклатурата на цените“, работата на повечето нестандартни отчети се провали.
Колкото повече алгоритми са свързани с обикновени елементи на директория чрез код или име, толкова по-малко стабилна е системата.
В допълнение, този подход ще ви позволи да не променяте стандартните конфигурационни обекти, ако трябва да добавите предварително дефиниран елемент към тях. Това ще направи процеса на актуализиране на конфигурацията малко по-лесен в бъдеще.
Файлове за изтегляне:
- Качване на тестова база данни с примери от статията.
Добър ден.
Днес ще говорим за иновациите в платформа 8.3 по отношение на предварително дефинираните елементи.
Въведение
Позволете ми да ви напомня, че по-рано на практика много често исках да погледна елемент от директория, за да разбера неговото предварително дефинирано име. Например, създадохте два предварително дефинирани контрагента и ги нарекохте IPSidorov и OOOMeteor. И им пришиха някаква логика.
Когато всичко беше отстранено и разработено, се оказа, че задачата е поставена обратно и логиката за индивидуалния предприемач е необходима за LLC, а логиката на LLC е необходима за индивидуалния предприемач. „Няма проблем“, казваме ние и в корпоративния режим преименуваме елементите. В крайна сметка влизането в кода е много по-трудно. Минава година и вие получавате нова задача: да настроите още малко логика за IP Sidorov. Влизате в конфигуратора, пишете логика, започвате да проверявате и нищо не работи, защото... в конфигуратора IPSidorov, а в предприятието - OOOMeteor. Мозъкът е счупен и искам да унищожа това гребло. Най-простото и очевидно нещо е да се покаже името на предварително дефиниран елемент под формата на списък. Ето уловката: можете да получите само името на предварително дефиниран в 8.2, като използвате метода. Но методът има своите неудобства; не може да бъде получен чрез заявка. Тези. Първото неудобство е да получите името на предварително дефинирания от препратка към директорията.
Второто неудобство е, когато вече имаме елемент от директория и трябва да го направим предефиниран. Създаваме предварително дефиниран елемент и получаваме два елемента в директорията. Единият е предварително дефиниран, другият е оперативен, който се споменава във всички наши документи. Подмяната на връзки със сигурност помага, но ако базата данни е голяма, тогава е трудно.
Сега към точката
Първото е, че директорията вече има свойството „Актуализиране на предварително зададени данни“.
Какво ни дава това поле? Ако е зададено на „Не актуализирай автоматично“, тогава чрез добавяне на предварително дефиниран елемент няма да го видим веднага в директорията. Тези. метаданните нямат нищо общо с данните. И ако не го създадете в директорията, тогава достъпът до него чрез неговото име чрез мениджъра на директории ще доведе до синтактична грешка.
Много интересно, но защо? Как можем да създадем елемент в директорията? Можете да го създадете, както искате, или можете да го свържете към съществуващ. Сега директорията има атрибут "Име на предварително дефинирани данни". Създаваме елемент на директория програмно, както обикновено чрез „Directories.Contractors.CreateElement()“ и попълваме неговия атрибут „PredefinedDataName“, равен на името на предварително дефинирания елемент. Или ако елементът вече съществува, получаваме неговия обект и отново попълваме „Име на предварително дефинирани данни“. Всичко.
И накрая малко сироп
Този нов атрибут е не само годен за четене и писане, той също е наличен в заявки. По този начин можете да му налагате условия в заявки, да определяте дали е предварително дефиниран или не.
Благодаря за вниманието.
Всеки знае разликата между предварително дефинираните елементи и обикновените: „Предварително дефинираните елементи се създават в режим Конфигуратор и не могат да бъдат изтрити в режим 1C:Enterprise.“ В потребителски режим можете да различите предварително дефиниран елемент от тези, добавени от потребителите, като използвате специална икона (вижте следната екранна снимка).
По принцип предварително дефинираните елементи се създават от разработчиците, за да се обвържат алгоритми към тях в различни конфигурационни обекти. Например в конфигурацията „Manufacturing Enterprise Management“ в директорията „Quality“ разработчиците добавиха предварително дефиниран елемент „New“.
Този елемент се използва в много конфигурационни модули. Така че в документа „Получаване на стоки и услуги“ при осчетоводяване във всички регистри, където има измерение „Качество“, се замества стойността на предварително зададен елемент. Следва списък на попълването на таблицата за осчетоводяване за регистъра "Стоки на организации":
// ПРОДУКТИ ПО РЕГИСТЪР ProductsOrganizations. MoveSet = Премества. ПродуктиОрганизации; Ако Тип разписка = Трансфери. Видове разписки за стоки. Тогава в склада // Вземете таблица със стойности, която съответства на структурата на набора от записи в регистъра. MotionTable = MotionSet. Unload() ; // Попълване на таблицата за движение.С общо предназначение. LoadValueTable(ProductTable, MovementTable) ; // Липсващи полета.Таблица за движение. FillValues(Организация, "Организация" ) ; Таблица за движение. FillValues(Undefined, "Комисионер"); Таблица за движение. FillValues(Директории. Качество. Ново, "Качество" ); // Попълнете качеството от предварително дефиниран елементПо този начин характеристиките на предварително дефинираните елементи и тяхното предназначение са доста прости. Нека да разгледаме начина, по който те се съхраняват в таблиците на базата данни и как се различават от обикновените елементи.
Разлики
В тестовата конфигурация е създадена директория "Продукти". В него е създадена група "Тестови елементи". Можете да видите съдържанието на групата на екранната снимка в началото на статията. За директорията „Продукти“ SQL базата данни има съответстваща таблица „_Reference37“ със следната структура:
Но как можем да определим дали подробностите съответстват на конфигурационното дърво и полетата в SQL таблицата?
Ще използваме стандартния метод за глобален контекст „GetDatabaseStorageStructure()“, който ще ни върне таблица със стойности с описание на структурата на таблицата.
В таблицата със стойности „Полета“ виждаме съответствието между полетата на SQL таблицата и детайлите на обекта в дървото с метаданни. В нашия пример разглеждаме структурата на директорията „Продукти“. Всички директории имат стандартен атрибут "Predefined" от булев тип, който е зададен на TRUE за предварително дефинирани елементи:
Въз основа на таблицата със структурата за съхранение на директория в базата данни можем определено да кажем, че полето „Предварително зададено“ съответства на полето „IsMetadata“. Ако погледнем съдържанието на таблицата "_Reference37" в SQL базата данни, ще видим следното:
В записа за предварително дефинирания елемент стойността на полето "IsMetadata" е зададена на "0x01", което съответства на флага TRUE. За нормалните елементи стойността е зададена на "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 формуляра (видове формуляри) за директории:
- форма на елемент– за създаване или редактиране на елемент от директория;
- групова форма- за създаване или редактиране на група директории;
- форма на списък– за показване на списък с елементи на директория;
- формуляр за избор- използва се за избор на един от елементите на тази директория в поле от определена форма. Например, за да изберете конкретен склад от директория Складове в документа Стокова разписка в полето Склад;
- формуляр за избор на група– служи за избор на една от групите на тази директория в поле на определена форма.
Предварително дефинирани елементи на директория– елементи на директория, създадени от разработчика в режим на конфигуратор и които могат да бъдат достъпни от вградения 1c език по име.
Има фундаментална разлика между обикновените и предварително дефинираните елементи на директория. Обикновените елементи не са постоянни в конфигурацията. По време на работа на потребителя те могат да се създават, редактират и изтриват и поради тази причина не трябва да се разчита на тях при изпълнението на каквито и да било алгоритми (кодът и името на елемента могат да бъдат променяни от потребителя).Предварително дефинираните елементи, от друга страна, са постоянни. По време на работа, дори ако потребителят преименува такъв елемент, той може да бъде достъпен от вградения 1c език. Това се постига, като предварително дефинираният елемент има опора Име, който не е достъпен за потребителя. Обикновените елементи на директория нямат такива атрибути.
важно! Технически, потребителят има възможност да изтрие предварително дефиниран елемент от директория, но по правило потребителите нямат права да изтриват предварително дефинирани елементи от директория.
Домашна работа за урок 4 от курса
Домашната работа за четвъртия урок от курса ще бъде достъпна за вас веднага след успешно решаване на теоретичния тест.
