ChkXML от 07.04.2014

[LoraK]

Сдают саму по себе, без РСВ-1, без связи с отчётом за период.

И в межотчетный период? И принимают?
П.С.
Мы раньше так сдавали, потом отказались принимать : только вместе с отчетом!

[elgai]

Сформировал в Spu-Orb корректирующую форму по стажу (только по стажу, доначислений нет) за 4 кв 2013. При тестировании CheckXML выходит ошибка:

***30: Ошибка. Блок <СведенияОкорректировках> №1 код кв.4 г.2013 (С 01.10.2013 ПО 31.12.2013).
При указанном значении 2013 элемента <Год> должен быть указан (иметь отличное от нуля значение) хотя бы один из элементов <СуммаДоначисленныхВзносовНаСтраховую> или <СуммаДоначисленныхВзносовНаНакопительную>. Тем не менее, оба элемента <СуммаДоначисленныхВзносовНаСтраховую> и <СуммаДоначисленныхВзносовНаНакопительную> имеют нулевые значения.

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

Сдают саму по себе, без РСВ-1, без связи с отчётом за период.

[v_i_b]

Это парограмма не доработана в текущей версии или я что-то неправильно делаю? CheckPfr ошибок не выявил.

Судя по политики ПФР надо в основном ориентироватся на CHECKPFR.

[Котофей]

Сформировал в Spu-Orb корректирующую форму по стажу (только по стажу, доначислений нет) за 4 кв 2013. При тестировании CheckXML выходит ошибка:

***30: Ошибка. Блок <СведенияОкорректировках> №1 код кв.4 г.2013 (С 01.10.2013 ПО 31.12.2013).
При указанном значении 2013 элемента <Год> должен быть указан (иметь отличное от нуля значение) хотя бы один из элементов <СуммаДоначисленныхВзносовНаСтраховую> или <СуммаДоначисленныхВзносовНаНакопительную>. Тем не менее, оба элемента <СуммаДоначисленныхВзносовНаСтраховую> и <СуммаДоначисленныхВзносовНаНакопительную> имеют нулевые значения.

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

[Михаил Иванович]

Сегодня формировал отчёт по новой (очередной) базе. Протестировал файлы CHECKXML от 06.04.2014 (в перечне тестовых программ она идёт как от 07.04.2014). Меня удивило, что этот тест повторяет ошибку CHECKPFR при наличии нескольких периодов по ДОГОВОР. Зачем наступать на те же грабли? Если не указывать последующие записи по договору, то как отреагирует программа, что в последующих месяцах в разделе 6.4., графа 6 будут стоять не нулевые суммы?

[BlackFox]

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

Сегодня разбирался с этой ситуацией. Смоделировал два варианта:

Вариант 1.
Стаж с 1 по 15 февраля - список 2, подкласс 3.1
Стаж с 16 по 28 февраля - список 1, подкласс 3.2
Взносы заплачены по обеим спискам.

Вариант 2.
Стаж с 1 по 15 февраля - список 1, подкласс 3.2
Стаж с 16 по 28 - список 2, подкласс 3.1
Взносы те же самые.

В итоге имеем:
вариант 1 - предупреждение
вариант 2 - ошибка

Хотя в обеих случаях не должно быть ни ошибок, ни предупреждений. Ибо ситуация абсолютно нормальная.

Тексты файлов и сообщений прилагаю.

[Denis_pfr066]

В строках 110-114 нет страховой и накопительной части. И тэги должны отсутствовать.

[Rak]

Тестирование выдало вот такую ошибку:

Нарушена структура блока. Отсутствует обязательный элемент (либо нарушен порядок следования элементов).
Ожидался элемент: ВзносыПоДопТарифу1, ВзносыПоДопТарифу2_18, СтраховыеВзносыОМС.
<ОПСстраховаяЧасть>0.00</ОПСстраховаяЧасть>
30
24

Тест CheckPFR тестирует отчет без ошибок. В файле такая последовательность в строках от 100 до 150 :

<КодСтроки>110</КодСтроки>
<СтраховыеВзносыОПС>1712773.98</СтраховыеВзносыОПС>
<ОПСстраховаяЧасть>0.00</ОПСстраховаяЧасть>
<ОПСнакопительнаяЧасть>0.00</ОПСнакопительнаяЧасть>
<ВзносыПоДопТарифу1>0.00</ВзносыПоДопТарифу1>
<ВзносыПоДопТарифу2_18>0.00</ВзносыПоДопТарифу2_18>
<СтраховыеВзносыОМС>397052.18</СтраховыеВзносыОМС>

В чем м.б. проблема?

[vk65]

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

Взносы считаются нарастающим итогом. Из ст. 15 212-ФЗ:

3. В течение расчетного (отчетного) периода по итогам каждого календарного месяца плательщики страховых взносов производят исчисление ежемесячных обязательных платежей по страховым взносам, исходя из величины выплат и иных вознаграждений, начисленных (осуществленных - для плательщиков страховых взносов - физических лиц) с начала расчетного периода до окончания соответствующего календарного месяца, и тарифов страховых взносов, за вычетом сумм ежемесячных обязательных платежей, исчисленных с начала расчетного периода по предшествующий календарный месяц включительно.

[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коп?
Хотя не исключено, что "+" в первом месяце был бы нивелирован "-" во втором или третьем, все зависит от конкретного предприятия...

[vk65]

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

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

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

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

[Котофей]

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

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

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

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

[vk65]

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

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

[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.
Случайное округление — округление происходит в меньшую или большую сторону в случайном порядке, но с равной вероятностью (может использоваться в статистике).
Чередующееся округление — округление происходит в меньшую или большую сторону поочерёдно.

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

[Котофей]

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

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

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

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