≡×МЕНЮ

• Връзка
• руски стандарт
• Интернет банкиране
• търговия
• организации

Функционални опции и параметри на функционалните опции. Изграждане на разпределени информационни системи, търсене, рутинни задачи, функционални опции 1в не успя да получи стойността на функционалната опция

Функционални опции Механизъме един от инструментите за разработка. Позволява ви да дефинирате в конфигурацията функционалността, която може или не може да се използва по време на внедряването, в зависимост от нуждите на конкретна организация.

Работата на механизма се основава на два конфигурационни обекта:

• Функционална опция
  Функционалните опции, добавени към приложното решение, могат да бъдат свързани с конфигурационни обекти и техните атрибути. Например с функционалната опция Складово счетоводствоможе да свързва реквизит Складдокумент Касова бележка. След това, ако тази функционална опция е активирана в режим 1C:Enterprise, полето Складще се показва във всички форми на документа. Ако е забранено - поле Складняма да се покаже. Прочетете още...

• Параметър на функцията
  Опциите на функциите могат да се използват с параметри. Например, за да зависи появата на определена форма от стойността на параметъра, избран във формуляра. Например параметър на опция за функция Валутно счетоводствоможе би организация. След това, в зависимост от това коя организация е избрана във формуляра, полето Валута за сетълментще бъде скрит или показан. Прочетете още...

.
„1C: ERP Enterprise Management“ е иновативно решение за изграждане на комплексни информационни системи за управление на дейностите на разнообразни предприятия, включително такива с технически сложно многопроцесорно производство, като се вземат предвид най-добрите световни и местни практики за автоматизиране на големи и средни предприятия.
Малко инфографики:

Днес (март 2016 г.) повече от 900 предприятия са станали потребители на 1C:ERP и техният брой расте. В същото време няколко десетки проекта, от гледна точка на разработчиците, получиха статут на "пилотен", т.е. тези предприятия и организации основно участват активно в разработването на нова функционалност, предоставяйки своевременно обратна връзка.
Ето лога на някои потребители на 1C:ERP:


Интересна особеност на решението 1C: ERP е, че ние разработваме едно решение- 1C: ERP - и от неговите източници автоматично получаваме четири решения(чрез „изрязване“ на функционалност и превключване на функционалните опции):


При разширяване на бизнеса или увеличаване на нуждите на компанията от автоматизация, функционалността на системата може да се увеличава поетапно, преминавайки от конфигурация „Управление на търговията“ към конфигурация „Комплексна автоматизация“ и след това към „ERP Enterprise Management 2“. Поради високата степен на унифициране на решенията, такъв преход се извършва бързо, данните, натрупани в информационната база данни, се запазват и не се изисква преквалификация на потребителите - те продължават да работят в познатата софтуерна и информационна среда.

Как се пише 1C:ERP

Как вземаме четири решения от едно

Разработката се извършва само в един клон (ERP). Автоматизиран е процесът на формиране от водещото ERP решение на по-лека, функционално ограничена Интегрирана автоматизация (наричана по-долу - KA за краткост) и две разновидности на управление на търговията (по-нататък - UT и UT Basic).
Промените от ERP към "производни" конфигурации (KA, UT, UT Basic) се прехвърлят автоматично, като се използва механизмът за сравнение и сливане на конфигурациите. Този механизъм първоначално е проектиран да автоматизира процеса на преход към нови версии на приложните решения за тези потребители, които променят/разширяват функционалността на приложното решение от своя страна. Механизмът за сравнение и сливане на конфигурации извършва тристранно семантично сливане въз основа на анализа на три конфигурации:

• стара конфигурация на доставчика
• нова конфигурация от доставчика
• текуща потребителска конфигурация (стара конфигурация от доставчика плюс промени, направени в нея от потребителя)

В резултат на това получаваме нова текуща конфигурация, която съчетава нова функционалност (въведена от разработчика) и спестява подобрения (персонализации), направени от потребителя.
В нашия случай ролята на текущата конфигурация е алтернативно KA, UT, UT Basic, ролята на старата и новата конфигурация от доставчика е съответно ERP на старата и новата версия. Тези. вярваме, че функционално ограничените конфигурации - KA, UT, UT Basic - са персонализирани (главно чрез премахване на неизползвани обекти) версии на ERP.


Един от малкото обекти, които се пишат ръчно за всяко от решенията, са планове за обмен, които определят правилата за интегриране на това решение с други 1C решения (например с 1C: Управление на документи) или, например, с външно оборудване. Но благодарение на постепенния преход в обмена на данни към единен стандарт EnterpriseData, ние намаляваме броя на плановете за обмен, които са уникални за конкретно решение, и се опитваме да използваме един код за обмен на данни.
Има една интересна особеност в този подход. Цялото решение се записва веднъж, в ERP клона; но повечето от кода, формуляри, скриптове, отчети и т.н. се използва в четири решения, и то много различни - ERP се внедрява в предприятия с хиляди потребители, а UT Basic е предназначен да обслужва индивидуални предприемачи. Опитваме се да обърнем много внимание на използваемостта на нашия продукт.
Международният стандарт ISO 9241-11 определя използваемостта като:

степента, в която продуктът може да се използва определени потребители в определен контекст на използване за постигане на определени цели с необходимата ефективност, производителност и удовлетворение

Опитваме се да напишем приложението по такъв начин, че да е лесно и удобно да се работи с него дори и за неопитен потребител.

Характеристики на развитие

Когато разработваме ERP, винаги трябва да помним, че разработената функционалност може да се използва в едно или повече решения, получени от ERP (KA, UT, UT Basic). За лесно активиране/деактивиране на функционалността, ние използваме широко механизма за функционални опции, който първоначално беше създаден за такива задачи. Функционалните опции ви позволяват да изберете функционалност в приложното решение, която може да бъде активирана/деактивирана по време на внедряването, без да променяте самото приложно решение. Функционалните опции са настройки на решението, квадратчета за отметка, когато са изключени, цялата функционалност, свързана с тях, става недостъпна. На първо място, функционалните опции се използват за фина настройка на програмата за нуждите на конкретна реализация. В ERP ние използваме този механизъм (в допълнение към основната му цел) за „изрязване“ на производни конфигурации от ERP. Например, в ERP решението има функционална опция "Управление на предприятието", с нея е свързана цялата функционалност, отговорна за управлението на производството - планиране на производството, отчитане на производствените разходи, свързани отчети и много други. Тази опция е активирана само в решението 1C: ERP и е деактивирана в "производните" решения KA, UT, UT Basic. Общо 1C:ERP използва около 600 функционални опции.
Друг механизъм на платформата, който улеснява работата на 1C: ERP разработчик, е . Подсистемите са начин за разбиване на функционалността на решение на блокове; всеки обект в решението (каталог, документ, отчет и т.н.) трябва да бъде включен в поне една подсистема. По-специално, ERP решението има три подсистеми, които улесняват изграждането на решения, получени от ERP:

1. "Обекти UE, UT, KA" - обекти, включени във всички приложни решения: управление на търговията, интегрирана автоматизация, управление на предприятието (руско име ERP).
2. "Обекти UE, KA" - обекти, свързани само с конфигурациите на Интегрирана автоматизация и ERP.
3. "UE objects" - обекти, свързани само с ERP решението

Всеки обект на приложение в ERP решение трябва да принадлежи САМО на ЕДНА от тези три подсистеми. Това условие се проверява по време на статичен анализ на кода на ERP решение (вижте по-долу).

Числа след десетичната запетая

Версията на ERP продукта се състои от четири числа, разделени с точки. Например - 2.1.3.117.

• Първият номер (ревизия) във версията се променя изключително рядко (например КА 1.х.х.х и КА 2.х.х.х са разделени с почти 8 години).
• Вторият номер (подиздание) се променя приблизително веднъж годишно. Версията с новото подиздание пуска нова функционалност. Пускането на такива версии често е насрочено да съвпадне с началото на календарната година, така че потребителите да имат достатъчно време да „преместят“ към новата версия.
• Версиите с нов трети номер (релиз) развиват съществуващата функционалност; нова версия излиза на всеки два до три месеца.
• Версиите с актуализиран четвърти номер (сглобяеми компилации) съдържат само корекции на грешки и актуализации, за да бъдат в съответствие с действащото законодателство. Излизат на всеки две седмици.

Можем да имаме до 3 версии на продукта в разработка едновременно, например:

1. 2.1.3.X - Поддържано издание на предишното подиздание. Ще бъде пуснат до края на 2016 г. В тази версия има само корекции на грешки и редакции, които да отговарят на действащото законодателство.
2. 2.2.1.X - Текущата версия на текущото подиздание. Има нова функционалност за подредактиране. За него, преди пускането на 2.2.2.X, ще бъдат пуснати компилации за корекции.
3. 2.2.2.X - Развитие на функционалността на текущата подиздание. Тази версия е в активна разработка.

Като се има предвид, че освен ERP, от всеки ERP клон се получават още 3 решения - KA, UT и UT Basic - получаваме 12 версии на продукти, разположени в 12 различни хранилища.
По време на разработката имаме до 4 хоризонта на планиране, например:

1. 2.1.3 (поддържа се), ние решаваме кои грешки да бъдат коригирани, кои проекти, свързани с промяна на законодателството, ще бъдат реализирани. Ще бъдат приложени само промените, които влязат в сила през 2016 г. Хоризонт – до края на 2016г
2. 2.2.1 (поддържа се) - "външните" грешки са коригирани + промени в законодателството, които влизат в сила преди пускането на 2.2.2. Хоризонт - преди изхода 2.2.2.
3. 2.2.2 (активно разработен) - коригирани са „външни” грешки + открихме грешки + внедрена е нова функционалност. Хоризонт - преди пускане 2.2.3
4. 2.2.3 (планирано). Ако проектът е голям, тогава той може да бъде разработен незабавно за тази версия (и няма да бъде включен в предишната). Horizon - до излизането на 2.2.4 или до края на 2017г.

Използване на продукта "1C: Application Design System" при разработването на ERP

Както вече споменахме, ние от 1С се опитваме да следваме принципа „Яжте своя собствена храна за кучета“, използвайки собствените си продукти в нашите вътрешни процедури. По-специално, при разработването на ERP, ние широко използваме продукта "1C: Application Design System" (съкратено DSS). DSS, както подсказва името, помага при проектирането на приложни решения на платформата 1C:Enterprise и ви позволява да се справяте със задачите на пълния цикъл на разработка на софтуер - събиране на изисквания, контрол на промените, документиране, проследяване на грешки и т.н.
DSS ви позволява да създавате два типа елементи - грешки (които трябва да бъдат коригирани) и изисквания (заявки за нова функционалност). Всичко е повече или по-малко ясно с грешките, нека помислим за създаване на ново изискване.
Причината за създаване на изискване може да бъде:

1. Заявка от партньор или клиент. Ние събираме такива заявки, по-специално на партньорски семинари; чрез гласуване между партньори избираме най-приоритетния от тях.
2. По време на пилотен проект може да възникне искане за въвеждане на нова версия, ако клиентът има важно желание за него.
3. Заявка от нашата служба за техническа поддръжка (по-точно заявка от партньор или клиент, минал през нашата техническа поддръжка), заявка от нашия партньорски форум или от нашия акаунт мениджър (който придружава важен клиент/клиенти за нас).
4. Заявка от екипа за разработка на платформа 1C:Enterprise. Екипът на платформата моли екипа за разработка на ERP (и други типични конфигурации) да използва нова функционалност на платформата - например интерфейса на Taxi, отхвърлянето на модални прозорци, отхвърлянето на синхронни повиквания и т.н.
5. Рефакторинг, оптимизация на архитектурата, подобряване на използваемостта.

Причината за рефакторинг (точка 5) може да са сериозни архитектурни промени (например ревизия на поръчки за доставка, когато поръчките започнаха да се използват вместо фактури).

Продуктът DSS се доставя като част от ERP (но може да бъде закупен и отделно). ERP решението може да се стартира в режим на DSS интеграция; в този случай всеки формуляр ще има бутон „Отвори функционален модел“; когато се натисне, ще се отвори описание на функционалността на формуляра в DSS.


Ето какво се отваря - това е моделът на работното място в IDEF0:


Възможно е и обратното да се изучава функционалния модел и да се отварят формите на работни места от него. Този режим може да се използва при изучаване на работата на програмата.
Важен момент - не се отваря DSS, отваря се формата вътре в ERP, където се зареждат данни от DSS. Тези. интеграцията е "безпроблемна" (потребителят не я вижда). Тази техника се използва при интегриране с други продукти. Например с 1C: Управление на документи (можете да работите, без да напускате ERP с поща, задачи, бизнес процеси, които работят в друга база данни).

Как разработваме ERP: 6 етапа на проекта

Така че беше решено да се приложи ново изискване за промяна на функционалността. Изисквания от същия тип се комбинират в технически проекти. В рамките на нова версия на ERP обикновено се изпълняват от 100 до 150 технически проекта, всеки проект - от една до няколко десетки изисквания. Техническият проект се вписва в DSS; проектът в хода на изпълнение преминава през 6 контролни точки, всяка от които се записва в DSS.
Малко за разделението на екипи в ERP дивизията. Ръководителят на екипа (лидерът на екипа) участва в проектирането и по правило участва в разработката. Екипът обикновено включва и тестери. Екипите за разработка са статични, те са разпределени в няколко предметни области. Ако проектът засяга съседни зони, членовете на съответния екип се включват по време на проекта. Не целият екип може да участва в проекта.
Отговорник за проекта е водещият разработчик или екип. Неговата отговорност е да контролира процесите:

• Висококачествен дизайн, отчитащ всички видове сценарии, взаимодействие със съседни блокове
• Време
• Качество на архитектурата, потребителски интерфейс
• Написване на справка, проектиране на проект, вкл. разработване на функционален модел

Точка 1. Отваряне на проекта

Ръководителят на екипа стартира технически проекти в DSS като списък с версии. Във всеки проект са очертани цели, посочени са изпълними изисквания. Списъкът се обсъжда с мениджъра за разработка преди да започне работа по изданието. Всъщност при отваряне на проект срещи не се провеждат - те просто изпращат проекта до DSS за отваряне.
Екипът на проекта започва разработването на концепцията.

Точка 2. Съгласуване на концепцията

За съгласуване на концепцията се провежда онлайн или офлайн среща, в която участват лицето, отговорно за проекта, ръководителят на екипа, мениджърът за развитие и специалистите, участващи в проекта. Обикновено до този етап лицето, отговорно за проекта, има готова концепция за „голям блок“, която се финализира по време на срещата. Сценариите и описанието на потребителския интерфейс също са дискутирани (и записани в DSS). Ако изискването е родено от заявка от партньори или клиенти, тогава проектните материали (концепции, сценарии, потребителски интерфейс) могат да бъдат изпратени на партньора/клиента за оценка на решението.
По време на срещата се договаря сложността на създаването на прототип (обикновено създаването на прототип отнема до 5 работни дни). Екипът започва изграждането на прототип.

Точка 3. Съгласуване на прототипи

Провежда се среща, по време на която се разглеждат готови прототипи, обсъждат се подробностите за внедряването (по-специално кои обекти ще бъдат добавени и променени), тестват се хипотези, одобряват се прототипи на формуляри и др. За да се тества използваемостта възможно най-сериозно, прототипите се пускат в най-„твърдия“ режим – в уеб клиента, в интерфейса на Taxi, на монитори с ниска разделителна способност.
Функционалният модел на проекта в нотацията IDEF0 се разработва и съхранява в DSS.
На този етап екипът на проекта трябва да оцени възможно най-точно разходите за труд за изпълнение на проекта, следователно всички аспекти на проекта се обсъждат (и документират в DSS):

• Координиране на коректността на описанието на проекта в DSS (по-специално се следи дали всички задачи по предходните етапи на проекта са изпълнени).
• Какви нови обекти с метаданни (справочници, документи и т.н.) ще бъдат добавени към решението
• Какви промени ще бъдат направени в съществуващите обекти с метаданни
• Координиране на планове за обмен на данни с други решения (дали нови/променени данни ще участват в обмен на данни с други приложения и ако да, как точно)

Ако всички са доволни от разходите за труд, се прави презентация (по материалите на проекта от DSS) на всичко, което е направено по проекта, за да се идентифицират възможно най-много нюанси преди започване на разработката.
И развитието започва!

Точка 4. Съгласуване на разработеното решение

Решението е разработено, изготвена е презентация (във формат PowerPoint). Често се провежда среща лице в лице с демонстрация на „на живо“ на разработеното решение.
Ако проектът е публичен (публикуван в списъка с планове, достъпни за партньорите на уебсайта на 1C), тогава презентацията се публикува на форума на партньорите в секцията ERP, така че всички заинтересовани партньори да могат да се запознаят и да изразят своите коментари.

Точка 5. Тестване и одит на проекта

В края на основната разработка се провеждат ръчни функционални тестове. Тестерите, като пълноправни членове на екипа, участват във всички етапи на проекта и имат разбиране за функционалността на проекта и работните сценарии. Тестерите също оценяват новата функционалност спрямо нашите стандарти за използваемост. Тези стандарти (включително стандарти за кодиране и стандарти за разработка на интерфейс) се публикуват в ресурс, достъпен за партньори и регистрирани потребители на уебсайта на 1C.
Кодът на проекта преминава през процедурата за преглед на кода. Прегледът на кода в ERP се извършва от членове на друга проектна група; прегледът на кода е задължение, което всички разработчици на ERP екипа имат на свой ред. Ако се открият проблеми в кода, в DSS се регистрират грешки, които трябва да бъдат коригирани преди преминаването на точка 5.
Актуализацията се проверява за нова версия от предишната (последната версия, която е пусната в момента).
И така, проектът е готов, тестовете са преминати, време е да качите кода в основното хранилище (преди това цялата разработка се извършва в отделно хранилище за технически проекти). На този етап приключва и писането на референтни материали за новата функционалност (препратката се съхранява в DSS).
В края на етапа (тестовете преминаха и референтните материали са готови), проектът се качва в основното хранилище; след това се извършва селективно регресионно тестване в свързани области - трябва да се уверим, че не сме нарушили нищо от съществуващата функционалност.

Точка 6. Край на проекта

Затваряме проекта в DSS и му присвояваме статус „Завършен“.

Издадена версия

Приблизително един месец преди пускането на нова версия се налага мораториум върху качването на нови проекти в основното хранилище (продължава развитието на техническите хранилища на проекти); тези проекти, които не са имали време да приключат до този момент, се прехвърлят в друга версия.
През този месец се извършва регресионно тестване; промените в кода са разрешени само за коригиране на грешки, въведени в тази версия. Невъведените грешки (тези, които бяха възпроизведени в предишни издания), до началото на регресионното тестване, обикновено почти всички са коригирани; същите грешки, които остават, се пренасят в следващата версия. Основната задача на регресионното тестване е да гарантира, че качеството на продукта не се влошава.
Както вече споменахме, същият DSS се използва като средство за проследяване на грешки.

Коригиращи конструкции

На всеки две седмици пускаме корекции на версии; днес е 2.1.3.x, след пускането на 2.2.1 ще бъдат пуснати 2 фикс билда - 2.1.3.x и 2.2.1.x. Отнема ни по-малко от две седмици от подаването на грешка до появата в версията за корекция; Нашата статистика показва, че средното време от клиент да се свърже с поддръжката на ERP с грешка до пускането на корекция в корекция днес е 9 дни.

Разклонено развитие

В груповата работа по ERP се опитваме да използваме инструментите, предоставени ни от платформата 1C:Enterprise. Конфигурациите се съхраняват в хранилището за конфигурации и когато новата функционалност е проверена в клон, се използва стандартният механизъм за доставка и поддръжка. Всички операции са максимално автоматизирани; ако обектите са променени само от страна на разработчика, кодът се обединява без участието на програмиста. Ако е необходима намеса на разработчика за сливане на източници, обикновено използваме вградените възможности на платформата. Но има и възможност за извикване на инструменти за разлика/сливане на трети страни от инструменти на платформата (например или Araxis). Между другото, тази функция - извикване на инструменти за сравнение/сливане на трети страни - беше добавена към платформата по искане на екипа за разработка на ERP.

разни

При разработването на нова функционалност използваме версията на платформата, която ще бъде налична към момента на пускане на новата версия на ERP (днес това е платформа 8.3.8).
Това е възможно поради факта, че платформата е много активна в поддържането на съвместимост с предишни версии. Веднага щом се появи нова платформа, преминаваме към нея, но деактивирането на режима на съвместимост не става веднага. Това се дължи на три причини:

1. Искаме да „шокираме“ потребителите по-малко, така че се опитваме да изключим режима на съвместимост през „тихи“ периоди, а не когато всички потребители, например, подават отчети.
2. Обикновено деактивирането на съвместимостта е свързано с различни промени в конфигурацията. Те трябва да бъдат планирани, отнема им време за изпълнение.
3. ERP е конфигурация, която в момента включва 10 библиотеки. Можете да деактивирате съвместимостта само когато всички библиотеки също го правят.

Библиотеките могат да се пишат отделно. Библиотеката е специално написана конфигурация, която включва функционалност, която трябва да работи по същия начин в различните ни крайни приложни решения. Интегрирането на библиотеки се извършва с помощта на вече споменатия механизъм на платформата "Configuration Delivery". Библиотеките са разделени на публикувани (тези, които публикуваме и които разработчиците на трети страни могат да използват в своите приложни решения) и вътрешни (които не публикуваме отделно – само като част от приложните решения). По-голямата част от библиотеките са публикувани.
ERP включва 10 библиотеки, разработени от други екипи. Техният код не се променя от разработчиците на ERP екипа.

Списък с библиотеки

1. Библиотека на стандартните подсистеми.
   Основна функционалност - права за достъп, печат, поща и др. Включен в повечето приложни решения.
2. в ERP
3. Библиотека за поддръжка на интернет потребители.
   Информиране за пускането на актуализации, свързване с тях. поддръжка, изтегляне и инсталиране на актуализации
4. Библиотека за електронно управление на документи.
   Обмен на електронни документи с контрагенти (включително правно значими EDI), DirectBank (директен обмен с банки), обмен с уебсайтове (CMS).
5. Библиотека за интеграция с EGAIS.
   Обмен с Единната държавна автоматизирана информационна система за счетоводни операции за търговия на дребно с алкохол.
6. Библиотека по регулирано счетоводство.
   "Piece" 1C: Счетоводство в ERP. Като цяло регулираното счетоводство в ERP в методологическата част (с някои малки изключения) е подобно на 1C: Счетоводство, но прилагането му е различно и се извършва самостоятелно. От 1С: Счетоводство приемаме счетоводни отчети и отчети за някои данъци.

Как тестваме 1C: ERP

След създаване на три решения от ERP – KA, UT, UT Basic – за проверка на коректността и на четирите решения, извършваме статичен и динамичен анализ на получените конфигурации.
Частичен статичен анализ се извършва всеки път, след като основните конфигурации на KA, UT, UT се създават от ERP хранилището и се качват в техните собствени хранилища (този процес се извършва два пъти на ден).
По-подробен статичен анализ се извършва с помощта на конфигурацията на 1C:Automatic Configuration Checker (1C:APK). По-специално, 1C:APK проверява:

• Съставът на ролите. Например, той проверява дали правата за четене на всички константи са включени в ролята "Основни права".
• Съответствие на кода с приетите стандарти. За голям брой стандарти за разработка на приложения (от които имаме няколкостотин) са написани процедури за анализиране на кода за съответствие с тях. Например, че пълните присъединявания не се използват в заявките или че низовете, които се показват в интерфейса, са правилно локализирани.
• Специфични проверки, свързани с особеностите на разработването на ERP
  Например, проверка дали всеки обект на приложение е включен само в една от подсистемите "UT, KA, UE обекти", "KA, UE обекти" или "UE обекти"

Анализът на динамичния код включва по-специално регресионно тестване, при което се изпълняват следните операции (и резултатите от операциите се проверяват спрямо последния предишен успешен тест):

• Отваряне на всички формуляри
• Обмен на данни с други приложни решения (например с 1C: Enterprise Accounting)
• Отражение на осчетоводени документи в счетоводството. Проверява се дали след осчетоводяването на документа в референтната база данни резултатът от отразяването му в счетоводството не се е променил.
• И т.н.

За регресионно тестване използваме от 10 до 20 бази данни с различни размери (от 15 GB до 70 GB) и различни специфики на съдържанието.
На същите основания тестваме актуализацията до нова версия от предишната, за да се уверим, че актуализацията върви а) правилно и б) в разумен срок.
При актуализиране на базата данни 1C има две основни стъпки:

1. Основното време е актуализиране на данни в многопотребителски режим. Приложението подготвя данни за актуализиране във фонов режим, потребителите могат да продължат да работят със системата, но производителността на системата може да бъде намалена и някои функции могат да работят по ограничен начин. Обикновено актуализирането до нова версия се извършва през уикендите (когато активността на потребителите е минимална).
2. Минимално време - актуализиране в изключителен режим. Когато всички данни са подготвени във фонов режим, е време да промените структурата на базата данни. За да направите това, базата данни се прехвърля в изключителен режим, когато потребителите не могат да работят със системата. Скоростта на актуализиране е изключително важна за нашите потребители.

В близко бъдеще планираме да разширим зоната за автоматично тестване, за да покрием максимален брой сценарии с тях.

Заключение

ERP е един от най-големите ни продукти. Опитваме се да използваме съвременни и усъвършенствани методи в неговото разработване, както и да създаваме нови методи и инструменти, за да, от една страна, бързо да го развием, а от друга, да осигурим високо качество на разработеното решение.

Етикети:

Добави тагове

1. Права на достъп.

Всъщност всичко е много просто. В 1C по подразбиране всичко непозволено е забранено. Има само един субект, отговорен за достъпапотребител на каквато и да е функционалност или данни. Това образувание се нарича "Право на достъп". Тя е единствениятелемент, отговорен за достъпа до определен режим на работа, директория, атрибут....

Броят на видовете права за достъп се определя предварително от платформата. Цялата платформа има две основни групи права за достъп. Общо за цялата система права за достъп до механизмите на платформата, отговарящ за достъпа до определени режими на платформата (Администрация, Ексклузивен режим, Тънък клиент, Интерактивно отваряне на външни отчети....). И разрешения за обект, което ви позволява да работите с различни конфигурационни обекти. Техният брой зависи от типа на конфигурационния обект. Например, директорията има 16 различни типа достъп (Четене, Добавяне, Промяна, Изтриване....). За информационния регистър има само пет вида достъп. Всички тези права могат да бъдат зададени само на ниво на цялата директория. Можете също да ограничите достъпа на ниво атрибут. Но в този случай са налични само част от видовете права (за директории това са правата за преглед и редактиране).

Всички права за достъп са взаимосвързани и зависят едно от друго. Има по-високи и по-ниски нива. Не можете да предоставите право на по-ниско ниво, ако потребителят няма право да извършва действия от по-високо ниво.

Обмисли права за достъп до директория.В тази диаграма можете да видите, че повечето права са уточнения на по-общи права. Ако Right1 е напълно разположен на диаграмата вътре в правоъгълника на друго Right2, тогава Right1 не може да бъде издаден без издаване на Right2. Най-често срещаното право е правото „Прочетете“. Ако липсва правото за четене, тогава всички други права са недостъпни. Ако правото на добавяне не е налично, тогава правото на интерактивно добавяне не може да бъде зададено. Но, системата от права не може да се нарече пълноценна йерархия.Например, правото "Редактиране" може да бъде предоставено само ако имате правата "Преглед" и "Промяна". Но е възможно да се даде "View" без "Change" или "Change" без "View".

Правото на достъп е най-малката единица за достъп. Целият контрол на достъпа се свежда до издаване на правилния набор от права на потребителя.Останалите обекти (роли, групи за достъп) са само допълнителна връзка, която служи за групиране и по-удобно издаване на права за достъп.

2. Роли – механизъм за предоставяне на права за достъп

Нека да разгледаме как работи предоставяне на права за достъп на потребителя.За удобство при издаване на права за достъп в платформата 1C, специален "Roly" механизъм. Това е слой между потребителите на информационната база и правата за достъп. Всяка роля съчетава набор от права за достъп, чието присвояване има смисъл само по едно и също време. Например, в ролята "Прочетете информация за контакт" е логично да се комбинират наборите от права, отговорни за свързани директории, с информация за контакт. Най-простият начин да зададете роля на потребител е отваряне на потребителската карта на IB в конфигуратора и поставяне на отметка в квадратчетата до ролите, от които се нуждае потребителят. Това е универсален начин и работи във всякакви конфигурации. С усложняването на конфигурациите и увеличаването на броя на ролите обаче стана доста трудоемко. Следователно в настоящите стандартни решения има допълнителен слой между потребителя на информационна сигурност и ролите. Този слой се реализира във формата подсистема "Контрол на достъпа". Позволява ви да комбинирате роли в по-големи обекти - "Профили" и да зададете на потребителя не отделни роли, а профили, съдържащи набори от няколко роли.

Помислете за схемата за присвояване на права за достъп на потребители, използвана в повечето типични конфигурации. В опростена форма тя може да бъде представена по следния начин. Въвеждат се нови субекти "Профил за достъп"и "Група за достъп". Всеки профил за достъп включва няколко роли. И на всеки потребител се присвоява една или повече групи за достъп. След това всяка група за достъп е свързана с профил за достъп. В резултат на това получаваме възможност да посочим за потребителя не просто роли, а набори от роли в зависимост от изпълняваните от него функции.

От техническа гледна точка тази система за издаване на права се реализира с участието на две стандартни подсистеми. Подсистемата "Управление на достъпа" се използва за конфигуриране на асоциирането на групите за достъп с ролите, предварително дефинирани в конфигурацията. Подсистемата "Потребители" се използва за създаване на връзки между потребители на IS и групи за достъп до конфигурация.

3. "Логика на разрешенията" като правило на пресичане на роли.

Важно е да се разбере, че в 1C общата логика на контрола на достъпа е логика за разрешение. В платформата 1C като цяло няма ограничения за достъп. Има само механизми издаване на достъп. По подразбиране достъпът до всички данни е отказан и настройката за достъп е да даде на всеки потребител правата, от които се нуждае. Това означава, че ако някаква роля дава на потребителя правото да преглежда документите "Продажби на стоки", тогава това право няма как да бъде отнетодруги роли или всякакви други механизми за платформа и конфигурация. Първоначално можете да дадете не пълен достъп до директорията, но да филтрирате данните, до които даваме достъп с помощта на RLS. Но ако достъпът вече е предоставен, той вече не може да бъде отнет от други роли.

Ето защо, когато ограничавате достъпа на потребителя до директорията по роли, е много важно да проверите дали на потребителя не е присвоена друга роля към същата директория. В противен случай първата роля ще даде необходимия достъп, който втората не може да откаже.

Платформата има възможност да дава на потребителя допълнителни права за продължителността на определена операция. Тази функция се нарича "Привилегирован режим". Той позволява на потребителя да извършва действия върху данни, които не са му достъпни. В платформата обаче няма възможност дори временно да се намалят правата на потребителя.

4. Индиректен контрол на достъпа.

Има отделни механизми, които макар и да не са предназначени пряко да контролират достъпа, косвено го засягат и могат да се използват за допълнителни ограничения. Нека да разгледаме основните им характеристики.

4.1. функционални опции.

Системата за контрол на достъпа понякога се нарича механизъм функционални опции. Това не е напълно вярно, тъй като функционалните опции не влияят по никакъв начин на достъпа до данни. Това е чисто интерфейсен механизъм,проектиран да опрости интерфейса за потребителя. Появи се в платформа 8.2 в резултат на усложняването на функционалността на конфигурацията. Функционалните опции са предназначени да се скрие от интерфейсафункционалност, която не се използва в тази конкретна компания или този конкретен потребител. Механизмът засяга само показването на данни. Командите изчезват от интерфейса, а детайлите, които са деактивирани от функционалните опции, са скрити във формулярите. При което потребителят има достъп до всички тези команди и подробности. Може да работи със скрити данни програмно, използвайки обработка без никакви проблеми.

Можете да прочетете повече за работата с функционални опции на ITS

4.2. RLS (Защита на ниво на запис)

Всички изброени по-горе механизми засягат предоставянето на достъп до обекти като цяло. Към директории, документи, подробности за указатели. Правата за достъп влияят на достъпа до обекти, функционалните опции влияят върху показването на обекти в интерфейса. Често има задача да позволи на потребителя да получи достъп до данните на директория или документ. Но не на всички данни, а само на някои от тях. Например, разреши достъп до документи за внедряване само за една организация.

Има допълнителен механизъм за настройка на това разрешение. RLS (Защита на ниво на запис). Както подсказва името, този механизъм за контрол на достъпа е на нивото на конкретни записи в таблицата. Ако правата за достъп дават достъп до таблици като цяло (директории) или колони от таблици (подробности), тогава RLS определя конкретни редове от таблици (записи), с които потребителят може да работи. Позволява ви да дефинирате данните, които са достъпни за потребителя.

Когато анализирате този механизъм, винаги си струва да го помните RLS не е механизъм за отказ на достъп. Той е механизмът филтриране на издаване на достъп. Тези. RLS не засяга правата на потребителя, той е филтър, който ограничава издаването на права. RLS засяга само тази конкретна връзка "Роля" - "Право на достъп", в която е регистрирана. И не засяга правата за достъп, предоставени от други роли. Например, ако една роля позволява достъп до документи само от Организация1, а друга роля позволява достъп до документи от Склад1, тогава в резултат потребителят ще има достъп до всички документи, които определят Организация1 ИЛИ Склад1. Следователно, ако на потребителя са дадени няколко роли, тогава филтър, използващ RLS, трябва да бъде зададен във всяка роляи за двете области (по организация и склад). В типичните решения тази задача обикновено се решава чрез създаване на една роля, в която се регистрират всички възможни RLS филтри. След това тази роля се присвоява на всички потребители, работещи с тези директории. Той също така контролира, че потребителят няма достъп до други роли, които съдържат право на достъп до документи с ограничен достъп.

Също така си струва да се отбележи, че RLS филтрите могат да се прилагат не към всички възможни видове достъп до данни, а само към типове достъп от най-високо ниво. Например, за директории от наличните шестнадесет типа достъп, RLS филтрите могат да се прилагат само към четири основни: Четене, Промяна, Добавяне и Изтриване. Това означава, че не можем например да дадем на потребителя правото „Промяна“ без филтър за възможност за програмна работа с всякакви документи и правото „Редактиране“ с филтъра RLS за организация за интерактивна работа едновременно. Ако искаме потребителят да може да редактира документи с RLS филтър, трябва да приложим общ филтър на най-горното ниво „Промяна“ или „Прочетене“.

Като се има предвид цялостната сложност на механизмите, обикновено е доста трудно да се разбере какво точно е достъпно за конкретен потребител с типична конфигурация. За проверка на предоставените права в типични конфигурации има много удобен отчет, който се извиква "Разрешения". Той анализира всички права, предоставени на потребителя, и показва окончателния списък с права, издадени от всички групи за достъп, като се вземат предвид RLS филтрите.

4.3. Разделяне на данни.

Друг механизъм, който засяга достъпа до данни е споделяне на данни. Този механизъм е предназначен да поддържа няколко независими бази данни в една физическа база данни, които имат обща конфигурация и общи директории. В някои много ограничени случаи този механизъм може да се разглежда като контрол на достъпа. Когато е активиран, всеки потребител може да работи само в една от своите независими бази данни, но в същото време да използва общи данни.

В някакъв общ смисъл този механизъм може също да се счита за филтър за данни и специален случай на изпълнение на RLS. За разлика от RLS, разделянето е много по-твърд механизъм. И благодарение на тази твърдост, разработчиците имат техническата възможност да използват допълнителни индекси, за да направят такова филтриране без забавяне, присъщо на RLS.

Всъщност RLS е само допълнителни борби, добавя автоматично към всяка заявка към база данни. Разделянето на данни е добавяне на разделителкъм всички разделени таблици и техните индекси, включително и клъстерираната. Данните се групират в контекста на разделителя, т.е. физически преразпределени на дискав отделни групи за всяка стойност на разделителя. Благодарение на това всеки потребител работи само със собствените си данни и сървърът не трябва физически да сканира цялата таблица с всяка заявка. Достатъчно е да видите само областта с данни на текущия дял.

Но именно поради това физическо преразпределение на данните, когато работи пълен потребител, който няма филтър по стойности на разделители, всички заявки са много, много бавни. Без стойност на разделител пълното използване на индекси не е възможно, така че количеството данни, физически прочетено от диска и обработено при всяка заявка, може повишаване на поръчките. Съответно, в действителност, разделянето има смисъл само ако всички потребители, които постоянно работят в базата данни, ще работят само в своята област.

4.4. Програмен код.

Може би най-универсалният начин за задаване на допълнителни ограничения е програмен код. Те могат да засегнат всякакви механизми на платформата. Например, за да ограничи достъпа до документи, разработчикът може да добави филтър към формуляра за списък с документи, към формуляра за избор и може програмно да провери възможността за преглед на документни данни при отваряне на конкретен формуляр за документи. Разработчикът в своите отчети може да приложи филтър при избор на данни.

Програмният код обаче няма как да се ограничават правата като цяло чрез конфигурация. Най-много, което разработчикът може да направи, е да вгради ограничения в специфични индивидуални механизми за извличане на данни. Поради факта, че 1C използва обектен модел за работа с данни, може да се гарантира, че програмният код защитава данните от модификация, добавяйки необходимите проверки към обектния модул. Но разработчикът не може напълно да гарантира, че потребителят определено няма да може да получи информация за документи за внедряване на други хора чрез други отчети или обработка.

Този принцип се използва например в. Свързвайки се с конфигурацията, разширението добавя потребителски ограничения и проверки към всички директории и документи. Той филтрира данните, показвани на потребителите в списъци, проверява достъпа при преглед или промяна на данни. Гарантира, че забранените данни не могат да бъдат променяни. Но не може да филтрира данни в отчети или заявки.

Винаги има опции за получаване на забранени данни по заявка, собствена обработка или доклад. Възможно ли е много стриктно да се ограничи списъкът с конфигурационни функции, използвани от потребителя, и да се добави отделен филтър към всеки механизъм (формуляр, обработка, отчет, заявка), разрешен на потребителя.

4.5. Сравнение на опциите.

Нека се опитаме да сравним накратко разглежданите опции за допълнително ограничаване на данните.

Как да включите	Какво ще се случи
Функционални опции- интерфейсен механизъм за скриване на функционалност
1. Добавете място за съхранение за функционална опция: константа, атрибут на справочник или ресурс на информационен регистър. 2. Добавете функционална опция към конфигурацията и посочете предварително създаденото място за съхранение в нея. 3. Посочете в свойствата на функционалната опция нейния състав, маркирайте всички конфигурационни обекти, които ще зависят от нея. 4. Разрешете използването на функционалната опция в корпоративен режим.	1. Всички обекти, включени във функционалната опция, вече няма да се показват в командния интерфейс. 2. Всички полета, скрити от опцията, ще изчезнат във формуляри и отчети.
RLS (Защита на ниво на запис)- допълнителни филтри за разрешени права за роля
1. Регистрирайте RLS филтри във всяка потребителска роля за всяко от правата, които трябва да бъдат ограничени. Забележка: В Enterprise Mode не се изисква действие. Филтрите ще се прилагат автоматично.	1. Конфигурираният филтър ще бъде добавен към всяка заявка към IB. 2. Данни, които не отговарят на RLS филтъра, не могат да бъдат получени по никакъв начин: те няма да се показват във формуляри, отчети; няма да бъде избран от никакви заявки.
Разделяне на данни- поддържане в една физическа база данни на няколко независими
1. Добавете общ атрибут към конфигурацията, който определя състава на споделените данни. 2. Добавя два параметъра на сесията: за флага за използване и текущата стойност на разделяне на данни. 3. Добавете програмен код, за да активирате разделянето на данни и попълнете текущата стойност на разделителя.	1. Веднага след добавяне на възможността за разделяне на данни към конфигурацията, таблиците, за които е добавена възможността за разделяне, ще бъдат физически възстановени. Ще бъде добавено поле "Разграничител", за да се съхрани стойността на разделителя. Всички индекси на таблици ще бъдат възстановени. Разделителното поле ще бъде добавено към тях като първо поле. 2. След включване на разделянето. Абсолютно всички заявки към IS ще бъдат филтрирани по стойността на разделителя. Когато записвате каквито и да е данни, стойността на разделителя ще бъде автоматично попълнена според стойността на параметъра на сесията.
Програмен код- всякакви допълнителни ограничения за точки
1. Добавете кода за прилагане на необходимите ограничения към конфигурацията.	1. Ще направи точно това, което е написано. Забележка: кодът не засяга конфигурацията като цяло, а само конкретния механизъм, за който е написано действието

5. Резултати.

Всеки метод за задаване на ограничения има своите плюсове и минуси. От гледна точка на технологията, най-правилният начин е компетентно разделение на роли. За да филтрирате наличните данни, най-надеждният начин е да използвате RLS. Именно за тази задача е проектиран механизмът. Ограниченията за точки са най-лесни за изпълнение с помощта на код. Функционалните опции и споделянето на данни са доста специфични механизми, които не са предназначени да ограничават достъпа. Въпреки че в някои случаи те могат да се използват за това.

Обект 1c "Функционални опции" - проектиран да подчертае функционалността в приложното решение, която може да бъде активирана (деактивирана) по време на внедряване, без да се променя (заедно с подсистемите, те образуват интерфейса на тънък клиент 1C). Те са част от механизма за функционални опции.

Функционални опции Механизъм включва два обекта на метаданни:

1. Функционална опция;
2. Параметри на функционалните опции.

| Повече ▼

Функционална опцияе обект на метаданни, който може директно да повлияе на състава на интерфейса на приложението (ако функционалната опция съхранява стойността си в булев атрибут). С помощта на обекти от този тип можете да скриете елементи, които се отнасят до недостъпна функционалност. Например, опцията за отчитане на валута може да скрие Валути, полето Валута от, колоната Валутна сума от отчети.

Източникът на стойността на функционалната опция е обектът с метаданни, избран като свойство Storage , например може да бъде .

В случай на съхраняване на стойността на функционална опция в атрибут на директория или ресурс, се изисква допълнителна информация, която показва как точно да изберете стойността на опцията. За тази цел е предвиден отделен обект с метаданни − Опции за функции Параметри.

Можем да кажем, че параметрите на функционалните опции са координатните оси на пространството от стойности на функционалните опции. Освен това, един параметър на функционалните опции може да определи стойността на "своята" координатна ос едновременно за множество функционални опции.

[Крия]

Функционалните опции могат да засегнат:

1. към потребителски интерфейс:
   • глобален ;
   • реквизити (включително колони с реквизити от формата като напр Таблица със стойностиили Дърво на стойността);
   • команди за формуляри;
2. за отчети, реализирани с помощта на система за съставяне на данни;
3. върху алгоритми, написани на вградения език - възможно е да получите стойностите на функционалните опции от вградения език и да ги използвате при различни условия, например, за да намалите количеството изчисления (вижте например ).

ВНИМАНИЕ!Ако клиентското приложение работи с файловата версия на информационната база през уеб сървъра, тогава промяната на функционалната опция ще промени потребителския интерфейс само след рестартиране на уеб сървъра (рестартирането на клиентското приложение няма да промени потребителския интерфейс).

Свойства на функционалните опции на 1C

• Съхранение - поле, в което трябва да изберете обект с булев тип. Като правило се използват константи.
• при получаване - флагът е отговорен за възможността за получаване на стойността на функционалната опция в привилегирован режим.
• Композиция - списък с обекти и атрибути на обекти, видимостта на които се включва / изключва, когато функционалната опция е изключена / изключена (да се контролира с помощта на управлявана форма).

Например, в зависимост от условията на конкретна реализация, можете да предвидите деактивиране на отчитането на стоки по складове, така че при регистриране на документи за получаване на стоки полето Склад да не се показва във формуляра на документа.

Характеристики на използването на функционални опции на 1C:

1. Функционалните опции могат да имат стойности от произволен тип (не непременно булеви).
2. Когато добавяте нова константа за използване на функционална опция, не забравяйте да я включите в съответната подсистема и да й зададете разрешения.
3. Работата с функционални опции е достъпна от вградения език, благодарение на който разработчикът може да създаде свои собствени алгоритми за стойностите на функционалните опции.
4. Командата на командния интерфейс ще бъде изключена от командния интерфейс, ако опцията за функция е деактивирана:
   • атрибут, който е команден параметър;
   • типа на командния параметър (ако типът на командния параметър е съставен, тогава командата става недостъпна, когато всички типове параметри са деактивирани).

ВНИМАНИЕ!Функционалните опции и техните параметри не оказват влияние върху състава на базата данни: всички таблици и полета присъстват в базата данни, независимо от състоянието на функционалните опции.

Влияние на функционалните опции върху детайлите и командите на формата:

1. тип управляван формуляр<Вид>Предмет ( DirectoryObject, DocumentObject и т.н.) ще бъдат деактивирани, ако съответният обект е деактивиран от функционалната опция. Само тези функционални опции, които нямат параметри, се анализират.
2. Основният атрибут на типа управляван формуляр DynamicListще бъде деактивиран, ако функционалната опция деактивира конфигурационния обект, който е посочен като основна таблица на динамичния списък. Само тези функционални опции, които нямат параметри, се анализират.
3. Атрибут на форма на референтен тип е деактивиран, ако конфигурационният обект, който формира този тип, е деактивиран от функционална опция. Атрибутът на формата на съставен тип е деактивиран, ако функционалните опции деактивират всички типове компоненти.
4. Таблицата на формуляра ще бъде деактивирана, ако показва данните от атрибут на формуляр, деактивиран от функционална опция.
5. В диалоговия прозорец за избор на тип няма типове (например за полета за въвеждане, свързани с атрибути от съставен тип), ако конфигурационните обекти, които формират тези типове, са деактивирани от функционална опция. Информацията за типове, деактивирани от функционалните опции, се кешира от страна на клиента и се изчиства след 20 минути или по време на извикване на метод UpdateInterface().

ВНИМАНИЕ!За разлика от командния интерфейс, стойностите на параметрите на функционалните опции се задават само за конкретен екземпляр на формуляра.

Създаване на параметър за функционални опции

Параметърът на функционалната опция се създава с помощта на конфигурационен обект 1C "Параметри на функционални опции".

[Крия]

Това може да стане в прозореца за конфигурация чрез добавяне на нов обект.

Свойства на параметрите на функциите:

• Използване - задава набор от обекти, чиито стойности ще определят как трябва да бъде избрана стойността на функционалната опция. Списъкът на наличните обекти включва речници и измерения на информационния регистър. За всеки параметър от функционални опции в този списък можете да изберете една директория (от целия списък с директории) и едно измерение на всеки информационен регистър.

ВНИМАНИЕ!Не можете да използвате един и същ обект с метаданни в повече от един параметър на функцията.

Функционални опциие една от новите функции на платформата 1C:Enterprise 8.2. Смисълът на тяхното използване се крие във факта, че те ви позволяват да персонализирате потребителския интерфейс в съответствие с настройките на функционалните опции, да зададете видимостта на детайлите във формуляри. Освен това разработчикът има възможност да внедри програмен код, чието изпълнение зависи от състоянието на функционалната опция.

Нека създадем функционална опция, която ви позволява да активирате и деактивирате поддръжката на заплати в конфигурацията. С негова помощ можем бързо да скрием онези части от интерфейса, които са свързани с решаването на изчислителни проблеми. Функционална опция сама по себе си не съхранява никаква стойност, която позволява да бъде активирана или деактивирана. Обикновено константа се използва за съхраняване на състоянието на функционална опция, въпреки че може да бъде обвързана и с друг обект, например с атрибут на някакъв обект.

Нека създадем нова константа и да я наречем Счетоводство Заплата, тип - булев. Нека включим константа в подсистемата администрацияи във форма на константи, за да можем да го редактираме. Освен това, под формата на константи, ще зададем манипулатора AfterWrite в следната форма:

&При клиентската процедура AfterWrite(WriteParameters) UpdateInterface(); EndProcedure

Значението на използването на командата UpdateInterface()е да актуализирате, преначертаете интерфейса, след като промяната на константата, свързана с функционалната опция, влезе в сила. В противен случай, за да влязат в сила промените, ще трябва да рестартирате конфигурацията.

Нека създадем нова функционална опция, наречете я Счетоводство Заплата, в раздела Основен, в параметъра Съхранениепосочваме новосъздадената константа, фиг. 7.23. Включете функционална опция в подсистема администрация.

Ориз. 7.23.

Сега да отидем в раздела на прозореца за настройки на функционалните опции Съединениеи изберете всичко (Фигура 7.24), което се отнася до заплатите. Ако някакви обекти, например директории, принадлежат към различни части на конфигурацията, ние няма да ги маркираме, в противен случай, когато функционалната опция е изключена, те ще "изчезнат" от интерфейса.

Ориз. 7.24.

Избор на подсистема Подготовка на заплатив този случай не води до автоматичен избор на всички обекти, включени в подсистемата. Когато избираме, имаме предвид само скриване или показване на раздела на командния интерфейс Подготовка на заплати.

Като стартираме системата в потребителски режим, можем да активираме и деактивираме видимостта на обекти, свързани с подсистемата за заплати на нашата конфигурация, като просто зададем или премахнем отметката от флага на константата Счетоводство Заплата.

По-трудно случай на употребафункционални опции е да зададете видимостта на отделни елементи на формата в случай, че стойността на функционалната опция се съхранява в атрибута на някакъв обект.

Ще направим промени в конфигурацията, по-специално в директорията Физически лицадобавете булев атрибут Има опит в областта на човешките ресурсии го поставете върху формата на елемента директория.