Материалы курса «Подготовка к Аттестации по Платформе 8.2 – Раздел 3, задача 3.04
Это первая задача раздела “Расчетные задачи” – задача 3.04
- Изучите материалы задачи.
- Вопросы, возникшие в ходе изучения этих материалов, задавайте в комментариях на текущей странице. Ответы преподавателя и комментарии других участников будут Вам доступны, только если Вы залогинены и у Вас есть доступ в Мастер-группу.
- Общие вопросы по курсу (в т.ч. организационные) задавайте на стартовой странице.
К сожалению, у Вас недостаточно прав для дальнейшего просмотра.
Если Вы приобрели курс, но еще не активировали токен — пожалуйста, активируйте доступ по инструкциям, высланным на Ваш email после покупки.
Если Вы не залогинены на сайте — залогиньтесь, вернитесь на эту страницу и обновите ее.
Если Вы залогинены, у Вас активирован токен доступа, но Вы все равно видите эту запись — напишите нам на e-mail поддержки.
Комментарии / обсуждение (147):
Комментарии закрыты
Для создания отчета нужно пользоваться физической таблицей РР?
Да
Здравствуйте!
1) Подскажите, пожалуйста, будет ли считаться ошибкой, если сделать вахту в ПВР ОсновныеНачисления. Период действия и базовый периоды будут совпадать. И фразу из задания “…сотрудник может быть отправлен в командировку. В этом случае оплата по окладу И НАДБАВКЕ не происходит.” трактовать как командировка вытесняет и оклад И ВАХТУ?
2) Можно ли вот это “Процент надбавки должен быть определен отдельно для каждого сотрудника. В информационной
базе необходимо хранить историю изменения этого процента” реализовать так: процент руками писать в документе в поле параметр, а при проведении документа записывать этот параметр в нужный регистр сведений?
1. Можно. Да вытесняет.
2. Лучше наоборот, хранить процент в РС, и автоматом писать его в параметр РР.
Добрый день.
Хочу задать вопрос по условию, которое встречается в билетах на экзамене.
“Три дня в неделю (пон.,среда, пятница) по два часа работы приходится на вечерние часы. За каждый час работы в вечернее время сотрудники получают оплату на 50% больше их часовой ставки по окладу”. Каким образом можно решить подобную задачу? Нужно заводить новый вид расчетов – вечерние часы. А каким образом их определять при решении?
Можно предложить завести в графике информацию о том какой размер ставки используется при оплате часа. с 9 до 18 = 1, с 18 до 8 = 1,5. Это ресурс в регистре расчета.
Можно ли получать ВСЕ данные из Док. Начисление запросом и класть во Врем. табл. ДокТЧ и уже обращаться к ней (с использованием Менеджера ВТ) с фильтром по ВР в первом этапе записей наборов?
Спасибо.
Это приведет к реальному созданию таблице на сервере 1С:Предприятия, с последующим ее удалением. Это не то за что начисляют балы.
Насколько плохо вместо конструкции например:
СтруктураПоиска = Новый Структура();
СтруктураПоиска.Вставить(“НомерСтроки”,0);
Выборка = РезультатЗапроса.Выбрать();
Для каждого Запись Из НаборЗаписей Цикл
СтруктураПоиска.НомерСтроки = Запись.НомерСтроки;
Если Выборка.НайтиСледующий(СтруктураПоиска) Тогда
Запись.Сумма = …….;
КонецЕсли;
Выборка.Сбросить();
КонецЦикла;
НаборЗаписей.Записать();
Использовать конструкцию:
Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
НаборЗаписей[(Выборка.НомерСтроки-1)].Сумма= ……;
КонецЦикла;
НаборЗаписей.Записать();
Если запрос упорядочен по номеру строки и строк мало – то ничем.
Не могли бы Вы ответить подробнее почему запрос должен быть упорядочен и строк мало. Или причина в том что обращение к набору записей “тяжелее” чем поиск в выборке?
Если строк много, то на упорядочивание уйдет больше времени, чем на поиск по номеру.
Добрый вечер. Не совсем понятно каким образом в зад. 3.4 реализовать доплату до оклада, если сумма командировки меньше чем сумма оклада.
Получить оклад как базу и сравнить с расчетной частью командировки.
1. объясните для чего получать оклад как базу? в условии сказано “оклада, который МОГ БЫ БЫТЬ начислен”, значит подразумевается сравнение рассчитанного (а не взятого по базе) полного оклада и оклада + командировочные? мне кажется это уточнение введено для случая, например если сотрудник в первый месяц работы едет в командировку и базы за прошлые периоды еще нет. подскажите, какое решение лучше выбрать?
2. что делать если во время командировки у сотрудника изменился оклад? ведь в этом случае расчет оклада, который МОГ БЫ БЫТЬ начислен, будет записан в РР несколькими записями. как в этом случае посчитать доплату до оклада используя расчетные механизмы платформы?
Вы предлагаете формировать записи окладов (по норме) и рассчитывать их перед расчетом командировки? Или сторнировать оклады?
можно например рассчитать оклад без командировки, после сформировать записи по командировке чтобы корректно отработало вытеснение, рассчитать командировку и надбавку (сравнив с окладом). но это сильно усложняет задачу, требует больше времени и боюсь экзаменатор может скинуть баллы за такое “решение”
Павел, скажете пожалуйста, будет ли являться решение которое я описал выше неверным?
Мне видятся подводные камни при перепроведении уже вытесненного оклада и командировки. И при вводе обоих видов расчета одним документом, тогда вытеснение произойдет сразу.
так я и имел в виду ввод одним документом. сначала мы вводим в РР только записи по окладу, записываем, рассчитываем оклад, потом В ЭТОЙ ЖЕ ТРАНЗАКЦИИ вводим записи по командировке, записываем, происходит вытеснение и мы уже рассчитываем все вместе как положено. но благодаря первому расчету у нас есть результат оклада, который мог бы быть начислен без командировки и мы можем эти данные использовать для расчета “доплаты”. в обработке проведения в самом начале очищаем набор записей РР, поэтому при перепроведении все корректно отработает. “подводный камень” который я сейчас увидел — оклад и командировка должны вводиться одним документом, иначе расчет не будет работать.
но по другому не вижу как это условие можно реализовать. если у вас есть идеи, поделитесь пожалуйста
Я об этом же. Если нет единой транзакции, то решение не работает.
1. Мне кажется, задача здесь решена не полностью.
” Если сумма начисленных командировочных, оказывается меньше, чем сумма оклада,
который мог бы быть начислен за дни командировки, тогда сотруднику начисляется доплата до
оклада.”
Тут, мне кажется, надо применять то же, что при расчете оклада – получаем периоды оклада по изменению, по ним считаем командировочные и сравниваем с полученными по базе за те же периоды, выбираем наибольший. Но почему это не решено?
2. Как я понял, надо хранить оклад в документе. А как это делать? Это в решении не описано. Ведь у нас оклад может меняться в промержутке времени. Я полагаю, что надо хранить оклад на начало, оклад на конец и дату изменения. Или на экзамене этим не заморачиваться? Достаточно, что история в регистре сведений?
1. Это не видеозаписи с абсолютным решением всех задач. Если есть вопросы по задачам – я отвечу.
2. Оклады надо хранить в реквизите документа “Параметр”. На дату начисления. В регистре сведений нужно хранить историю. Автоматизировать получение данных из РС не нужно.
Если в начислении зарплаты № 1 в основных начислениях поставить Иванову период действия начало например 10.01.2012 возникает ошибка “Запись не верна! Неверно задан период действия (Регистр расчета: Основные начисления; Номер строки: 1)”
Период действия начало и период действия конец не может быть в разных расчетных периодах.
Здравствуйте. Вопрос по задаче 3.4. Вы говорите о том, что в реквизитах документа должна содержаться вся информация, на основании которой были произведены расчеты, на случай изменения данных в источнике этой информации, например регистре сведений. В данной задаче необходимо получить оклад сотрудника, который может быть изменен в течении месяца. Оклад хранится в регистре сведений и в процессе расчета используются значения из этого регистра сведений. Нужно ли записывать полученные значения оклада из регистра сведений в реквизиты документа?
Приветствую. Я пишу. И в регистр расчета.
Добрый день! Спасибо за ответы.
Иногда в задачах встречается еще такое условие: нужно получить количество рабочих дней за предыдущий период.
Например:
“Больничный. Рассчитывается как количество дней болезни умноженное на среднюю дневную ставку. Средняя дневная ставка = Сумма оклада, начисленного за предыдущий месяц, деленная на количество рабочих ДНЕЙ в том же месяце”.
Как решать такие задачи? Я пока не придумал ничего, кроме как суммировать количество записей- рабочих дней в регистре сведений “Графики”.
Но когда периодов регистрации в документе может быть несколько, в запросе приходится привязывать график и в нем суммировать раб. дни группировкой – это не очень оптимально.
Может просто завести еще один регистр сведений – “Раб.дни в месяце” с периодичностью “Месяц”, измерение – “График”, ресурс – число раб. дней в месяце? Или оборотный регистр накопления?
Количество рабочих дней в том же периоде – это дней в базовом периоде.
Добрый день!
Не совсем понял ответ.
Для расчета базы используем, допустим, таблицу ОсновныеНачисленияБазаОсновныеНачисления.
Но в ней ведь нет поля: “Плановые Рабочие дни Базового периода” – нужны именно плановые дни.
Оклад начислили, допустим, только за 2 недели, отработанных дней 10, но рабочих 21-22 (если по пятидневке). Эти рабочие дни, выходит, только из данных графика можно получить?
Дни берем из данных графика. Если сотрудник отработал 2 недели, в качестве базы все равно берем месяц.
Добрый вечер.
В задачах на СПР иногда есть условие. “В одном документе могут быть данные за разные расчетные периоды”. Не совсем понимаю что с этим надо сделать? Указать в документе НачислениеЗарплаты эти периоды (например периоды действия за прошлый период у соответствующих видов расчетов) и все? или предпринять какие-то действия? Вроде, здесь не говорится, что эти начисления что-то в прошлом вытесняют. Или надо организовать возможность вытеснения в прошлом? Проводить их, как-будто они могут что-то вытеснить (вдруг что-то уже введено), используя сразу метод дополнения?
Как правило, тут нужно будет реализовать сторно записи и приоритеты расчета по периоду.
Здравствуйте!
Тоже интересовал этот вопрос и вопрос, как лучше организовать обход по приоритетам?
Пока видится такой путь:
1. В общем модуле надо все записи набора Основных и Дополнительных начислений выбрать единой таблицей в запросе, сгруппировать записи в итогах по приоритету (периоду регистрации), отсортировать по периоду регистрации.
2. Второй группировкой в итогах сделать Вид регистра (Основные начисления, Дополнительные начисления).
3. Полученную выборку обходить сначала по периоду регистрации (верхний уровень), потом обходить по виду регистра расчета (второй уровень), потом по видам расчета (третий уровень).
Тут код довольно сильно усложняется. Может есть более простой вариант?
Обход по приоритетам не получится, если базу не записывать в регистр и потом не считывать. Одним запросом тут не обойдется, запрос будет в цикле.
Обход результата запроса нужен только по записям, какая разница что рассчитывается, главное, чтобы база уже была получена запросом.
Добрый день!
Хотел уточнить:
А для расчета коммандировки не по периоду ли регистрации нужно делать зависимость?
“Дневная ставка для расчета командировки определяется как
сумма всех начислений за предыдущий месяц, деленная на количество рабочих дней в этом
месяце”.
Правда, проверил – при зависимости по периоду действия в базу начисления попадают и записи, не имеющие периода действия, например, Вахта из ДопНачислений. Выходит, что в данной задаче можно использовать зависимость ОсновныхНачислений как по периоду действия, так и по периоду регистрации?
Добрый.
Тут спорная ситуация.
Записи, естественно, попадают по периоду регистрации если у них нет периода действия.
Добрый вечер.
Хотел бы уточнить. В расчетных задачах существует подзадача, где использован не метод вытеснения, а вручную заполняемый Производственный календарь. Где отмечают рабочие дни и т.д. Вопрос: Корректно ли его данные записывать в РС, а потом получать в момент расчета зарплаты, игнорируя данные, что получаются методом вытеснения. Или данные этого документа могут записываться в РР? Если могут, то подскажите куда смотреть, чтобы их сразу туда записать.
Метод рачета по фактически отработанным дням разбирается в примерах с задачей Табель. Данные табеля вносятся в регистр накопления и при расчете зарплаты берутся от туда. Никаких вытеснений в этих задачах нет и быть не может.
Производственный календарь в таких задачах не используется.
Добрый день.
Спасибо за ответ. Но я, сколько не искал в приведенных в основном блоке и в задачах по Расчетному разделу задачи Табель, но так и не нашел.
Задача с табелем в блоке, который записывал Евгений.
А можно ссылку?
Это архив на странице: http://курсы-по-1с.рф/dev-attestation/startpage/
Название архива: Пакет бонусных задач от проекта Spec8.ru: DevAtt-BonusPack.rar
Добрый вечер.
Возникли следующие вопросы:
В требованиях к аттестации заявлено, что должны учитываться возможности дублей строк (номенклатуры, сотрудников). В документе начисления зарплаты надо ли учитывать этот момент? Если его учитывать, то мне потребуется взять ТЧ и связать ее с собой же (исключить элементы с равенством номеров строк) и там искать: не происходит ли пересечение дат Периода действия начисления с другой записью с таким же видом начисления , если происходит, то сообщать пользователю, что есть ошибка. Нужен ли этот контроль, или он избыточен?
Второй вопрос: По некоторым условиям сказано, что в Табличной части могут быть данные нескольких периодов. В случае с данными у которых есть период действия, можно попробовать поработать с методом ПолучитьДополнение() и осторнировать записи прошлых периодов. В случае, например, с Доп. Начислениями, где нет периодов действия, что лучше предпринять? Вручную сторнировать данные за прошлый период? Например ввести реквизит Сторно в Табличную часть Дополнительных начислений и предположить, что пользователь сначала сам сторнирует запись прошлого периода, а затем вводит правильную?
Добрый время суток.
1. В расчетных механизмах можно этим пренебречь.
2.В доп начислениях нет (как правило) фактического периода действия, и понятие “Сторно” там не применимо.
Здравствуйте!
1. В процедуре “ОбработкаПроведения” для РР получаем набор сторно записей с помощью метода ПолучитьДополнение(). Правильно ли понимаю, что сторно записи есть смысл получить только для РР с установленным свойством “Период действия”?
2. В задачах на СПР часто встречается фраза о том, что оклад (или размер чего-то) может меняться не чаще одного раза в день. При решении задачи нужно ли автоматизировать распределение указанного значения во времени, или можно исходить из того, что пользователь самостоятельно укажет в документе “НачислениеЗарплаты” периды начала и окончания действия размера соответствующего начисления.
Например,
01.01.15 – 15.01.15 оклад 10000
15.01.15 – 31.01.15 оклад 15000
Спасибо.
Приветствую.
1. Да, без периода действия, метод “ПолучитьДополнение” ничего не вернет.
2. Пользователь сам введет несколько строк с окладом в ТЧ документа.
Здравствуйте!
Ситуация воспроизведена в документе “Начисление зарплаты” конфигурации “Подготовка к аттестации 3.9”.
Если у вновь созданного документа нажать кнопку “Записать”, происходит запись документа без проведения. А если нажать эту кнопку в существующем документе, то происходит и перепроведение.
От чего зависит такое поведение?
Если записывать уже проведенный документ, то он будет перепроведен, а не проведенный не будет.
Здравствуйте!
Для первой записи наборов в процедуре “ОбработкаПроведения” модуля документа, используете
Движения.Записать()
вместо
Движения.ОсновныеНачисления(Истина, Ложь).
В синтакс помощнике не нашел указания на то, что в первом варианте происходит расчет факт. периода действия, хотя это происходит.
Это документированная возможность такого способа записи?
Документированная возможность.
Здравствуйте!
Для того, чтобы при записи данных в РР не происходил расчет факт. периода, вы пишете:
Набор.Записать(,,Ложь)
В книге “Профессиональная разработка в системе 1С:Предприятие” для этой цели используют
Набор.Записать(Истина, Истина)
В чем разница?
Судя по описанию в СП – ни в чем.
Здравствуйте!
При решении расчетных задач нужно ли вводить приоритеты для видов расчетов, и проводить расчеты в порядке приоритетов?
Зависит от задачи, если сказано, что могут разные виды расчетов вводится одним документом, то, очевидно, без приоритетов не обойтись.
Уже нашел проблему:)
Здравствуйте. У меня вопрос по задачам третьего раздела.
В задачах используются фразы:
– в том же расчетном периоде;
– в предыдущем же расчетном периоде;
– за тот же период оклада (либо за этот же период оклада);
– в периоде начисления удержания;
– и др.
Как разобраться, понять и запомнить, какую зависимость от базы надо поставить:
– зависит по периоду действия;
– зависит по периоду регистрации.
Приветствую.
Все зависит от задачи.
К примеру, если рассчитывается больничный по среднему, то у него зависимость от базы будет по периоду действия, а если налог на начисления в том же периоде – то по периоду регистрации.
Рекомендую базовый курс по программированию, или книжку “Решение прикладных задач”, на сайте ИТС, можно в деморежиме посмотреть ее бесплатно.
Спасибо за ответ.
Базовый курс уже весь смотрела.
Добрый день!
1. На экзамене можно так же писать “не оптимально”? Я про процедуру расчета записей регистра (копи-паст по черному:)) Все не лепить в один запрос, а делить их на несколько мелких запросов. Можно оптимизацией не заниматься? Можно? а?
2. Вопрос про получение изменений окладов. Можно ли было получать оклады не на начало месяца, а на дату ПериодДейсивмяНачало вида расчета Оклад? Вопрос возник, потому, что: Например, начисляем оклад с 10.01 и нам не важно какой оклад у сотрудника был на 01.01 ибо в период с 01.01 по 09.01 все равно сумма оклада = 0. А вот когда с 10.01. начинает действовать вида расчета Оклад, вот с этой даты и будем учитывать изменения оклада. Верный ход мыслей?
3. Почему в запросе формирования записей в РР сразу не сделали проверку оклада на 0? Тогда в коде лишнее условие можно было бы убрать.
4. Если сотруднику ввести изменение оклада 01.01 и попытаться выполнить расчет, то система сообщит об ошибке “Неверно задан период действия”. Как лучше исправить эту ошибку?
5. Параметры вирт. таблицы “ПлановыеДанныеСотрудниковСрезПоследних”.
Почему не устанавливаем условие в параметрах вирт. таблицы на сотрудников которые только есть в документе начисления, а устанавливаем лишь на период? В этом случае получаем срез данных по всем сотрудникам и только потом за счет условия соединения в результат попадают только нужные сотрудники.
6. Вопрос по расчету записей РР.
Нужно ли хранить норму времени в днях в РР Основных начислений? В приведенном решении она там не хранится. Но ведь для обеспечения надежности решения это нужно сделать? Иначе если пользователь изменит кол-во дней в графике и перепроведет документ, то результат изменится (это касается Оклада). То же касается и Премии. Нужно ли хранить все (или если не все, то какие) показатели в РР для обеспечения устойчивости решения? Как надо поступать на экзамене и в жизни? Спасибо!
Приветствую.
1. Я надеюсь, что Вы понимаете, что мое мнение может не совпасть с мнением экзаменатора. Мне кажется, что время на экзамене один из важных факторов и какой-то оптимизацией можно пренебречь. Но не переусердствуйте в этом, так как если у экзаменатора будут сомнения в оценке он учтет все мелочи.
2. Можно вообще не получать оклад программно, достаточно вручную ввести запись в документ с указанием оклада.
3. См. п.1.
4. См. п.2.
5. Это опять вопрос оптимизации.
6. На сертификации этим можно пренебречь и дни оставить только в РС. В жизни – смотрите типовую, там многие документы имеют заполнение данных для расчета, часть из них пишется в регистр расчета, часть остается в документах для фиксирования показателей на момент ввода.
С этим понятно, спасибо.
1. Возник еще небольшой вопрос (уже думаю над ним очень долго и не могу найти решения): В приведенном решении при расчете командировки не учитывается оклад, который мог бы быть начислен за дни командировки. Вот цитата из задания: “Если сумма начисленных командировочных, оказывается меньше, чем сумма оклада, который мог бы быть начислен за дни командировки, тогда сотруднику начисляется доплата до оклада.”. Вот как при расчете командировки узнать сумму оклада, который мог бы быть начислен причем в текущем рассчитываемом периоде?
2. Еще решил задачу из сборника и как можно передать ее к вам на проверку? Вдруг есть критичные моменты, которые стоит учитывать?
Спасибо!
1. Рассчитать командировку, посчитать оклад (факт дней у нас есть, оклад можно в реквизит записать), сравнить записи.
2. Спасибо не стоит, у меня сейчас “висит” 142 домашки в очной группе.
Тогда изменение оклада в период командировки можно не учитывать? И взять значение оклада на начало командировки – это не будет ошибкой? Или нужно сначала получить изменения оклада в период командировки и рассчитать его (пропорционально периодам изменения оклада получается)?
Или вообще можно значение оклада взять то, которое укажет пользователь в документе Начисления?
Спасибо!
Оклад указывается в документе. Я не могу дать 100% гарантию, но смысла автоматизировать изменение оклада я не вижу.
Оклад мы как раз получаем из регистра сведений. Приведу пример.
Мы получили сумму командировки за период с 15.08 по 20.08 включительно. Из них 4 дня рабочие. Далее нам нужно понять какой оклад мог быть начислен в эти дни. Если бы он не менялся, то проблем бы не было – получили данные за месяц из таблицы “фактический период” и посчитали пропорцию. Но дело в том, что оклад в мог 16.08 поменяться. Как отследить это изменение, мне не понятно.
В документе “Начисление зарплаты”, вручную, вводятся две записи с 01 по 15 с старым окладом, и с 16 по последнее число месяца с новым.
Коллеги , добрый день
прокомментируйте решение по хранению данных об окладах и их изменении по условию данной задачи:
оклад может меняться не более одного раза за период расчета
регистр сведений оклады сотрудников
измерение
сотрудник
ресурсы
оклад
окладДоИзменения
изменили оклад 10 числа, возьмем для периода с 10 по коней месяца показатель оклад , а до 10 показатель окладДоИзменения
А зачем ОкладДоИзменения? Нужно просто 2 записи в регистре делать, одну до изменения, другую – после.
А зачем ОкладДоИзменения? Нужно просто 2 записи в регистре делать, одну до изменения, другую — после. Источник: ©Курсы-по-1С.рф
с этим разобрался , спасибо
второй вопрос
Павел , посмотрите плиз . не будет ли ошибкой запрос на получение даты “период действия конец” для определения даты действия вида расчета при изменении оклада ?
смысл , получаем предыдущую дату до которой действует вид расчета в запросе, что бы не накладывать условия в коде .
===
ВЫБРАТЬ
НачислениеЗарплатыОсновныеНачисления.Сотрудник КАК Сотрудник,
НачислениеЗарплатыОсновныеНачисления.ПериодДействияНачало КАК ПериодДействияНачало,
ОкладыСотрудниковСрезПоследних.Оклад
ПОМЕСТИТЬ ИстрияОкладов
ИЗ
Документ.НачислениеЗарплаты.ОсновныеНачисления КАК НачислениеЗарплатыОсновныеНачисления
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ОкладыСотрудников.СрезПоследних(&НачалоПериода, ) КАК ОкладыСотрудниковСрезПоследних
ПО НачислениеЗарплатыОсновныеНачисления.Сотрудник = ОкладыСотрудниковСрезПоследних.Сотрудник
ГДЕ
НачислениеЗарплатыОсновныеНачисления.Ссылка = &Ссылка
И НачислениеЗарплатыОсновныеНачисления.ВидРасчета = &ВидРасчета
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
ОкладыСотрудников.Сотрудник,
ОкладыСотрудников.Период,
ОкладыСотрудников.Оклад
ИЗ
РегистрСведений.ОкладыСотрудников КАК ОкладыСотрудников
ГДЕ
ОкладыСотрудников.Период МЕЖДУ &НачалоПериода И &КонецПериода
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
НачислениеЗарплатыОсновныеНачисления.ПериодДействияНачало КАК ПериодДействияНачалоВДокументе,
НачислениеЗарплатыОсновныеНачисления.ПериодДействияКонец,
ИстрияОкладов.Сотрудник КАК Сотрудник,
ИстрияОкладов.ПериодДействияНачало КАК ПериодДействияНачалоВИстории,
ИстрияОкладов.Оклад
ПОМЕСТИТЬ ВР
ИЗ
Документ.НачислениеЗарплаты.ОсновныеНачисления КАК НачислениеЗарплатыОсновныеНачисления
ЛЕВОЕ СОЕДИНЕНИЕ ИстрияОкладов КАК ИстрияОкладов
ПО НачислениеЗарплатыОсновныеНачисления.Сотрудник = ИстрияОкладов.Сотрудник
ГДЕ
НачислениеЗарплатыОсновныеНачисления.Ссылка = &Ссылка
И НачислениеЗарплатыОсновныеНачисления.ВидРасчета = &ВидРасчета
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ РАЗЛИЧНЫЕ
ВР.ПериодДействияНачалоВДокументе КАК ПериодДействияНачалоВДокументе,
ВР.ПериодДействияКонец,
ВР.Сотрудник КАК Сотрудник,
ВР.ПериодДействияНачалоВИстории,
ЕСТЬNULL(ВР.Оклад, 0) КАК Оклад,
ЕСТЬNULL(ДОБАВИТЬКДАТЕ(ВР1.ПериодДействияНачалоВИстории, ДЕНЬ, -1), ВР.ПериодДействияКонец) КАК ПериодДействияКонецДляЗаписи
ИЗ
ВР КАК ВР
ЛЕВОЕ СОЕДИНЕНИЕ ВР КАК ВР1
ПО ВР.ПериодДействияНачалоВИстории < ВР1.ПериодДействияНачалоВИстории
И ВР.Сотрудник = ВР1.Сотрудник
УПОРЯДОЧИТЬ ПО
Сотрудник,
ПериодДействияНачалоВДокументе
ИТОГИ ПО
Сотрудник
Не надо этого делать вообще. Просто руками в документе введите две записи.
понятно , спасибо
Добрый день!
При заполнении истории окладов следующим образом:
Иванов 01.04.15 2000р.
Иванов 15.04.15 3000р.
Происходит ошибка при проведении (Запись не верна. Не верно задан период действия)
ПериодДействияНачало = 01.04.15
ПериодДействияКонец = 31.03.15
Вопрос по проведению экзамена: если в литературе, принесённой с собой на экзамен, карандашиком набросать на полях некоторые алгоритмы, чтобы не тратить время на заморочки вроде этой, не будет ли это считаться листингом?
За это выгоняют с экзамена, без разбирательств. Ставят “0”.
И это еще никому не помогало.
Добрый день!
Скажите пожалуйста, почему присваиваем периоду регистрации дату документа, ведь дата документа может быть и первым числом следующего месяца?
Здравствуйте.
Не могу придумать как ответить на этот вопрос.
Показать как присвоить произвольную дату в поле “ПериодРегистрации”?
Показать как поменять дату документа?
Добавить дату периода регистрации в табличную часть?
С чем вопрос связан? Условие задачи мы выполнили.
Добрый день!
При окончательной записи НабораЗаписей ОсновныеНачисления в общем модуле мы не выставляем флаги НаборЗаписей.Записать(Истина, Истина). Второй флаг, в нашем случае, по умолчанию =Ложь, и следовательно при записи будет повторно пересчитываться фактический период действия и ввод записей перерасчетов, что нам уже не требуется. На экзамене это не принципиально?
Приветствую.
На экзамене это принципиально, мне казалось в начальных задачах я об этом говорил.
Павел, добрый день. Хочу уточнить такой момент, очень часто в заданиях встречаются следующие формулировки: “Каждый сотрудник может работать одновременно только в одном подразделении компании, то есть совместительство не допускается.” или “Каждый сотрудник может работать одновременно в нескольких подразделениях компании, то есть совместительство допускается.”. Как эти условия реализовывать в решении? И где можно почитать информацию про связь графика с регистром расчета?
Формулировки не связаны непосредственно с алгоритмами решения.
Связь графиков с регистрами расчета хорошо описана в Профессиональной разработке.
Здравствуйте!
Я прочитал комментарии. И все-таки не понятно, как рассчитывать доплату до оклада. Конечно, хорошо бы рассчитать её как оклад и потом отнять базу по командировке. Только размер оклада у нас может изменяться. Это все сильно усложняет. Получается, что размер оклада при расчете доплаты нужно как-то получать. А что если, за базу взять оклад, рассчитать доплату сразу после расчета окладов (до расчета командировок), а потом, при расчете командировки, находить записи с доплатой и пересчитывать их? Записи с нулевой доплатой нужно будет удалять. Для того, что бы найти нужные записи, набор записей нужно будет каждый раз обходить в цикле, т.к набор записей не имеет методов для поиска записей.
Можно, конечно, предоставить пользователю вводить нужное количество строк с доплатой в документ, а также указывать нужный размер оклада в параметре, базовый период и т.д вручную. Но не знаю, примут ли такое решение.
С уважением,
Антон
Кажется мне удалось найти неплохое решение.
1. 3а базу доплаты до оклада принимаем оклад.
2.При формировании набора движений в модуле документа (до расчета) в записях по командировке вместо вида расчета “командировка” подставляем “доплата до оклада”. Базовый период меняем на период действия.
2. Рассчитываем оклады (предварительно).
3. Рассчитываем доплату (т.е. просто приравниваем её к сумме базы)и снова заменяем вид расчета (возвращаем обратно “командировку”) и базовый период (можно в модуле документа сделать).
4. Записываем набор записей в таком виде.
Теперь у нас и размер предполагаемого оклада есть (в ресурсе записи), и остальные данные выбираются тривиальным образом.
5. Снова вызываем процедуру расчета из документа.
6. Далее, при расчете командировки мы уже можем решить добавлять ли запись по доплате до оклада.
7. Рассчитываем оклады еще раз.
Все довольно просто. Минус – процедуру расчета нужно два раза вызывать.
В принципе, в записях командировки/доплаты можно просто менять местами базовый период и период действия. На первом этапе расчета период действия нам не нужен и мы можем хранить там базовый период командировки. Но оклады все равно пересчитывать нужно будет.
Пришлите мне Ваше решение, я прокомментирую.
Я выложил выгрузку базы с решением на Яндексе. Вот ссылка https://yadi.sk/d/Wg6PwksibtBEa
Приветствую. Не имею возможности посмотреть решение до понедельника. Отвечу позже.
Здравствуйте, Павел. Вопрос не конкретно по этой задаче, а по данному разделу. Если нас в условии стоит “Данные от такого-то начисления (периодичность у него будет Месяц) получаем за предыдущий месяц” какую зависимость по базе нужно выбирать? Ведь подойдет и по периоду регистрации и по Периоду действия?
И еще 1 вопрос. В расчетных задачах встречается уcловие “За каждый день невыхода/прогула начисляется штраф”. Вот здесь как поступать фиксировать сумму в ВР невыход или создать еще 1 ВР Штраф который будет зависеть от невыхода/прогула?
1. Не могу ответить на этот вопрос. Тут надо смотреть конкретно задачу, там обычно все понятно по регистрации или по действию.
2. Штраф берет в качестве базы данные по дням прогула.
Спасибо, буду считать, что если в условии упоминается текущий период – Период регистрации, если за несколько предыдущих месяцев или просто предыдущий – Период действия.
И еще один вопрос – по поводу того, что оклад может изменяться.
В обсуждении вы говорите, что необязательно автоматизировать ввод оклада из регистра сведений, можно просто разбить запись на два периода. То есть то что в решении автоматизирован ввод оклада, это просто будет дополнительный плюсик на экзамене? И если нам не надо плюсиков, то можно не делать этого?
Это редко становится “плюсиком”.
Немного не понял. То есть можно так не делать? Из дальнейшего обсуждения я понял, что можно пренебречь этим.
Точно.
Добрый вечер!
Я слышал, что на экзамене требуется оформлять расчеты так, чтобы пользователь мог вводить новые виды сам, то есть необходимо использовать, например Перечисление – тип расчета. Это так?
И еще в задании указано
“Если сумма начисленных командировочных, оказывается меньше, чем сумма оклада, который мог бы быть начислен за дни командировки, тогда сотруднику начисляется доплата до оклада. Следует учесть, что данные о командировке не могут вводиться в систему задним числом.” Этот момент не нашел отражения в Вашем решении.
Далее в комментариях к задаче:
Решение с изменяющимся окладом можно упростить, если следовать тексту задачи «оклад может быть изменен 1 раз».
Как можно упростить решение?
1. При расчете опираться не на вид расчета, а на перечисление. Если тип = процентом тогда База*Процент и тп.
2. Вопрос не понял.
3. Ввести вручную 2 записи в документ “НачислениеЗарплаты”. Старый и новый оклад.
По п.1 вы лично как рекомендуете делать расчет – не заморачиваясь с перечислениями, или все таки сделать перечисление? Затраты труда небольшие, но я так понял, что излишние усложнения на экзамене не приветствуются?
По п.2 у вас в решении нет вида расчета Доплата до оклада.
Могу предположить, что размер доплаты надо рассчитать, и если он больше 0, тогда добавлять его. Вопрос – можно опираться на то, что пользователь сам введет этот вид расчета, и тогда, если мы его находим в документе, то рассчитываем. Можно автоматически вводить этот вид расчета во все документы начисления, где есть командировка, но тогда он может быть пустым. Можно при расчете добавлять его в документ. Все это усложняет решение и требует дополнительного времени. Как лучше поступить?
1. Сделать обязательно.
2. Пользователь сам введет его. Автоматизировать ввод данных не надо.
Здравствуйте! Павел, подскажите, нужно ли в задачах по СПР накладывать блокировки на регистры?
Нет
Добрый день.
1. Павел, в решении при построении запроса для получения окладов, Вы делаете объединение с физической таблицей РС, получается выбираются все записи, так же те, по которым в ТЧ нету записей. Далее Вы делаете левое соединение табличной части документа к ВТ ИсторияОкладов, получается что не все данные присоединяться( в РС есть запись по сотруднику, а в ТЧ нет такого сотрудника). Получается что ПериодДействияНачало и Конец будут нулы. Это ошибка?
2. Ну и в видео Вы сказали, что алгоритм кривой, и исправлять его не будете. Получается если я на экзамене напишу Ваш алгоритм то он будет ошибочным?
В решении нет необходимости автоматизировать получение окладов из регистра сведений. Достаточно в документе вручную ввести несколько записей с разными окладами.
Логично ;) Там указано просто хранить историю. А по поводу алгоритма, если все работают будут ли докапываться до кода?
Если “косяки” будут, то докопаются до кода. Если нет, то код могут даже и не смотреть.
Мне тоже кажется, что попытка автоматизировать получение оклада из регистра в условиях экзамена есть верная смерть.
Вернее так:
Проблема решается легко, если мы не разрешаем пользователю менять границы периода действия оклада, а также менять само значение оклада внутри расчетного периода.
Сложность проблемы взлетает экспоненциально, если мы позволяем такие вещи как:
– двигать границы периода действия
– менять многократно оклад внутри расчетного периода
– многократно увольнять сотрудника и принимать его обратно на работу (внутри расчетного периода, конечно)
Сложным становится сам дизайн алгоритма. Но еще более сложной становиться задача доказать, что алгоритм будет работать верно на любом наборе данных.
Например в приведенном решении алгоритм задумывался так, чтобы оклад в течение месяца менялся многократно. Но на самом деле это не работает. Попробуйте, скажем, Петрову с начала месяца поменять оклад пару – тройку раз, а потом с середины месяца и до конца начислить ему оклад.
Согласен с тем, что важно почувствовать уровень сложности, с которым можно эффективно справиться в формате экзамена.
Павел, не нашел этого в вашем решении, поэтому хочу уточнить.
Т.к в данной задаче в отчете есть Подразделение, нужно ли добавить его как реквизит Регистров расчета?
И снизят ли мне оценку если я его определю, как измерение данных регистров?
В большинстве задач “Подразделение” некий аппендикс не вписывающийся в логику задачи. Для отчетов думаю достаточно добавить реквизит.
Измерение регистра разрезает базу, если в этом нет необходимости, то создавать измерение смысла нет.
Павел, добрый день. В условии задачи 3.04 сказано: за работу на вахте каждый сотрудник получает надбавку процентом от начисленного оклада. Процент надбавки определен для каждого сотрудника. Необходимо хранить историю изменения этого процента. Могу ли я непосредственно в документе проставлять процент надбавки, а затем при проведении записывать его значение в регистр сведений (для истории), а не наоборот. Не будет ли это считаться ошибкой?
Не принципиально.
Добрый день.
1. Павел, скажите, когда в задаче написано “Все сотрудники работают по графику работы, установленному отдельно для каждого подразделения”, то в этом случае график в регистре расчета (в качестве реквизита) не нужен? Т.е. хватит реквизита Подразделение (или измерения, в зависимости от задачи), связанного с измерением производственного календаря Подразделение?
2. Когда написано “Все сотрудники работают по пятидневному графику работы, однако в решении необходимо предусмотреть возможность работы по нескольким различным графикам”, это значит, что в производственном календаре нужен разрез по типам графиков и реквизит График в регистре расчета, у которого будет связь с графиком?
Здравствуйте. Я очень извиняюсь за ответ, но все же:
Мне кажется Вы не смотрели, или не подробно смотрели видеокурс, в котором неоднократно был дан отчет на этот вопрос.
Предлагаю вам сформировать вопрос более детально: на каком основании вы пришли к выводу, что нужен или не нужен реквизит, и т.п.
“Расчет должен производиться исходя из действующего на рассчитываемую дату начального значения оклада.
Например, если начальное значение оклада изменилось 10 августа, то до 10 августа при расчете берется старое значение, а начиная с 10 августа – новое.”
Нужно ли где-то хранить это значение (Например, в регистре сведений) или просто в документе разбивать строку на 2 и руками вносить размер оклада?
Если в задаче не указано иное, то достаточно разбить запись.
Павел, при решении обнаружил пару моментов.
1. Если сотруднику назначить оклад на начало месяца, то при объединении с РС запись об окладе будет дважды.
2. При объединении порядок строк может быть не последовательный(история будет беспорядочная) тогда при обходе результата запроса ПериодДействияКонец будет иметь некорректную дату.
3. Если у сотрудника изменился оклад 20.01 а он работает по 18.01 то при объединении будут получены некорректные данные и при добавлении записи в регистр возникает критическая ошибка.
1,2, – спасибо. Проверил, есть такой косяк.
3 – “защиту от дурака” я не делал. Не думаю что это повлияет на оценку.
Корень проблемы 1 в неправильном использовании оператора МЕЖДУ.
В данном случае проблема с ним в том, что он цепляет движения на самое начало периода. Поэтому условие:
ГДЕ ОкладыСотрудников.Период МЕЖДУ &НачалоМесяца И &КонецМесяца
нужно заменить на условие:
ГДЕ (ОкладыСотрудников.Период > &НачалоМесяца) И (ОкладыСотрудников.Период <= &КонецМесяца)
Строго больше)))
Добрый день.
Павел возник вопрос по формулировке в задаче 3.03,
“Дополнительно, сотрудникам компании может быть начислена премия процентом от начисленного за тот же период оклада. Процент премии зависит от стажа работы сотрудника на данном предприятии. При решении задачи необходимо учитывать, что на момент начала ведения учета в информационной базе у сотрудника уже может быть стаж отличный от нуля”. Последнее предложение значит что нибудь? Или можно у сотрудника задать реквизит СтажРаботы отличный от нуля?
Я бы в регистре это хранил.
Павел здравствуйте, правильно ли я поняла, что если существует два Измерения в РР: Сотрудник, Подразделение, то их нужно индексировать, причем измерение Сотрудник -базовое?
Ну если это оправдано, то да. Базовое измерение порождает внутренний индекс с таблицей БАЗА других регистров.
Здравствуйте, Павел! Подскажите пожалуйста, как решается задача 3.41 (с документом табель)? Как там реализовать вытеснение Оклада Командировкой и куда записывать отработанное время? Буду очень признателен за ответ. Времени нет совсем, осталась неделя до экзамена. А задачи с Табелями очень часть встречаются на экзамене.
Отработанное время храним в регистре накопления.
Настройка вытеснения классическая. Командировка вытесняет Оклад.
Это понятно. Если отработанное время хранится в регистре накопления, то как работает вытеснение?
В задаче 3.41 на мой взгляд вытеснения нет. Табель пишет данные в регистр накопления. По факту мы сами определяем в какие дни нужно начисления по окладу делать. В конце месяца вводится документ по начислению зарплаты, в котором вид расчета Оклад рассчитывает фактически отработанные запросом к регистру накопления.
Спасибо большое! Я так и решал эту задачу, но сомневался в правильности решени.
Как понимать формулировкуиз данной задачи: “В этом случае оплата по окладу и НАДБАВКЕ не происходит”? Не является ли это указанием на то, что командировка должна вытеснять не только оклад, но и надбавку за вахту? И соответственно надбавка должна иметь период действия(входить в ПВР “ОсновныеНачисления”). Кроме этого формулировка: “Сумма оклада всегда берется только за период начисления надбавки”, по-моему указывает на то, что у надбавки за вахту должен быть выставлен флаг “Период действия является базовым”.
Флаг “Период действия является базовым” просто позволяет не указывать базовый период, и в том случае если он не указан под базовым периодом понимается период действия.
Базой для надбавки является оклад, следовательно если командировка вытеснит оклад то ни оклад ни надбавка не будет рассчитаны.
“…если командировка вытеснит оклад то ни оклад ни надбавка не будет рассчитаны” по-моему это и подразумевает формулировка задачи: “В этом случае оплата по окладу и НАДБАВКЕ не происходит”. У Вас в решении надбавка не вытесняется командировкой.
Относительно “Период действия является базовым”: в случае вытеснения надбавки, например с периодом действия с 10.03 по 25.03, командировкой с периодом действия с 15.03 по 20.03, фактический период действия надбавки распадется на два интервала: с 10.03 по 14.03 и с 21.03 по 25.03. И в этом случае брать базу для надбавки надо брать по этим двум интервалам, а не всему периоду действия, что и позволяет сделать флаг “Период действия является базовым”. Это и будет выполнением условия задачи: “Сумма оклада всегда берется только за период начисления надбавки”.
Если мы набдавку считаем процентом от оклада, который уменьшается при вытеснении, какая разница какой базовый период указан? Оригинальный базовый или базовый с учетом вытеснения? База то уменьшится.
Согласен. То есть указание, что при начислении командировки не происходит начисление надбавки не следует понимать буквально(переносить надбавку в “ОсновныеНачисления” и настраивать вытеснение её командировкой)? Это условие выполняется косвенно, через уменьшение базы надбавки(оклада) при вытеснении оклада командировкой? Правильно?
От задачи конечно зависит, но в контексте обсуждения, да все правильно.
Добрый день. Не могли бы вы записать видео задачи с документом Табель(3.40-3.41) или хотя бы описать как-нибудь решение такой задачи. Эти задачи часто встречаются на экзамене. Хотелось бы знать как решать подобное. Заранее благодарен.
Замечание учту.
Добрый день.Как следует рассматривать фразу в задаче “Если сумма начисленных командировочных, оказывается меньше, чем сумма оклада, который мог бы быть начислен за дни командировки, тогда сотруднику начисляется доплата до оклада.” ? Получается нам всегда нужно рассчитывать оклад и при командировочных тоже? И тогда требуется извлекать историю окладов за этот период и командировочные так же разбивать по этим периодам?
Да, при расчете командировки нужно считать оклад.
Павел, поясните, пожалуйста, как именно следует считать оклад.
на данные каких виртуальных таблиц регистров расчета опираться? Или же получать данные для расчета “возможного оклада” вручную из регистра с графиком работы и значениями окладов – но тогда не будет ли такое решение ошибкой?
Оклад считать как обычно. По данным графика. Отработано / Норма * Оклад.
Но так как у нас командировка сторнирует оклад, именно на эту сумму сторно и можно опираться.
Павел, здравствуйте!
А как получить эту сумму сторно?
Ведь командировка вытесняет оклад, и таблицу дополнения нам не получить?
Со сторно я что-то напутал, задним числом командировку вводить нельзя.
По доплатам до оклада схема такая:
Вводим оклад
Вводим командировку, она вытесняет оклад и рассчитывается.
водим вид расчета “Доплата до оклада”, он в качестве базы получает сумму рассчитанной командировки, а сам рассчитывается как оклад, ну и в сравнении с суммой командировки в результат попадает либо ноль, либо разница, сколько не хватает до оклада.
Прокомментируйте, пожалуйста, чуть подробнее этот алгоритм.
Со вводом оклада и командировки все понятно: записали, рассчитали.
Получили базу командировки, допустим это 10000. Можно даже получить фактический график командировки, например 5 (рабочих) дней.
Каким образом дальше рассчитать Доплату как оклад? Мы можем получить значение графика для периода действия, нам даже известно количество фактических дней – данные графика командировки, но что брать за сумму, если у нас может быть несколько значений оклада в периоде (база командировки ведь рассчитана прошлым месяцем)? Таким же методом, как и с окладом, клонировать строки (если было несколько изменений оклада за период)? Но ведь по факту, нам нужна одна строка с суммой доплаты, а не эти вспомогательные строки, что их удалять потом из набора?
Второй вариант – это при расчете оклада и командировки проверять, соответственно, есть ли за данный период уже записи об командировке или окладе. Если есть, то добавлять соотв. сумма к командировке или новым значением в набор записей. Но выглядит этот вариант как-то уж очень “в лоб”.
Командировка является базой для Доплаты. Доплата считается как оклад, разница между реальным окладом и доплатой и получается результатом расчета.
Когда данные оклада берем из регистра сведений за месяц, его тоже нужно с документом “Начисления зарплаты” связывать? В решении Вы просто данные берете без связи.
Что означает “связывать”? Хранить в документе? В самом документе можно и не хранить. А вот в регистре расчета хранить не помешает.
Не понятно условие
“Расчет должен производиться исходя из действующего на рассчитываемую дату начального значения оклада.
Например, если начальное значение оклада изменилось 10 августа, то до 10 августа при расчете берется старое значение, а начиная с 10 августа – новое.”
Если в январе месяце сотруднику каждый день увеличивали окад, то каждый день рассчитывается сходя из значения актуального оклада на этот день.
и еще вопрос
Если сумма начисленных командировочных, оказывается меньше, чем сумма оклада, который мог бы быть начислен за дни командировки, тогда сотруднику начисляется доплата до оклада
алгоритм : в общем модуле расчет, после получения суммы командировочных рассчитываем сумму возможного оклада за период действия командировки и на разницу добавляем еще одну запись в р.р. “Основные начисления” ? Как то кривовато получается
Можно добавить сумму в результат командировки.
Павел доброе время.
Как понимать фразу : “Следует учесть, что данные о командировке не могут вводиться в систему задним числом.” ? Сторнирование не описывать ?
Совершенно верно. Эта фраза призвана уменьшить трудозатраты на решение задачи.