Ваши комментарии
Нам не удалось повторить ошибку на поставке "законными" способами. Во всяком случае текущие версии программы одинаково успешно подхватывают продление в виде ЭЛН как из нового расчета больничного, так и из продления. Правда я проверял только при непротиворечивых данных в первичном больничном и продлении.
При просмотре сохраненки были обнаружены следующие ошибки:
- В настройках кадровой части размер поля Подразделение 10 символов. Архитектурно заложено подразделение + ТН должны быть не больше 9 символов. Работоспособность программы даже при размере подразделения больше 6 не гарантируется. При размере 10 в частности у вас в программе происходит "порча" стека данных, как следствие работа программы становится непредсказуемой. Кто Вас научил менять размер подразделения на 10? Если вам нужны длинные подразделения, для этих целей есть "внешний код подразделения". Внутренний код подразделения должен оставаться не больше 6 символов.
- В настройке больничных "Настройка -> 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 вид посчитает НДФЛ правильно, рубль в рубль (при поставочных настройках).
Что значит "недобор", "перебор" и что значит правильная сумма. Можете привести примеры?
Замечу что в Налоговом Кодексе нет понятия "источник финансирования" или "внутреннее совместительство" и как следствие нет понятия "НДФЛ по источнику финансирования". Налоговому Кодексу (и ФНС) важно чтобы в целом по человеку НДФЛ был правильным, а разбиение по источникам финансирования никем и никогда не регламентировалось.
- Запомнить суммы старого больничного
- Удалить больничный
- Рассчитать новый с правильными датами
- Убедиться что суммы не изменились
- Изменить месяц начисления у новых сумм на явнарь 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 года, а есть баг в Вашем алгоритме?
Подразделение добавлять пока не планируем. Если у ЭЛН проставлены табельные номера и настроен доступ расчетчиков к своим лицевым счетам, то чужие ЭЛН расчетчик не увидит. Он увидит только свои и те, для которых не заполнен ТН.
Не совсем понятно что хочется услышать от разработчиков?
Если вы сделаете так, что флешка при подключении к компьютеру всегда будет подключаться с одной и той же буквой диска, то достаточно настроить путь до реестра на флешку (правда в этом случае пока флешки не будет в компьютере, ничего с ЭЛН делать будет нельзя).
Ну то есть в этом случае программа будет считать что реестр лежит по этому пути, который указывает на флешку.
Но, если флешки в компьютере не будет (или у нее поменяется буква диска), то при попытке попасть в реестр ЭЛН или при начале расчета больничного, будет выдаваться сообщения "Ошибка при работе с реестром. Путь до хранилища не найден".
Если это не будет пугать расчетчиков, то конечно можно работать с флешкой как с хранилищем.
Планируется ли возможность пополнения реестра ЭЛН с сайта ФСС по рег.номеру предприятия всеми теми ЭЛН, которые требуется рассчитать, или все-таки без предварительной набивки СНИЛС и №_ЭЛН не обойтись?
Одной из причин по которой ФСС не делает такой режим: предоставление больничных право а не обязанность сотрудника. Сотрудник может не захотеть предоставлять больничный, даже если он был выписан МУ.
Другой причиной, возможно, является тот факт, что предоставление всех ЭЛН только по рег.номеру потенциально несет больше рисков по утечке перс.данных высшего уровня защиты. В одном случае нам надо знать: РНС, иметь сертификат, знать СНИЛС и номер больничного. В другом случае достаточно знать только РНС (публичная информация) и иметь доступ к сертификату юр.лица.
BASE_AVG_SAL |
Данные для расчёта: Суммарный заработок за два года с учетом ограничений на максимальную базу для начисления страховых взносов по каждому году |
Я не вижу оснований для настройки. То что в некоторых отделениях ФСС сидят некомпетентные люди не является таким основанием.
Кроме описания поля из формата, на поверхности лежит и другое объяснение: когда мы проставляем фактический заработок - у инспектора есть полная картинка по расчету ("ага, доход был маленький, значит надо считать из МРОТ, МРОТ был такой-то". Если мы проставим 24*МРОТ - никто без запроса дополнительных документов от работодателя не сможет проверить правильность расчета. А при расчету по МРОТ, как мы помним, много тонкостей в зависимости от того, когда и как применять районный коэффициент или ставку.
Резюме: настройку делать не будем, пока не будет официальной бумаги от ФСС, в которой написано, что в поле BASE_AVG_SAL необходимо проставлять 24*МРОТ, если расчет шел из МРОТ.
Сервис поддержки клиентов работает на платформе UserEcho
Думаю, что еще надо чтобы у вида по которому проходит пособие 65 рублей должны стоять фиксированные даты а не бесконечные (пустая дата начала и дата конца = 01.01.2050)