Можно ли создать такой вид расчета?

Вопрос задал Наталья С.

Ответственный за ответ: Змиевская Светлана (★9.93/10)

Пожалуйста, подскажите.
Можно ли создать копированием ВР «Оплаты по окладу» новый ВР «Оплата по окладу_ОплачНерабочиеДни», но чтобы этот новый ВР не входил в базу среднего заработка?

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

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

    Я опробовала на демобазе такую настройку. При последующем назначении сотруднику этого начисления и отмены типового оклада, при расчете зп все отражается корректно. И период действия оклада за нерабочие дни исключается из сз и сама сумма начисления.

  2. Да, именно так я все и делала, но перестает работать перерасчет, а хотелось бы корректно пересчитать ЗП за, например, апрель. Я думала, можно изменить настройки вида расчета Групповой обработкой, но не нашла, какие же реквизиты «отвечают» за средний заработок?

    1. Приложение

      «Я думала, можно изменить настройки вида расчета Групповой обработкой, но не нашла, какие же реквизиты «отвечают» за средний заработок?»
      Действительно, можно изменить настройку включения в сз групповой обработкой (реквизит «Входит в учет общего среднего заработка» = Нет, дополнительно нужно подключить режим разработчика, см. скриншот).

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

    2. Извините, попробовала на демобазе и возникли сомнения по поводу самого реквизита. Посмотрю через конфигуратор верное название и отпишусь дополнительно

  3. Это я пробовала, однако не сработало!!!!

    1. Ответила Вам в предыдущем комментарии 🙂 Да, у меня тоже уже как-то были поиски верного реквизита для сз, но уже забыла на какой вышла в итоге. Отпишусь как проверю все

    1. К сожалению, нечем Вас обрадовать. Реквизит мы выбрали верный «Входит в учет общего среднего заработка». Брала для сравнения 2 начисления типовой оклад и оклад за нерабочее время (с назначением «Прочие начисления и выплаты»), сравнивала все настройки через консоль запросов, отличается только этот реквизит (ну и назначение конечно).
      Кстати если поменять значение реквизита «Входит в учет общего среднего заработка» в режиме разработчика, то в консоли запросов видно, что он меняется, а при открытии начисления и расчете зп все равно ведет себя неправильно. Предполагаю, что где-то в коде стоит дополнительно проверка по остальным настройкам и при назначении начисления «Повременная оплата труда и надбавки» для начисление за отработанное время действительно смена настроек сз не срабатывает.

      Давайте попробуем вернуться к типовому варианту оклада за нерабочие дни с назначением «Прочие начисления и выплаты». Я попробовала его назначить сотруднице с 01.04.2020, при этом перерасчет зп за апрель у меня зарегистрировался корректно. Скажите, у Вас с этим проблема? Если да, то сверьте по порядку все настройки типового оклада и оклада за нерабочее время. Должны отличаться только Назначение начисления и настройки сз. И заново попробуйте провести (через отмену проведения) документ изменения оплаты задним числом. Кстати, каким документом пользуетесь?

      И уточните еще, пожалуйста, релиз программы, в которой работаете?

  5. Доброе утро, спасибо за Ваш ответ! Релиз программы — 3.1.13.219. Допускаю, что перерасчет не отрабатывает верно, т.к. вручную заполнены настройки, на закладке «Зависимости» — пара десятков видов начислений (бюджетники, маленький оклад и очень много разных надбавок). Вот из-за этой особенности я и хотела воспользоваться именно копированием: перерасчеты предстоит провести в 18 (может, и более) ИБ, используемых видов расчета Оплата по окладу, с разными модификациями, в каждой 2-3 штуки. То есть настройка потребует много сил и времени.

  6. А сейчас как раз сотрудников активно отправляют в отпуска. Кстати, расчетчик вручную поправила средний для одного из сотрудников, разница сотавила около 40 рублей. В то же время перерасчет ЗП за апрель потребует огромных усилий: отделить работавших от неработавших, работавших несколько дней, работавших через день (!!!!!!), а через день — сидевших дома (это чтобы было поменьше людей и они могли соблюдать социальную дистанцию), на каждого завести документ Изменение оплаты труда (я пользовалась им), а затем опять создать такой документ, чтобы вернуть сотруднику обычное начисление…..

  7. Наверное, разумнее в этой ситуации дождаться решения от 1С, хотя я совсем не уверена, что все описанные мною нюансы 1С удастся «отработать». В то же время назойливое сообщение об этой трагической и непоправимой ошибке очень нервирует расчетчиков, которые и так работают в непростой, даже стрессовой, обстановке.

  8. Сегодня я не смогу еще раз проверить этот свой вариант перерасчета ЗП, т.к. работаю у заказчика за городом, проверю вечером или в выходные. Пожалуйста, пока не закрывайте мой вопрос!

    1. Хорошо, вопрос пока подержу открытым. Отпишитесь, пожалуйста, по результату

  9. Спасибо, сейчас посмотрю!

  10. Спасибо, вопрос можно закрыть.

  11. Перерасчет работает нормально, однако для пересчета ЗП для нескольких сотен сотрудников — слишком трудозатратный путь, увы. Посмотрю, что предложит 1С. Спасибо за помощь!

  12. И вот еще такой момент: перерасчет выполняется, но из расчета среднего исчезает только сумма оклада и дни, соответственно, средний увеличивается. Да уж….

  13. То есть, на период НОД нужно и все надбавки дублировать и для дублей указывать, что они не входят в расчет среднего. Нет, это совсем сложно будет.

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

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

  14. Спасибо! Ваши ответы укрепили мои подозрения, что ситуация ужасна, и, пожалуй, правы те, кто забил на эту рекомендацию, исключить из оплаты среднего, а еще правее те, кто сразу не повелся на оплату НОД(((((

    1. Согласна, что выбор другой методики учета нерабочих дней (сразу как неявки с оплатой по документам-отклонениям: Отсутствие с сохранением оплаты или Простой) был бы сейчас предпочтительнее. Но т.к. уже имеем то, что имеем, то нужно принимать решение или оставлять как есть или все-таки пересчитывать. Я обычно рекомендую взвесить все «за» и «против» пересчета. Попробовать на копии базы пересчитать нескольким людям, сравнить средний. Если разница в копейках, то может и нет смысла в это лезть.

      Но с методолгической точки зрения верно конечно пересчитывать, я обязана сделать на этом акцент 🙂

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