Ваши комментарии
В этом случае, при расчёте БЛ до перехода в следующий месяц, символы О заменяют в табеле символы Р,
но суммы пересчётных видов по этому дню не сторнируются.
Всё сторнируется. Видимо, после расчета БЛ, вы "забываете" сделать окончательный расчёт ЛС.
З.Ы. Наверно, всё-таки, символы "Б", а не "О"?
Законодательством передача расчетных листков сотрудникам через банк предусмотрена
С каких пор возможность получения расчетных листков, реализованная в ЛК СБ, приобрела статус законодательно определенной необходимости?
Если вы разрабатываете программу по заработной плате, то должны предусматривать все возможные нюансы.
Верно. Только если речь идёт о "должны", то в конце фразы не хватает слова "Законодательства". Всё, что выходит за эти рамки - это и есть "хотелки" пользователей, учесть которые все, попросту невозможно. Безусловно, их реализация в программе имеет огромное значение. Если внимательно приглядеться, то процентное соотношение уже реализованных "хотелок", упрощающих труд расчетчика, к законодательно определенным возможностям программы, как бы не 90/10. И разработчики на этом не останавливаются. Обратите внимание, на форуме даже есть раздел "Как нам стать лучше", в котором пользователи могут свои "хотелки" озвучить. Другое дело, что в приоритете - "хотелки" Законодательства, а не пользователей. Вот что для вас важнее: обязанность в срок и без ошибок сдать, например, 6-НДФЛ, или отправить в Сбербанк квитки сотрудников, при условии, что такая обязанность вообще отсутствует?
Но счастье есть 🙂:
Возможность сформировать реестр квитков в программе будет реализована.
Необходимо реализовать выгрузку расчетных листков в формат XML в виде требуемом банками (Сбербанк).
Для реализации такой возможности надо знать формат XML-файла. Он у Вас есть?
Будет ли реализована такая возможность?.
Самый простой вариатн - обратиться к своему сопровождающему программисту. Вряд ли у разработчиков есть время на реализацию в поставке не предусмотренных законодательством и маловостребованных "хотелок".
Пробовал, конечно. Этот параметр корректно отрабатывает только если смена процента произошла в полностью отработанном месяце.
ИМХО, надо не "усреднять" а считать так:
1. Сумма до смены процента = дневная ставка * ФРВ до смены * старый %
2. Сумма после смены процента = дневная ставка * ФРВ после смены * новый %
3. Общая сумма = п.1 + п.2
Вот что придумалось (дилетантство, конечно, но вроде бы работает):
case 878:
{
struct Struct_Alg Work;
Get_AlgWithParam(Work,info.ikod);
// параметр 1 - номер сетки
int NumSet = 78; // номер сетки по умолчанию
if(Work.Count_Par > 0)
{
NumSet = atoi(reinterpret_cast_to_string(Work.List_Par[0]));
}
// параметр 2 - номер столбца ТВХ для расчета ставки
int stolbec = 1001; // номер столбца по умолчанию
if(Work.Count_Par > 1)
{
NumSet = atoi(reinterpret_cast_to_string(Work.List_Par[1]));
}
char data_sm_kch[20], data_sm_tek[20];
GetKchDate("datavys",data_sm_kch,6,KDateFromStr(datatek)); // дата из поля КЧ "datavys"
sprintf(data_sm_tek,"%s%d",data_sm_kch,gtek); // дата смены процента в текущем году в формате ДД.ММ.ГГГГ
double data_double = GetDateFromFuncRWScript(data_sm_tek); // дата смены процента в текущем году в формате ГГГГММ.ДД
int day_sm = SubStr(data_sm_tek,0,2); // день смены процента
int kol_day_mes = dney_v_tab("Р",calm,info.z1,info.z2); // количество рабочих дней в месяце
int kol_day_before = dney_v_tab("Р",calm,info.z1,day_sm-1); // количество рабочих дней до смены процента
int kol_day_after = dney_v_tab("Р",calm,day_sm,info.z2); // количество рабочих дней после смены процента
double st,st_dn;
s97col(stolbec,info.d1,info.d2,st_dn,st,1); // st_dn - дневная ставка
double pr, pr_old, pr_new, summ1, summ2;
if(kol_day_before==0)
{
procent_ot_staga(NumSet,"datavys",31,0,1,info.crow,info.d1,data_double,pr); // процент действует весь месяц
info.n1 = st_dn*kol_day_mes*pr/100;
pr_old = pr;
}
else
{
procent_ot_staga(NumSet,"datavys",1,0,1,info.crow,info.d1,data_double-0.01,pr_old); // старый процент
procent_ot_staga(NumSet,"datavys",1,0,1,info.crow,data_double,info.d2,pr_new); // новый процент
summ1 = st_dn*kol_day_before*pr_old/100;
summ2 = st_dn*kol_day_after*pr_new/100;
info.n1 = summ1 + summ2;
}
if(FL_V_ALG && uprc != NO_SCREEN)
{
infolist.add_record("дата смены %",data_sm_tek);
infolist.add_record("ФРВ до смены % ",kol_day_before);
infolist.add_record("ФРВ после смены %",kol_day_after);
infolist.add_record("старый процент",pr_old);
infolist.add_record("новый процент",pr_new);
infolist.add_record("ставка",st_dn);
infolist.add_record("Результат",info.n1);
}
return code_Break;
}
В БЗ вида указываю 50, при расчете ставит суммовое значение.
50% в БЗ учитываются в случае расчета строки по 7-му алгоритму (по F4 или в автоматическом режиме) . Вы же, судя по всему, делаете расчет в режиме "отпуск/по среднему". В этом случае значение в БЗ не учитывается, но при расчете, по умолчанию, туда подставляется рассчитанный средний дневной заработок. Чтобы при расчете в режиме "отпуск/по среднему" учитывался процент выплаты, необходимо в настройке расчета указать этот процент явно, либо сделать запрос процента выплаты:
З.Ы. Использовать поставочный 107 вид для расчета в режиме "отпуск/по среднему" нет смысла, т.к. при расчете ЛС строка этого вида всё равно пересчитается по 7-му алгоритму.
Я клиенту нарисовал свой скрипт для расчета выслуги. Но надо бы на уровне поставки вопрос решить. Получается, что в месяце смены процента 178 алгоритм всю жизнь считал не правильно...
Вопрос снят.
Вопрос крайне актуален. Клиенты плачут... Каков срок реализации?
Сервис поддержки клиентов работает на платформе UserEcho
С чего бы вдруг? Ст.136 ТК РФ обязывает извещать работников о составных частях заработной платы в письменной форме, в переводе на русский - выдавать работникам бумажные квитки. Более ни к чему ст.136 не обязывает и ни чего не разрешает.
"Выдавать" бумажные квитки КЗ умеет. Требование законодательства соблюдено.
В 2020 году Роструд с какого-то перепугу самовольно решил "разрешить" работодателям отправлять квитки по почте. Ну да Бог с ним, разрешил, и разрешил. Отправлять квитки по почте КЗ умеет. "Хотелка" не желающих переводить бумагу на квитки была удовлетворена году эдак в 2014.
Возможность просматривать квитки в ЛК СБ - не требование законодательства, а маркетинговый ход Сбербанка, на который вы купились и решили усложнить себе жизнь.