Зарплата и управление персоналом КОРП, редакция 3.1 (3.1.14.55).

Открываю регистр расчетов (РР). Наблюдаю картину, при которой сами начисления по БЛ вводятся и указывается график начисления 40 часовая рабочая неделя. Собственно плановый календарь.
Всегда считал, что БЛ оплачивается по календарю всех дней.

Собственно почему это важно. Представим ситуацию со злосчастными доплатами по БЛ до чего-то. Например, на предприятии принято, что таких доплат, например бывает не более чем ХХ дней в календарном году. Или какая-то другая ситуация, но в результате доплата вводится не за тот же период, а за часть периода. Либо за каждый такой период свой размер доплаты и зависит, он например от планового оклада или от какой-то константы по грейду или, или, или - не важно от чего.

Например доплата до 800 рублей в день:
1) БЛ с 10.07.2020 по 12.07.2020 = 1500. Доплата только за один первый день с 10.07.2020 по 10.07.2020 = 0 рублей. А должна была бы быть 300 рублей = 800 рублей в день - доля в базе одного дня = 500 рублей
2) БЛ с 10.07.2020 по 12.07.2020 = 1500. Доплата только за один первый день с 12.07.2020 по 12.07.2020 = 800 рублей. Расчет такой же как и в предыдущем варианте. Какая разница какой день.

При расчете базы учитывается календарь. Получается, если день в базе не рабочий, то база = 0. А если рабочий, то в данном случае база равна всему результату 1500. 10.07.2020 это пятница. 12.07.2020 это воскресение.

На сколько я помню всегда был график такой, по которому производится оплата.

Как это поправить понятно. Тоже безобразно как и в типовой конфигурации не лезть в эти графики, а при получении таблицы дат разбивать ещё на дополнительные части.

P.S.
Цифры у меня другие, но суть та же.

Собственно вопрос.
Какая логика в том что бы график у БЛ указывать не график всех дней?

(1) суббота и воскресенье по больничным тоже оплачиваются. Такого не может быть, чтобы получилось 0 рублей.

(2) Если указать календарь у БЛ не 40 часовой, а календарь все дни, которого в общем случае нет, то будет правильно считать базу. А так не будет.

Завтра в демке свежей посмотрю как считает.

(4) Посмотрел в демке.
Зарплата и управление персоналом КОРП, редакция 3.1 (3.1.14.97)

Ситуация таже самая.
Графика оплаты больничных листов не предусмотрено.

Ввел БЛ с 01.08.2020 по 03.08.2020 (с субботы на понедельник). Оплата БЛ вводится с графиком пятидневки, но оплачивается в количестве дней по всем дням.
Ввел доплату до среднего в двух вариантах:
1) С 01.08.2020 по 01.08.2020 = размеру среднедневного без ограничения, так как база = 0 так как график пятидневка у БЛ стоит, а 01.08.2020 это не рабочая суббота.
2) С 03.08.2020 по 03.08.2020 = среднедневной без ограничения - вся сумма БЛ за период с 01.08.2020 по 03.08.2020, так как график пятидневка и все рабочие дни приходятся на единственный понедельник и в базу попадает вся сумма БЛ.

Т.е. правильного варианта расчета доплаты не существует и не может существовать, так как база рассчитывается по графику оплаты БЛ, а там прописывается пятидневка, которая никакого отношения к оплате БЛ не имеет от слова СОВСЕМ :-)

"Всегда считал, что БЛ оплачивается по календарю всех дней... а там прописывается пятидневка"

Функция КоличествоКалендарныхДнейВДвухГодахФСС() Экспорт
    Возврат 730;
КонецФункции

Функция СреднееКоличествоДнейВМесяцеФСС() Экспорт
    Возврат 730 / 24;
КонецФункции

(6) И при чем тут расчет дней, который используется при расчете среднего заработка для БЛ?
Я же не про расчет саомго среднего, а уже про расчет результата "Оплата БЛ за счет работодателя" и "Оплата БЛ за счет ФСС" в регистре расчетов.

У кого какие мысли по поводу вопроса в (1).
"Какая логика в том что бы график у БЛ указывать не график всех дней?"

А в ответ тишина.....

Нет специалистов по ЗиУП что ли?

Никому видать не интересно из спецов .....
Они же должны быть тут. Или все пропали?

А в ответ тишина...

Как ввести доплату, что бы база по виду расчета "Оплата БЛ (работодатель/ФСС)", учитывалась пропорционально графику оплаты БЛ (все дни) с учетом вытеснения и перерасчетов (прогулы, перерасчеты БЛ и т.д.).

Мне приходит в голову только один вариант - предварительно разбивать БЛ ещё и по периоду действия доплаты и по датам изменения показателей доплаты.
Более правильный вариант указывать график всех дней и не маяться дурью, но не понятно для чего 1С туда плановый график засовывает и на что это повлияет.
Где спецы?

(13) На самом деле, если согласно локального нормативного акта имеется решение, что за дни больничного листа нужно производить доплату, то такая доплата обычно вводится отдельным документом разовых начислений. Сумму самой доплаты рассчитывать можно используя типовой показатель (автоматически пересчитываемый) для дневного среднего заработка.
Если вдруг оказывается, что где-то немного не точно вычислена сумма такой доплаты, то это абсолютно не критично.
Ввод количества оплачиваемых дней без мучений просто вводят вручную при регистрации разового начисления. Автоматизировать выборку числа дней при условии переходящих из месяца в месяц больничных типовыми средствами не получается. Точнее, получится только, если в разные месяцы создаются разные разовые начисления.
И тогда получается вполне логично, что доплата в больничном с какого-то января и по какое-то февраля, к примеру - это доплата январская, относимая в расходы за январь в БУ
и соотв. февральская - за февраль в БУ

Это имеет особый смысл, если больничные зачастую продлеваются и т.д. Заболевший подает свою записку, по ней становится ясно, что больничный больше продлеваться уже не будет и его можно рассчитать и оплатить. И такая доплата по собственноручно заполненной записке является отдельной мотивацией к тому, чтоб своевременно уведомлять расчетный отдел о самом факте попадания ценного специалиста на больничный. А не валяться где-то равнодушно на диване и никак не забивать себе голову, что для расчетов и включения в отчеты нет оснований.

(14) Прочитал - как ответ относится к (0) не понял.
А потом прочитал ещё раз - и опять ничего не понял.

Суть вопроса в (0) заключается в следующем.
Пусть есть некая сумма за день, до которой необходимо доплатить по необходимому графику за некий период. И вычесть из этой суммы уже оплаченную сумму БЛ. Оплаченная сумма БЛ рассчитывается с помощью базы. База рассчитывается пропорционально графику оплаты самого БЛ. Ну так платформа 1С базу рассчитывает - что верно. В графике же оплаты БЛ указан график "Пятидневка 40 часов", не смотря на то, что оплата БЛ производится по календарю всех дней. Календаря всех дней в 3.1 нет.

Собственно вопросы:
* Для чего запихивать график, который к реальному расчету не имеет ничего общего?
* Почему нет в календарях предопределенных графиков: все дни, календарные дни....? А фактические оплаты по ним рассчитываются.
* Как рассчитать правильно базу средствами платформы при неправильном графике в регистре расчетов?

Я нашел пока только два варианта. Один правильный методологически, но не факт что впишется в "религию" ЗиУП 3.1 - завести календарь все дни и указывать его.
Второй вариант - городить огород и разбивать максимально оплаты по БЛ на периоды, которые будут в доплате и показателях доплаты. Что там может быть в теории - да что угодно: оклад, оклад+премия, оклад + стаж, оклад+премия+стаж, средний для отпуска, просто некая сумма действующая по предприятию для тех или иных грейдов и т.д.

(15) Я тоже не понимаю с какой целью ты пытаешься решить такую вот задачу, что в этом топике?

Тебя заботит решение на практике проведения расчетов с персоналом типовыми средствами или ты сам себя уговариваешь, как бы побольше задачек на программирование придумать?

А показатель для Дней в ЗУП уже есть.

(16) Какая задача передо мной стоит - такую и решаю.
Затык в расчете базы доплаты, период которой не совпадает с периодом оплаты БЛ. Доплата вводится не за весь период БЛ, а только за часть. + Зависит от плановых показателей, которые никак не коррелируют с периодом БЛ.

(16) В (0) я привел пример №1, в котором как раз период БЛ три дня, а доплачивать необходимо только за один день.

(17) Когда мне поставили задачу с определением доплаты, то после серии попыток пришлось согласиться с тем, что расчетную базу приходится вычислять заново.

Число дней или период, задается вручную

И вставка в формулу начисления типового показателя одного из подходящих

СреднедневнойЗаработок
СреднечасовойЗаработок
СреднийЗаработокОбщий
СреднийЗаработокФСС

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

И есть еще КалендарныеДни - и там несколько разных

(19) (20) По моему мы говори о разных вещах.
Формула состоит из двух частей. Некая плановая сумма доплаты минус сумма оплаты БЛ.
Пусть я эту плановую сумму доплаты уже нашел и знаю чему она у меня за период равна. Осталось из неё взять сумму оплаты БЛ за этот период и вычесть. Для этого используется база доплаты. В базу доплаты всегда входят все виды расчетов, которые являются оплатами БЛ. Их может быть несколько. Как правило минимум таких видов расчетов два: Оплата БЛл за счет работодателя и оплата БЛ за счет ФСС. Иногда выделяют отдельно оплату за счет ФСС НС и т.д. Т.е. может быть и больше видов начислений, которые входят в базу доплаты.

Так вот размер базы средствами платформы будет рассчитан не верно.
Т.е. запрос из БД вида:

Выбрать
...
ИЗ
    РегистрРасчета.Начисления.БазаНачисления(....)

Вернет полную ерунду.

Я правильно понимаю, что предлагается насовать в доплату всё что есть в оплате в виде показателей и заново рассчитать и сумму доплаты и ту сумму базы БЛ которую необходимо их этой суммы вычесть.
Если это так, то это тоже не верно. Размер оплаты БЛ может быть откорректирован в РР и необходимо брать имеено сумму, которая находится в РР.

В (21) я хоть понятно пояснил или нет?

Да мне изначально все было понятно.
Я уже успел ответить, что серию экспериментов с такими расчетами выполнять приходилось. Результат показал, что с типовыми в этом случае все довольно кисло.

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

ьам даже вручную ничего корректировать не нужно. Достаточно оплачивать больничные, у которых не 100% оплата и сумма СреднедневнойЗаработок оказывается не пригодной для повторного расчета влоб

(23) (24) Спасибо.
Я уж думал что, есть какие-то ещё варианты. Хотя подсознательно понимал, что если они и есть, то противоречат логике работы РР - а это уже само по себе не есть хорошо.
Сами РР тоже не хороши, но уж какие в платформе есть.

У меня у одного складывается впечатление, что разработчики первых конфигураций для 8.0, совсем не общались с разработчиками ЗиК 77. Далее разработчики ЗиУП 3.х совсем не общались с разработчиками 2.5. И т.д. Каждая новая редакция пишется как буд-то только вчера родились. Такой багаж знаний на собственном диске ИТС и сами же их не читают.
А есть же ещё и сторонний багаж знаний. Как решалась данная задача 40, 30, 20 лет назад. Задача по сути же не поменялась. Это всё тот же расчет ЗП. Да появился дополнительный какой-то учет (усложнился НДФЛ), отчетность какая-то новая и т.д. Но это всё фантики. По сути расчет остался расчетом.

(23) "абсолютной метаморфозы 1С-прогов в 1С консов для ЗУП не произойдет" - а есть такая цель?
Если есть, то это изначально утопия как коммунизм. Социализм возможен, а вот коммунизм нет. Аналогия такая же.