Ну вроде бы помог этот пост от   Шинкарев Вячеслав (Менеджер разработки) 21 час назад     

в дискуссии с руководством бухгалтерии, в том плане, что не надо поддаваться на

провокации ФСС.

Но возник следующий вопрос:  поскольку в НПА  прописана дата  01.01.2022г.,

а про переходный период в 6 месяцев ничего не говорится,   можно ли где-то найти ссылку

на какой-нибудь  вэбинар или видео-конференцию,  или какое-нибудь письмо,

где оговаривается это понятие - переходный период до 01.07.2022Г.?

Местный ФСС ограничил  "переходный период"   датой  15.03.2022г,   поскольку

на  дату окончания  "переходного периода"  30.06.2022г.  никакого  НПА  не существует.

Поэтому хотелось бы знать  хотя бы приблизительные сроки реализации 

нового формата в КЗ.

А есть возможность заполнить в КонтурЭкстерне   запрос о недостающих сведениях

  автоматически  из реестра ПВСО?

Спасибо !

Т.е.   выполняем пункт

-  "Обмен данными с ФСС (ЭЛН)"

-  рассчитываем  ЭЛН

-  заполняем в КонтурЭкстерн  в запросе о недостающих сведениях зарплатные данные

Ещё один вопрос.

КонтурЭкстерн выгружает информацию по реестру  в  XML-файл.

Каким образом его можно принять в КЗ,  для расчёта ЭЛН?

zpl_zplinfo(20220119_135452).cab

Воспроизвёл ситуацию в поставочной базе.

Условия следующие:

сотрудница уходит в декретный  и затем до 1.5  с 01.01.2021;

в декабре 2020 есть зарплата,  

а поскольку в настройках 6НДФЛ  дата выдачи зарплаты - 12

                                                         месяц выдачи зарплаты - 1                                                                                            то, соответственно, этот ЛС принимает участие в 6НДФЛ.

Но при формировании 6НДФЛ  на этот ЛС, при заполненной КЧ, выпадает  набор ошибок:

Атрибут ”ДатаРожд” недействителен: значение ” . . ”

Атрибут ”КодУдЛичн” недействителен: значение ”0”

Атрибут ”Статус” недействителен: значение ”0”

Отсутствует обязательный атрибут ”СерНомДок”

Насколько правильны эти ошибки ?

Сохранёнку выложил,  но ситуация легко воспроизводится в поставке.

В таком случае история вопроса остаётся неполная,  несколько строчек в одну схлопываются.

Ну да,  основная причина это  внутренние отчёты,  ну и сложившаяся технология работы.

Во-первых текущих рабочих сводов приличное количество, и заставлять бухгалтеров делать дополнительные своды - нежелательно.

Затем  в ОТИЗе  куча своих отчётов по распределению зарплаты.

Ну и потом,  перевыдавать отчёты по зарплате 10-летней давности  - это вероятность меньше 1%.

Да и добавление нового вида для текущей работы тоже вещь непростая,  т.к. видов НУ уже итак много. 

Эта таблица, собственно и делается, чтобы решить проблему 100-й строки.

Есть некий вид, достигший порога 100, у некоторых сотрудников.

Работать с незакрываемым видом, т.е. с датой конца = 01.01.2050, нежелательно.

Вводить новый вид (дублёр) тоже нежелательно,  но допустимо, если на этот вид-дублёр перенести суммыы за 

предыдущие года, с одновременным удалением строк основного вида за те же года.

Перекодировка вида не годится, т.к. она перекодирует вообще весь вид без запроса начала и конца,

а надо будет сдавать отчёты годовые, как общегосударственные так и ведомственные.

Вот и решили всё-таки создать вид-дублёр но перекодировку делать за конкретный год,  т.е. в древних

годах суммы будут на виде-дублёре,  а в текущей базе расчёты будут производиться на основной.вид.

Задача таблицы заключается в следующем:

- принять суммы, допустим за 2010 год,  по основному виду (с расширением);  

- произвести разноску этих сумм на вид-дублёр (с тем же самым расширением, в тот же 2010);

- удалить строки основного вида за 2010 год,  чтобы высвободить диапазон расширений для текущей работы.

Т.е. - краткий ответ такой  - добавить вид и разнести сумму.