Ваши комментарии
Удвоение возникает из-за того что РВ берется из вида начисления удержания общей суммой за месяц.
По этому РВ из вида, не определить за какой оно период календарных дней. Если взять ФРВ из двух видов из разных исп.должностей, то по этим двум числам невозможно сказать какая часть из них "повторяется", можно либо взять оба, либо игнорировать одно из них полностью. Поэтому если уж у вас настроено "брать из видов", то вариант "взять не все РВ из вида, а только какую-то часть" сложно реализуем (если вообще реализуем).
Если мы делаем настройку "брать из основной" - ок. Вы получите РВ стоящее в виде в исп.должности с "галкой" "основная должность".
Но если эта должность была не весь месяц, то "се ля ви". РВ будет неполным.
Брать ФРВ из видов - это "полумера", когда по каким-то причинам табельный учет не ведут, или ведут как-то "частично".
Если в 6-НДФЛ захотите чтобы возвраты показывались именно как возвраты их надо поставить в отдельный вид(ы). См. описание поставки 632.1 от 02.04)
В противном случае они будут просто уменьшать сумму удержанного НДФЛ. Проблем в этом случае возникать не должно так как скорее всего за счет других людей, у кого будет удержан НДФЛ в ту же самую дату, общего минуса не возникнет. Если бы был только один человек, то точно пришлось бы оформлять в лицевом как возврат, чтобы не возникал минус по удержанному в первом разделе.
Где же вы это прочитали.
Я же уточнил: а вам точно хватит настройки "бери с основного"
Недостатки:
1) галка "основное" имеет обыкновение "перемещаться" с исп.должности на исп.должность (без сохранения историчности) - а значит повторный расчет может потом дать другой результат
2) что делать с периодами из разных должностей, которые "не пересекаются". Странно же их игнорировать. Или такого у вас нет?
Вот поэтому я настоятельно прошу всех наших кураторов "под расписку" брать пожелания заказчиков, особенно если они расходятся со здравым смыслом. Чтобы потом заказчик не выставлял крайним специалиста по внедрению "это не мы, это внедренец, это Контур".
Вы себе можете представить ситуацию, что специалист по внедрению приходит на рабочее место клиента и начинает "по своему разумению" (потому что душа попросила?) менять поставочные настройки. Я - нет. Я видел разных специалистов, но таких - нет.
Если вы недовольны уровнем квалификации "куратора" или тем, на сколько он своевременно отвечает на ваш вопрос, вы всегда можете инициировать процесс замены куратора на другого.
Если вас не устраивает уровень оказанной тех.поддержки, вы тоже можете оставить обратную связь, когда и какую конкретно поддержку вам оказали некомпетентно.
Фраза "сплошные стажеры, за компетенцию которых должно быть стыдно" не дает ничего полезного ни вам, ни нам не дает возможности стать лучше. Просто уход в эмоции. А смысл?
Брать РВ "по основной должности" это просто реализуемая вещь, но вас она же не устроит.
Если у вас две должности одна из которых продолжает другую, или они пересекаются частично вы же захотите так, чтобы было суммарное РВ по "непересекающимся" периодам?
1) "за квартал" и "за предшествующие 3 месяца" это не одно и тоже.
Если считаем в феврале - РВ за какие месяцы выбирать? декабрь-октябрь? январь-ноябрь?
(но это так, уточнения к постановке задачи).
2) если график менялся или был составным - норму какого графика берем?
3) всегда ли берем график человека, или в каких-то случаях придется брать "стандартную пятидневку" например?
4) если человек был принят в течении "квартала" - все равно делим на 3, или делим на те месяцы, когда он был устроен на работу, или на полные месяцы работы?
Но по исходному вопросу - нет, ничего подобного в поставке нет. Но скриптами такой алгоритм вроде несложно должно быть написать.
Может, вы выработаете общие рекомендации для всех пользователей по хранению старых программ с данными за прошлые годы?
1. Ежегодные копии
2. У большого числа клиентов не стоит проблема с особой лицензией для копий, им подходит лицензия от текущего рабочего каталога. Для тех клиентов перед кем проблема встанет - как уже выше написали, тех.поддержку проинформировали по порядку выдачи особых лицензий для таких каталогов.
Ну сложно поверить что они ничего не делали.
У них сейчас 305 вид настроен как "непересчитываемый" если по нему уже есть данные.
Если я это отключаю, то получаю в декабре вот такую картинку:
Т.е. программа говорит что излишне удержан НДФЛ как раз тот самый что вылез позже.
Плюс в феврале возникает разница на 1 рубль относительно посчитанного.
Вот так те самые 1495 рублей и получаются которые выползли в апреле.
А что они делали и как они считают - мы тоже не можем сказать. Надо с клиентом разбираться.
У них эта история и дальше продолжается, если смотреть на январь, то там будет сумма 1494 с месяцем принадлежности январь и с датой 10.02 (что компенсировало потерянную в декабре сумму налога) - программа этот НДФЛ отнесет к январю несмотря на дату, т.е. по факту это НДФЛ с декабрьской суммы ГПХ выплаченной 10.01
И в феврале есть 1494 рубля с датой 10.03 - не смотря на дату это сумма НДФЛ с январской суммы ГПХ выплаченной 10.02 (т.к. месяц принадлежности февраль)
И в марте с датой 10.04 - не смотря на дату это сумма НДФЛ с февральской суммы ГПХ выплаченной в марте.
Ну а тот НДФЛ про который вы спрашиваете это НДФЛ с мартовской суммы ГПХ выплаченной в апреле.
Еще раз по месяцам доходы (рассматриваю не аванс по ГПХ, а расчет):
774 вид выплаты были по 11494: 10.01 (с месяцем принадлежности декабрь), 10.02 ( с месяцем принадлежности январь), 10.03 (с месяцем принадлежности февраль) и 10.04 (с месяцем принадлежности март).
А НДФЛ:
305: 1494 с месяцем принадлежности декабрь с датой 10.01 - потерян (для налога важен месяц принадлежности)
Поэтому остаются: 1494 с месяцем принадлежности январь (дата 10.02), 1494 с месяцем принадлежности февраль (дата 10.03) и 1494 с месяцем принадлежности март (дата 10.04). Итого на 4 договора ГПХ имеется три суммы НДФЛ чего недостаточно поэтому программа в апреле добрала налог.
А еще если по этому человеку сделать 6-НДФЛ (или справку по сотруднику), то получим такую картинку (излишне удержанный налог):
Сервис поддержки клиентов работает на платформе UserEcho
сложно спорить, что не пользователь должен считать.
Только мы говорим о ситуации, когда у вас схлопнуты данные (в одно число в РВ вида), и хоть тресни арифметику не провести.