Отправлено: SergTH000 от Сентябрь 07, 2010, 12:07:40 am
1. Данные о приеме на работу (дата) добавил в спр. ФизЛица, туда же добавил три реквизита: Год, Месяц, День для хранения сведений о пред. стаже. Можно было и в РС сделать, просто итак их много в задаче получилось.
2. Долго думал как лучше выцепить сведения о проценте премии, вот как получилось:
-Определяем сколько полных лет сотр. отработал (нужно учесть еще стаж который мог быть у сотр)
-Соединяем таблицу ОснНачисления док. НачислениеЗП левым соединением с РС Премия (там у меня процент премии от стажа зависит) по условию что СколькоОнОтработал >= ЧтоВРегистреПремия, затем группируем а процент Премии берем МАКСИМУМ
На расчеты мало задач, решал, поэтому есть вопросы, не хочется в посл. задачах те же ошибки делать:
1. Премия начисляется процентом от начисленного в том же периоде оклада. Сделал зависимость от базы по периоду регистрации, это норм? или все равно надо по периоду действия?
2. Правильно ли я понимаю, что связь через реальные таблицы должна быть только когда мы считаем базу и эта вирт. таблица
может содержать разное количество строк по сравнению с реальной (например в доп начислениях у нас есть ПремияОтОклада и ПремияСуммой, для которой базы нет, то есть в вирт таблицу она не попадет.) А если у нас все начисления имеют базу, тогда можно и не соединять через реальную табл.
3. Видел у некоторых ребят, в модуль расчета передают не только ссылку на регистратор, но и сам Объект Движения документя Начисление. То есть теперь, не надо отбор по регистратору делать, по сути все движения у нас уже есть. Задал этот вопрос Павлу, он ответил, что если будут перерасчеты, то это плохой вариант. А если их не будет? Кто как думает?
4. Надо ли стараться для расчета (в общем модуле) все начисления выбирать одним запросом? Или будет нормально на каждый План видов расчета по запросу?
5.Буду рад любым комментариям по момему решению)
Вложения:
3.03.dt
Отправлено: palax от Сентябрь 08, 2010, 10:57:09 am
Функция ПремияОтСтажа(Значение)Экспорт;
Запрос = Новый Запрос;
Запрос.Текст = "
| ВЫБРАТЬ
| ШкалаПремииОтСтажа.ЗначениеМин,
| ШкалаПремииОтСтажа.ЗначениеМакс,
| ШкалаПремииОтСтажа.Процент
|ИЗ
| РегистрСведений.ШкалаПр емииОтСтажа КАК ШкалаПремииОтСтажа
|ГДЕ
| ШкалаПремииОтСтажа.ЗначениеМин < &Значение
| И ШкалаПремииОтСтажа.ЗначениеМакс > &Значение";
Запрос.УстановитьПараметр("Значение",Значение); //Число
РезультатЗапроса = Запрос.Выполнить();
Выборка=РезультатЗапроса.Выгрузить();
Возврат ?(Значение=Неопределено,0,Выборка[0].Процент);
КонецФункции
2. в запросе при вычислении РасчетДН стаж расчтывал так:
ВЫРАЗИТЬ(РАЗНОСТЬДАТ(СотрудникиСрезПервых.ДатаПриема, &ПериодРегистрации, МЕСЯЦ) / 12 + СотрудникиСрезПервых.СтажНаПрошлойРаботе КАК ЧИСЛО(15, 0)) КАК Стаж
и никакие дни и месяцы нам не нужны. зачем усложнять, в шкале их же нет в сборнике, там говорится только про года...
3. В расчете ДН пишем следующее:
Если Выборка.ВидРасчета=ПланыВидовРасчета.ДополнительныеНачисления.Премия тогда
НаборЗаписей[Выборка.НомерСтроки-1].Размер=ПремияОтСтажа(Выборка.Стаж);
НаборЗаписей[Выборка.номерСтроки-1].Результат=Выборка.База*ПремияОтСтажа(Выборка.Стаж)/100;
КонецЕсли;
Отправлено: SergTH000 от Сентябрь 08, 2010, 11:49:38 am
Quote
Думаю надо рег.сведений завести СтажПредРаботе(изм-Сотр. ресурс -Значение). Справочник для этого не подойдет явно.
Хм..Я предполагаю, что справочник ФизЛица это как бы спр. "Сотрудники". То есть если там есть "элемент", то этот "элемент" принят на работу. При приеме на работу указывается дата приема и пред. стаж и они не меняются! Если сотрудник уволился и потом опять пришел на работу, то он заново попадает в этот спр., графа пред. стаж заполняется из его трудовой (расчитывается кадровиком). Так что по моему справочник не так плохо. Ну единственное нужно бы конечено новый спр. завести Сотрудники, но его тада заполнять придется. Поэтому считал так.
Quote
и никакие дни и месяцы нам не нужны. зачем усложнять, в шкале их же нет в сборнике, там говорится только про года...
Дни и месяцы используются в типовой зупии, взял от туда. А вдруг сотрудник отработал 2 года и 1 день, устроился к нам и через 364 дня начисляем премию. Если этот день не указать, то премия будет 10. А если указать получиться 3 полных года и будет 15.
Про функцию пока не могу посмотреть, но могу сказать, что у меня точно верно считает премию, в независимости от количества строк в шкале.
Спасибо, что ответил, я знаю ты уже сдал этот экзамен, если тебе не трудно посмотри эту базу на предмет реализации самих механизмов расчета. Или мои вопросы в первом посте)
Добавлено (08.09.2010, 11:49)
---------------------------------------------
Слушай, ты при расчете премии, получаешь запросом, данные из регистра, перебираешь их для каждой строки вызываешь функцию? Запрос в цикле?
Отправлено: palax от Сентябрь 08, 2010, 04:53:00 pm
Добавлено (08.09.2010, 16:53)
---------------------------------------------
Quote (SergTH000)
Если сотрудник уволился и потом опять пришел на работу, то он заново попадает в этот спр.,
Вложения:
palax-8.2-3.03.dt
Отправлено: SergTH000 от Сентябрь 08, 2010, 04:56:41 pm
Quote
Думаю не стоит добавлять в ТЧ дока Нач.Зар. колонки Подразделение,Должность. т.к все пусть хранится в регистре сведений
Посмотри отчет (я не знаю какой у тебя сборник, но у меня в отчете четко видно, что сотрудник в одном и том же подразделении может иметь разные должности. ) Придется все же начислять такому сотруднику из такого то подразделения именно на такой то должности.
Отправлено: palax от Сентябрь 08, 2010, 04:56:42 pm
Quote (SergTH000)
Дни и месяцы используются в типовой зупии, взял от туда. А вдруг сотрудник отработал 2 года и 1 день, устроился к нам и через 364 дня начисляем премию. Если этот день не указать, то премия будет 10. А если указать получиться 3 полных года и будет 15.
Отправлено: SergTH000 от Сентябрь 08, 2010, 04:59:52 pm
Месяцы и Дни нужны для подсчета ПОЛНЫХ ЛЕТ
Отправлено: palax от Сентябрь 08, 2010, 05:06:26 pm
Добавлено (08.09.2010, 17:06)
---------------------------------------------
Quote (SergTH000)
palax, Смотри, сотрудник РАНЬШЕ отработал 2 года 1 месяц. Пришел к нам 01.01.2010. Через 11 месяцев мы начисляем ему премию - 01.11.2010. Какой стаж у сотрудника? Если ты укажешь только полные года при приеме то у него будет 2 года, если с месяцем то 3 года. Это разные премии. Месяцы и Дни нужны для подсчета ПОЛНЫХ ЛЕТ
...Думаю ты лезешь в дебри. Тогда возьми функцию с конфы ЗУП и пиши с месяцами и днями, думаю препод этого точно не поймет)))
Отправлено: SergTH000 от Сентябрь 08, 2010, 05:07:39 pm
Итого
Отправлено: palax от Сентябрь 08, 2010, 05:09:39 pm
Добавлено (08.09.2010, 17:09)
---------------------------------------------
Quote (SergTH000)
Подразделение|Сотрудник|Вид расчета|Должность1|Должность2|...| Итого
Отправлено: SergTH000 от Сентябрь 08, 2010, 05:12:48 pm
Добавлено (08.09.2010, 17:12)
---------------------------------------------
Quote
ну и у меня такой же, чем тебе мой отчет не понравился?!
Из за того что у сотрудника могут быть разные должности, приходится в ТЧ документа Начисление, указывать на какую должность сотруднику ты начисляешь оклад. Для этого и нужны колонки в ТЧ
Отправлено: palax от Сентябрь 08, 2010, 05:15:53 pm
Quote (SergTH000)
palax, Смотри, сотрудник РАНЬШЕ отработал 2 года 1 месяц. Пришел к нам 01.01.2010. Через 11 месяцев мы начисляем ему премию - 01.11.2010. Какой стаж у сотрудника? Если ты укажешь только полные года при приеме то у него будет 2 года, если с месяцем то 3 года. Это разные премии. Месяцы и Дни нужны для подсчета ПОЛНЫХ ЛЕТ
Добавлено (08.09.2010, 17:15)
---------------------------------------------
Quote (SergTH000)
Из за того что у сотрудника могут быть разные должности, приходится в ТЧ документа Начисление, указывать на какую должность сотруднику ты начисляешь оклад. Для этого и нужны колонки в ТЧ
Отправлено: SergTH000 от Сентябрь 08, 2010, 05:16:55 pm
Quote
А ЕЩЕ ГОД МОЖЕТ БЫТЬ ВЫСОКОСНЫМ И В ФЕВРАЛЕ РАЗНОЕ КОЛ-ВО ДНЕЙ, ТОГДА ТОЖЕ РЕАЛИЗУЙ И УЧТИ
При моем методе это учитывается. Я всегда получу реальное полное количество лет отработанных сотрудником. Точнее это учитываю не я, а функция запроса РАЗНОСТЬДАТ
Отправлено: palax от Сентябрь 08, 2010, 05:17:39 pm
Quote (SergTH000)
Из за того что у сотрудника могут быть разные должности, приходится в ТЧ документа Начисление, указывать на какую должность сотруднику ты начисляешь оклад. Для этого и нужны колонки в ТЧ
Отправлено: SergTH000 от Сентябрь 08, 2010, 05:22:00 pm
Quote
нет ты не понял, отчет совсем другой смысл в себе несет
А какой? Разве это не означает, что у сотрудника могут быть разные должности? А если так то на какую должность ты начисляешь оклад, если колонки должность у тебя нет?
Добавлено (08.09.2010, 17:22)
---------------------------------------------
palax,
Quote
изменение должности во времени -это регистр сведений Сотрудники, там же и подразделение
Может быть. Я предположил, что может быть и так что сотрудник работает на разных доложностях. В принципе это не слишком усложняет задачу.
Отправлено: palax от Сентябрь 08, 2010, 05:28:17 pm
Quote (SergTH000)
А какой? Разве это не означает, что у сотрудника могут быть разные должности? А если так то на какую должность ты начисляешь оклад, если колонки должность у тебя нет?
Отправлено: SergTH000 от Сентябрь 08, 2010, 05:34:04 pm
Quote
понимаешь теперь, что это все мелочи?!)))
Хорошо. Если сотрудник отработал 2 года и 11 месяцев. Через месяц ему начисляют премию и он все равно получит как будто отработал 2 года (ты же месяцы не указываешь).
Может я чего то не понимаю, но почему бы если есть возможность избежать подобных моментов довольно простым способом (добавлением трех реквизитов и последующем вычитании их значений) не воспользоваться ей?
Отправлено: palax от Сентябрь 08, 2010, 05:36:09 pm
Отправлено: SergTH000 от Сентябрь 08, 2010, 05:37:48 pm
Отправлено: palax от Сентябрь 08, 2010, 05:54:17 pm
Отправлено: SergTH000 от Сентябрь 08, 2010, 05:55:39 pm
Отправлено: palax от Сентябрь 08, 2010, 06:30:38 pm
Отправлено: SergTH000 от Сентябрь 08, 2010, 06:50:38 pm
Отправлено: palax от Сентябрь 08, 2010, 07:03:34 pm
Добавлено (08.09.2010, 19:03)
---------------------------------------------
Базу я исправил свою,записал в ту же ветку
Отправлено: AS от Ноябрь 06, 2010, 08:42:31 pm
Вложения:
3-3.dt
Отправлено: AndreiPiter от Январь 17, 2011, 07:31:27 pm
Вложения:
AP_3.03.dt
Отправлено: detec от Май 23, 2011, 01:50:06 pm
Добавлено (23.05.2011, 13:50)
---------------------------------------------
У меня такой вот вопрос есть. Я пересмотрел несколько решений из ветки и никак не могу понять, почему данные о стаже, премии и окладе заполняются на этапе проводки документа? Почему нельзя заполнить их интерактивно или программно в форме документа? Тем более, что этим можно показать знание управляемого интерфейса, т.к. нужно создать команду формы, заполнить данные на севрере, вернуть на клиента, повесить кнопку команды в командной панели таблицы формы.
Вложения:
1Cv8_detec.dt
Отправлено: Gulf_Stream от Июнь 11, 2011, 04:41:59 pm
Я не стал сильно заморачиваться с расчётом стажа - добавил в справочник реквизты стаж ( в месяцах) и дату приёма на работу, а в запросе обработки проведения вляпал такую конструкцию:
Code
ВЫБОР
| КОГДА (НачислениеЗарплатыДополнительныеНачисления.Сотрудник.Стаж + РАЗНОСТЬДАТ(&ПериодРегистрации, НачислениеЗарплатыДополнительныеНачисления.Сотрудник.ДатаПриемаНаРаботу, МЕСЯЦ)) / 12 < 1
| ТОГДА 5
| ИНАЧЕ ВЫБОР
| КОГДА (НачислениеЗарплатыДополнительныеНачисления.Сотрудник.Стаж + РАЗНОСТЬДАТ(&ПериодРегистрации, НачислениеЗарплатыДополнительныеНачисления.Сотрудник.ДатаПриемаНаРаботу, МЕСЯЦ)) / 12 > 3
| ТОГДА 15
| ИНАЧЕ 10
| КОНЕЦ
| КОНЕЦ
| КОГДА (НачислениеЗарплатыДополнительныеНачисления.Сотрудник.Стаж + РАЗНОСТЬДАТ(&ПериодРегистрации, НачислениеЗарплатыДополнительныеНачисления.Сотрудник.ДатаПриемаНаРаботу, МЕСЯЦ)) / 12 < 1
| ТОГДА 5
| ИНАЧЕ ВЫБОР
| КОГДА (НачислениеЗарплатыДополнительныеНачисления.Сотрудник.Стаж + РАЗНОСТЬДАТ(&ПериодРегистрации, НачислениеЗарплатыДополнительныеНачисления.Сотрудник.ДатаПриемаНаРаботу, МЕСЯЦ)) / 12 > 3
| ТОГДА 15
| ИНАЧЕ 10
| КОНЕЦ
| КОНЕЦ
И ещё у меня вопрос, оптимален ли такой запрос по производительности:
Code
ВЫБРАТЬ
| ДополнительныеНАчисления.НомерСтроки,
| ДополнительныеНАчисления.ВидРасчета,
| ДополнительныеНАчисления.Размер,
| ДополнительныеНАчисленияБазаОсновныеНачисления.РезультатБаза КАК База
|ИЗ
| РегистрРасчета.ДополнительныеНАчисления КАК ДополнительныеНАчисления
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрРасчета.ДополнительныеНАчисления.БазаОсновныеНачисления(&Изм, &Изм, , Регистратор = &Регистратор) КАК ДополнительныеНАчисленияБазаОсновныеНачисления
| ПО ДополнительныеНАчисления.НомерСтроки = ДополнительныеНАчисленияБазаОсновныеНачисления.НомерСтроки
|ГДЕ
| ДополнительныеНАчисления.Регистратор = &Регистратор
| ДополнительныеНАчисления.НомерСтроки,
| ДополнительныеНАчисления.ВидРасчета,
| ДополнительныеНАчисления.Размер,
| ДополнительныеНАчисленияБазаОсновныеНачисления.РезультатБаза КАК База
|ИЗ
| РегистрРасчета.ДополнительныеНАчисления КАК ДополнительныеНАчисления
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрРасчета.ДополнительныеНАчисления.БазаОсновныеНачисления(&Изм, &Изм, , Регистратор = &Регистратор) КАК ДополнительныеНАчисленияБазаОсновныеНачисления
| ПО ДополнительныеНАчисления.НомерСтроки = ДополнительныеНАчисленияБазаОсновныеНачисления.НомерСтроки
|ГДЕ
| ДополнительныеНАчисления.Регистратор = &Регистратор
Не лучше ли этот запрос строить через временные таблицы, отфильтровав реальную таблицу по регистратору?
Вложения:
3.03_Gulf_Strea.dt
Отправлено: Gyd от Июль 06, 2011, 12:11:08 pm
Quote (detec)
Я пересмотрел несколько решений из ветки и никак не могу понять, почему данные о стаже, премии и окладе заполняются на этапе проводки документа? Почему нельзя заполнить их интерактивно или программно в форме документа?
А зачем оклад, к примеру, заполнять интерактивно? Это неправильно, ведь его могут изменить потом. Программно в форме - это усложнение.
---------------------------------------------
Quote (Gulf_Stream)
Code
ТОГДА 5
.....
| ТОГДА 15
| ИНАЧЕ 10
.....
| ТОГДА 15
| ИНАЧЕ 10
"Хранить" значения размера премии в коде - это не гуд
---------------------------------------------
Quote (Gyd)
в справочник реквизты стаж ( в месяцах) и дату приёма на работу,
Я тоже также сделал. Только засунул эти реквизиты в регистр СведенияОСотруднике. Заметил что в некоторых решениях стаж до приема на работу не учтен. Значения размера премий сохранил в другом регистре (РазмерыПремий), так же как это сделал AS, в запросе получаю Общий стаж работы (ПериодРегистрации-ДатаПриемаНаРаботу + Стаж до приема), и выбираю из регистра РазмерыПремий соответствующее значение (процент).
Отправлено: DoctorRoza от Октябрь 30, 2011, 06:26:38 pm
Насчет стажа, у нас же есть РС СведенияОСотрудниках, период и будет датой приема, а допол. реквизит - стажем на дату приема. Ну и уже в док. Начисление зарплаты находить процент премии.
Вложения:
DoctorRoza_3_3.dt
Отправлено: Gyd от Октябрь 31, 2011, 12:09:59 pm
Quote (DoctorRoza)
Возникает вопрос, в РР дополнительные начисления зависимость от базы по периоду действия или по периоду регистрации? ИМХО, по периоду действия .. Может кто-нибудь пояснить это, да и вообще в чем разница?
В принципе тут без разницы какую зависимость ставить. Период регистрации у оклада наверняка совпадает с периодом действия (в одном месяце). Но лучше конечно поставить зависимость по периоду действия, на тот случай если период регистрации оклада всё же попадёт в другой месяц. Например, период действия - 01.10-31.10, период регистрации- 15.10 и 01.11, базовый период - 01.10-31.10. Период регистрации второй части оклада в ноябре, а нам надо базу оклада за октябрь-месяц. Зависимость по периоду регистрации уже не подходит.
Зависимость по периоду регистрации обычно применяют для удержаний. Я так понимаю период регистрации служит показателем когда человеку реально выплатили начисления и значит с них можно производить удержания. Например: есть оклад (за октябрь), премия за прошлый месяц (за сентябрь) и квартальная премия (за июль-сентябрь). Всё это выплачивается в октябре (и регистрируется в октябре). И со всех этих начислений нужно удержать профвзносы. Логичнее всего поставить зависимость по периоду регистрации и указать базовый период - октябрь. В этом случае все три начисления попадут в базу.
А вот если мы поставим по периоду действия, они тоже попадут в базу, но при этом попадут и те которые еще не выплачивались, например больничный за октябрь (период действия больничного октябрь-ноябрь, выплачиваться будет в ноябре).
Отправлено: LEOON от Февраль 07, 2012, 09:52:24 pm
Вложения:
LEOON_3.03.dt
Отправлено: kow1976 от Апрель 20, 2012, 09:19:00 pm
Спасибо за комментарии и замечания.
В решении предположил, что работник может работать только в одном подразделении и по одной должности.
Вложения:
kow1976_3.3.dt
Отправлено: Anykey_d от Май 10, 2012, 03:02:24 pm
Вложения:
_3.3.dt
Отправлено: bezplana от Май 17, 2012, 08:05:13 pm
Вложения:
TSUP_3.3.dt
Отправлено: Lazio от Август 06, 2012, 01:22:14 pm
Вложения:
3.3.dt
Отправлено: Oliver от Ноябрь 20, 2012, 09:17:57 am
Исходя из отчёта Должность в измерения (Совмещения возможны).
Стаж и дату приёма в Одном РС измерение:Сотрудник и с двумя ресурсами: ДатаПриёма и ДопСтажВДнях.
В запросе:
Code
РАЗНОСТЬДАТ(СтажСотрудников.ДатаПриёма, ДОБАВИТЬКДАТЕ(&ПериодРегистрации, ДЕНЬ, СтажСотрудников.ДопСтажВДнях), ГОД) КАК Стаж
Получаем Процент премии Левым Соединением (но не в коем случае не в цикле!)
Code
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СтавкиПремии КАК СтавкиПремии
ПО (ВлЗапрос.Стаж >= СтавкиПремии.ШкалаДо
И ВлЗапрос.Стаж < СтавкиПремии.ШкалаПосле)
...Можно ШкалаДо и ШкалаПосле в измерения загнать... - котроль?
У кого есть мысли как обойти эту "придирку"...
Вложения:
Oliver_3_3.dt
Отправлено: GranatUA от Декабрь 10, 2012, 05:16:29 pm
В коде оставлял комментарии, чтобы начинающие расчетчики смогли понять что к чему.
P.S. Спасибо Oliver-у, некоторые моменты заимствовал у него.
Вложения:
3_3_GranatUA.dt
Отправлено: Oliver от Декабрь 11, 2012, 05:51:46 am
Ставлю плюс за подробные коментарии.
Процент премии хранить в коде не очень хорошо.
Главне в Общем модуле нельзя делать так:
Quote
НаборЗаписейРегистра.Записать();
надо так:
Quote
НаборЗаписейРегистра.Записать(,Истина);
... это стоит один балл...
Отправлено: semtesem от Январь 10, 2013, 06:01:34 pm
именно это нужно было в задаче реализовать?
Делал на регистре Сведений,
нет отчета так как проглядел в начале Должность, соответственно нет и должности:
? снижают ли балы если обрабатывать какие-то данные в цикле а не в запросе,
мне например намного проще (по времени) отобрать при помощи если, ИначеЕсли процент
чем делать это в запросе соединениями и объединениями.
В решении собираю год как 365 дней - а нужно по идее секундами и разность дат - критично ли это.
Вложения:
semtesem_3.03.dt
Отправлено: Oliver от Январь 11, 2013, 08:16:41 am
ПериодДействияКонец желательно приводить к концу дня перед записью.
Цитата
? снижают ли балы если обрабатывать какие-то данные в цикле а не в запросе
Цитата
В решении собираю год как 365 дней - а нужно по идее секундами и разность дат - критично ли это.
Вот это не сдача:
РН:СведеньяОСтаже - Остатки, или при смерти сотрудника выводите ресурс в 0!
Отправлено: mik19770727 от Январь 25, 2013, 03:17:36 pm
Отправлено: SerF от Февраль 08, 2013, 11:20:48 pm
Проверьте, кто интересуется.
Вложения:
3.03_SerF.dt
Отправлено: asokop от Февраль 22, 2013, 10:41:00 am
У меня в условии задачи 3.3 такой текст: "Процент премии зависит от стажа работы сотрудника на данном предприятии. При решении задачи необходимо учитывать, что на момент начала ведения учета в информационной базе у сотрудника уже может быть стаж отличный от нуля."
Здесь ни слова не написано о стаже на предыдущих местах работы ( Может быть у меня старая формулировка задачи?). Имеется в виду следующее: допустим Бельдыев работает в фирме с 01.05.2010, а учет в 1С начался с 01.01.2012 (и соответственно документы "Начисление з/п" стали оформляться в 1С с 01.01.2012). Следовательно, у Бельдыева на момент начала ведения учета имеется стаж 20 месяцев.
Поэтому считаю правильным вариантом просто использовать дату приема на работу и хранить ее в справочнике ФизЛица.
А дальше как у всех - высчитывать разницу дат (в месяцах, днях или секундах - кому как нравится, я брал целое количество месяцев) и на основе этой разницы искать нужную запись в РС "ПроцентыПремии".
Отправлено: fimanich от Апрель 02, 2013, 11:51:47 pm
Цитата (asokop)
Поэтому считаю правильным вариантом просто использовать дату приема на работу и хранить ее в справочнике ФизЛица.
Прикрепляю свое решение. Любая критика приветствуется.
Добавлено (02.04.2013, 23:51)
---------------------------------------------
Нашел недочет: график надо в днях, а у меня в часах; поправлю позже.
Вложения:
fimanich_03_03.dt
Отправлено: fimanich от Апрель 03, 2013, 08:47:46 am
Вложения:
9432134.dt
Отправлено: Maxus от Май 21, 2013, 01:14:50 am
Вложения:
3_3_mbs.dt
Отправлено: arthur2003 от Июнь 03, 2013, 10:19:35 am
Цитата
Мой вариант решения.
Прикрепления: 3_3_mbs.dt(168Kb)
почему
Код
Движения.ОсновныеНачисления.Записать(,Ложь);
Выкладываю свои вариант
Вложения:
4135354.dt
Отправлено: TuMyP1985 от Август 22, 2013, 11:24:15 pm
Вложения:
KTT_3_3.dt
Отправлено: sergejandreev от Август 25, 2013, 10:07:42 pm
Отправлено: TuMyP1985 от Август 26, 2013, 10:04:12 am
Цитата (sergejandreev)
Такой вопрос...
Отправлено: nskripka от Август 26, 2013, 10:44:34 am
....
Делать по другому не стал (соединение с реальной таблицей и обращение к записям - выборка[номерстроки-1]), так как возможны замечания.
Отправлено: sergejandreev от Август 26, 2013, 04:55:41 pm
Отправлено: artfa от Август 28, 2013, 08:15:21 pm
Вложения:
0954335.dt
Отправлено: artfa от Октябрь 08, 2013, 10:06:08 pm
Вложения:
4066945.dt
Отправлено: Калифорниец от Октябрь 23, 2013, 09:36:30 pm
Отправлено: Voyager от Октябрь 23, 2013, 09:54:13 pm
Отправлено: Калифорниец от Октябрь 23, 2013, 10:02:23 pm
Отправлено: Voyager от Октябрь 23, 2013, 10:08:07 pm
Отправлено: Калифорниец от Октябрь 23, 2013, 10:14:38 pm
Отправлено: artfa от Октябрь 23, 2013, 11:49:58 pm
Цитата Калифорниец (
)
)Могу ли я опираться на твое решение как на эталонное?
Отправлено: Калифорниец от Октябрь 24, 2013, 06:00:36 pm
Добавлено (24.10.2013, 17:14)
---------------------------------------------
Подскажите, как понимать фразу - "Дневная ставка рассчитывается как оклад деленный на количество рабочих дней в том же периоде, что и фактически отработанные дни"? Где взять рабочие дни? Это ведь не факт из данных графика?
Добавлено (24.10.2013, 17:54)
---------------------------------------------
Вопрос снимается. Рабочие дни, это ведь план, норма - из данных графика это ЗначениеПериодДействия.
Добавлено (24.10.2013, 18:00)
---------------------------------------------
Еще вопрос: как принято на экзамене организовывать расчет записей. В данной задаче можно все одним пакетным запросом сделать и перебрать двумя циклами 2 пакета, либо тремя запросами, т.е. под каждый вид начисления свой запрос и свой цикл? В методичке преподы делают запрос под каждое начисление (может, из-за совместимости решения с объектной моделью получения данных)?
Отправлено: Stanistas от Январь 14, 2014, 09:07:33 am
Отправлено: non1ka от Февраль 02, 2014, 07:53:02 pm
У Вас ошибка. У регистра расчета "Основные" установлен признак "Базовый период", а для Основных видов расчета, по условию задачи, нет необходимости в получении базы.
artfa,
1. У Вас не учтено условие задачиЦитата"При решении задачи необходимо учитывать, что на момент начала ведения учета в информационной базе у сотрудника уже может быть стаж отличный от нуля.А у Вас только ДатаПриема, а стажа нет
2. Расчет результат нужно делать в общем модуле, несмотря на изменения в платформе 8.2
Выкладываю свое решение
Вложения:
9818921.dt
Отправлено: Leo705 от Март 31, 2014, 07:36:11 am
Вложения:
Leo705_3.3.dt
Отправлено: unf13 от Сентябрь 30, 2014, 12:12:22 pm
Добавлено (30.09.2014, 11:50)
---------------------------------------------
Цитата
Я пересмотрел несколько решений из ветки и никак не могу понять, почему данные о стаже, премии и окладе заполняются на этапе проводки документа? Почему нельзя заполнить их интерактивно или программно в форме документа?
Интересный вопрос, так-то. Вроде сведения об окладе, подразделении итп, классически просто берутся из табличной части. Если так рассуждать,то и процент премии по-хорошему должен браться из тч (заполняться в реквизит "размер" табличной части),т.е. заполняться в форме документа.
Насколько это правильно методически, кто-нибудь знает?
Добавлено (30.09.2014, 12:02)
---------------------------------------------
Посмотрел сейчас пример решения из сборника,который там приводится, там по-крайней мере тарифная ставка заполняется в форме в реквизит тч "Размер" и при проведении просто записывается в РР.
Тогда по логике вещей, разбитие на шкалу следует поместить в специальную обработку заполнения табличной части документа "Наичсление ЗП" или в процедуру выбора сотрудника.
Добавлено (30.09.2014, 12:12)
---------------------------------------------
Мне кажется где-то в описании типичных ошибок что-то было подобное.
Если заполнять размеры окладов, проценты премий итп. при проведении,то получается, если вдруг данные в регистре сведений о сотруднике будут удалены или изменены задним числом и потом документ случайно перепровести,то получим совершенно другие результаты расчета, т.е. документ при проведении опирается на внешние не стабильные данные и будет не понятно, почему когда-то при расчете мы получили именно такие результаты.
Коллеги, выскажите свое мнение, плиз, а то варюсь сам со своими мыслями,может я жутко туплю просто или чего не понимаю.
Отправлено: naumenko_alex от Март 26, 2015, 11:18:51 pm
Буду ждать ваших замечаний и отзывов. ;)
Отправлено: rusmosav от Апрель 18, 2015, 08:54:58 pm
Отправлено: Sanek421 от Июнь 01, 2015, 04:38:11 pm
Отправлено: SunB от Июнь 13, 2015, 12:49:23 am
Скажите, что значит эта формулировка? Нужно хранить данные в регистре сведений и просто подтягивать по срезпоследних на дату документа в таблицу основных начислений по конкретному сотруднику в поле оклад?
Отправлено: ksandr от Июнь 13, 2015, 10:41:41 am
срезпоследних на дату документаНе на дату, а на начало расчетного периода.
Отправлено: SunB от Июнь 13, 2015, 11:44:15 am
Отправлено: SunB от Июнь 13, 2015, 03:23:11 pm
Что следует предусмотреть в функционале по этой формулировке?
Отправлено: АндрейМ от Июнь 16, 2015, 02:07:16 pm
Отправлено: Jestery от Июль 03, 2015, 07:14:53 pm
Отправлено: ZZZZ от Июль 09, 2015, 05:20:51 pm
Каждый сотрудник может работать одновременно в нескольких подразделениях компании, то есть совместительство допускается.
Или
Каждый сотрудник может работать одновременно только в одном подразделении компании, то есть совместительство не допускается.
Вот как это условие влияет на логику решения????
Отправлено: nuraliev от Июль 09, 2015, 10:15:02 pm
Отправлено: ZZZZ от Июль 09, 2015, 10:22:35 pm
Наверное влияет на использование измерения подразделение в регистре расчетаДа так и есть, уже разобрался, когда совместительство то нужно добавить измерение "Подразделение" иначе, когда совместительство не допускается, то не нужно, ну или если нужно в отчете вывести, то можно добавить реквизит "Подразделение".
Отправлено: ComradeKite от Июль 14, 2015, 06:32:53 pm
Прошу прокомментировать мое решение
Привет,
добавил белдыева с другим отделом и другой должностью на период 01012015 - 01092015.
Отчет сразу перекосило.
Мое решение
Отправлено: alex1248 от Июль 22, 2015, 09:34:43 pm
Прощу оценить.Тем, у кого стаж от 1 до 365 дней, премия начисляется в размере 15% (неточность в коде).
На мой взгляд, при таком учете данных о сотрудниках высока вероятность, что не будет соблюдено вот это условие: "на момент начала ведения учета в информационной базе у сотрудника уже может быть стаж отличный от нуля".
Мой вариант решения. Буду рад любым комментариям.Тоже по поводу стажа. Думаю, вариант с регулярным его вводом кадровиком/расчетчиком - не самый оптимальный.
Я предполагаю для учета стажа в соответствии с условиями задачи добавить в справочник сотрудников реквизит "Дата приема на работу". Как насчет такого варианта?
PS. Еще кое-что добавлю.
В обоих решениях при выборке окладов используется дата регистрации. Думаю, надо брать начало месяца периода действия, тем более, что формально (хотя в этой задаче не указано) периоды действия могут различаться для разных записей (в аналогичной этой задаче 01-СПР из "Актуальных билетов" конкретно указано, что "В одном документе могут быть данные за разные расчетные периоды").
Отправлено: tatyana_fiesta от Июль 24, 2015, 03:19:44 pm
Многие здесь решения без этого условия =(((
Пример,
Мой документ с ПериодомРегистрации = 01.03.15
Имеет поля:
ОсновныеНачисления:
Сотрудник Оклад 01.02.15 - 20.02.15
Сотрудник Оклад 01.03.15 - 15.03.15
ДопНачисления:
Сотрудник Премия 01.02.15 - 28.02.15
Сотрудник Премия 01.03.15 - 31.03.15
Первое! Как установить ДатуСреза(Период) у регистра "СведенияОСотрудникахСрезПоследних" равным ПериодуДействия, чтобы получить Оклад?
Второе! Премия не берет Базу за Февраль, а плюсует Февраль и Март
ВЫБРАТЬ
ДополнительныеНачисленияБазаОсновныеНачисления.НомерСтроки,
ДополнительныеНачисленияБазаОсновныеНачисления.Сотрудник,
ДополнительныеНачисленияБазаОсновныеНачисления.ВидРасчета,
ДополнительныеНачисленияБазаОсновныеНачисления.РезультатБаза
ИЗ
РегистрРасчета.ДополнительныеНачисления.БазаОсновныеНачисления(&Измерения, &Измерения, , Регистратор = &Ссылка) КАК ДополнительныеНачисленияБазаОсновныеНачисления
Отправлено: alex1248 от Июль 24, 2015, 06:01:59 pm
Как установить ДатуСреза(Период) у регистра "СведенияОСотрудникахСрезПоследних" равным ПериодуДействия, чтобы получить Оклад?Я брал данные не из вирт таблицы, а из самого регистра сведений: по каждому сотруднику в ТЧ документа выбираю записи с периодом, меньшим начала периода действия, а затем из них выбираю максимальный период. Далее по этому периоду просто беру нужную запись в РС.
Премия не берет Базу за Февраль, а плюсует Февраль и МартА тут всё зависит от настроек ПВР - "зависимость от базы". Видимо, у вас выбрана зависимость по периоду регистрации.
Отправлено: tatyana_fiesta от Июль 27, 2015, 10:13:35 am
Помогите додумать ;) Не получается адекватно получить Оклад, запрос ниже:Как установить ДатуСреза(Период) у регистра "СведенияОСотрудникахСрезПоследних" равным ПериодуДействия, чтобы получить Оклад?Я брал данные не из вирт таблицы, а из самого регистра сведений: по каждому сотруднику в ТЧ документа выбираю записи с периодом, меньшим начала периода действия, а затем из них выбираю максимальный период. Далее по этому периоду просто беру нужную запись в РС.
ВЫБРАТЬ
ОсновныеНачисленияДанныеГрафика.НомерСтроки,
ОсновныеНачисленияДанныеГрафика.ЗначениеПериодДействия КАК Норма,
ОсновныеНачисленияДанныеГрафика.ЗначениеФактическийПериодДействия КАК Факт,
ОсновныеНачисленияДанныеГрафика.Сотрудник,
ОсновныеНачисленияДанныеГрафика.ПериодДействия
ПОМЕСТИТЬ Док_ТЧ
ИЗ
РегистрРасчета.ОсновныеНачисления.ДанныеГрафика(Регистратор = &Ссылка) КАК ОсновныеНачисленияДанныеГрафика
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
Док_ТЧ.НомерСтроки,
МАКСИМУМ(СведенияОСотрудниках.Период) КАК Период,
Док_ТЧ.Норма,
Док_ТЧ.Факт,
СведенияОСотрудниках.Оклад
ИЗ
Док_ТЧ КАК Док_ТЧ
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СведенияОСотрудниках КАК СведенияОСотрудниках
ПО Док_ТЧ.Сотрудник = СведенияОСотрудниках.Сотрудник
И Док_ТЧ.ПериодДействия >= СведенияОСотрудниках.Период
СГРУППИРОВАТЬ ПО
Док_ТЧ.НомерСтроки,
Док_ТЧ.Норма,
Док_ТЧ.Факт,
СведенияОСотрудниках.Оклад
Отправлено: tatyana_fiesta от Июль 27, 2015, 10:15:14 am
Проверила ещё раз: зависимость от базы точно по по периоду действияПремия не берет Базу за Февраль, а плюсует Февраль и МартА тут всё зависит от настроек ПВР - "зависимость от базы". Видимо, у вас выбрана зависимость по периоду регистрации.
Сработало, когда установила ПериодДействия у ДопНачислений =) вот только насколько это правильно?! ???
Отправлено: alex1248 от Июль 27, 2015, 11:08:44 pm
Сработало, когда установила ПериодДействия у ДопНачислений =) вот только насколько это правильно?! ???Наверное, всё-таки еще какая-то проблема есть.
Отправлено: alex1248 от Июль 27, 2015, 11:28:54 pm
Помогите додумать ;) Не получается адекватно получить Оклад, запрос ниже:Думаю, вместо ПериодДействия следует использовать ПериодДействияНачало (нам же начальный оклад нужен на начало фактического периода, а не расчетного).
А оклад я получал следующим запросом в пакете по уже определенной дате.
И еще, до получения окладов надо к начальному добавить возможные следующие даты изменения оклада в периоде.
Отправлено: tatyana_fiesta от Июль 28, 2015, 03:39:16 pm
его мне подсказал HRom в другой теме:
А почему обязательно надо запросом? Почему не воспользоваться методами объекта РегистрСведенийМенеджер?Т.е. в модуле "Начисление з/п" сразу получаем Оклад, исходя из Табличной части:
Движение.Размер = Регистрысведений.СведенияОСотрудниках.ПолучитьПоследнее(ТекСтрокаОсновныеНачисления.ДатаНачала, новый структура("Сотрудник",ТекСтрокаОсновныеНачисления.Сотрудник)).Оклад;
Отправлено: alex1248 от Июль 28, 2015, 05:46:22 pm
исходя из Табличной части:Я могу ошибаться, но мне кажется, что получается запрос (неявный) в цикле.
Движение.Размер = Регистрысведений.СведенияОСотрудниках.ПолучитьПоследнее(ТекСтрокаОсновныеНачисления.ДатаНачала, новый структура("Сотрудник",ТекСтрокаОсновныеНачисления.Сотрудник)).Оклад;
Отправлено: tatyana_fiesta от Июль 29, 2015, 08:53:30 am
А как всё таки лучше? ;)исходя из Табличной части:Я могу ошибаться, но мне кажется, что получается запрос (неявный) в цикле.
Движение.Размер = Регистрысведений.СведенияОСотрудниках.ПолучитьПоследнее(ТекСтрокаОсновныеНачисления.ДатаНачала, новый структура("Сотрудник",ТекСтрокаОсновныеНачисления.Сотрудник)).Оклад;
Отправлено: alex1248 от Июль 29, 2015, 09:20:30 am
Лучше без запроса (любого) в цикле. Вы же сами, вроде бы, писали,что у вас было такое замечание.А как всё таки лучше? ;)исходя из Табличной части:Я могу ошибаться, но мне кажется, что получается запрос (неявный) в цикле.
Движение.Размер = Регистрысведений.СведенияОСотрудниках.ПолучитьПоследнее(ТекСтрокаОсновныеНачисления.ДатаНачала, новый структура("Сотрудник",ТекСтрокаОсновныеНачисления.Сотрудник)).Оклад;
А по поводу неявных где-то недавно прочитал, что аналогичное замечание сделали на экзамене за то, что при отборе только товаров из табличной части, содержащей товары и услуги, делали в цикле проверку Если Не Номенклатура.Услуга Тогда...
Так что если цикл неизбежен, и надо обратиться к базе, ИМХО, только запрос (явный или неявный) перед циклом, оптимально - один.
Отправлено: tatyana_fiesta от Июль 29, 2015, 11:11:30 am
В задаче написано "но берется на начало расчетного периода", поэтому я и беру ПериодДействия :)Помогите додумать ;) Не получается адекватно получить Оклад, запрос ниже:Думаю, вместо ПериодДействия следует использовать ПериодДействияНачало (нам же начальный оклад нужен на начало фактического периода, а не расчетного).
А оклад я получал следующим запросом в пакете по уже определенной дате.
И еще, до получения окладов надо к начальному добавить возможные следующие даты изменения оклада в периоде.
Если я в табличной части документа с ПериодомРегистрации "01.03.15" пишу две след.записи Оклада по сотруднику:
10.01.15 - 25.01.15
10.02.15 - 28.02.15
В Регистре расчета получаем:
Период действия Дата начала периода действия Дата окончания периода действия
01.01.2015 0:00:00 10.01.2015 0:00:00 25.01.2015 23:59:59
01.02.2015 0:00:00 10.02.2015 0:00:00 28.02.2015 23:59:59
Как получить Оклады на ПериодДействия?
Неужели ни у кого не возникло проблемы???!!! ??? ведь такое же условие в половине задач =(((
Пожалуйста, дайте текст запроса ;D
Отправлено: alex1248 от Июль 29, 2015, 11:47:42 am
В задаче написано "но берется на начало расчетного периода", поэтому я и беру ПериодДействия :)А еще есть задачи, где оклад не просто меняется, но и берется с учетом этих изменений, почему-то я решил, что вы говорите об этой ситуации.
ОК, выкладываю мой запрос, при условии, что берется на начало периода (только что исправил ошибку, брал на начало фактического периода действия, а вообще пока всего 2 задачи по СПР решил, так что "нюансы" возможны :D) вроде работает правильно.
Но в нем не учтена ситуация, когда на начало расчетного периода оклад не установлен (хотя, на сколько я понял, если в задаче специально не оговорена возможность ситуации, то следует допускать, что данные введены корректно в соответствии с условиями задачи).
Запрос.Текст = "ВЫБРАТЬ
| ОсновныеНачисленияДанныеГрафика.НомерСтроки,
| МАКСИМУМ(ОсновныеНачисленияДанныеГрафика.Сотрудник) КАК Сотрудник,
| МАКСИМУМ(СведенияОСотрудниках.Период) КАК Период
|ПОМЕСТИТЬ ВТ_Период
|ИЗ
| РегистрРасчета.ОсновныеНачисления.ДанныеГрафика(
| Регистратор = &Ссылка
| И ВидРасчета = &ВидРасчета) КАК ОсновныеНачисленияДанныеГрафика
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СведенияОСотрудниках КАК СведенияОСотрудниках
| ПО ОсновныеНачисленияДанныеГрафика.Сотрудник = СведенияОСотрудниках.Сотрудник
| И ОсновныеНачисленияДанныеГрафика.ПериодДействия >= СведенияОСотрудниках.Период
|
|СГРУППИРОВАТЬ ПО
| ОсновныеНачисленияДанныеГрафика.НомерСтроки
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| СведенияОСотрудниках.Оклад,
| ЕСТЬNULL(ОсновныеНачисленияДанныеГрафика.ЗначениеПериодДействия, 0) КАК Норма,
| ОсновныеНачисленияДанныеГрафика.ЗначениеФактическийПериодДействия КАК Факт,
| ВТ_Период.НомерСтроки КАК НомерСтроки
|ИЗ
| ВТ_Период КАК ВТ_Период
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СведенияОСотрудниках КАК СведенияОСотрудниках
| ПО ВТ_Период.Период = СведенияОСотрудниках.Период
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрРасчета.ОсновныеНачисления.ДанныеГрафика(
| Регистратор = &Ссылка
| И ВидРасчета = &ВидРасчета) КАК ОсновныеНачисленияДанныеГрафика
| ПО ВТ_Период.НомерСтроки = ОсновныеНачисленияДанныеГрафика.НомерСтроки";
А дальше распределяю по номерам строк, как у Радченко.
ПС. Убрал в первом запросе ГДЕ, переместил в условие вирт таблицы.
Отправлено: tatyana_fiesta от Июль 29, 2015, 12:23:05 pm
В задаче написано "но берется на начало расчетного периода", поэтому я и беру ПериодДействия :)А еще есть задачи, где оклад не просто меняется, но и берется с учетом этих изменений, почему-то я решил, что вы говорите об этой ситуации.
ОК, выкладываю мой запрос, при условии, что берется на начало периода (только что исправил ошибку, брал на начало фактического периода действия, а вообще пока всего 2 задачи по СПР решил, так что "нюансы" возможны :D) вроде работает правильно.
Но в нем не учтена ситуация, когда на начало расчетного периода оклад не установлен (хотя, на сколько я понял, если в задаче специально не оговорена возможность ситуации, то следует допускать, что данные введены корректно в соответствии с условиями задачи).
Запрос.Текст = "ВЫБРАТЬ
| ОсновныеНачисленияДанныеГрафика.НомерСтроки,
| МАКСИМУМ(ОсновныеНачисленияДанныеГрафика.Сотрудник) КАК Сотрудник,
| МАКСИМУМ(СведенияОСотрудниках.Период) КАК Период
|ПОМЕСТИТЬ ВТ_Период
|ИЗ
| РегистрРасчета.ОсновныеНачисления.ДанныеГрафика(
| Регистратор = &Ссылка
| И ВидРасчета = &ВидРасчета) КАК ОсновныеНачисленияДанныеГрафика
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СведенияОСотрудниках КАК СведенияОСотрудниках
| ПО ОсновныеНачисленияДанныеГрафика.Сотрудник = СведенияОСотрудниках.Сотрудник
| И ОсновныеНачисленияДанныеГрафика.ПериодДействия >= СведенияОСотрудниках.Период
|
|СГРУППИРОВАТЬ ПО
| ОсновныеНачисленияДанныеГрафика.НомерСтроки
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| СведенияОСотрудниках.Оклад,
| ЕСТЬNULL(ОсновныеНачисленияДанныеГрафика.ЗначениеПериодДействия, 0) КАК Норма,
| ОсновныеНачисленияДанныеГрафика.ЗначениеФактическийПериодДействия КАК Факт,
| ВТ_Период.НомерСтроки КАК НомерСтроки
|ИЗ
| ВТ_Период КАК ВТ_Период
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СведенияОСотрудниках КАК СведенияОСотрудниках
| ПО ВТ_Период.Период = СведенияОСотрудниках.Период
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрРасчета.ОсновныеНачисления.ДанныеГрафика(
| Регистратор = &Ссылка
| И ВидРасчета = &ВидРасчета) КАК ОсновныеНачисленияДанныеГрафика
| ПО ВТ_Период.НомерСтроки = ОсновныеНачисленияДанныеГрафика.НомерСтроки";
А дальше распределяю по номерам строк, как у Радченко.
ПС. Убрал в первом запросе ГДЕ, переместил в условие вирт таблицы.
СПАСИБО!!! Теперь всё получилось ;D
Ещё не хватает условия: ВТ_Период.Сотрудник = СведенияОСотрудниках.Сотрудник
А то одно условие по ПО ВТ_Период.Период = СведенияОСотрудниках.Период, не исключает всех сотрудников в данном Периоде ;)
Отправлено: alex1248 от Июль 29, 2015, 12:55:28 pm
Ещё не хватает условия: ВТ_Период.Сотрудник = СведенияОСотрудниках.СотрудникДа, спасибо, видимо, при переделке (менял источники данных) что-то упустил. Тем не менее, не могу понять, почему при 4-х сотрудниках в базе всё работало корректно. Ввел 5-го - выборка оклада стала двоиться с одним из старых.
А то одно условие по ПО ВТ_Период.Период = СведенияОСотрудниках.Период, не исключает всех сотрудников в данном Периоде ;)
Теперь вроде бы всё норм. :)
Отправлено: alex1248 от Июль 29, 2015, 02:31:38 pm
Вот так должно быть лучше :)
Запрос.Текст = "ВЫБРАТЬ
| ОсновныеНачисленияДанныеГрафика.НомерСтроки,
| ОсновныеНачисленияДанныеГрафика.Сотрудник,
| ОсновныеНачисленияДанныеГрафика.ЗначениеПериодДействия,
| ОсновныеНачисленияДанныеГрафика.ЗначениеФактическийПериодДействия,
| МАКСИМУМ(СведенияОСотрудниках.Период) КАК Период
|ПОМЕСТИТЬ ВТ_Период
|ИЗ
| РегистрРасчета.ОсновныеНачисления.ДанныеГрафика КАК ОсновныеНачисленияДанныеГрафика
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СведенияОСотрудниках КАК СведенияОСотрудниках
| ПО ОсновныеНачисленияДанныеГрафика.Сотрудник = СведенияОСотрудниках.Сотрудник
| И ОсновныеНачисленияДанныеГрафика.ПериодДействия >= СведенияОСотрудниках.Период
|ГДЕ
| ОсновныеНачисленияДанныеГрафика.Регистратор.Ссылка = &Ссылка
| И ОсновныеНачисленияДанныеГрафика.ВидРасчета = &ВидРасчета
|
|СГРУППИРОВАТЬ ПО
| ОсновныеНачисленияДанныеГрафика.НомерСтроки,
| ОсновныеНачисленияДанныеГрафика.Сотрудник,
| ОсновныеНачисленияДанныеГрафика.ЗначениеПериодДействия,
| ОсновныеНачисленияДанныеГрафика.ЗначениеФактическийПериодДействия
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ВТ_Период.НомерСтроки КАК НомерСтроки,
| ВТ_Период.ЗначениеПериодДействия КАК Норма,
| ВТ_Период.ЗначениеФактическийПериодДействия КАК Факт,
| СведенияОСотрудниках.Оклад
|ИЗ
| ВТ_Период КАК ВТ_Период
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СведенияОСотрудниках КАК СведенияОСотрудниках
| ПО ВТ_Период.Период = СведенияОСотрудниках.Период
| И ВТ_Период.Сотрудник = СведенияОСотрудниках.Сотрудник";
Отправлено: GROOVY от Июль 29, 2015, 08:04:07 pm
Отправлено: alex1248 от Июль 29, 2015, 08:55:51 pm
Зачем вы это все делаете? Достаточно руками в документ ввести оклады с разными периодами и все.Тогда, чтобы выполнить условие "В информационной базе необходимо хранить историю его изменения" надо будет по каждой записи записывать также данные об окладах в РС? Причем, делать это независимо от того, было фактическое изменение или нет, ведь позже может быть введен документ за ранний период, в котором было изменение, и возврат к прежнему значению уже не отразится в РС. Но тогда это будет не совсем "история изменения". :-\
ПС. Такая формулировка почти во всех задачах из "Сборника актуальных".
Отправлено: tatyana_fiesta от Июль 30, 2015, 09:41:52 am
Зачем вы это все делаете? Достаточно руками в документ ввести оклады с разными периодами и все.Мне, кажется, тогда снимут балы за Упрощение задачи
Отправлено: artemusII от Октябрь 03, 2015, 02:56:03 pm
Отправлено: pila86 от Декабрь 30, 2015, 01:02:42 pm
Отправлено: Odines от Февраль 11, 2016, 09:08:59 pm
Отправлено: Rokky78 от Март 27, 2016, 08:07:12 pm
Отправлено: Odines от Март 27, 2016, 08:14:17 pm
Odines, а зачем нужно перечисление "СпособРасчета" в ПВР?что бы сделать учет зп более универсальным, то есть что бы была возможность добавлять новые виды расчетов. По моему есть такое требование к задачам по периодическим расчетам
Отправлено: Гакусей от Март 27, 2016, 10:55:19 pm
Мое решениеДа вроде нормально, только забыл галочки "Базовое" в измерениях ОН. И ведущие можно было не настраивать, раз в условии не просят сделать перерасчеты.
Отправлено: alfalume от Август 06, 2016, 02:18:48 pm
Отправлено: Novik14 от Ноябрь 08, 2016, 02:30:19 pm
Посоны, я мож переучился, но не пойму, в чем прикол. ...Данные строки в начале процедуры ОбработкаПроведения лишние:
Движения.ОсновныеНачисления.Записывать = Истина;
Движения.ДопНачисления.Записывать = Истина;
Флаг работает при Движения.Записать(), а также учитывается системой после завершения ОбработкиПроведения, в итоге в вашем случае в последний момент записываются движения сформированные первоначально.
При прямом вызове Движения.ОсновныеНачисления.Записать(); данный флаг роли не играет.
Также не забываем про второй параметр при записи набора Набор.Записать(,Истина). Для РР с периодом действия это будет лишний пересчет фактического периода.
Отправлено: xXeNoNx от Март 24, 2017, 07:24:23 pm
Запись не делалась скорее всего потому что схема расчета была такая:
Процедура Расчет(...) экпорт
РассчитатьОН(...., наборзаписей)
КонецПроцедуры
и Наборзаписей записывался в процедуре РассчитатьОН, но так не прокатить, нужно записывать в процедуре Рассчитать, т.е. где получил набор записей, там и записал. Почему так -хз, не разбирался.
Отправлено: Байт от Ноябрь 02, 2017, 10:45:51 am
покритикуйте
А почему не реализована шкала процентов трудового стажа как в задаче? У меня сборник от 2014 года.
Отправлено: ТимТим88 от Февраль 22, 2018, 04:30:21 pm
Зависимость лучше ставить по периоду действия - по периоду регистрации - Удержания.
Премии и.т.п. - зависят от базы - т.е. сумма начислений между БазПерНачало и БазПерКонец по базовым ВР и
умн. на %.
Приоритет нужно ставить чтобы расчет проходил в определенном порядке.
Отправлено: baksan от Июль 02, 2020, 12:18:37 pm
Отправлено: Ильнур1975 от Июль 02, 2020, 12:34:28 pm
Отправлено: baksan от Июль 03, 2020, 07:19:29 am
Это означает что не нужно использовать механизм Сторно. Вытесняющий ВР обязательно нужно указывать в том же расчетном периоде, что и начисление.Спасибо!