Изпратете тази статия на моя имейл

В тази статия ще разгледаме как да индексираме заплатите в 1C ZUP за служители на организация. Ръководейки се от член 134 от Кодекса на труда на Руската федерация, който гласи, че работодателят трябва да осигури увеличение на заплатите на служителите, тъй като цената на стоките и услугите периодично се увеличава. Ако организацията се финансира от бюджета, тогава индексирането се извършва и в съответствие с Кодекса на труда на Руската федерация, различни актове или колективен договор.

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

За да извършите индексиране на заплатите в 1C ZUP, трябва да изпълните редица стъпки в програмата. Първото нещо, което трябва да направите, е да проверите дали необходимите настройки са зададени. В секцията „Настройки“ изберете елемента „Изчисляване на заплатите“. Изисква се квадратче за отметка, което показва, че приходите са индексирани в базата данни.

Трябва също така да се уверите, че документите за персонала се поддържат и историята се поддържа. За да проверите наличността на тези опции, трябва да изберете елемента „Човешки ресурси“ и да следвате връзката „Настройване на таблица с персонал“.

За да се индексира в програмата, започвайки с версия 3.1.3, има специален документ „Промяна на таблицата с персонала“, който се намира в раздела „Персонал“. Създаваме нов документ и попълваме датата, от която влизат в сила промените и организацията. За попълване на таблицата. части, щракнете върху бутона „Промяна“ и добавете необходимите графични единици.

Като щракнете върху бутона „Още“ вдясно, като изберете „Показани индикатори“, можете да използвате квадратчета за отметка, за да контролирате видимостта на индикаторите и да показвате само тези, които са необходими в документа. След това кликнете върху бутона „Попълване на индикатори“ и в прозореца, който се отваря, задайте коефициента за индикатора „Заплата“ на 1,1.

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

Ако имате въпроси по темата за индексирането на заплатите в 1C ZUP, попитайте ги в коментарите под статията, нашите специалисти ще се опитат да отговорят на тях.

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

След което ще бъде създаден готов документ. Моля, обърнете внимание, че квадратчето „Счита се за индексиране на приходите“ трябва да бъде отметнато.

След това изпълняваме документа. При изплащане на заплати за следващия месец заплатата се изчислява, като се вземе предвид индексацията.

Екип от опитни 1C програмисти:

От 5 минути време за реакция до спешни задачи, дори през почивните дни и празниците.

30+ програмисти с до 20 години опит в 1C.

Правим видео инструкции по изпълнени задачи.

Комуникация на живо чрез всякакви месинджъри, удобни за клиента

Следене на изпълнението на вашите задачи чрез нашето специално разработено приложение

Официални партньори на компанията 1C от 2006 г.

Опит с успешна автоматизация от малки фирми до големи корпорации.

99% от клиентите са доволни от резултатите

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

Този вид ускорение просто не може да бъде постигнато с хардуер.Следователно на тази тема трябва да се обърне голямо внимание.

Често, за да ускорите заявка, трябва да създадете свой собствен индекс и има няколко различни начина да направите това.

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

Настройване на индекси с помощта на стандартни инструменти на платформата

Урокът показва какви индекси всъщност се създават за обекти на ниво СУБД.
Не всичко в тази тема е толкова очевидно, колкото може да изглежда на пръв поглед. В крайна сметка за редица обекти има функции за създаване на индекси.
Ще разгледаме всички подробности в това видео.

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

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

Създаване на индекс за измерения на регистъра

Индексирането на първото измерение на регистрите има няколко нюанса.
Видеото показва какви индекси се създават за регистрационни измервания. Ситуацията на индексиране на първото измерение на регистъра също се разглежда.

Печат (Ctrl+P)

„Копирах този материал от ITS диска за разглеждане и възможна дискусия по темата за оптимизиране на заявки https://its.1c.ru/db/metod8dev#content:5842:hdoc

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

Основните причини за неоптималната производителност на заявките

1. Обединява се с подзаявки

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

Пример за неоптимална опасна заявка, използваща съединение с подзаявка от дясната страна на съединението, използваща подзаявка:

ИЗБЕРЕТЕ . . . ОТДокумент . Продажба на стоки и услуги ЛЯВА ВРЪЗКА ( ИЗБЕРЕТЕ ОТИнформационен регистър . Граници КЪДЕ . . . ГРУПА ОТ . . . ) ОТ . . .

За да оптимизирате заявка, трябва да я разделите на няколко отделни заявки (според броя на подзаявките, използвани в съединенията). Препоръчва се тези заявки да се поставят в една пакетна заявка.

// Създаване на временен мениджър на таблициМениджърVT = НовМениджър на разписание ; Заявка = НовЗаявка ; Заявка . Мениджър на разписание = МениджърVT ; // Текст на пакетна заявкаЗаявка . Текст = " // Попълване на временната таблица. Заявка към лимитния регистър. | ИЗБЕРЕТЕ... | PUT Ограничения | ОТ Информационен регистър.Ограничения | КЪДЕ... | ГРУПИРАНЕ ПО... | ИНДЕКС ПО...; // Изпълнение на основната заявка с помощта на временна таблица ИЗБЕРЕТЕ... ОТ Документ за стоки и услуги LEFT JOIN Граници ОТ...;" внимание!В този пример е много важно да индексирате създадената временна таблица.

Всички полета, които се използват в условието за присъединяване, трябва да бъдат посочени като индексни полета.

2. Съединения с виртуални таблици Ако заявката използва връзка към виртуална таблица на езика за заявки 1C:Enterprise (например „ RegisterAccumulations.Products.Remains()

“) и заявката се изпълнява с незадоволителна производителност, се препоръчва извикването на виртуалната таблица да се превърне в отделна заявка и да се съхранят резултатите във временна таблица. Тоест, трябва да използвате същата препоръка, както в случай на присъединяване с подзаявка (вижте точка 1).

Факт е, че виртуалните таблици, използвани в езика за заявки 1C:Enterprise, могат да бъдат разширени в подзаявки, когато се превеждат в SQL. Това е така, защото една виртуална таблица често (но не винаги) получава данни от множество физически СУБД таблици. Ако използвате съединение с виртуална таблица, то на ниво SQL в някои случаи може да се реализира като съединение с подзаявка. В този случай оптимизаторът на СУБД може да избере неоптимален план по същия начин, както при работа с подзаявка, използвана изрично в езика 1C:Enterprise.

3. Несъответствие между индексите и условията на заявката

Условията се използват в следните раздели на заявката:<условие>
ИЗБЕРЕТЕ... ОТ... КЪДЕ<условие>
ВРЪЗКА...ОТ<ВиртуальнаяТаблица>(, <условие>)
ИЗБЕРЕТЕ... ОТ<условие>

ИМАЩ

За всички тези условия, използвани в заявката, трябва да има подходящи подходящи индекси за оптимизиране на избора на данни по условие. Освен това подходящ индекс е този, който отговаря на следните изисквания:Изискване 1
. Индексът съдържа всички полета, изброени в условието;Изискване
2. Тези полета са в самото начало на индекса;Изискване 3

. Тези полета са в един ред, т.е. полетата, които не са включени в условието на заявката, не са „заклещени“ между тях;

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

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

Конфигурацията описва регистъра за натрупване Продукти в складове:

Фигура 1. Пример за структурата на регистъра за натрупване на стоки в складове

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

Нека да разгледаме няколко примерни заявки и да анализираме дали те могат да бъдат оптимално изпълнени с тази структура от данни.

Заявка 1

Заявка . Текст = „ИЗБЕРЕТЕ | ОТ , Номенклатура = &Номенклатура) КАТО Оставащи продукти в складове";

В този случай изискване 2 е нарушено в условието, че няма избор по първото поле на индекса (Склад). Такава заявка няма да бъде изпълнена оптимално. За да го изпълни, СУБД сървърът ще трябва да итерира (сканира) всички записи в таблицата. Времето за изпълнение на тази операция директно зависи от броя на записите в таблицата с остатъците от регистъра и може да бъде много голямо (и ще се увеличи с нарастването на количеството данни).

Опции за оптимизация:

Индексирайте измерението „Номенклатура“.
Поставете измерението „Номенклатура“ първо в списъка с измерения. Бъдете внимателни, когато използвате този метод. Възможно е да има други заявки в конфигурацията, които могат да бъдат забавени от този суап.

Заявка 2

В този случай е нарушено изискване 3. Между измеренията „Склад“ и „Качество“ в структурата на регистъра има измерение „Номенклатура“, което не е посочено в условието на заявката. Тази заявка също няма да може да се изпълни оптимално. Когато се изпълни, СУБД ще търси първото поле на индекса, но след това ще бъде принудена да сканира част от него. Сканирането ще доведе до увеличаване на времето за изпълнение на заявката и до блокиране на излишни записи в таблицата, тоест до намаляване на общата пропускателна способност на системата.

Опции за оптимизация:

Добавете условие за измерението „Номенклатура“ към заявката
Премахнете условието за измерението „Качество“ от заявката
Прехвърлете „Номенклатура“ от измервания към детайли
Разменете измеренията „Номенклатура“ и „Качество“.

Заявка 3

В този случай изискванията за съвпадение на индекса и заявката не са нарушени. Тази заявка ще бъде изпълнена от СУБД по оптималния начин. Моля, обърнете внимание, че редът на условията в заявката не трябва да съвпада с реда на полетата в индекса. Това не е проблем и ще се обработи нормално от СУБД.

4. Използване на логическо ИЛИ в условия

4.1 Използване на логическо ИЛИ в секцията WHERE на заявка

Не трябва да използвате OR в секцията WHERE на заявка. Това може да накара СУБД да не може да използва индекси на таблици и ще извърши сканиране, което ще увеличи времето за изпълнение на заявката и вероятността от заключване. Вместо това трябва да разделите една заявка на няколко и да комбинирате резултатите.

Например, молба

ИЗБЕРЕТЕ продукт . Име ОТСправочник . Продукти КАК Продукт КЪДЕ Статия = "001" ИЛИстатия = "002"

трябва да се замени с молба

ИЗБЕРЕТЕ продукт . Име ОТСправочник . Продукти КАК Продукт КЪДЕ Статия = "001" |КОМБИНИРАЙТЕ ВСИЧКИ |ИЗБЕРЕТЕ продукт . Име ОТСправочник . Продукти КАК Продукт КЪДЕ Статия = "002"

4.2. Записване на потребители в множество роли, всяка с RLS

1 СЪС RLS (Записвайте Ниво сигурност) или ограничаване на правата на ниво запис - това е настройката на потребителските права в системата 1 СЪС, което ви позволява да разделите правата за потребителите в контекста на динамично променящи се данни.

Ако конфигурацията описва няколко роли с RLS условия, тогава не трябва да присвоявате повече от една такава роля на един потребител. Ако един потребител е включен, например, в две роли с RLS - счетоводител и служител по персонала, тогава когато всичките му заявки бъдат изпълнени, условията на двата RLS ще бъдат добавени към техните условия с помощта на логическо ИЛИ. По този начин, дори ако няма условие ИЛИ в оригиналната заявка, то ще се появи там, след като RLS условията бъдат добавени. Такава заявка може да бъде изпълнена и неоптимално - бавно и с прекомерни заключвания.

Вместо това трябва да създадете „смесена“ роля – „счетоводител-служител по човешки ресурси“ и да регистрирате RLS по такъв начин, че да избегнете използването на ИЛИ в условието, и да включите потребителя в тази роля.

4.3 Използване на ИЛИ в условия на връзка

Не се препоръчва използването на логическо ИЛИ в условията на връзка, тоест в раздела на софтуера за заявка. Това също може да доведе до избор на неоптимален план и бавна производителност на заявките. Няма прост универсален начин за пренаписване на такава заявка без използване на OR. Трябва да анализирате решавания проблем и да се опитате да намерите друг алгоритъм за решаването му.

5. Използване на подзаявки в условие за присъединяване

Не трябва да използвате подзаявки в условие за присъединяване. Това може да доведе до значително забавяне на заявката и (в някои случаи) до пълната й неработоспособност на някои СУБД. Пример за заявка, използваща подзаявка в условие за свързване:

В този случай подзаявката в условието за присъединяване се използва за получаване, така да се каже, на „част от най-новото“ в края на предишния период. Освен това за всяка номенклатура периодът може да е различен. Препоръчително е да пренапишете такава заявка с помощта на временни таблици. Например, това може да стане по следния начин:

Заявка . Текст = " // Максимални дати за определяне на цени в предходен период за тези артикули |ИЗБЕРЕТЕ | Останали продукти Номенклатура AS Номенклатура, | МАКСИМУМ(Цени.Период) КАТО Период |МЯСТО Дати По номенклатури | ОТ | RegisterAccumulations.GoodsInWarehouses.Remainings(...) AS RemainingProducts | ЛЯВА ВРЪЗКА Информация за регистъра. Цена КАТО Цени | Софтуерни цени.Номенклатура = Оставащи продукти.Номенклатура И | Цени.Точка< НАЧАЛОПЕРИОДА(ОстаткиТоваров.Период, МЕСЯЦ) | ГРУПИРАНЕ ПО Останали продукти. Номенклатура | WHERERemainingItems.Warehouse = &Warehouse; // Изберете данни по цена за намерения период |ИЗБЕРЕТЕ | Дати По номенклатури. Номенклатура КАТО номенклатура, | Цени. Цена КАТО цената от миналия месец |FROM DateBy номенклатури | ЛЯВА ВРЪЗКА Информация за регистъра. Цена КАТО Цени | Софтуерни цени.Номенклатура = Оставащи продукти.Номенклатура И | Цени.Период = DatesByNomenclatures.Period " ;

6. Получаване на данни чрез точка от полета от съставен тип

Ако заявката използва пунктирана стойност от поле от сложен референтен тип, тогава при изпълнение на тази заявка ще бъде извършено присъединяване към всички обектни таблици, включени в този сложен тип. В резултат на това SQL прави текста на заявката изключително сложен и при изпълнението му оптимизаторът на СУБД може да избере неоптимален план. Това може да доведе до сериозни проблеми с производителността и дори неуспешна заявка в някои случаи.

По-специално, не се препоръчва достъп до данните на регистратора на регистъра (например „ProductsInWarehouses.Registrar.Date“) и т.н. В този случай няма значение в коя част на заявката използвате атрибута, получен чрез точка от поле от сложен тип - в списъка с върнати полета, в условие и т.н. Във всички случаи това лечение може да доведе до проблеми с ефективността.

Избягвайте излишъка, когато създавате полета от съставни референтни типове. Посочете толкова възможни типове за дадено поле, колкото е необходимо. Не трябва ненужно да използвате типовете „всяка връзка“ или „връзка към всеки документ“ и т.н. Вместо това трябва да анализирате по-внимателно логиката на вашето приложение и да присвоите точно онези възможни референтни типове към полето, които са необходими за решаване на проблема.
Когато е необходимо, жертвайте компактното място за съхранение за производителност. Ако във вашата заявка се нуждаете от стойност, получена чрез препратка, тогава може би тази стойност може да бъде съхранена директно в този обект. Например, ако при работа с регистър се нуждаете от информация за датата на регистратора, можете да създадете съответните подробности в регистъра и да му присвоите стойност при осчетоводяване на документи. Това ще доведе до дублиране на информация и известно (леко) увеличаване на нейния обем, но може значително да подобри производителността и стабилността на заявката.
Когато е необходимо, жертвайте компактността и гъвкавостта на кода за производителност. По правило не са необходими всички възможни типове дадена връзка за изпълнение на конкретна заявка при дадени условия. В този случай трябва да ограничите броя на възможните типове с помощта на функцията EXPRESS. Ако тази заявка е универсална и се използва в няколко различни ситуации (където типовете връзки може да са различни), тогава можете да генерирате заявката динамично, като замените във функцията EXPRESS типа, който е необходим при тези условия. Това ще увеличи размера на изходния код и вероятно ще го направи по-малко универсален, но може значително да подобри производителността и стабилността на заявката.

Пример

Тази заявка използва достъп до данните на регистратора. Регистраторът е поле от съставен тип, което може да приема референтни стойности към един от 56 типа документи.

SQL текстът на тази заявка ще включва 56 леви съединения към таблиците на документа. Това може да причини сериозни проблеми с производителността при изпълнение на заявката. Въпреки това, за да се реши този конкретен проблем, не е необходимо да се свързвате с всичките 56 вида документи. Условията на заявката са такива, че при нейното изпълнение ще бъдат избрани само движенията на документите „Продажби на стоки и услуги“ и „Поръчки на купувача“. В този случай можем значително да ускорим заявката, като ограничим броя на връзките с помощта на функцията EXPRESS().

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

7. Филтриране на виртуални таблици без използване на параметри

Когато използвате виртуални таблици в заявки, трябва да предадете всички условия, свързани с тази виртуална таблица, към параметрите на таблицата. Не се препоръчва да филтрирате виртуални таблици, като използвате условия в секцията WHERE и др. Такава заявка ще върне правилния (от функционална гледна точка) резултат, но ще бъде много по-трудно за СУБД да избере оптималния план за нейното изпълнение. В някои случаи това може да доведе до грешки в оптимизатора на СУБД и значително забавяне на производителността на заявките.

Например следната заявка използва раздела WHERE на заявката, за да избира от виртуална таблица.

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

Заявка . Текст = „ИЗБЕРЕТЕ | Номенклатура | ОТ | RegisterAccumulations.GoodsInWarehouses.Remains(, Warehouse = &Warehouse)";

Съгласно разпоредбите на член 134 от Кодекса на труда на Руската федерация работодателите са длъжни да предоставят на служителите увеличение на заплатите във връзка с нарастващите потребителски цени на стоките и услугите. Процедурата за индексиране (като се вземе предвид становището на профсъюза) се предписва в колективния договор или в местния регулаторен акт на организацията. В статията експертите на 1C разказват как да индексират таблицата с персонала и текущите тарифи на тарифите на служителите в „1C: Заплата и управление на персонала 8“ издание 3 (с по-нататъшно преизчисляване на средните доходи).

Индексирането в „1C: Заплати и управление на персонала 8“ (изд. 3) обикновено означава две задачи:

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

Индексирането на таблицата с персонала е възможно, ако програмата „1C: Заплати и управление на персонала 8“ издание 3 поддържа таблица с персонал със запазена история (флаговете Поддържане на персонала и Поддържане на история на промените в таблицата с персонала в Настройки - Записи на персонала - Настройка на таблицата с персонала са избрани флагове).

Индексацията се извършва в документа Промяна на персонала. Изборът на индексирани позиции се извършва чрез бутона Промяна на позиция. Щракнете върху бутона Попълване на показатели, за да посочите показателите, които са отбелязани в настройките за изчисляване на работната заплата като определящи състава на общата тарифна ставка. Стойностите на тези показатели могат да бъдат индексирани, като се умножат по коефициента на индексиране (фиг. 1).

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

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

Индексация на текущите тарифи на тарифните ставки на служителите

Започвайки от версия 3.1.3 в програмата 1C: Заплата и управление на персонала 8, издание 3, индексирането на текущите тарифи на тарифните ставки на служителите не се изразява просто в увеличение на тарифната ставка, но може да се комбинира с промени в други такси, които определят състава на общата тарифна ставка. В този случай коефициентът на индексиране не се посочва, а се изчислява като съотношение на новата обща тарифна ставка към предишната. Индексирането на текущите тарифи на тарифните ставки на служителите се извършва с помощта на документа Промяна на планираните начисления (меню Заплата - Промяна на заплащането на служителите - бутон Създаване).

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

ориз. 2. Индексация на доходите на служителите

Този флаг е наличен в документа, ако възможността за използване на механизми за индексиране на заплатите е разрешена от флага Доходите на служителите се индексират (меню Настройки - Платежна ведомост). С помощта на бутоните Избор или Попълване трябва да създадете списък със служители, чиито доходи подлежат на индексиране. След това щракнете върху бутона Попълване на индикатори в документа Промяна в заплащането на служителя отваря прозорец, където можете да въведете фиксирани стойности (Фиксирана стойност - вижте Фигура 2) или да преизчислите предварително попълнените с помощта на математически операции (Добавяне, Умножение по ), посочвайки например коефициента, по който трябва да се умножи заплатата, почасовата ставка или друг показател, който определя състава на общата тарифна ставка. Щракнете върху бутона Заповед за индексиране на доходите, за да генерирате печатна форма на заповедта за индексиране на доходите на служителите.

Ако предприятието използва тарифни групи, тогава документът Промяна на планираните такси може да бъде създаден чрез натискане на бутона Промяна на планираните такси в документа Одобряване на тарифна група (меню Заплата - Одобряване на тарифна група).

или

Защо разработчикът на 1C трябва да „индексира“ регистрационните размери и подробности?

- Е, имате заявки! - каза базата данни и затвори...

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

Какво е индекс?

Оптимизиране на разположението на индекса

Когато обемът на таблиците не им позволява да се „поберат“ в RAM паметта на сървъра, скоростта на дисковата подсистема (I/O) е на първо място. И тук можете да обърнете внимание на възможността за поставяне на индекси в отделни файлове, разположени на различни твърди дискове.

Подробно описание на действията http://technet.microsoft.com/ru-ru/библиотека/ms175905.aspx
Използването на индекс от различна файлова група подобрява производителността на неклъстерираните индекси поради паралелността на I/O процесите и работата върху самия индекс.
За да определите размерите, можете да използвате горепосочената обработка.

Влияние на индексите върху ключалките

Липсата на необходимия индекс за дадена заявка означава итерация през всички записи на таблицата, което от своя страна води до излишни заключвания, т.е. ненужните записи се блокират. Освен това, колкото по-дълго отнема завършването на заявка поради липсващи индекси, толкова по-дълго ще бъде времето за задържане на заключването.
Друга причина за блокировки е малкият брой записи в таблиците. В тази връзка SQL Server, когато избира план за изпълнение на заявка, не използва индекси, а обхожда цялата таблица (Table Scan), блокирайки цялата таблица. За да се избегне такова блокиране, е необходимо да се увеличи броят на записите в таблиците до 1500-2000. В този случай сканирането на таблици става по-скъпо и SQL Server започва да използва индекси. Разбира се, това не винаги може да се направи; редица директории като „Организации“, „Складове“, „Деления“ и т.н. обикновено имат малко записи. В тези случаи индексирането няма да подобри производителността.

Изпълнение на индекса

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

Заявки, които задават „тесни“ критерии за търсене.Такива заявки трябва да четат само малък брой редове, които отговарят на определени критерии.
Заявки, които задават диапазон от стойности.Тези заявки също трябва да прочетат малък брой редове.
Търсене, което се използва при операции за свързване.Колоните, които често се използват като свързващи ключове, са чудесни за индекси.
Търсене, при което данните се четат в определен ред.Ако наборът от резултати трябва да бъде сортиран в ред на клъстерен индекс, тогава не е необходимо сортиране, тъй като наборът от резултати вече е предварително сортиран. Например, ако се създаде групиран индекс върху колоните фамилия, собствено име и приложението изисква сортиране по фамилия и след това по собствено име, тогава няма нужда да добавяте клауза ORDER BY.

Вярно е, че при цялата полезност на индексите има едно много важно НО - индексът трябва да бъде „ефективно използван“ и трябва да позволява намирането на данни с помощта на по-малко I/O операции и количеството системни ресурси. Обратно, неизползваните (рядко използвани) индекси е по-вероятно да влошат производителността на запис на данни (тъй като всяка операция, която променя данните, трябва също така да актуализира страниците на индекса) и да създадат излишно пространство в базата данни.

Покриване(за дадена заявка) се нарича индекс, който съдържа всички необходими полета за тази заявка. Например, ако индексът е създаден върху колони a, b и c и операторът SELECT прави заявки за данни само от тези колони, тогава се изисква само достъп до индекса.

За да определим ефективността на даден индекс, можем да направим груба оценка с помощта на безплатна онлайн услуга, която показва „плана за изпълнение на заявката“ и използваните индекси.