Отправлено: sada от Октябрь 03, 2010, 12:20:53 pm
Вложения:
1Cv8_sada_3_22.dt
Отправлено: SergTH000 от Октябрь 03, 2010, 07:35:18 pm
Как я делал: ОснНачисления - Надбавка, Доп - Оклад, Премия, Удержания - Взносы.
Я норму дней храню в РС. При расчете Надбавки если ЗначениеФактПД - Норма > 0 получаю базу делю на Норму и умножаю на эту разницу.
Все остальное в задаче несколько типовое: вводить свои виды и т.д. Ручную корректировку сделал как у Чистова на вебинаре=) Перерасчет осилил только ОН...=) однообразная задача какая то
Добавлено (03.10.2010, 19:27)
---------------------------------------------
sada, Че то я не понял у тебя как учитывается что за каждый переработанный час сотруднику платят надбавку?
Добавлено (03.10.2010, 19:33)
---------------------------------------------
Ух нифига у тебя мудрено все как для ручной корректировки, посмотри мое решение=) Я обработку проведения документа сделал экспортной, из модуля формы вызвыю ее в тразакции передаю в форму результат и отменяю транзакцию все дела - документ не провелся, результат посчитался=)
Добавлено (03.10.2010, 19:35)
---------------------------------------------
sada, И еще самое точное добавить реквизит типа булево - Корректировка, если он истина данные просто записываются в регистр без расчета.
Вложения:
3.22.dt
Отправлено: sada от Октябрь 03, 2010, 09:42:54 pm
Да, код хороший, такой вариант можно даже быстрее чем за час написать. 5+
В задаче есть такое условие «После проведения расчетов, в том же расчетном периоде размер суммы может быть признан ошибочным и подлежит исправлению.» - я предполагаю, что это намек на то, что при изменения оклада , надо фиксировать перерасчет в текущем периоде.
Почему ты для расчета передаешь только ссылку, а не готовый набор записей, неужели создание нового набора записей и отбора по регистратору работает быстрее, чем передача готового набора?
И еще, такую схему можно применять для задач где приоритет можно разнести на разные планы видов расчета, а если в задаче с ручным вводом видов расчета , необходимо будет выполнить расчет в такой последовательности "основные -> дополнительные -> основные"
в зависимости от способа расчета, прийдется глабально менять схему
Я не реализовывал механизм по расчету сверхурочных часов. Как отразить переработку в системе, если все работают по графику. Мне не понятен этот момент, вот недоработку можно отразить уменьшением количества дней работы в месяце, а переработку как? Накручивать не хочется, по этому я просто ввел количество часов переработки в документ, и от него рассчитывал переработку.
Посмотрел той вариант по переработке, думаю он правильный.
Отправлено: SergTH000 от Октябрь 03, 2010, 10:14:31 pm
Quote
Почему ты для расчета передаешь только ссылку, а не готовый набор записей, неужели создание нового набора записей и отбора по регистратору работает быстрее, чем передача готового набора?
Честно, не знаю=) мне кажется, что также. Просто я набил руку, у меня такой код на автомате идеь и не хочу ее сбивать. Только из-за скрости.
Quote
Я не реализовывал механизм по расчету сверхурочных часов. Как отразить переработку в системе, если все работают по графику. Мне не понятен этот момент, вот недоработку можно отразить уменьшением количества дней работы в месяце, а переработку как? Накручивать не хочется, по этому я просто ввел количество часов переработки в документ, и от него рассчитывал переработку.
Я думаю что расчетчик сам корректирует график. Например Бельдыев отработал в среду не 8 как предполагалось а 12 расчетчик залез и исправил. На этом мое решение и основывается, фактический период действия как раз то что сотрудник реально отработал. Или может ему норму установят поменьше и получится что он переработает всегда сколько то часов
Quote
В задаче есть такое условие «После проведения расчетов, в том же расчетном периоде размер суммы может быть признан ошибочным и подлежит исправлению.» - я предполагаю, что это намек на то, что при изменения оклада , надо фиксировать перерасчет в текущем периоде.
Да я тоже так подумал: при изменении константы - добавить в перерасчет записи (ну также как мы там из расходной передавали). Да забыл потом=) Я сейчас стараюсь во всех задачах неясности прояснить, завтра сдавать иду=) поэтому бросаю когда уж точно знаю как доделывать=)
Добавлено (03.10.2010, 22:14)
---------------------------------------------
Quote
Да, код хороший, такой вариант можно даже быстрее чем за час написать. 5+
Спасибо=) Но идея с корректировкой не моя, взял у Чистова=)
Отправлено: sada от Октябрь 03, 2010, 10:25:01 pm
Quote (SergTH000)
Я думаю что расчетчик сам корректирует график. Например Бельдыев отработал в среду не 8 как предполагалось а 12 расчетчик залез и исправил. На этом мое решение и основывается, фактический период действия как раз то что сотрудник реально отработал.
Да, но вот только график устанавливается не на сотрудника, а на подразделение, в нем не добавиш часы переработки одного человека.
Но наверное мысль правильная.
Удачи :))) , пиши завтра как и что.. 
Отправлено: SergTH000 от Октябрь 03, 2010, 10:30:42 pm
Отправлено: ut2k5 от Октябрь 05, 2010, 11:52:07 am
Отправлено: hapcher от Октябрь 11, 2010, 04:05:28 pm
Отправлено: sada от Октябрь 12, 2010, 08:58:10 pm
Отправлено: hapcher от Октябрь 13, 2010, 09:57:43 pm
Отправлено: sada от Октябрь 14, 2010, 05:06:23 am
, в этой задаче нет необходимости заполнять реквизиты документа по результатам расчета, по этому после изначального расчета реквизит "размер" будет пустым. А когда необходимо откорректировать записи расчета по этому документу по окладу, мы его открываем и вводим нужное значение, при проведении т.к. реквизит размер не пустой, то уже ничего не считаем по окладу, а берем значение из него.
Отправлено: Zhora_Vlg от Октябрь 18, 2010, 05:57:25 am
Так можно, кто знает?
Вложения:
Zhora_Vlg-3.22.dt
Отправлено: SergTH000 от Октябрь 18, 2010, 05:32:22 pm
Добавлено (18.10.2010, 17:32)
---------------------------------------------
hapcher,
Quote
в чем смысл флажка "Корректировка"? Я ввела два начисления за один РП и теперь в базе две записи с ВР "Оклад фиксированной суммой". Может быть, в данной задаче следует использовать вытеснение или как-то организовать сторнирование предыдущих записей?
В задаче сказано, что пользователь может изменить результат расчета. А как мы узнаем нужно при проведении документа считать или он уже посмотрел расчет и изменил результат?
Там где флаг корректировка стоит, результат записи не расчитывается.
Отправлено: Zhora_Vlg от Октябрь 18, 2010, 05:53:19 pm
Quote (SergTH000)
Нет, так нельзя=) Получаешь наборы записей кот нужно пересчитать и через общий модуль перерасчитываешь.
Ты так думаешь, или где то об этом написано?
Отправлено: sada от Октябрь 18, 2010, 06:55:42 pm
чем более что этот документ может еще какие нибудь записи для переасчета зарегистрирует, уже по другим сотрудникам, и вновь прийдется перезаполнять обработку и чтото перепроводить, так цепочку долго раскручивать прийдется
Отправлено: hapcher от Октябрь 18, 2010, 10:03:12 pm
Quote (SergTH000)
А как мы узнаем нужно при проведении документа считать или он уже посмотрел расчет и изменил результат?
Там где флаг корректировка стоит, результат записи не расчитывается.
Там где флаг корректировка стоит, результат записи не расчитывается.
SergTH000, твоя логика ясна.
Но кроме этого решения, можно пойти другим путем: сделать как в ЗУПе, т.е. не рассчитывать записи при проведении, а только по кнопке "Рассчитать". Лично меня условия задачи наталкивают именно на этот способ реализации.
Отправлено: SergTH000 от Октябрь 19, 2010, 08:28:00 am
sada, Во-первых да, зачем же тогда измерение в объекте перерасчет, если весь документ (объект перерасчета) будет перепроводится.
Не только в этом дело. При проведении документа сначала выполняется заново запись его движений, а зачем? Движения документа не поменялись, поменялась БАЗА расчета, нужно только пересчитать записи, основываясь на тех же движениях.
Добавлено (19.10.2010, 08:19)
---------------------------------------------
Для этого и процедура расчета записей выносится из обработки проведения.
Добавлено (19.10.2010, 08:28)
---------------------------------------------
hapcher, Наверное можно и так.Есть только один момент, если запись вручную отредактирована пользователем, то она не должна попадать в перерасчет. Смысла нет. По какому алгоритму пользователь что-то там наменял? А при твоем подходе эти записи будут не различимы и все попадут в перерасчет. Или попадать, но как то сообщить, что она вручную скорректирована.Хотя может это и неважно, не знаю.
Я, повторюсь, что эту идею взял из вебинаров Чистова и мне понравилось, трудно здесь придраться к чему-то=)
Отправлено: Slimper от Июль 20, 2011, 01:19:22 pm
-фикс оклад
-надбавка от всех начислений за прошлый месяц
-премия процентом от всех начислений за текущий период
-удержание процентом от всех начислений за текущий период
получается у каждого вида расчета, кроме оклада, ведущие виды расчета - все остальные? Зациклится же
Отправлено: Gyd от Сентябрь 12, 2011, 05:19:30 pm
Quote (Slimper)
получается у каждого вида расчета, кроме оклада, ведущие виды расчета - все остальные?
Оклад - ведущий для Надбавки (если в прошлом месяце он изменялся). Оклад, Надбавка, Премия - ведущие для Премии, если изменялись в прошлом месяце. Оклад, Надбавка, Премия - ведущие для Профвзносов, если менялись в этом месяце.
Добавлено (12.09.2011, 17:19)
---------------------------------------------
Понравился вариант SergTH000, но на мой взгляд не совсем правильно реализован перерасчет:
перерассчитываются только записи по перерасчету РР Основные начисления (так как остальных в обработке нет, видимо с точки зрения экономии времени), перерасчет идет по всем документу целиком, а не по нужным записям.
Транзакция при расчете из формы документа тоже непонятно зачем, документ итак не проводится. Графики неправильно заполнены, нужно по подразделениям графики вести и соответственно связь измерения с графиком реализовать.
Часы отработанные сверх нормы я сделал вводом вручную, а рабочие часы накапливаю на ресурсе, потом получаю по нему базу. Это конечно посложнее чем у SergTH000.
Отправлено: sv_mikh от Январь 15, 2012, 02:20:46 pm
Сначала запутался на условии начисления премии от начислений сделанных В прошлом месяце (надбавка ЗА прошлый месяц). Начал делать 2 РР без периода действия (база по периоду регистрации + база по периоду действия).. Потом заметил допущение "Считать, что все данные вводятся только в пределах одного месяца".
Очень конечно сомнительно уместить решение в час... Чего то наверно не оптимально сделал
Отладка сожрала не мало времени.Вложения:
sv_mikh_03_22.dt
Отправлено: DoctorRoza от Январь 31, 2012, 10:44:09 pm
Скажите, имеются 4 вида расчета .. Вытеснения у них нет. Тогда какие виды расчета нужно определять в ПВР с периодом действия, чтобы получить фактический период действия?
Отправлено: Gyd от Январь 31, 2012, 11:31:41 pm
Quote (DoctorRoza)
Скажите, имеются 4 вида расчета .. Вытеснения у них нет. Тогда какие виды расчета нужно определять в ПВР с периодом действия, чтобы получить фактический период действия?
А зачем нужен фактический период действия?
С периодом действия я бы оклад сделал (фикс.сумма). Чтобы получить рабочие часы.
Отправлено: DoctorRoza от Февраль 01, 2012, 09:58:46 pm
Вложения:
_16_1_37_2_21_3.dt
Отправлено: max_osodoev от Февраль 09, 2012, 09:05:39 am
Вложения:
3.22_max_osodoe.dt
Отправлено: kow1976 от Июнь 18, 2012, 10:49:56 am
Может есть у кого нибудь мысли как их можно посчитать с использованием РР?
Отправлено: kow1976 от Июнь 20, 2012, 05:52:51 am
Спасибо за комментарии и замечания.
Вложения:
3912657.dt
Отправлено: SAV_tlt от Июнь 29, 2012, 12:26:02 pm
РС ГрафикиРаботы - График(тип подразделение), Значение(Часы)
ОснПВР(использует ПД, база по ПД):
- Сверхурочные -> база(ФиксОклад,Премия,Сверхурочные)
---результат = параметр * 0.5 * (база за прошлый месяц / ЧасыПериодДействия(план часы из графика))
ДопПВР(база по ПД):
- Премия -> база(ФиксОклад,Премия ,Сверхурочные)
---результат = процент из регистра / 100 * база за прошлый месяц
- ФиксОклад -> база(ФиксОклад), // обязательно не должно быть ведущих! дабы не получить замкнутый цикл в перерасчетах
---результат = параметр - база;
Удержания(база по ПР):
- Профвзносы -> база(ФиксОклад,Премия,Сверхурочные) - последний приоритет в расчете
---результат = база за этот месяц * 0.1
Всегда в задачках где сомневаетесь, перед тем как приступить накидайте на листочке, полностью всю схему чтобы потом не переделывать
Отправлено: kow1976 от Июнь 29, 2012, 01:02:32 pm
Quote (SAV_tlt)
Всегда в задачках где сомневаетесь, перед тем как приступить накидайте на листочке, полностью всю схему чтобы потом не переделывать
Все равно два раза за бутылкой бегать.
Отправлено: SAV_tlt от Июль 02, 2012, 04:23:25 pm
Отправлено: SAV_tlt от Июль 02, 2012, 04:24:25 pm
Сделал рекурсивную процедуру и в отбор по ВР обязательно каждый раз жестко нужно добавлять Профвзносы, а иначе система не берет их, потому что они находятся в одном регистраторе и при записи наборов по этому регистратору попросту сбрасывается... ну это из-за особенностей конструкции моего варианта... а еще, думаю, нужно проверку делать, чтобы при открытии документа, данные в ТЧ брались из движений, иначе после перерасчета данные будут отличаться
Вложения:
3_22_SAV.dt
Отправлено: magrib от Июль 03, 2012, 06:41:38 pm
Quote (SAV_tlt)
- ФиксОклад -> база(ФиксОклад), // обязательно не должно быть ведущих! дабы не получить замкнутый цикл в перерасчетах
---результат = параметр - база;
---результат = параметр - база;
SAV_tlt - не понятно для чего фиксированному окладу ставить в базовые начисления его же ,
ну и странная формула для расчета результата.
Отправлено: SAV_tlt от Июль 04, 2012, 12:24:49 pm
Quote
в том же расчетном периоде размер суммы может быть признан ошибочным и подлежит исправлению.
Вот например, сделали один документ с начислениями, оклад 20 000, потом оказалось что нужно исправить оклад, делаем другой документ, чтобы зафиксировать факт ошибки, а не исправлять в том же документе и не пере проводить тот документ, там в параметре ставим нужный оклад например 18000 нажимаем расчет(вот тут то и нужно узнать базу) и в результат попадает -2000. Потом еще можно один документ делать например на 22000 нужно исправить, в результат попадет 4000. Вот только если пере проводить (перерасчитывая) первый документ, то нужно и остальные в хронологической порядке...
Ну в общем, я так понимаю это условие.
Отправлено: andrew-ko от Ноябрь 06, 2012, 11:27:13 pm
2. Сверхурочные - осн. нач. по тому же графику что и Оклад, но в параметре "Размер" - указываю количество часов сверху, ДатаНачала - ДатаОкончания - период действия (дни сверхуорчных).
3. Премия процентом - доп. нач., база по периоду регистрации (ПВР) (т.к. "В" периоде).
4. Удержания - ПВР удержания с базой по периоду действия (т.к. "ЗА" период)
Поправьте, пожалуйста, если не прав.
Вложения:
3.22_andrew-ko.dt
Отправлено: @cool@ от Ноябрь 08, 2012, 07:52:39 pm
1) Вводить вручную в качестве параметра для соответствующегоВР в до-ке Нача.Зарпл.
2) Вводить через документ типа табеля фактически отработанные (или уже сверхурочные ) для каждого дня и накапливать в РН (оборотном) хотя про табель в задаче не говорится..наоборот надо методом отклонения
3) Для ВР "Надбавка" создать график почасовой с ресурсами "Норма"-восем записей с знач "1" (если 8 часовой день) остальные "0" и "Переработка" все 24 записи (для одного дня) с значением "1" и указанием интервалов в до-ке Нач.Зарп. отсчитывать факт отработанные часы.. можно для этого ВР отдельный РР с периодичность день чтобы вытащить норму часов как НормаПериодДействия и факт как ПереработкаФактическийПериодДействия
Ну и зависимость от базы от Оклада с него БазаНачислено(деньги) и БазаРабочиеЧасы - для этого Оклад имеет ПД и работает по обычному графику "одна запись на день" периодичность РР месяц... (типа вырыване гландов через опу...)
кто что думает по этому поводу в ЗУПе по моему переработку вводят вруную в спец. док.
Отправлено: NigaStoleMyPlane от Июнь 13, 2013, 04:31:06 pm
Мое решение... не работает одна вещь - Виды расчета из ПВР "Удержания" (ПрофсоюзныеВзносы) не попадают в таблицу перерасчетов. В чем мб дело...
Вложения:
3-22--.dt
Отправлено: 89161008397 от Август 01, 2013, 08:07:33 am
Помогите!!!!!!!!!!!!! с задачей, не могу понять почему в таблицу перерасчета не попадают записи (отчет Перерасчет).
Есть два документа. Если провожу документ за первый месяц должна заполнятся таблица перерасчета. Что не так скажите.
Вложения:
3-22.dt
Отправлено: TuMyP1985 от Сентябрь 06, 2013, 01:01:09 am
Цитата (89161008397)
Всем привет! Помогите!!!!!!!!!!!!! с задачей, не могу понять почему в таблицу перерасчета не попадают записи (отчет Перерасчет).
Мой вариант.
Вложения:
KTT_3_22.dt
Отправлено: TuMyP1985 от Сентябрь 09, 2013, 12:54:02 am
Вложения:
1450382.dt
Отправлено: artfa от Сентябрь 19, 2013, 10:58:44 pm
Вложения:
7370708.dt
Отправлено: fimanich от Ноябрь 03, 2013, 05:00:44 pm
Цитата artfa (
)
)в задаче множество неочевидных сложностей
. Например, у тебя опечатка Для Каждого ТекСтрокаДополнительныеНачисления Из ДополнительныеНачисления Цикл
Должность = РегистрыСведений.СведенияОСотрудниках.ПолучитьПоследнее(НачалоМесяца(ПериодРегистрации),Новый Структура("Подразделение", ТекСтрокаОсновныеНачисления.Подразделение)).Должность;
Цикл по доп. начислениям, а Подразделение из основных начислений берешь, если ТЧ Основные начисления пустая - вылет с синтаксической ошибкой.
Однако больше хотелось бы другое обсудить. Насколько я понял, в процедуре РасчитатьНачисления ты в конце программно создаешь перерасчеты. Скорее всего, это делается, для того, чтобы предусмотреть следующую ситуацию: есть документ за январь, есть премия и профвзнос за февраль. Перепроводим документ за январь. В перерасчет попадет премия, но не попадет профвзнос, т.к. база его в феврале.
В своем решении я, чтобы подобную ситуацию разрешить, в случае перерасчета при записи набора РР параметр ТолькоЗапись устанавливаю в Ложь. То есть предполагаю, что в обработке надо будет несколько раз нажать кнопки Заполнить - Перерасчитать: сначала в перерасчет попадет документ с премией, потом - с профвзносом.
Еще один момент:
в твоем решении в случае перерасчета идет внутренее соединение виртуальной таблицы (например, ДанныеГрафика) с таблицей перерасчета. Однако, более эффективно, на мой взгляд, в случае перерасчета ограничение передавать в параметры виртуальной таблицы.
Прикрепляю свое решение. Критика приветствуется.
Вложения:
fimanich_03_22.dt
Отправлено: artfa от Ноябрь 04, 2013, 05:03:53 pm
2. ты правильно понял.
3. я так делал когда вид расчета завит от самого себя, например премия начисляется от всех начислений (в т.ч. и премии) за предыдущий период, только я еще избавил пользователя от необходимости нажимать кнопку Заполнить, Заполнить отрабатывало сразу после перерасчета.
4. не понял о чем речь.
Вложения:
2890031.dt
Отправлено: fimanich от Ноябрь 04, 2013, 06:29:58 pm
Цитата artfa ()
)4. не понял о чем речь.
1-й вариант: соединение с таблицей перерасчета:
ВЫБРАТЬ
ДанныеГрафика.НомерСтроки,
ЕСТЬNULL(ДанныеГрафика.ЗначениеФактическийПериодДействия, 0) КАК ДнейФакт,
ДанныеГрафика.ВидРасчета.СпособРасчета КАК СпособРасчета
ИЗ
РегистрРасчета.ОсновныеНачисления.ДанныеГрафика(
Регистратор = &Регистратор
И ВидРасчета.СпособРасчета В (&Оклад, &Невыход)) КАК ДанныеГрафика
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрРасчета.ОсновныеНачисления.ПерерасчетОН КАК ПерерасчетОН
ПО ДанныеГрафика.Подразделение = ПерерасчетОН.Подразделение
И ДанныеГрафика.Сотрудник = ПерерасчетОН.Сотрудник
И ДанныеГрафика.Регистратор = ПерерасчетОН.Регистратор
2-й вариант: отбор по таблице перерасчета в параметрах виртуальной таблицы.
ВЫБРАТЬ
ПерерасчетОН.Подразделение,
ПерерасчетОН.Сотрудник
ПОМЕСТИТЬ Перерасчет
ИЗ
РегистрРасчета.ОсновныеНачисления.ПерерасчетОН КАК ПерерасчетОН
ГДЕ
ПерерасчетОН.ОбъектПерерасчета = &Регистратор
И ПерерасчетОН.ВидРасчета = &Сверхурочные
;
////////////////////////////////////////////
ВЫБРАТЬ
ДанныеГрафика.НомерСтроки,
ЕСТЬNULL(ДанныеГрафика.ЗначениеБазовыйПериод, 0) КАК ЧасовБаза,
ЕСТЬNULL(БазаОН.РезультатБаза, 0) + ЕСТЬNULL(БазаДН.РезультатБаза, 0) КАК РезультатБаза
ИЗ
РегистрРасчета.ОсновныеНачисления.ДанныеГрафика(
ВидРасчета = &Сверхурочные
И Регистратор = &Регистратор
И (Подразделение, Сотрудник) В
(ВЫБРАТЬ
Перерасчет.Подразделение,
Перерасчет.Сотрудник
ИЗ
Перерасчет КАК Перерасчет)
) КАК ДанныеГрафика
ЛЕВОЕ СОЕДИНЕНИЕ РегистрРасчета.ОсновныеНачисления.БазаОсновныеНачисления(
&Измерения,
&Измерения,
,
ВидРасчета = &Сверхурочные
И Регистратор = &Регистратор
И (Подразделение, Сотрудник) В
(ВЫБРАТЬ
Перерасчет.Подразделение,
Перерасчет.Сотрудник
ИЗ
Перерасчет КАК Перерасчет)
) КАК БазаОН
ПО ДанныеГрафика.НомерСтроки = БазаОН.НомерСтроки
ЛЕВОЕ СОЕДИНЕНИЕ РегистрРасчета.ОсновныеНачисления.БазаДополнительныеНачисления(
&Измерения,
&Измерения,
,
ВидРасчета = &Сверхурочные
И Регистратор = &Регистратор
И (Подразделение, Сотрудник) В
(ВЫБРАТЬ
Перерасчет.Подразделение,
Перерасчет.Сотрудник
ИЗ
Перерасчет КАК Перерасчет)
) КАК БазаДН
ПО ДанныеГрафика.НомерСтроки = БазаДН.НомерСтроки
2-й вариант вроде как более правильный, т.к. отбор по параметрам виртуальной таблицы, но конечно же, более громоздкий.
Отправлено: artfa от Ноябрь 04, 2013, 08:39:20 pm
но я думаю сдесь выигрыш в скорости будет незначительный, да и создавать такой запрос более проблематично, слишко много будет условий Если Перерасчет Тогда...
Отправлено: Alexander от Декабрь 08, 2013, 03:21:19 pm
А так, спасибо fimanich, ну и всем остальным, включая давно покинувших эту ветку.
Жду не дождусь критики.
Вложения:
Kul_3_22_122_21.dt
Отправлено: IT_PROGRAMMIST от Февраль 16, 2014, 07:16:22 pm
Вложения:
IT_PROGR_22.dt
Отправлено: non1ka от Февраль 23, 2014, 09:36:02 pm
Проблемы с пере расчетами, хотел что бы и в документе производилась модификация результата перерасчета,
Наверное не правильно, нужно было просто изменять движения в регистре.
Но условие задачи странное, если пользователь руками зашел в документ и изменил результат расчета, как действовать при перерасчете, изменять его данные введенные руками и проводить по измененной базе или менять его значения введенные вручную.
Очень долго расставлял в каком месте должен происходить сброс перерасчета, потому что запросы в общем модуле возвращали пустые таблицы.
Ошибка банальная, при формировании Рабочих наборов сбрасывался перерасчет
Кстати ни кто не обратил внимание на то, что фиксированная сумма может быть изменена. (правда по условию задачи она может быть изменена в том же периоде) но это условие может значить что необходимо предусмотреть возможность стробирования прошлой суммы? или этим намекают на один из возможных вариантов появления перерасчета.
Выкладываю свой вариант решения.
Вложения:
3.22_non.dt
Отправлено: korsal от Апрель 03, 2014, 10:59:50 am
Получение информации, хранящейся в информационной базе, (остатков, оборотов, данных базы, данных графика и т.п.) в цикле. Снижение оценки - 2,0 балла.
Отправлено: Leo705 от Май 13, 2014, 11:39:51 am
Мои мысли...:
1. Размер проф. сборов и процент для расчета сверхурочных можно было хранить и в константе, сделал в коде согласно размерам в задаче;
2. Количество сверхурочных вводиться в документе, не вижу смысла городить все остальное;
3. По данному пункту "...После проведения расчетов, в том же расчетном периоде размер суммы может быть признан ошибочным и подлежит исправлению..." сделал, как писали выше, при изменении константы добавляю перерасчет;
4. Как вариант, перерасчет, можно было бы делать не по всему документу, а конкретно по сотрудникам, но лень;
5. Подразделение и должность не стал добавлять в измерения РР и их перерасчеты, а сделал как реквизиты, т.к. в условии ничего не сказано про совместительство, можно было бы сделать РС типа кадровой истории и брать оттуда.
Отправлено: Igor-pn от Май 13, 2014, 08:43:32 pm
Цитата sada ()
)В задаче есть такое условие «После проведения расчетов, в том же расчетном периоде размер суммы может быть признан ошибочным и подлежит исправлению.» - я предполагаю, что это намек на то, что при изменения оклада , надо фиксировать перерасчет в текущем периоде.
Вложения:
1694909.dt
Отправлено: Leo705 от Май 14, 2014, 07:31:58 am
Цитата Igor-pn ()
)можно предположить, что необходимо создать вид расчета "корректировка оклада", который будет вытеснять оклад. Похожее условие есть в 3.24, но там перерасчеты не нужны. Поэтому добавление "корректировки оклада" кажется логичным
Но там указано "...в том же расчетном периоде размер суммы может быть признан ошибочным и подлежит исправлению...", а если Вы будете делать запись в том же расчетном периоде, то есть период регистрации будет одинаков в записях оклада и корректировки оклада, механизм сторнирования не сработает, кстати в Вашем решении в крайнем документе именно это и происходит.
Еще у Вас в решении "ОтчетПоПерерасчетам", а должна быть обработка с функционалом перерасчета.
Код
ВыборкаДетальныеЗаписи.Сбросить();
Код
Если Записываем Тогда
НаборУд.записать(,Истина);
Если Перерасчет Тогда
НаборУД.записать(,,Ложь);
КонецЕсли;
КонецЕсли;
НаборУд.записать(,Истина);
Если Перерасчет Тогда
НаборУД.записать(,,Ложь);
КонецЕсли;
КонецЕсли;
В принципе указывая "НаборУд.записать(,Истина);" фактический период пересчитываться не будет.
Код
Движение.БазовыйПериодКонец = ДобавитьМесяц(ТекСтрокаОсновныеНачисления.ДатаОкончания,-1);
Отправлено: Igor-pn от Май 14, 2014, 01:05:37 pm
Да верно, но есть еще вытеснение. При повторном перепроведении документов текущего периода, в хронологии оно отработает. Этот момент я обрабатываю, и обнуляю программно сумму по окладу в общем модуле расчета(так как она фикси), оставляю сумму только по корректировке. Количество отработанных дней вытесняется автоматически. Иное применение механизмов платформы для реализации этого момента задания в голову не пришло. Формирование сторно-записей можно было не добавлять так как в задании сказано что корректировка происходит только в текущем периоде.
Нашел так же такое мнение - рассчитывать сумму корректировки
http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=579238
По поводу обработки соглашусь, нужно делать как в сказано в задании.
По поводу выборки - уже так привык :), но попробую так как и вы говорите.
Цитата Leo70534952НаборУд.записать(,Истина);
Почему то это этот код не отрабатывал при обработке, равно как НаборУД.записать(,Истина,,Истина); , пришлось дописывать НаборУД.записать(,,Ложь); Этот момент так и не понял.:(
Насчет базового периода ценное замечание, очень благодарен, спасибо!!!
Отправлено: maksonman от Май 21, 2014, 01:22:01 pm
Вложения:
4555766.dt
Отправлено: DimaKV от Январь 26, 2015, 10:38:26 pm
Другое дело, профсоюзные Удержания. Зависят от всех начислений текущего периода, поэтому при изменении какого-либо начисления, удержание должно пересчитаться. Вот здесь и заполняем ведущие виды расчета.
Какие есть мнения по этому вопросу?
Отправлено: rusmosav от Июнь 02, 2015, 04:04:50 pm