внимание! Ето пробна версия на урока, чиито материали може да не са пълни.
Влезте като студент
Влезте като ученик за достъп до училищно съдържание
1C 8.3 език за заявки за начинаещи програмисти: функция VALUE
функция ЗНАЧЕНИЕ проектирани да се справятв тялото на заявката към системните стойности на enumИ предварително дефинирани данни.
Какво друго за трансфери и предварително зададени данни, ще попитате. Нека поговорим за всичко по ред.
Изброявания
Изброявания- това е обект на приложение (сещате се, че все още има СправочнициИ Документация). Защо беше нужен?
Въпросът е, че изброяването е специален обект. За разлика от ръководствата и документите всички възможни стойности на изброяване се задават на етапа на конфигуриранеи не може да се променя допълнително в потребителски режим.
Неизменността е основният им коз. Това са един вид константи на база данни.
И ако програмистът в режим на конфигурация създаде изброяване с име Етажи ценности МъжкиИ Женски пол, тогава когато пише програма, той може да бъде сигурен, че стойностите на това изброяване няма да се променят в бъдеще. Следователно той може безопасно да получи достъп до тези стойности от кода.
Представете си какво ще се случи, ако той се опита да използва директорията за тези цели?
Първо, някой потребител ще продължи и ще добави малко "марсиански под".
Второ, друг потребител ще приеме „да“ и ще изтрие един от вече съществуващите полове или ще промени името си.
И програмата ще се счупи от това, защото за нейната работа е необходимо да има точно два пола и с имената "Мъжки" и "Женски".
Именно за такива случаи съществуват изброения: за да веднъж (дори на етапа на конфигуриране) твърдо да зададете всички възможни стойности и по-късно да ги използвате в програмния код.
Нека да разгледаме пример за такова изброяване в нашата база данни „Gastronom“. Четете пробна версия на урока, намират се пълни уроци.
Ето го изброяването ни с името Етаж. Какви стойности може да приеме?
Има само две стойности. С имената "Мъжки" и "Женски". Това, от което се нуждаем.
Къде можем да използваме това изброяване в бъдеще? Е, разбира се, в ръководството клиенти. Обърнете внимание, че в неговия списък има нов проп Етажи тип Enum.Gender:
По този начин, когато попълваме клиентската карта вече в потребителски режим, ще можем да изберем само две стойности Мъж и Жена като пол на клиента:
Сега нека направим заявка, която избира клиенти и техния пол от базата данни:
Сега нека променим заявката, така че да останат само мъже. Ако се опитаме да напишем нещо като:
тогава не получаваме нищо:
Тъй като не е възможно да получите достъп до изброени стойности по този начин. Те трябва да бъдат достъпни чрез функцията ЗНАЧЕНИЕ:
И така, една от задачите на функцията ЗНАЧЕНИЕ- използване на изброени стойности в заявки.
предварително дефинирани данни
По-добре да покажа с пример какво представляват предварително дефинираните данни за директории. Четете пробна версия на урока, намират се пълни уроци.
В нашата база данни "Gastronom" (в потребителски режим) отворете справката "Мерни единици":
Разгледайте елементите му. Виждате ли жълтите кръгове до някои от елементите? Тези елементи (които имат кръгове) са предварително дефинирани данни.
По принцип, ако някой елемент от директорията е предварително дефиниран (т.е. има жълт кръг върху него), тогава този елемент е специален.
Първо, това означава, че елементът е създаден на етапа на конфигуриране от програмиста (в нашия случай това са елементи с кодове 1, 2 и 3).
И второ, това означава, че този елемент е много важен за функционирането на програмата. Че някакъв код в базата данни е свързан с него (или по-скоро с неговото предварително дефинирано име).
Ето защо простото изтриване на такъв елемент няма да работи. Опитайте да го маркирате за изтриване:
Нека сега да преминем към режима на конфигурация и да видим къде са създадени тези много предварително дефинирани елементи (в този случай за справочника за мерни единици):
Тук са всички наши предварително дефинирани елементи за референтната мерна единица. Имайте предвид, че всички предварително дефинирани елементи имат специално име, което не се показва в потребителски режим.
За елемент с код 1 това име е Тон, с код 2 - Грам и т.н. Това име се нарича предварително зададено име на елементи именно с това име можете да го посочите от кода (или от заявката в нашия случай).
Може да попитате защо не беше възможно да се направят мерните единици просто изброяване с елементите тон, грам и опаковка? И всичко това, защото в този случай за нас е важно референтната мерна единица винаги да съдържа някои специфични елементи (тон, грам и опаковка), но в същото време не искаме да забраним на потребителя да добавя някой от техните елементи ( килограм, парче и т.н.). Четете пробна версия на урока, намират се пълни уроци.
Следователно предварително дефинираните елементи определено са по-подходящи тук от enums.
И можем да получим достъп до нашите предварително дефинирани елементи от заявката, като използваме функцията, която вече ни е позната ЗНАЧЕНИЕ:
Направете теста
Стартирайте теста
1. Стойностите на Enum са зададени
2. Да се съхранява списък със складове във фирма, вид
3. Да се съхранява списък на мерните единици в склад, вид
4. Да съхранява данъчни ставки, чийто списък не трябва да се променя от потребителя, вида
5. За препратка към изброената стойност в заявка е подходяща функция
6. Да съхранява данъчни ставки, чийто списък ще се променя от потребителя, вида
7. Предварително зададените данни идват от
Когато работите на платформата 1C:Enterprise 8.x, често става необходимо да се обвърже в програмния код обикновени (не предварително дефинирани) елементи на директории. Например една организация може да има пет вида цени, които се използват в почти всички механизми. В същото време програмният достъп до конкретна цена в най-добрия случай се осъществява или чрез скърцане на кода в директорията, в най-лошия случай от името на елемента.
Бях свидетел как в отчетите, за да се получи необходимата цена, се използваше селекция от типа цена в заявката по нейното име (вижте следната екранна снимка).
Освен това, ако се обвържете с името или кода на елементите на директорията, тогава, когато получите връзка към елемента, винаги ще се извършва търсене в таблицата на директорията. Въпреки факта, че стандартните системни детайли се индексират от СУБД, търсенето в тях в някои случаи може да отнеме значителни ресурси. Освен това би било по-рационално да не се изпълнява заявка за търсенеспоред референтната таблица, ако, да кажем, препратката към елемента вече е "известна предварително".
Като изход можете да съхранявате връзка към всеки често използван елемент от директорията „Типове цени на артикули“ в отделни константи и да получавате стойности от тях в заявката. В този случай обаче разработчикът ще трябва да добави отделна константа за всеки такъв елемент. Ситуацията ще стане много по-сложна, ако такива елементи не са само в директорията „Номенклатурни видове цени“, но и в други директории („Категории обекти“, „Качество“, „Номенклатура“ и други). Тогава броят на константите в системата може да се увеличи няколко пъти!
Разбира се, би било възможно да се добавят предварително дефинирани елементи към всяка от директориите и достъпът до тях ще стане много по-лесен. Промяната на общите обекти обаче би затруднила актуализирането на конфигурацията от пакетите на доставчика.
Съществува по-оптимален подход както по отношение на разработването на структурата на метаданните за конфигурация, така и по отношение на производителността на системата. За него днес и ще бъде обсъдено.
Решение на едно гише
Същността на универсалното решение ще бъде следната: ще бъде създадена директория, в която разработчикът ще добави предварително дефинирани елементи. Към речника е добавен атрибутът „Стойност“, чийто тип зависи от стойностите, за които ще бъде създадено съответствието „Предварително зададен речников елемент -> Свързана стойност“. Структурата на метаданните на директорията изглежда така (вижте следната екранна снимка).
За да получите предварително дефиниран елемент най-добрият варианте да използвате глобалния метод "PredefinedValue(<Имя>)" . Предава се като параметър на метода пълен пъткъм предварително зададен елемент. Синтаксисът е подобен на функцията на езика за заявки "VALUE()".
За удобство на разработката препоръчвам да преместите функцията за получаване на стойността, свързана с предварително дефиниран елемент, в общ модул. IN тестова конфигурация, достъпен за изтегляне от връзката в края на статията, е създаден общ модул „Стойности на предварително дефинирани елементи“ с функция за експортиране "GetPredefinedElementValue(<ИмяПредопределенногоЭлемента>)" . Програмен кодфункцията получава препратка към предварително дефиниран елемент, след което по заявка получава стойностите на атрибута "Стойност". Следващата екранна снимка показва пълния списък на функцията.
Както виждаме, функцията формира заявка към атрибута "Value" на предефинирания елемент, предаден като параметър. Параметърът на функцията е низ с името на предварително дефиниран елемент.
За да работи правилно създаденият механизъм, трябва да свържете предварително дефиниран елемент в потребителския режим с обикновен елемент от речника, като изберете съответния елемент в атрибута "Стойност". Да преминем към въпроса за въздействието върху производителността.
Въздействие върху производителността
Проведен тест за скорост и за двете опции за търсене: по име и по връзка от предварително дефиниран елемент. Търсенето е извършено в указател "Стоки" с 20 000 записа. При провеждане на тестове върху файловата база бяха получени следните резултати:
Резултатите показаха, че за версия на файларабота, използването на предварително дефинирани елементи за получаване на често използвани елементи от други директории е почти 4 пъти по-бавно!
Във версията клиент-сървър на работа резултатите от теста показват съвсем различна картина. Скоростта на получаване на връзка към желания елемент не намаля значително (един от тестовете показа 0,002 секунди за търсене по име и 0,0008 секунди при работа с предварително зададен елемент), но надеждността на програмата се увеличи значително!
заключения
В случаите, когато често е необходимо да се свързвате с обикновени елементи на директорията, препоръчвам да не използвате свързване по код или име. Този подход намалява надеждността и производителността на системата.
Докато работя с платформата, многократно съм се сблъсквал със ситуации, когато след промяна на името, например, работата на повечето нестандартни отчети се срива за елемента на справочника „Видове номенклатурни цени“.
Колкото повече алгоритми са свързани с обичайните елементи на директории чрез код или име, толкова по-малко стабилна е системата.
В допълнение, този подход ще ви позволи да не променяте типичните конфигурационни обекти, ако трябва да добавите предварително дефиниран елемент към тях. В бъдеще това ще направи процеса на актуализиране на конфигурацията донякъде по-лесен.
Изтегляния:
- Разтоварване на тестова база данни с примери от статията.
Всеки знае разликата между предварително дефинираните елементи и обикновените: "Предварително дефинираните елементи се създават в режим Конфигуратор и не могат да бъдат изтрити в режим 1C:Enterprise." В потребителски режим можете да различите предварително дефиниран елемент от тези, добавени от потребителите чрез специална икона (вижте следната екранна снимка).
По принцип предварително дефинираните елементи се създават от разработчиците, за да обвържат алгоритми върху тях в различни конфигурационни обекти. Например в конфигурацията „Управление на производствено предприятие“ в справочника „Качество“ разработчиците са добавили предварително дефиниран елемент „Нов“.
Този елемент се използва в много конфигурационни модули. Така в документа "Получаване на стоки и услуги" при осчетоводяване във всички регистри, където има измерение "Качество", се замества стойността на предварително зададен елемент. Следва списък на попълване на таблицата за осчетоводяване според регистър "Стокови организации":
// СТОКИ ПО РЕГИСТРИ СтокиОрганизации. MoveSet = Премества. СтокиОрганизации; Ако ReceiptType = Изброявания. Видове стокови разписки. Тогава в склада // Вземете таблица със стойности, която съответства на структурата на набора от записи в регистъра. MoveTable =MoveSet. Unload() ; // Попълване на таблицата за движение.С общо предназначение. LoadToValueTable(TableByProducts,TableMovements) ; // Липсващи полета.Таблица на движенията. FillValues(Организация, "Организация" ) ; Таблица на движенията. FillValues(Undefined, "Комисар"); Таблица на движенията. FillValues(Референции. Качество. Ново, " Качество " ); // Попълване на качеството от предварително дефиниран елементПо този начин характеристиките на предварително дефинираните елементи и тяхното предназначение са доста прости. Нека разгледаме как се съхраняват в таблиците на базата данни и как се различават от обикновените елементи.
Разлики
В тестовата конфигурация е създадена директория "Стоки". В него се създава групата "Тестови елементи". Можете да видите съдържанието на групата на екранната снимка в началото на статията. За справочника "Продукти" в SQL базата данни има съответстваща таблица "_Reference37" със следната структура:
Но как да определим съответствието между детайлите на конфигурационното дърво и полетата в SQL таблицата?
Нека използваме стандартния метод на глобалния контекст "GetDatabaseStorageStructure()", който ще върне таблица със стойности с описание на структурата на таблицата.
В таблицата със стойности „Полета“ виждаме съответствието между полетата на SQL таблицата и детайлите на обекта в дървото с метаданни. В нашия пример разглеждаме структурата на директорията "Продукти". Всички речници имат стандартен атрибут "Предварително дефиниран" от булев тип, който е зададен на TRUE за предварително дефинирани елементи:
Според таблицата със структурата за съхранение на директория в базата данни можем определено да кажем, че полето „Predefined“ съответства на полето „IsMetadata“. Ако прегледаме съдържанието на таблицата "_Reference37" в SQL базата данни, ще видим следното:
В записа за предварително дефинирания елемент стойността на полето "IsMetadata" е зададена на "0x01", което съответства на флага TRUE. За нормалните елементи стойността е зададена на "0x00". Това е основната разлика между предварително дефинираните елементи и обикновените. Всички други полета се съхраняват в базата данни по същия начин като полетата на обикновените елементи, добавени от потребителите.
Предварително дефинираните елементи могат да намерят много интересна цел. С тяхна помощ можете да забраните изтриването / маркирането за изтриване на група елементи в директорията и други обекти, където могат да бъдат добавени. Ако се опитаме да изтрием или маркираме за изтриване групата „Тестови елементи“. получаваме следните грешки:
Така предварително дефинираните елементи правят групата, в която са поставени, също „предефинирана“.
Завършване
Предварително дефинираните елементи са неразделна част от повечето конфигурации. Използването им опростява разработката и прави изграждането на функционалността логически по-„хармонично” и солидно.
Валидно за платформа версия 1C:Enterprise 8.3.3 и по-висока без режим на съвместимост с версия 8.2
1.1. В указатели, сметкопланове, диаграми на типове характеристики и диаграми на типове изчисления е възможно автоматично или програмно да се създават предварително дефинирани елементи.
1.2. В повечето случаи се препоръчва автоматично създаване на предварително дефинирани елементи, тъй като те са постоянно необходими и искате да улесните достъпа до тези елементи от вашия код.
Например предварително зададена държава Русияв указателя Страни по света, предварително дефиниран профил на групи за достъп Администратори така нататък.
За това
- в свойството на справочника, сметкоплана, плана на видовете характеристики или плана на видовете изчисления, стойността трябва да бъде зададена Автоматичен(по подразбиране) и не трябва да позволява програмни извиквания на метода SetUpdatePredefinedDataтези обекти, за да превключите този режим.
- попречете на потребителите да изтриват предварително дефинирани елементи, като деактивирате следните права във всички роли (деактивирани по подразбиране):
- Интерактивно изтриване на предварително дефинирани данни
- InteractiveDeletionMarkPredefinedData
- InteractiveUnflaggingDeletingPredefinedData
- InteractiveDeletingLabeledPredefinedData
1.3. Изключение са дъщерните възли на RIB, в които предварително дефинираните елементи не се създават автоматично (и не се актуализират при промяна на метаданните), но трябва да бъдат прехвърлени от главния възел заедно с промените в конфигурацията.
при което:
a) конфигурацията трябва да гарантира, че съобщението за обмен е заредено в подчинения възел на RIB преди изпълнението на друг приложен код, който осъществява достъп до предварително дефинираните елементи, получени от главния възел;
б) в логиката на приложението за зареждане на данни от главния възел (манипулатор на събития При получаване на данни от Master, правила за регистрация на обекти) препратките към предварително дефинирани елементи трябва да се избягват, тъй като няма гаранция, че те вече са били заредени от съобщението за обмен;
в) кодът на манипулаторите за актуализиране на IS, които обработват предварително дефинирани елементи, не трябва да се изпълняват в RIB подчинени възли:
Ако планове за обмен. MainNode() = Недефиниран Тогава // попълване на предварително дефинирани елементи// ... EndIf ;При използване на подсистемата "Обмен на данни" в конфигурацията на Библиотеката на стандартните подсистеми (BSP) версия 2.1.4 и по-нова, изискванията (a) и (b) се премахват.
1.4. За таблици с предварително дефинирани елементи, които не са част от плана за обмен на RIB (и които не са посочени от други таблици, които са част от плана за обмен на RIB), се препоръчва да зададете свойството Актуализиране на предварително зададени даннив смисъл Актуализиране автоматично, както и при първото стартиране на подчинения възел RIB, комплект автоматична актуализацияв данните с повикване:
Справочници. Име на директория> . SetUpdatePredefinedData(UpdatePredefinedData. UpdateAutomatically) ;
2. В някои случаи не е необходимо предварително дефинираните елементи да се създават автоматично, ако наличието им зависи от някакво условие: активирана функционална опция, режим на работа на програмата и др.
Например някои предварително дефинирани типове изчисления в плана на видовете изчисления начислениязависят от стойностите на функционалните опции Използвайте проследяване на времето EmployeesIn Hours, Използвайте Печалби на парчеи т.н.
За това
- в собственост Актуализиране на предварително зададени даннисправочник, сметкоплан, диаграма с типове характеристики или диаграма с типове изчисления трябва да бъдат зададени на „Не актуализирай автоматично“
- предоставя код за създаване (и обезсилване) на предварително дефиниран елемент в зависимост от бизнес логиката, например:
- вземете предвид липсата на предварително дефинирани елементи в IS в кода на приложението. В противен случай, при достъп до несъществуващ предварително дефиниран елемент от кода или текста на заявката, ще бъде хвърлено изключение:
Когато използвате библиотеката на стандартните подсистеми (SSL) версия 2.1.4 и по-нова в конфигурацията, се препоръчва да използвате функцията Предварително дефиниран елементобщ модул Клиентски сървър с общо предназначение, който се връща Недефиниранза предварително дефинирани елементи, които не съществуват в IB.
Печат (Ctrl+P)
Работа с предварително зададени стойности с помощта на Object Manager
Можете да получите предварително зададена стойност от страната на сървъра на 1C:Enterprise, като използвате съответния мениджър на обекти. Низът, който дефинира получения атрибут, има следната форма:
PredefinedValueType.MetadataObjectName.Value
● Предефиниран тип стойност– за получаване на предварително зададени стойности могат да бъдат зададени следните типове данни (записани на
множествено число):
● Наръчници,
● Планове на типове характеристики,
● Сметкопланове,
● Планове за типове изчисления,
● Изброявания.
● Име на обект с метаданни
● Стойност - може да бъде едно от следните:
● за изброяване се посочва името на стойността на изброяването;
● RoutePoints.PointName е точката на маршрута на бизнес процеса.
В случай, че е необходимо да се получи точка на маршрут на бизнес процес, низът, описващ получената стойност, ще изглежда така:
BusinessProcesses.MetadataObjectName.RoutePoint.RoutePointName
Пример:
Вид = Изброявания. Видове стоки. Стоки;
// Получаване на предварително дефинирани данни за директория.
Елемент = Директории.Валута.Рубла;
// Точка на маршрут на бизнес процес
Точка = Бизнес процес Одобрение Маршрут Точки Одобрение;
Работа с предварително зададени стойности Използване на функцията Предварително зададена стойност ()
Поради факта, че обектите на приложението не са налични от страна на клиента, получаването на предварително дефинирани атрибути с помощта на мениджъри на обекти става невъзможно. Следователно, за да ги получите, има метод за глобален контекст PredefinedValue(). Параметърът на този метод е низ, описващ каква предварително дефинирана стойност трябва да бъде извлечена. Синтаксисът за описание на предварително дефинирана стойност е същият като за оператора VALUE на езика за заявки.
Низът, който дефинира получения атрибут, има следната форма:
Нека разгледаме по-подробно компонентите на тази линия:
● Предефиниран тип стойност– за получаване на предварително зададени стойности могат да бъдат зададени следните типове данни (записани на
единствено число):
● Наръчник,
● PlanSpeciesCharacteristics,
● Сметкоплан,
● Изчисляване на типове планове,
● Обява,
● Бизнеспроцес.
● И ObjectNameMetadata– задайте името на обекта с метаданни, както е посочено в конфигуратора.
● Стойност - може да бъде едно от следните
● за изброяване се посочва името на стойността на изброяването;
● за да получите предварително зададена стойност, посочете името й, както е посочено в конфигуратора;
● RoutePoint.PointName – точка на маршрут на бизнес процес;
● EmptyLink - за получаване на празна връзка.
Ако трябва да получите стойността на системното изброяване, параметърът на метода ще изглежда така:
SystemEnumName.SystemEnum Стойност.
Например:
ChartType = PredefinedValue("ChartType.ConcaveSurface“);
Ако искате да получите точка на маршрут на бизнес процес, низът, описващ стойността, която получавате, ще изглежда така:
Пример:
// Получаване на стойността на enum.
Изглед = Предварително зададена стойност(“Изброяване.Видове стоки.Стоки”);
// Вземете стойността на празна препратка.
Празна връзка =
Предварително зададена стойност(“Document.Invoice.EmptyReference”);
// Получаване на предварително дефинирани данни за директория.
Елемент = Предварително зададена стойност(„Наръчник. Валута. Рубла“);
// Точка на бизнес процес
Точка = Предварително зададена стойност(“BusinessProcess.Agreement.Routepoint.Approval”);
Зареждане...