ChkXML от 07.04.2014

[Oksana_A]

В разделе персучета. Там теперь 3 группы программ.

Спасибо, вчера обыскалась его

[VRALD]

Подскажите, пожалуйста, где можно скачать CheckXML от 07.04.2014 ?
На сайтеПФР не нашла, там только CheckPFR предлагается.

http://www.pfrf.ru/free_programs/

[fla3]

http://www.pfrf.ru/free_programs/

А с сайта Бухсофта скачать, что, не судьба? Чего проще?!

[Oksana_A]

А с сайта Бухсофта скачать, что, не судьба? Чего проще?!

Да, сегодня и на Бухсофте можно скачать. Я-то вчера пыталась CheckXML найти. Клиенты проверяют в Контуре, говорят CheckXML ругается, а я у себя протестировать не могу. Каюсь, сегодня уже не искала, сразу на форум пошла спрашивать.
Всем СПАСИБО!

[BlackFox]

В этой версии неправильно проверяется ситуация, когда работник в одном месяце работал по двум спискам с разными подклассами вредности.
Т.е. например полмесяца - список 1, подкласс 3.1, другие полмесяца - список 2, подкласс 3.2
В файле получается, что суммы по одному списку у него в подстроках 700-703, а по другому списку в подстроках 710-713.
В результате Чек выдает ошибку, что по одному списку нет сумм допвзносов, хотя есть стаж.
Скрин привести не могу, на работе нет инета. Желающие могут смоделировать ситуацию и проверить.

Проблема остается. Когда выйдут исправления, хоть приблизительно ?

[fla3]

В этой версии неправильно проверяется ситуация, когда работник в одном месяце работал по двум спискам с разными подклассами вредности.
Т.е. например полмесяца - список 1, подкласс 3.1, другие полмесяца - список 2, подкласс 3.2
В файле получается, что суммы по одному списку у него в подстроках 700-703, а по другому списку в подстроках 710-713.
В результате Чек выдает ошибку, что по одному списку нет сумм допвзносов, хотя есть стаж.
Скрин привести не могу, на работе нет инета. Желающие могут смоделировать ситуацию и проверить.

У меня в контрольном примере один человек с 5 подклассами, причём О4-по списку 1, остальные - по 2. Контроль проходит нормально.
Попробовала на 3.1 поставить 1 список, по всем остальным - 2. Тоже нормально!

[olmor]

Аналогично, правда, начиная со 2 квартала. И кирпичом к этому:
***30: Ошибка. Значение 3866444.04 элемента <БазаДляНачисленияСтраховыхВзносовНеПревышающаяПре дельную> в документе СВЕДЕНИЯ_ПО_ПАЧКЕ_ДОКУМЕНТОВ_РАЗДЕЛА_6 не равно сумме 8020981.85 всех значений элемента <НеПревышающиеВсего> по всем блокам <СведенияОсуммеВыплатИвознагражденийВпользуЗЛ>, в которых элемент <ТипСтроки> имеет значение "ИТОГ", по всем документам СВЕДЕНИЯ_О_СУММЕ_ВЫПЛАТ_И_СТРАХОВОМ_СТАЖЕ_ЗЛ (расхождение 4154537.81 руб.).

Действительно, для проверок начиная со 2 квартала, программа пока не годится. В этой проверке их явная ошибка.

[BlackFox]

У меня в контрольном примере один человек с 5 подклассами, причём О4-по списку 1, остальные - по 2. Контроль проходит нормально.
Попробовала на 3.1 поставить 1 класс, по всем остальным - 2. Тоже нормально!

Разные подклассы и разные списки в одном месяце ?

[fla3]

Разные подклассы и разные списки в одном месяце ?

Повторюсь - тестирование проходит с "Хорошо".

[Котофей]

CheckXML неправильно округляет суммы? При проверке выдал следующее:

«!!!20: Предупреждение. Значение 2698.24 элемента <СуммаВзносовНаОПС> не равно расчетной величине 2698.25, т.е. не равно:
([с.401 гр.5]4053.75 + [с.402 гр.5]4140.00 + [с.403 гр.5]4071.00) * [тариф ОПС для НР]22%»

Из правил округления: «Если отсекается цифра 5, а за ней не имеется значащих цифр, то округление выполняется на ближайшее четное число, другими словами, последняя оставляемая цифра остаётся неизменной, если она четная, и усиливается в случае, если она нечетная.»

Хоть и предупреждение, а не ошибка, но все равно - правил математики еще никто не отменял. К сведению разработчиков в общем, я так понимаю они заглядывают на этот форум.

[yante]

CheckXML неправильно округляет суммы? При проверке выдал следующее:

«!!!20: Предупреждение. Значение 2698.24 элемента <СуммаВзносовНаОПС> не равно расчетной величине 2698.25, т.е. не равно:
([с.401 гр.5]4053.75 + [с.402 гр.5]4140.00 + [с.403 гр.5]4071.00) * [тариф ОПС для НР]22%»

Из правил округления: «Если отсекается цифра 5, а за ней не имеется значащих цифр, то округление выполняется на ближайшее четное число, другими словами, последняя оставляемая цифра остаётся неизменной, если она четная, и усиливается в случае, если она нечетная.»

Хоть и предупреждение, а не ошибка, но все равно - правил математики еще никто не отменял. К сведению разработчиков в общем, я так понимаю они заглядывают на этот форум.

Вот, из Википедии - http://ru.wikipedia.org/wiki/%CE%EA%...B%E5%ED%E8%E5:

Математическое округление — округление всегда в бо́льшую по модулю сторону (предыдущий разряд всегда увеличивается на единицу).
Банковское округление (англ. banker's rounding) — округление для этого случая происходит к ближайшему чётному, то есть 2,5 → 2, 3,5 → 4.
Случайное округление — округление происходит в меньшую или большую сторону в случайном порядке, но с равной вероятностью (может использоваться в статистике).
Чередующееся округление — округление происходит в меньшую или большую сторону поочерёдно.

Интересно, что используют в ПФР, и описано ли это правило в каких-либо официальных документах самого ПФРа?

[vk65]

Интересно, что используют в ПФР, и описано ли это правило в каких-либо официальных документах самого ПФРа?

Судя по приведенному примеру (а сам посчитать не попробовал? ) ПФР применяет математическое округление. А автор, видимо, применяет банковское округление, и это его личные трудности.

[Котофей]

ПФР применяет математическое округление. А автор, видимо, применяет банковское округление, и это его личные трудности.

У меня это разногласие вышло при применении Spu-orb. То есть, Spu-orb с з-ты 12264.75 22% считает как 2698.24, а у CheckXML получается 2698.25. Очевидно, что разработчики Spu-orb и CheckXML используют разные правила при округлении.

Судя по приведенному примеру (а сам посчитать не попробовал? )

Попробовал. 22% от 12264.75 = 2698.245

[vk65]

У меня это разногласие вышло при применении Spu-orb.

Так с этого и нужно было начинать. Косяк у Дениса, причем тут чек?

Очевидно, что разработчики Spu-orb и CheckXML используют разные правила при округлении.

Имхо, округление, отличное от математического должно оговариваться в НПА, иначе будет полный бардак.

[yante]

А насколько правомерно считать как

([с.401 гр.5]4053.75 + [с.402 гр.5]4140.00 + [с.403 гр.5]4071.00) * [тариф ОПС для НР]22%»

а не

[с.401 гр.5]4053.75 * [тариф ОПС для НР]22%» + [с.402 гр.5]4140.00 * [тариф ОПС для НР]22%» + [с.403 гр.5]4071.00 * [тариф ОПС для НР]22%»

Учитывая, что на самом деле считается-то и по людям, и по месяцам, округляя КАЖДОЕ начисление...
Хорошо, что в приведенном примере округлять надо только первую сумму, а две вторые - не нужно, а если бы округлять пришлось все три ( максимальное/минимальное отклонение ), то было бы +1.5коп ошибка, или -1,5коп?
Хотя не исключено, что "+" в первом месяце был бы нивелирован "-" во втором или третьем, все зависит от конкретного предприятия...