Оплата 2/3 за 8 марта

Добрый день

1)РВ из отпуска исключить из БЛ не исключать.

2)Суммы из отпуска исключить из БЛ не исключать.

Чего-то мне сам подход, что доплату за праздничный день вы провели как "простои" не очень нравится. Это же где угодно может сказаться.
Как минимум я бы хотя бы вид другой завел. А раз уж вид другой, то можно в параметрах и символ табеля указать другой и проблем с настройкой расчета среднего нет (это ведь отдельный вид).

p.s. расчет среднего для больничных идет по настройке страховых конечно (но можно настройками добиться чтобы и по столбцу ТВХ шел, но это будет странно).

Спасибо за ответ.

Но уже все посчитали на этот вид, сделали расчет за месяц. Как теперь быть? Перекодировать вид в другой( оставив алгоритм тот же), а как массово букву в табеле заменить, и на какую? В SetSim поставочном расчетчик никакой другой буквы для этой ситуации не нашел.

Это потому что данная доплата не на основании табельного учета делается. Если бы он работал у вас в выходные - тогда нужен символ в табеле и оплата на основании символа.
А в вашем случае лучше сделать так, что РВ будет задаваться при расчете.

// алгоритм имеет 5 параметров
// 1: РВ в днях - 1; РВ в часах - 2
// 2: РВ задается - 0; РВ берется из табеля по символам 'В' для простоя по
// вине работодателя или 'Е' для простоя не по вине работодателя если
// 5-м параметром не определен другой символ
// 3: считать по тарифной ставке - 0; по среднему заработку - 1
// 4: коэффициент расчета простоя (не может быть меньше 2/3)
// 5: символ для обозначения дня простоя в табеле работника

То есть во втором параметре поставить 0.

Да, когда вы заведете новый вид, можно сделать массовую перекодировку. Если вид использованный для доплаты за праздники вы до этого не использовали для расчета простоев.

Добрый день!

Т.е. мы должны завести свой вид с алгоритмом 121, во 2 параметре 0, а что в 5 параметре задавать?

Надо ли у вида заводить дату начала действия и конца?

Как правильно перекодировать вид? 221 вид мы раньше не использовали.

 И можно ли использовать 121 алгоритм, нигде потом это не выйдет нам плохо, или надо свой подобный писать?

Если мы оставим все как есть сейчас,то вопрос:

В поставке в настройке больничного и отпуска символ Е стоит в Символы, не учитываемые в ФРВ(больничный),Дни не включ. в РВ при расчете среднего(отпуск). Так и надо настраивать если оставим Е в табеле? Расчетчики настаивают на Е в табеле на день 8 Марта.(трактуют как простой) и только хотят вид вместо 221 использовать другой.

Я уже не знаю как правильно и по закону.Может кто-то уже оплачивал такие дни(Новый год, 8 Марта),

1) 5 параметр в этом случае не нужен.
2) Даты можете оставить стандартные. Рабочее время все равно же будете ставить вручную.
3) "Сервис" - "Корректировка видов Н-У" - "Массовая перекодировка видов"

4) лучше написать свой алгоритм, но примитивный:
case ХХХ:
   info.kod_alg=121;
   return 3;
Это будет означать "вызови мне системный алгоритм с кодом 121".
Ставить новому виду 121 алгоритм нехорошо, потому что при поиске простоев ищутся виды со 121 алгоритмом.
5) Если расчетчик хотят видеть в табеле особую букву на этом дне, то они могут тогда ответить какое стандартное обозначение из Т12 они готовы увидеть на этом же дне.

Как правильно я уже сказал: за праздничные по ТК сдельщикам положена доплата. Как они рассчитываются (алгоритм получения суммы) - определяет организация. То что вы решили считать это как простой - ваше право. Но зачем вносить данные в табель?! Ну то есть пусть все таки расчетчик попробует сказать, каким стандартным символом (из Т-12 или Т-13) он хочет пометить этот день? "ОВ"? Если ОВ, то требуется оплата в двойном размере.

Спасибо!

Завели новый вид, перекодировали уже 221вид в него. Сейчас считаем по 121, просто уже нет времени ждать, торопят.Могу я потом в апреле поставить новому виду другой алгоритм?

Что касается буквы, уперлись в Е и все, ничего другого пока не хотят. Может позже уговорю без буквы работать. Ведь пока настоящие простои 220 и 221 не появятся, нам они не должны помешать?

Голова уже кругом. Там еще проблемы с графиками примешались, но это тоже потом(там столько специфики открылось). 

Если все рабочие места пользуются одним RSCALT(а значит и SCRIPT) то надо вставить указанные три строчки (подменив ХХХ на ваш номер) в usalg.s в каталоге SCRIPT\USER...
Если рабочих мест много и у каждого свой каталог SCRIPT то есть смысл сделать так:

1. копируем usalg.s из каталога SCRIPT\user в сетевой каталог ZPL\SCRIPT
2. В файле ZPL\SCRIPT\startup.s прописываем текст:
   

  UnloadScriptModule("user\\usalg"); // выгрузить модуль script\user\usalg.s
  LoadScriptModule("ZPL:usalg"); // загрузить модуль ZPL\script\usalg.s 

Все расчетчики получают единые доработанные алгоритмы без необходимости размножать usalg.s по машинам.

Добрый день! Срочно помогите!

После того как ввели новый вид с алгоритмом 121 и все просчитали, новая ошибка!

Те люди у которых есть этот вид и была когда-то материальная выгода по ссуде( давно закрытая) вдруг насчитался налог 345 вид(вид не закрыт).

Для ЛС где присутствует вид 345 налога, сумма по виду хх(оплата 2/3), если он считается по 121 алгоритму облагается по 2 таблице(35%). Но ведь человек может иметь ссуду и у него считается налог 345 видом(кроме 305) и будет простой, то сумма за простой обложится 35% НДФЛ.

Какую настройку мы неправильно сделали?

Не могу откорректировать предыдущее сообщение.

Там неверно я написала. Налог берется не 35%, а так же 13(по первой таблице), но на 345 идет 13% от нашего вида простоя(который вместо 221), а остальное на 305 вид. И если мы наш вид ххх удалим, а введем 221 все считается правильно.

Настройки ТВХ сверили, налоги тоже. В чем секрет? 

345 вид у вас считается по алгоритму 209?

Зайдите в настройку НДФЛ этого алгоритма (Справочники -> 7. Настройка налога на доходы физических лиц -> НДФЛ 35% с выгоды (резиденты) (алг.: 209, символ: Ф))

и уберите код дохода у вида ххх 

Спасибо!

Это мы автоматом разнесли код в налоги при вводе его в ТВХ, и потом проверили все налоги, а 35%(209) забыли, он с 2013 года не обновлялся и его пропустили.

Еще раз СПАСИБО!!