Задача 3.22

[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]

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