Ваши комментарии
Я переформулирую чуть по-другому: потому что ЭЛН это только то, что отдает ФСС (с подписью ФСС). Все остальное вы можете называть как угодно, но только не ЭЛН. Задача "готовить" результаты расчета в виде неполноценного ЭЛН есть, но не высокоприоритетная.
Не совсем понятно для чего пользоваться Контур-Экстерн, если можно пользоваться демо-версией Контур-Зарплата для отправки ЭЛН с рабочего места где есть Интернет.
Добрый день! У вас как доступ в интернет организован? При попытке выхода в интернет попадаете на какую-то страницу для идентификации и авторизации?
Это не ответ сервиса ФСС это какая-то html-страница. Предположительно страница на которой делается авторизация для выхода в Интернет.
Столбец "Признак начисления удержания" добавьте.
1) чтобы ответить правильная сумма 45 копеек или 46, на самом деле надо знать точные суммы (не округленные до копеек) в трех разных строчках экселя (или свода). Я положился на то, что эксель правильно сложил суммы не округленные до копеек. Выборка по видам Н-У вообще не показатель если вы там не увеличили точность столбца.
2) О проставляется исключительно для травматизма. О(тчисление) пошло из далеких 90х прошлого года, когда все взносы платились с ФОТ. С тех пор большая часть взносов стала считаться отдельно по каждому человеку, а травматизм по факту остался с ФОТ. Символ О как раз и позволяет программе в момент выборки сумм из людей не делать округления до копеек, после того как все суммы выбраны - выполнить округление до копеек строк помеченных О. В поставке с исправлениями столбец НУО будет необязательным. Определить травматизм можно и по столбцу Вид Н-У (виды с 254 алгоритмом налога).
Поэтому ваши своды править не надо будет если там есть либо столбец "НУО" либо столбец "Вид Н-У". Если нет ни того ни другого, то после выборки сумм в свод суммы по травматизму будут храниться не округленными.
Обнаруженная вами ошибка проявляется не всегда, а только в тех случаях когда предпоследний значимый знак дроби не может быть представлен точно в double. Например 0.015 будет хранится как 0.014999999.... отсюда получим при простом округлении до 2 знаков 0.01 вместо 0.02.
Исправим так, что в своде сразу будет сделано округление до точности столбца свода. В эксель в этом случае тоже будут попадать суммы округленные.
Как это будет работать можете проверить уже сейчас если добавите временно в шаблон свода, для удержаний столбец "Признак начисления/удержания" (в заголовке у него будет написано "НУО").
P.S. Правильная сумма 364 275-46.
Настройками нет. Поменяем.
Сегодня до 12.00 Выпустим 599.5 с исправлением этой ошибки.
Программисты SPU-ORB не умеют работать с пространством имен в xml-файле. Они считают что значения префикса определяется своим названием (ну что должно быть обязательно ИС2 а не ИС), а по стандарту xml префикс определяется uri присвоенным префиксу в начале xml файла.
Если программисты SPU-ORB в начале файла написали:
xmlns:ИС2="http://пф.рф/ВС/ИС/типы/2018-11-20",а мы написали
xmlns:ИС="http://пф.рф/ВС/ИС/типы/2018-11-20"
То ИС2:Документы у них и ИС:Документы у нас - это одинаковые элементы. Что и подтверждает проверочная ПО ПД.
Мы даже можем написать
xmlns:НекоторыеПрограммистыНеЗнаютЧтоТакоеХМЛ="http://пф.рф/ВС/ИС/типы/2018-11-20" и пользоваться внутри xml
этим префиксом:
НекоторыеПрограммистыНеЗнаютЧтоТакоеХМЛ:Документы.
Ну вот можно на наших файлах проверить, кто как с xml работает. На текущий момент в список "неумёх" попали: СБИС и SPU-ORB.
Что касается проверки ПО ПД (не найдена xsd схема). Попробуйте скачать и установить последнюю версию ПО ПД. Проверка проходит отлично хоть с ИС хоть с НекоторыеПрограммистыНеЗнаютЧтоТакоеХМЛ
Сервис поддержки клиентов работает на платформе UserEcho
1) Вроде как у дубликата должен быть заполнен номер того больничного к которому выдается. Можно пробовать его анализировать.
2) Можно смягчить поиск первичного больничного. Можно искать в качестве первичного больничный заканчивающийся в предыдущую дату и позволять его выбирать даже если номер не совпадает (может быть показывая предупреждение).