Ваши комментарии

Какое решение требуется от разработки?
Есть Шифр затрат, в него вы можете добавлять аналитику. Эта аналитку включаете в проводки и передаете дальше. С учетом того что это три отдельных вида взносов. Не понятно в чем может быть проблема.

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

Немножко не так.
Вы положили сумму "аванса" 15000 на оклад 106. При захвате ведомостью, например 20.01.2023, она в налоговую базу положит эту сумму с 2000 кодом дохода.
Получим (для простоты без вычетов):
Дата               Код дохода      Сумма   
20.01.2023    2000                   10000   

После того как вы сделаете расчет за месяц, у вас на окладе 106 получится сумма 10000. При этом 15000 захвачено ведомостью в аванс.
При формировании следующей ведомости "Зарплата" за этот месяц (ну или ведомостью по набору видов куда опять включите 106 вид). Программа увидит что предыдущая ведомость захватила с вида больше чем было начислено, и захватит корректирующую сумму "минус 5000" и поместит ее тоже с кодом 2000 но уже в дату этой ведомости. Допустим это будет 10.02.2023

Дата             Код дохода  Сумма
20.01.2023   2000             10000
10.02.2023   2000             -5000

А дальше все зависит от остальных сумм.
Если в налоговую базу февраля ведомостями будут захвачены еще доходы с кодом 2000 в сумме больше 5000, то в справке 2-НДФЛ эти нюансы останутся незамеченными, так как "минус 5000" схлопнется в феврале с большей положительной суммой по 2000 коду дохода.

Ну в примере выше. Если бы вдруг окончательная ведомость пошла так же январем. Например 29.01.2023, то все было бы хорошо:
Дата            Код дохода Сумма
20.01.2023  2000             10000
29.01.2023  2000              -5000

В январь тогда бы на 2000 код встала сумма 10000-5000 = +5000.

Если же вдруг такого не произойдет. Например из-за отпуска оклада в принципе не было. То есть получим что-то вроде такого:
Дата             Код дохода  Сумма
20.01.2023   2000             10000
10.02.2023   2000             -5000
03.02.2023   2012            50000

То в справке НДФЛ получите:
январь 2000 10000
февраль 2000 -5000
февраль 2012 50000

И потребуется корректировка. Сделать ее можно тем же самым 277 видом.
Ставите в февраль 277 видом с 2000 кодом дохода "+5000"
Ставите в февраль другим 277 видом с к 2012 кодом дохода "-5000" и получаете что-то вроде этого:
январь 2000 10000
февраль 2012 45000


p.s.Выше объясняются правила игры установленные НК. Но я не умею объяснять с какой целью в чьей-то  голове родилось решение вводить 100500 кодов дохода, и считать НДФЛ "по дням" и почему, например, налоговые агенты (то есть работодатели) не могут считать НДФЛ существенно проще. Ну например как считают страховые, суммарно за месяц. 
Те, кто это все придумывают преследуют какие-то свои цели. Возможно они важные и ценные. 
Но при этом "изобретатели" кажется плохо представляют реальную жизнь, которая происходит в бухгалтерии организации и насколько придуманные ими правила усложняют повседневную деятельность бухгалтера.

Ну если примерно, то: если на 106 виде стоит та сумма которая была выплачена в первый аванс, то можете ее увеличить на 5747,13 и сформировать ведомость по 106 виду, которая должна удержать 13% и поставить к выплате 5000

1. Словами подробно проговаривал на вебинаре

Если бухгалтер разбирающий в НК, то разговор с клиентом можно начать с вопросов:
* какой календарный год был раньше 2022 или 2023?
* какая версия НК действовала 31.12.2022 (та которая действовала в 2022 году, а не та которая стала действовать в 2023)
* попала ли зарплата декабря в налоговую базу декабря 2022 года в полном объеме на основании НК 2022 (да попала)
* где в НК 2023 года написано, что суммы попавшие в налоговую базу 2022 года надо изъять из налоговой базы 2022 года (нигде, кроме писем Минфина и ФНС, а они не являются нормативным актом)

Если бухгалтер не разбирается в НК вместо вопросов надо давать ответы.

2. Подумать и сформулировать как у всех этих людей определить "грязную" сумму дохода которая должна перейти на январь. Ну например "начислено в декабре - аванс_декабря/0.87 = сумма которую хотим перенести на январь".

Если такая формулировка устраивающая бухгалтера найдется, то не должно быть сложно автоматизировать разноску 277 вида на 1500 человек. 

С другой стороны. Странно идти на полумеры. С аванса выплаченного в декабре НДФЛ не удерживался. Все удержание НДФЛ происходило в январе. То есть перенеся часть зарплаты в январь но при этом по платежкам у вас будет весь НДФЛ декабря в январе вы по концу года не получите в 6-НДФЛ красивой картинки "исчислено = удержано". Если уж переносить то все или ничего. Полумеры приведут к тому что единственным достойнством будет "ура мы выполнили рекомендации ФНС". Но при этом и пообъясняетесь почему доход в РСВ больше 6-НДФЛ в 2022 и почему исчисленный НДФЛ не совпадает с удержанным в итоговой 6-НДФЛ по 2023.

1. Тоже самое что вы делаете когда обнаруживаете что НДФЛ излишне удержан - возврат НДФЛ.

2. До этого и сейчас по умолчанию. Кассовая ведомость, если она насчитала отрицательный НДФЛ, его не учитывает. Ну то есть берет просто сумму дохода не удерживая НДФЛ (но и не возвращая его).
Если включить эту настройку, то за счет расчета отрицательного НДФЛ кассовая ведомость его начнет и возвращать.
Если следовать дословно "букве закона". То все возвраты НДФЛ это целая процедура и следовать этой букве досконально может быть неудобно и тогда возможность отрицательного НДФЛ хотя бы в итоговой ведомости "Зарплата" минусы могла бы "подобрать".

Но настройкой стоит пользоваться аккуратно. Есть риски при ее использовании.
Ну например самый яркий: в каком-то месяце что-то не "захватывали" ведомостями (то есть формально в налоговую базу за этот месяц попал ноль), ручной корректировкой в этот же месяц поставили насильно сумму НДФЛ с этого дохода. Закрыли месяц.

При расчете в следующем месяце программа будет считать что "дохода не было", а НДФЛ был и как вернет все отрицательным налогом в ведомость.
Понятно что здесь некорректная исходная ситуация, но гарантии что ее не окажется у клиента нет. А значит получим необоснованный возврат.


При веб-обновлении 619.2 исправляется эта настройка.

Обновление 619.2 исправляет устаревшую и некорректную настройку в больничных, которая приводила к такому эффекту

Для ведомости "Зарплата"?
У вас итог по месяцу должен быть "с копейками" тогда.
Настраивается тут:
Настройка -> 4. Настройки параметров расчета -> 1. Настройка для суммы расчета за месяц -> Округление сумм расчета за месяц

Сервис поддержки клиентов работает на платформе UserEcho