Задача 3.22

[sada]

Мой вариант решения задачи 3.22Вложения:
1Cv8_sada_3_22.dt

[SergTH000]

sada, Ну написал бы хоть как ты понял задачу, а то разбирать решения даже не зная что и зачем не охота как то +)
 Как я делал: ОснНачисления - Надбавка, Доп - Оклад, Премия, Удержания - Взносы.
 Я норму дней храню в РС. При расчете Надбавки если ЗначениеФактПД - Норма > 0 получаю базу делю на Норму и умножаю на эту разницу.
 Все остальное в задаче несколько типовое: вводить свои виды и т.д. Ручную корректировку сделал как у Чистова на вебинаре=) Перерасчет осилил только ОН...=) однообразная задача какая то

Добавлено (03.10.2010, 19:27)
---------------------------------------------
sada, Че то я не понял у тебя как учитывается что за каждый переработанный час сотруднику платят надбавку?

Добавлено (03.10.2010, 19:33)
---------------------------------------------
Ух нифига у тебя мудрено все как для ручной корректировки, посмотри мое решение=) Я обработку проведения документа сделал экспортной, из модуля формы вызвыю ее в тразакции передаю в форму результат и отменяю транзакцию все дела - документ не провелся, результат посчитался=)

Добавлено (03.10.2010, 19:35)
---------------------------------------------
sada, И еще самое точное добавить реквизит типа булево - Корректировка, если он истина данные просто записываются в регистр без расчета.

Вложения:
3.22.dt

[sada]

SergTH000,
 Да, код хороший, такой вариант можно даже быстрее чем за час написать. 5+

В задаче есть такое условие «После проведения расчетов, в том же расчетном периоде размер суммы может быть признан ошибочным и подлежит исправлению.» - я предполагаю, что это намек на то, что при изменения оклада , надо фиксировать перерасчет в текущем периоде.

Почему ты для расчета передаешь только ссылку, а не готовый набор записей, неужели создание нового набора записей и отбора по регистратору работает быстрее, чем передача готового набора?

И еще, такую схему можно применять для задач где приоритет можно разнести на разные планы видов расчета, а если в задаче с ручным вводом видов расчета , необходимо будет выполнить расчет в такой последовательности "основные -> дополнительные -> основные"
 в зависимости от способа расчета, прийдется глабально менять схему

Я не реализовывал механизм по расчету сверхурочных часов. Как отразить переработку в системе, если все работают по графику. Мне не понятен этот момент, вот недоработку можно отразить уменьшением количества дней работы в месяце, а переработку как? Накручивать не хочется, по этому я просто ввел количество часов переработки в документ, и от него рассчитывал переработку.

Посмотрел той вариант по переработке, думаю он правильный.

[SergTH000]

sada,

Quote

Почему ты для расчета передаешь только ссылку, а не готовый набор записей, неужели создание нового набора записей и отбора по регистратору работает быстрее, чем передача готового набора?

 Честно, не знаю=) мне кажется, что также. Просто я набил руку, у меня такой код на автомате идеь и не хочу ее сбивать. Только из-за скрости.
 

Quote

Я не реализовывал механизм по расчету сверхурочных часов. Как отразить переработку в системе, если все работают по графику. Мне не понятен этот момент, вот недоработку можно отразить уменьшением количества дней работы в месяце, а переработку как? Накручивать не хочется, по этому я просто ввел количество часов переработки в документ, и от него рассчитывал переработку.

 Я думаю что расчетчик сам корректирует график. Например Бельдыев отработал в среду не 8 как предполагалось а 12 расчетчик залез и исправил. На этом мое решение и основывается, фактический период действия как раз то что сотрудник реально отработал. Или может ему норму установят поменьше и получится что он переработает всегда сколько то часов
 

Quote

В задаче есть такое условие «После проведения расчетов, в том же расчетном периоде размер суммы может быть признан ошибочным и подлежит исправлению.» - я предполагаю, что это намек на то, что при изменения оклада , надо фиксировать перерасчет в текущем периоде.

 Да я тоже так подумал: при изменении константы - добавить в перерасчет записи (ну также как мы там из расходной передавали). Да забыл потом=) Я сейчас стараюсь во всех задачах неясности прояснить, завтра сдавать иду=) поэтому бросаю когда уж точно знаю как доделывать=)

Добавлено (03.10.2010, 22:14)
 ---------------------------------------------
 

Quote

Да, код хороший, такой вариант можно даже быстрее чем за час написать. 5+

 Спасибо=) Но идея с корректировкой не моя, взял у Чистова=)

[sada]

Quote (SergTH000)

Я думаю что расчетчик сам корректирует график. Например Бельдыев отработал в среду не 8 как предполагалось а 12 расчетчик залез и исправил. На этом мое решение и основывается, фактический период действия как раз то что сотрудник реально отработал.

 Да, но вот только график устанавливается не на сотрудника, а на подразделение, в нем не добавиш часы переработки одного человека.
 Но наверное мысль правильная.

Удачи ) , пиши завтра как и что..

[SergTH000]

sada, Спасибо, обязательно напишу=)

[ut2k5]

SergTH000, ага мне тоже интересно, удачи на экзамене, скоро и мы там будем

[hapcher]

SergTH000, в чем смысл флажка "Корректировка"? Я ввела два начисления за один РП и теперь в базе две записи с ВР "Оклад фиксированной суммой". Может быть, в данной задаче следует использовать вытеснение или как-то организовать сторнирование предыдущих записей?

[sada]

hapcher, думаю можно просто в документе условие наложить (провеку на заполненность реквизита "Размер") только по окладу, если размер установлен, то не расчитываем а берем из реквизита а если не установлен то расчитваем , т.е. после расчета если что то не понравилось по окладу, заходим в документ и введя нужную цифру переповодим его.

[hapcher]

А чем для данной задачи не подходит такой вариант: рассчитываем документ, проводим (без расчета), когда захотим откорректировать, опять заходим в этот документ и просто меняем сумму, затем проводим? Насколько я правильно поняла, нам вовсе не обязательно хранить информацию о том, что какая-то запись была откорректирована, нам просто необходимо менять сумму начисления без расчета.

[sada]

hapcher, Я думаю, мы об одном и том же говорим , в этой задаче нет необходимости заполнять реквизиты документа по результатам расчета, по этому после изначального расчета реквизит "размер" будет пустым. А когда необходимо откорректировать записи расчета по этому документу по окладу, мы его открываем и вводим нужное значение, при проведении т.к. реквизит размер не пустой, то уже ничего не считаем по окладу, а берем значение из него.

[Zhora_Vlg]

Выполнение перерасчета сделал простым перепроведением объектов перерасчета.
 Так можно, кто знает?Вложения:
Zhora_Vlg-3.22.dt

[SergTH000]

Zhora_Vlg, Нет, так нельзя=) Получаешь наборы записей кот нужно пересчитать и через общий модуль перерасчитываешь.

Добавлено (18.10.2010, 17:32)
 ---------------------------------------------
 hapcher,

Quote

в чем смысл флажка "Корректировка"? Я ввела два начисления за один РП и теперь в базе две записи с ВР "Оклад фиксированной суммой". Может быть, в данной задаче следует использовать вытеснение или как-то организовать сторнирование предыдущих записей?

 В задаче сказано, что пользователь может изменить результат расчета. А как мы узнаем нужно при проведении документа считать или он уже посмотрел расчет и изменил результат?
 Там где флаг корректировка стоит, результат записи не расчитывается.

[Zhora_Vlg]

Quote (SergTH000)

Нет, так нельзя=) Получаешь наборы записей кот нужно пересчитать и через общий модуль перерасчитываешь.

 Ты так думаешь, или где то об этом написано?

[sada]

Zhora_Vlg, Назначение механизма перерасчета определить конкретные записи которые необходимо пересчитать, зачем перерасчитывать весь документ , ради 1, 2... записей.
 чем более что этот документ может еще какие нибудь записи для переасчета зарегистрирует, уже по другим сотрудникам, и вновь прийдется перезаполнять обработку и чтото перепроводить, так цепочку долго раскручивать прийдется

[hapcher]

Quote (SergTH000)

А как мы узнаем нужно при проведении документа считать или он уже посмотрел расчет и изменил результат?
 Там где флаг корректировка стоит, результат записи не расчитывается.
 

SergTH000, твоя логика ясна.
 Но кроме этого решения, можно пойти другим путем: сделать как в ЗУПе, т.е. не рассчитывать записи при проведении, а только по кнопке "Рассчитать". Лично меня условия задачи наталкивают именно на этот способ реализации.

[SergTH000]

Zhora_Vlg, Не знаю где написано, сам додумался=)
 sada, Во-первых да, зачем же тогда измерение в объекте перерасчет, если весь документ (объект перерасчета) будет перепроводится.
 Не только в этом дело. При проведении документа сначала выполняется заново запись его движений, а зачем? Движения документа не поменялись, поменялась БАЗА расчета, нужно только пересчитать записи, основываясь на тех же движениях.

Добавлено (19.10.2010, 08:19)
 ---------------------------------------------
 Для этого и процедура расчета записей выносится из обработки проведения.

Добавлено (19.10.2010, 08:28)
 ---------------------------------------------
 hapcher, Наверное можно и так.Есть только один момент, если запись вручную отредактирована пользователем, то она не должна попадать в перерасчет. Смысла нет. По какому алгоритму пользователь что-то там наменял? А при твоем подходе эти записи будут не различимы и все попадут в перерасчет. Или попадать, но как то сообщить, что она вручную скорректирована.Хотя может это и неважно, не знаю.
 Я, повторюсь, что эту идею взял из вебинаров Чистова и мне понравилось, трудно здесь придраться к чему-то=)

[Slimper]

Начал разбираться в перерасчетах, запутался, в этой задаче есть такие виды расчета:

 -фикс оклад
 -надбавка от всех начислений за прошлый месяц
 -премия процентом от всех начислений за текущий период
 -удержание процентом от всех начислений за текущий период

 получается у каждого вида расчета, кроме оклада, ведущие виды расчета - все остальные? Зациклится же

[Gyd]

Quote (Slimper)

получается у каждого вида расчета, кроме оклада, ведущие виды расчета - все остальные?

 Оклад - ведущий для Надбавки (если в прошлом месяце он изменялся). Оклад, Надбавка, Премия - ведущие для Премии, если изменялись в прошлом месяце. Оклад, Надбавка, Премия - ведущие для Профвзносов, если менялись в этом месяце.

Добавлено (12.09.2011, 17:19)
---------------------------------------------
Понравился вариант SergTH000, но на мой взгляд не совсем правильно реализован перерасчет:
 перерассчитываются только записи по перерасчету РР Основные начисления (так как остальных в обработке нет, видимо с точки зрения экономии времени), перерасчет идет по всем документу целиком, а не по нужным записям.
 Транзакция при расчете из формы документа тоже непонятно зачем, документ итак не проводится. Графики неправильно заполнены, нужно по подразделениям графики вести и соответственно связь измерения с графиком реализовать.

 Часы отработанные сверх нормы я сделал вводом вручную, а рабочие часы накапливаю на ресурсе, потом получаю по нему базу. Это конечно посложнее чем у SergTH000.

[sv_mikh]

Мое решение... Как то вроде не сложная по условию задача... А далась не просто.
 Сначала запутался на условии начисления премии от начислений сделанных В прошлом месяце (надбавка ЗА прошлый месяц). Начал делать 2 РР без периода действия (база по периоду регистрации + база по периоду действия).. Потом заметил допущение "Считать, что все данные вводятся только в пределах одного месяца".
 Очень конечно сомнительно уместить решение в час... Чего то наверно не оптимально сделал Отладка сожрала не мало времени.Вложения:
sv_mikh_03_22.dt

[DoctorRoza]

Внимание вопрос!
 Скажите, имеются 4 вида расчета .. Вытеснения у них нет. Тогда какие виды расчета нужно определять в ПВР с периодом действия, чтобы получить фактический период действия?

[Gyd]

Quote (DoctorRoza)

Скажите, имеются 4 вида расчета .. Вытеснения у них нет. Тогда какие виды расчета нужно определять в ПВР с периодом действия, чтобы получить фактический период действия?

 А зачем нужен фактический период действия?

 С периодом действия я бы оклад сделал (фикс.сумма). Чтобы получить рабочие часы.

[DoctorRoza]

Предлагаю решение задачи 3.22 в рамках Билета 16. Особого изящества в обработке перерасчета нет, но все перерассчитывается, у обоих РР. Корректировку отдельно никак не выношу .. надо корректировать, изменяйте оклад в докумете и будет перерасчет.Вложения:
_16_1_37_2_21_3.dt

[max_osodoev]

моеВложения:
3.22_max_osodoe.dt

[kow1976]

Как-то не подымается рука вносить количество сверхурочных часов в таб. часть документа ЗП. С таким подходом можно заставить пользователя вводить количество рабочих или отработанных дней.

 Может есть у кого нибудь мысли как их можно посчитать с использованием РР?

[kow1976]

Такой вариант решения задачи.
 Спасибо за комментарии и замечания.Вложения:
3912657.dt

[SAV_tlt]

Тут всё просто, но не на первый взгляд конечно)

 РС ГрафикиРаботы - График(тип подразделение), Значение(Часы)

 ОснПВР(использует ПД, база по ПД):
 - Сверхурочные -> база(ФиксОклад,Премия,Сверхурочные)
 ---результат = параметр * 0.5 * (база за прошлый месяц / ЧасыПериодДействия(план часы из графика))
 ДопПВР(база по ПД):
 - Премия -> база(ФиксОклад,Премия ,Сверхурочные)
 ---результат = процент из регистра / 100 * база за прошлый месяц
 - ФиксОклад -> база(ФиксОклад), // обязательно не должно быть ведущих! дабы не получить замкнутый цикл в перерасчетах
 ---результат = параметр - база;
 Удержания(база по ПР):
 - Профвзносы -> база(ФиксОклад,Премия,Сверхурочные) - последний приоритет в расчете
 ---результат = база за этот месяц * 0.1

 Всегда в задачках где сомневаетесь, перед тем как приступить накидайте на листочке, полностью всю схему чтобы потом не переделывать

[kow1976]

SAV_tlt,
 

Quote (SAV_tlt)

Всегда в задачках где сомневаетесь, перед тем как приступить накидайте на листочке, полностью всю схему чтобы потом не переделывать

 Все равно два раза за бутылкой бегать.

[SAV_tlt]

kow1976 ну так то да))

[SAV_tlt]

kow1976 всё таки за бутылкой пришлось бегать из-за перерасчетов)))
 Сделал рекурсивную процедуру и в отбор по ВР обязательно каждый раз жестко нужно добавлять Профвзносы, а иначе система не берет их, потому что они находятся в одном регистраторе и при записи наборов по этому регистратору попросту сбрасывается... ну это из-за особенностей конструкции моего варианта... а еще, думаю, нужно проверку делать, чтобы при открытии документа, данные в ТЧ брались из движений, иначе после перерасчета данные будут отличатьсяВложения:
3_22_SAV.dt

[magrib]

Quote (SAV_tlt)

- ФиксОклад -> база(ФиксОклад), // обязательно не должно быть ведущих! дабы не получить замкнутый цикл в перерасчетах
 ---результат = параметр - база;

 SAV_tlt - не понятно для чего фиксированному окладу ставить в базовые начисления его же ,
 ну и странная формула для расчета результата.

[SAV_tlt]

Из условий:

Quote

в том же расчетном периоде размер суммы может быть признан ошибочным и подлежит исправлению.

 Вот например, сделали один документ с начислениями, оклад 20 000, потом оказалось что нужно исправить оклад, делаем другой документ, чтобы зафиксировать факт ошибки, а не исправлять в том же документе и не пере проводить тот документ, там в параметре ставим нужный оклад например 18000 нажимаем расчет(вот тут то и нужно узнать базу) и в результат попадает -2000. Потом еще можно один документ делать например на 22000 нужно исправить, в результат попадет 4000. Вот только если пере проводить (перерасчитывая) первый документ, то нужно и остальные в хронологической порядке...
 Ну в общем, я так понимаю это условие.

[andrew-ko]

1. Оклад фикс. суммой - осн. нач. для расчета нормы дней.
 2. Сверхурочные - осн. нач. по тому же графику что и Оклад, но в параметре "Размер" - указываю количество часов сверху, ДатаНачала - ДатаОкончания - период действия (дни сверхуорчных).
 3. Премия процентом - доп. нач., база по периоду регистрации (ПВР) (т.к. "В" периоде).
 4. Удержания - ПВР удержания с базой по периоду действия (т.к. "ЗА" период)

 Поправьте, пожалуйста, если не прав.Вложения:
3.22_andrew-ko.dt

[@cool@]

Доброго времени суток. Не могу решить как расчитывать (или накапливать) эти сверхурочные часы. Есть варианты:
 1) Вводить вручную в качестве параметра для соответствующегоВР в до-ке Нача.Зарпл.
 2) Вводить через документ типа табеля фактически отработанные (или уже сверхурочные ) для каждого дня и накапливать в РН (оборотном) хотя про табель в задаче не говорится..наоборот надо методом отклонения
 3) Для ВР "Надбавка" создать график почасовой с ресурсами "Норма"-восем записей с знач "1" (если 8 часовой день) остальные "0" и "Переработка" все 24 записи (для одного дня) с значением "1" и указанием интервалов в до-ке Нач.Зарп. отсчитывать факт отработанные часы.. можно для этого ВР отдельный РР с периодичность день чтобы вытащить норму часов как НормаПериодДействия и факт как ПереработкаФактическийПериодДействия
 Ну и зависимость от базы от Оклада с него БазаНачислено(деньги) и БазаРабочиеЧасы - для этого Оклад имеет ПД и работает по обычному графику "одна запись на день" периодичность РР месяц... (типа вырыване гландов через опу...)
 кто что думает по этому поводу в ЗУПе по моему переработку вводят вруную в спец. док.

[NigaStoleMyPlane]

Приветствую!
 Мое решение... не работает одна вещь - Виды расчета из ПВР "Удержания" (ПрофсоюзныеВзносы)  не попадают в таблицу перерасчетов. В чем мб дело...Вложения:
3-22--.dt

[89161008397]

Всем привет!
 Помогите!!!!!!!!!!!!! с задачей, не могу понять почему в таблицу перерасчета не попадают записи (отчет Перерасчет).
 Есть два документа. Если провожу документ за первый месяц должна заполнятся таблица перерасчета. Что не так скажите.Вложения:
3-22.dt

[TuMyP1985]

Цитата (89161008397)

Всем привет! Помогите!!!!!!!!!!!!! с задачей, не могу понять почему в таблицу перерасчета не попадают записи (отчет Перерасчет).

Не попадают, потому что при проведении документа не заполняются базовый период начало, базовый период конец у ПВР Дополнительные начисления и Удержания.

 Мой вариант.Вложения:
KTT_3_22.dt

[TuMyP1985]

Скорректировал решение - использование подразделение в РС ГрафикиРаботы (вместо реквизита графики в справочнике подразделения).Вложения:
1450382.dt

[artfa]

в задаче множество неочевидных сложностейВложения:
7370708.dt

[fimanich]

Цитата artfa ()

в задаче множество неочевидных сложностей

есть и очевидные . Например, у тебя опечатка
 Для Каждого ТекСтрокаДополнительныеНачисления Из ДополнительныеНачисления Цикл
         Должность = РегистрыСведений.СведенияОСотрудниках.ПолучитьПоследнее(НачалоМесяца(ПериодРегистрации),Новый Структура("Подразделение", ТекСтрокаОсновныеНачисления.Подразделение)).Должность;

 Цикл по доп. начислениям, а Подразделение из основных начислений берешь, если ТЧ Основные начисления пустая - вылет с синтаксической ошибкой.

 Однако больше хотелось бы другое обсудить. Насколько я понял, в процедуре РасчитатьНачисления ты в конце программно создаешь перерасчеты. Скорее всего, это делается, для того, чтобы предусмотреть следующую ситуацию: есть документ за январь, есть премия и профвзнос за февраль. Перепроводим документ за январь. В перерасчет попадет премия, но не попадет профвзнос, т.к. база его в феврале.
 В своем решении я, чтобы подобную ситуацию разрешить, в случае перерасчета при записи набора РР параметр ТолькоЗапись устанавливаю в Ложь. То есть предполагаю, что в обработке надо будет несколько раз нажать кнопки Заполнить - Перерасчитать: сначала в перерасчет попадет документ с премией, потом - с профвзносом.

 Еще один момент:
 в твоем решении в случае перерасчета идет внутренее соединение виртуальной таблицы (например, ДанныеГрафика) с таблицей перерасчета. Однако, более эффективно, на мой взгляд, в случае перерасчета ограничение передавать в параметры виртуальной таблицы.

 Прикрепляю свое решение. Критика приветствуется.Вложения:
fimanich_03_22.dt

[artfa]

1. спасибо исправил.
 2. ты правильно понял.
 3. я так делал когда вид расчета завит от самого себя, например премия начисляется от всех начислений (в т.ч. и премии) за предыдущий период, только я еще избавил пользователя от необходимости нажимать кнопку Заполнить, Заполнить отрабатывало сразу после перерасчета.
 4. не понял о чем речь.Вложения:
2890031.dt

[fimanich]

Цитата artfa ()

4. не понял о чем речь.

Поясню на примере (примеры из 2-х разных задач 3.17 и 3.22, т.е. это не один и тот же запрос в 2-х вариантах).
 1-й вариант: соединение с таблицей перерасчета:
 ВЫБРАТЬ
 ДанныеГрафика.НомерСтроки,
 ЕСТЬNULL(ДанныеГрафика.ЗначениеФактическийПериодДействия, 0) КАК ДнейФакт,
 ДанныеГрафика.ВидРасчета.СпособРасчета КАК СпособРасчета
 ИЗ
 РегистрРасчета.ОсновныеНачисления.ДанныеГрафика(
 Регистратор = &Регистратор
 И ВидРасчета.СпособРасчета В (&Оклад, &Невыход)) КАК ДанныеГрафика
 ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрРасчета.ОсновныеНачисления.ПерерасчетОН КАК ПерерасчетОН
 ПО ДанныеГрафика.Подразделение = ПерерасчетОН.Подразделение
 И ДанныеГрафика.Сотрудник = ПерерасчетОН.Сотрудник
 И    ДанныеГрафика.Регистратор = ПерерасчетОН.Регистратор

 2-й вариант: отбор по таблице перерасчета в параметрах виртуальной таблицы.
 ВЫБРАТЬ
 ПерерасчетОН.Подразделение,
 ПерерасчетОН.Сотрудник
 ПОМЕСТИТЬ Перерасчет
 ИЗ
 РегистрРасчета.ОсновныеНачисления.ПерерасчетОН КАК ПерерасчетОН
 ГДЕ
 ПерерасчетОН.ОбъектПерерасчета = &Регистратор
 И ПерерасчетОН.ВидРасчета = &Сверхурочные
 ;
 ////////////////////////////////////////////
 ВЫБРАТЬ
 ДанныеГрафика.НомерСтроки,
 ЕСТЬNULL(ДанныеГрафика.ЗначениеБазовыйПериод, 0) КАК ЧасовБаза,
 ЕСТЬNULL(БазаОН.РезультатБаза, 0) + ЕСТЬNULL(БазаДН.РезультатБаза, 0) КАК РезультатБаза
 ИЗ
 РегистрРасчета.ОсновныеНачисления.ДанныеГрафика(
 ВидРасчета = &Сверхурочные
 И Регистратор = &Регистратор
 И (Подразделение, Сотрудник) В
 (ВЫБРАТЬ
 Перерасчет.Подразделение,
 Перерасчет.Сотрудник
 ИЗ
 Перерасчет КАК Перерасчет)
 ) КАК ДанныеГрафика
 ЛЕВОЕ СОЕДИНЕНИЕ РегистрРасчета.ОсновныеНачисления.БазаОсновныеНачисления(
 &Измерения,
 &Измерения,
 ,
 ВидРасчета = &Сверхурочные
 И Регистратор = &Регистратор
 И (Подразделение, Сотрудник) В
 (ВЫБРАТЬ
 Перерасчет.Подразделение,
 Перерасчет.Сотрудник
 ИЗ
 Перерасчет КАК Перерасчет)
 ) КАК БазаОН
 ПО ДанныеГрафика.НомерСтроки = БазаОН.НомерСтроки
 ЛЕВОЕ СОЕДИНЕНИЕ РегистрРасчета.ОсновныеНачисления.БазаДополнительныеНачисления(
 &Измерения,
 &Измерения,
 ,
 ВидРасчета = &Сверхурочные
 И Регистратор = &Регистратор
 И (Подразделение, Сотрудник) В
 (ВЫБРАТЬ
 Перерасчет.Подразделение,
 Перерасчет.Сотрудник
 ИЗ
 Перерасчет КАК Перерасчет)
 ) КАК БазаДН
 ПО ДанныеГрафика.НомерСтроки = БазаДН.НомерСтроки

 2-й вариант вроде как более правильный, т.к. отбор по параметрам виртуальной таблицы, но конечно же, более громоздкий.

[artfa]

нужно проверить производительность обоих вариантов,
 но я думаю сдесь выигрыш в скорости будет незначительный, да и создавать такой запрос более проблематично, слишко много будет условий Если Перерасчет Тогда...

[Alexander]

К сожалению, не достаточно быстро пишется всё ещё.
 А так, спасибо fimanich, ну и всем остальным, включая давно покинувших эту ветку.
 Жду не дождусь критики.Вложения:
Kul_3_22_122_21.dt

[IT_PROGRAMMIST]

мой вариант решения. Благодарен за критикуВложения:
IT_PROGR_22.dt

[non1ka]

Решение далось жестко. 2 часа.
 Проблемы с пере расчетами, хотел что бы и в документе производилась модификация результата перерасчета,
 Наверное не правильно, нужно было просто изменять движения в регистре.
 Но условие задачи странное, если пользователь руками зашел в документ и изменил результат расчета, как действовать при перерасчете, изменять его данные введенные руками и проводить по измененной базе или менять его значения введенные вручную.

 Очень долго расставлял в каком месте должен происходить сброс перерасчета, потому что запросы в общем модуле возвращали пустые таблицы.
 Ошибка банальная, при формировании Рабочих наборов сбрасывался перерасчет

 Кстати ни кто не обратил внимание на то, что фиксированная сумма может быть изменена. (правда по условию задачи она может быть изменена в том же периоде) но это условие может значить что необходимо предусмотреть возможность стробирования прошлой суммы? или этим намекают на один из возможных вариантов появления перерасчета.

 Выкладываю свой вариант решения.Вложения:
3.22_non.dt

[korsal]

Заглянул в решения sv_mikh и non1ka. В перерасчетах запрос в цикле.

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

[Leo705]

Наконец-то руки дошли до этой задачи

 Мои мысли...:
 1. Размер проф. сборов и процент для расчета сверхурочных можно было хранить и в константе, сделал в коде согласно размерам в задаче;
 2. Количество сверхурочных вводиться в документе, не вижу смысла городить все остальное;
 3. По данному пункту "...После проведения расчетов, в том же расчетном периоде размер суммы может быть признан ошибочным и подлежит исправлению..." сделал, как писали выше, при изменении константы добавляю перерасчет;
 4. Как вариант, перерасчет, можно было бы делать не по всему документу, а конкретно по сотрудникам, но лень;
 5. Подразделение и должность не стал добавлять в измерения РР и их перерасчеты, а сделал как реквизиты, т.к. в условии ничего не сказано про совместительство, можно было бы сделать РС типа кадровой истории и брать оттуда.

[Igor-pn]

Цитата sada ()

В задаче есть такое условие «После проведения расчетов, в том же расчетном периоде размер суммы может быть признан ошибочным и подлежит исправлению.» - я предполагаю, что это намек на то, что при изменения оклада , надо фиксировать перерасчет в текущем периоде.

Учитывая http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=567332, можно предположить, что необходимо создать вид расчета "корректировка оклада", который будет вытеснять оклад. Похожее условие есть в 3.24, но там перерасчеты не нужны. Поэтому добавление "корректировки оклада" кажется логичным.Вложения:
1694909.dt

[Leo705]

Цитата Igor-pn ()

можно предположить, что необходимо создать вид расчета "корректировка оклада", который будет вытеснять оклад. Похожее условие есть в 3.24, но там перерасчеты не нужны. Поэтому добавление "корректировки оклада" кажется логичным

     Но там указано "...в том же расчетном периоде размер суммы может быть признан ошибочным и подлежит исправлению...", а если Вы будете делать запись в том же расчетном периоде, то есть период регистрации будет одинаков в записях оклада и корректировки оклада, механизм сторнирования не сработает, кстати в Вашем решении в крайнем документе именно это и происходит. 
     Еще у Вас в решении "ОтчетПоПерерасчетам", а должна быть обработка с функционалом перерасчета. 
 

Код

ВыборкаДетальныеЗаписи.Сбросить();

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

Код

Если Записываем Тогда
           НаборУд.записать(,Истина);
           Если Перерасчет Тогда
                  НаборУД.записать(,,Ложь);
           КонецЕсли;
    КонецЕсли;

 В принципе указывая "НаборУд.записать(,Истина);" фактический период пересчитываться не будет.
 

Код

Движение.БазовыйПериодКонец = ДобавитьМесяц(ТекСтрокаОсновныеНачисления.ДатаОкончания,-1);

Не совсем правильно, если Вы добавите к дате: 30.04.2014 23:59:59 -1 месяц, то у Вас получиться дата: 30.03.2014 23:59:59, хотя на сколько я помню в марте 31 день.

[Igor-pn]

...если Вы будете делать запись в том же расчетном периоде, то есть период регистрации будет одинаков в записях оклада и корректировки оклада, механизм сторнирования не сработает, кстати в Вашем решении в крайнем документе именно это и происходит.

 Да верно, но есть еще вытеснение. При повторном перепроведении документов текущего периода, в хронологии оно отработает. Этот момент я обрабатываю, и обнуляю программно сумму по окладу в общем модуле расчета(так как она фикси), оставляю сумму только по корректировке. Количество отработанных дней вытесняется автоматически. Иное применение механизмов платформы для реализации этого момента задания в голову не пришло. Формирование сторно-записей можно было не добавлять так как в задании сказано что корректировка происходит только в текущем периоде.

 Нашел так же такое мнение - рассчитывать сумму корректировки
 http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=579238

 По поводу обработки соглашусь, нужно делать как в сказано в задании.
 По поводу выборки -  уже так привык , но попробую так как и вы говорите.

 Цитата Leo70534952НаборУд.записать(,Истина);
 Почему то это этот код не отрабатывал при обработке, равно как НаборУД.записать(,Истина,,Истина); , пришлось дописывать НаборУД.записать(,,Ложь); Этот момент так и не понял.

 Насчет базового периода ценное замечание, очень благодарен, спасибо!!!

[maksonman]

Интересная задачка. Посмотрите решение. Интересны мненияВложения:
4555766.dt

[DimaKV]

Посмотрел несколько решений. Возник вопрос, зачем в Основных и Дополнительных начислениях указывать ведущие виды расчета? У многих такое увидел. Сверхурочные часы и премия зависят от всех начислений предыдущего расчетного периода. Т.к. данные задним числом не вводятся,  на расчеты текущего периода ничего не влияет. Следовательно, список ведущих расчетов у начислений должен быть пустым.
Другое дело, профсоюзные Удержания. Зависят от всех начислений текущего периода, поэтому при изменении какого-либо начисления, удержание должно пересчитаться. Вот здесь и заполняем ведущие виды расчета.
Какие есть мнения по этому вопросу?

[rusmosav]

Прощу оценить.