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

Вопрос задал Яна Л. (Казань)

Ответственный за ответ: Щелкунова Юлия (★9.81/10)

ЗУП 3.1.14.166. Добрый день! Сотрудник переведен 13.07.2020 в подразделение с районным коэффициентом, равным 1.15. Начисляется премия документом «Премии» за июль в размере 20% 25.08.2020. Необходимо рассчитать РК с премии в межрасчетный период. РК рассчитывается на всю сумму премии, за полный месяц, а не пропорционально за период, отработанный в подразделении с РК.

Метки вопроса: —

Все комментарии (28)

  1. Добрый день! В таких случаях я руками разбиваю премию на две строчки -два периода (в вашем примере с 1 по 12 и с 13 по 31) тогда РК считается верно. Надеюсь, эксперты помогут это автоматизировать

  2. Здравствуйте! К сожалению, автоматизировать расчет РК с такой премии нельзя. Программа учитывает в качестве Периода действие месяц начисления, и считает.,что если мы начисляем премию в Августе. то на всю премию нужно «накинуть» РК.
    Можо разделять начисление вручную: либо разбивать в одном документе на две строки: в одной из строк менять «Период» на Июль 2020 и разбивать сумму вручную. Либо вводить два документа, и ставить разные периоды в шапке документа: с 1 по 12 и с 13 по 31. В этом случае программа автоматически рассчитает суммы обоих документов (НО нужно проверить расчет на нескольких примерах вручную, если система оплаты сложная, не исключены ошибки).

  3. Добрый день! Спасибо за ответы. Я разбираю примеры из записи от 05.08.2020 г., тема «РАСЧЕТ ЗАВИСИМЫХ НАЧИСЛЕНИЙ В МЕЖРАСЧЕТНЫХ ДОКУМЕНТАХ» (https://buhexpert8.ru/1s-zup/nastrojki-vidov-raschetov/nastrojki-formul-i-pokazatelej/raschet-zavisimyh-nachislenij-v-mezhraschetnyh-dokumentah-zup-3-1-11.html#_1) В примере начисляется премия в текущем месяце за текущий месяц, когда был перевод. В случае, когда премия начисляется за прошлый месяц — это не работает? Мы сейчас работаем в версии 3.1.10. Планирую переход на 3.1.14 в октябре. Поэтому решила изучить подробно все «новшества»: что/в каком случае уменьшит ручную работу кадровиков и бухгалтеров после перехода на новую версию. Так как постоянно ожидают автоматизации, порой возмущаются, что ручная работа. Получается все эти механизмы «работают» при определенных условиях. У нас премии есть и текущие- «месяц в месяц» и за прошлые периоды месяц/квартал.

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

  4. запись семинара от 05.08.2020 Тема «РАСШИРЕНИЕ ДОСТУПНЫХ ДАННЫХ О СОТРУДНИКАХ В КАДРОВЫХ ОТЧЕТАХ » — добавить поля по стажу нет возможности…Их просто нет в выборке. Все примеры, предыдущий и этот разбираю на демо-версии 3.1.14.116. Возможно в релизе 3.1.14 разработчики уже и убрали данную возможность? Есть ли смысл тогда изучать все изменения, которые были в разных последующих релизах после 3.1.10? Если окажется что в 3.1.14 уже этого нет/не работает и т.д.?

    1. В отчете «Образования сотрудников» стажи не доступны, а вот в отчете «Штатные сотрудники — да.

  5. Протестировала начисление РК на премию суммой 10 000 руб текущего месяца при тех же условиях, т.е. перевод с 13.07.2020. Рассчитывает действительно часть, настройка о вводе индивид графика не отмечена. Т.е. премия должно рассчитываться «кусочками» исходя из нормы времени по каждому графику (до перевода и после)? В итоге для расчета РК на период после перевода расчетная база-часть премии посчиталась, но я не могу на неё никак выйти.

    1. Можно посмотреть расчетный листок этого месяца? Приложите, пожалуйста! Нужно увидетьна базовые начисления для премии.

  6. Первоначально я брала процентную премию. Но теперь это уже премия суммой 10 000 руб (как в примере в записи от 05.08.2020) и в текущем месяце за текущий месяц, в котором как раз перевод в подразделение с РК.

  7. Я никак не могу выйти на Расчетную базу (часть премии ) для РК

  8. Думала может влияет ещё различные производственный календари: изначально переводила с РФ в РБ (РК=1,15). Сейчас перевод с той же даты 13.07.2020 но в РФ. Расчетная база получилась одинаковой, и в первом случае и во втором, хотя норма времени разная…

  9. Добрый день! Судя по всему, программа рассчитывает расчетную базу как 10000/207 (общее количество рабочих часов в месяце) * 135 (почему 135 не поняла). Табели на теущий расчет не изменились 111 отработанных часов с 13 по 31-е?
    Вы на демо-базе свой пример воспроизводите, могли бы Вы эту базу мне прислать? (отправлю Вам письмо на почту).

  10. Здравствуйте, Яна! Посмотрела Вашу базу.
    В примере Никанорова легко выйти на посчитанную программой расчетную базу: 10000 / 23 * 15 = 6521,73913.
    А вот по Михейцевой поинтересней, потому что помимо прочего у нее меняется и график работы.
    Алгоритм распределения такой: Программа рассчитывает часть премии, которая относится к периоду до перевода пропорционально отработанному времени, а сумму за период после перевода получает вычитанием.
    В графике до перевода Михейцевой 31 рабочий день, отработано 12. Часть за период до перевода: 10000/31*12=3870,96774

    За период после перевода: 10 000-3870,96774=6129,03226.

  11. Здравствуйте, Юлия! Спасибо за ответ. По Никанорову действительно правильно при текущих условиях. Видимо из-за того, что изначально я их обоих переводила с 13.07 но в РБ, там норма дней другая, поэтому я выходила на другую базу премии, а программа показывала эту же…Потом решила
    упростить задачу, и Никанорова перевела в РФ, но в регион с РК, сама же запуталась…Но похоже программа норму берет по РФ, раз база премии в любом случае выходит 6521,73. Эту же базу программа показывала и при варианте перевода Никонорова в подразделение РБ.

    1. Добрый день! Программа берет норму по графику сотрудника, не по производственному календарю. Вы график сотрудника меняли, когда переводили его в РБ?

  12. Добрый день! Да, конечно. При переводе график «садится» из ШР по должности.

  13. База для расчета РК — часть суммы премии не изменилась — 6521,73913. По графику Пятидневка (РБ) норма 22дн/175час: 10 000 / 22 * 14 = 6363,6363

  14. Если по «принципу» как у Михеевой, то действительно получаем вычитанием ту же сумму, так как в первой части июля он работал в регионе РФ. И при двух вариантах перевода в этой части ничего не изменилось. Но мне кажется «вычитанием» — странное решение, но, с другой стороны, именно при таком варианте выйдем на полную сумму премии (базы для расчета РК). Это можно проверить, оформив перевод из региона с РК в регион без РК. Либо с другим значение РК.

    1. Добрый день!
      Да, мы же график меняем на вторую часть месяца. а значит на расчете это не скажется, поскольку расчет происходит только по первой части. а остальное — разница.
      Мы просто переводим из подразделения без РК в подразделение в с РК и расчет базы нам кажется непонятным. Но в обратной ситуации (Перевод с РК на без РК) будет ожидаемый расчет.
      Более «элегантного» решения для расчета части, которая должна войти в расчетную базу, лично я не вижу.

  15. Добрый день, Юлия! Спасибо Вам за ответ. В текущем релизе 3.1.10 у нас в настройках при смене графика работы не с первого числа месяца выбрано «исходя из графиков работы до и после изменения». Поэтому и пытаемся «таким образом применить» норму в расчетах….В ЗУП 3.1.14 такой настройки нет.
    Может это решение и «элегантное», только оно «не озвучено», возникают вопросы «почему не сходится»…И при расчете/проверке применяем норму со дня перевода. Бухгалтеры по расчету зпл именно так проверяют. Т.е. это решение разработчиков «не на поверхности». Вы знаете об этом, согласились с ним. Мне кажется это не совсем правильно по отношению к многочисленным пользователям 1С. Да и в 3.1.5/ 3.1.10 в некоторых случаях при расчете никак не выходили исходя из нормы на СтоимостьДняЧаса. Разница конечно небольшая была, но всё же. Похоже тоже подобный («тайный») алгоритм расчета.

    1. Здравствуйте! в 3.1.14 такая настройка тоже есть, только изменился ее внешний вид: Особенности расчета зарплаты при изменении графика в середине месяца.
      Мне ничего не остается, кроме как согласиться с таким решением разработчиков, поскольку я сама лучшего придумать не могу. 🙂 Если у Вас есть соображения на этот счет, поделитесь!
      Я думаю, мы сделаем публикацию о том, как работает этот механизм в типовой ЗУП.

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

    1. Здравствуйте! Да, обязательно сделаем публикацию!

Комментарии закрыты.