?! У меня вопросов стало еще больше.

Из какого реестра ЭЛН собираетесь данные подтянуть? Из Контур-Зарплаты? Как собираетесь это делать? Будете перебирать все xml-файлы в каталоге eln? будете читать xml-файл реестра ЭЛН и определять по каждому ЭЛН какой из файлов ЭЛН является последним?

Какое-то дикое количество работы на ровном месте с туманными перспективами на работоспособность в настоящем и уж тем более в будущем (поменяем структуру реестра например).

Может попросить разработчиков ускорить добавление расчета больничных из реестра или хотя бы засветку ЛС по списку в реестре?

1) Ну они скорее всего изменятся, так как расчетный период разный.

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

Тогда проверить то, что написал Николай.

Думаю, что еще надо чтобы у вида по которому проходит пособие 65 рублей должны стоять фиксированные даты а не бесконечные (пустая дата начала и дата конца = 01.01.2050)

Нам не удалось повторить ошибку на поставке "законными" способами. Во всяком случае текущие версии программы одинаково успешно подхватывают продление в виде ЭЛН как из нового расчета больничного, так и из продления. Правда я проверял только при непротиворечивых данных в первичном больничном и продлении.

При просмотре сохраненки были обнаружены следующие ошибки:

1. В настройках кадровой части размер поля Подразделение 10 символов. Архитектурно заложено подразделение + ТН должны быть не больше 9 символов. Работоспособность программы даже при размере подразделения больше 6 не гарантируется. При размере 10 в частности у вас в программе происходит "порча" стека данных, как следствие работа программы становится непредсказуемой. Кто Вас научил менять размер подразделения на 10? Если вам нужны длинные подразделения, для этих целей есть "внешний код подразделения". Внутренний код подразделения должен оставаться не больше 6 символов.
2. В настройке больничных "Настройка -> 4. Настройки параметров расчета -> 4. >>> Настройки для больничных -> 1. Настройки расчета больничного листа -> Суммы для средн. брать по настр. взносов" стоит 1. В этой настройке должен стоять номер алгоритма для расчета страховых взносов. У вас это 238. При ваших настройках программа считает среднее для больничного "непредсказуемо" (точнее в среднее попадают не обязательно те доходы, которые облагаются страховыми взносами, и программа не находит предельный размер базы (о чем честно вас предупреждает)).

Точнее Msxml2.DOMDocument.6.0

Если интересуют какие функции есть у этого объекта, то это в официальной документации Microsoft:
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms757878%28v%3dvs.85%29

Может быть скажете, что хотите сделать и мы подскажем как это можно сделать?

Добрый день. Непонятна суть вопроса.

поставочный 305 вид посчитает НДФЛ правильно, рубль в рубль (при поставочных настройках).

Что значит "недобор", "перебор" и что значит правильная сумма. Можете привести примеры?

Замечу что в Налоговом Кодексе нет понятия "источник финансирования" или "внутреннее совместительство" и как следствие нет понятия "НДФЛ по источнику финансирования". Налоговому Кодексу (и ФНС) важно чтобы в целом по человеку НДФЛ был правильным, а разбиение по источникам финансирования никем и никогда не регламентировалось.

1. Запомнить суммы старого больничного
2.  Удалить больничный
3. Рассчитать новый с правильными датами
4. Убедиться что суммы не изменились
5. Изменить месяц начисления у новых сумм на явнарь 2018

А точно отличаются только столбцом? Параметр, задающий столбец для "обычного" 12-15 алгоритма и для "параметризованного" алгоритма имеют одинаковый порядок. Ну то есть, если не писать что-то вроде 1=N, а просто перечислять параметры через запятую - то все работало бы.
Легко же проверить. Включите вашим особым видам РК расчет не через параметры, а через обычный алгоритм (2 в 26 столбце специальной ТВХ)
s100ras по стандартным то алгоритмам 12,15 давно умеет работать (в том числе с учетом другого столбца в параметре).

А что значит "нештатное" начисление р/к? Оно не укладывается в стандартные 12,15,99,98 алгоритмы? Почему?

Почему вы считаете это баг? У вас написан некоторый свой алгоритм, вы запускаете расчет среднего с указанием: "а пересчитай ка мне некоторый набор видов с учетом тех сумм, что попадают в расчет среднего". То есть ваш алгоритм должен уметь работать в такой ситуации. Это он должен понимать, что кроме того, что он считается в обычном режиме по некоторому набору видов, он должен уметь считаться в расчете среднего, когда надо взять "пересечение" двух наборов видов (обычного и того, по которому среднее считается).

"Параметры алгоритмов", которыми Вы любите пользоваться так не умеют. Скрипты - можно научить.

01.12.2016 релиз 591.0

! s100ras может отрабатывать по пользовательскому алгоритму при расчете среднего.
Извечной проблемой было то, что при расчете среднего можно указать виды, которые
при выборке в среднее подвергаются пересчету (районный коэффициент, процентные надбавки),
с целью не включить в выборку ту долю пересчитываемого вида, которая приходится на виды,
по которым среднее не считается (а пересчитываемый вид считается).
В качестве таких видов можно было указывать только виды, по которым написан специальный алгоритм
в s100ras (12,15,98,99).
Сейчас s100ras при своем вызове:
1) запоминает столбец по котором она должна отработать и его можно получить в алгоритме пользователя через GetLastS100rasColumn
2) если не находит алгоритм в числе "известных" s100ras, запускает для пересчета вида обычный расчетный алгоритм с флагом b3=7.
Таким образом, у внедренца есть возможность доработать свой алгоритм с прицелом на то, чтобы при вызове его с флагом b3=7 (то есть из s100ras)
этот алгоритм учел столбец, по которому отрабатывает s100ras (например используя w2dopst).

Это можно считать тем, что "бага" о котором Вы говорите в программе нет уже 2 года, а есть баг в Вашем алгоритме?